Research:
- The things the industry wants done, it’s doing already.
- The things the industry doesn’t know it needs… well…
- There is no pattern of discovery in gameplay, i.e. no way to build on previous work. Game AI is in a similar state. (Graphics and Physics do have a pattern of discovery; that’s what SIGGRAPH is for.)
- There is no design publishing culture, and no design or game-analysis critical vocabulary. We’re stuck describing game mechanics as “it’s like this other game”.
- Not much “software publishing” culture at universities.
- Ideally, it would be good to enable undirected research in the Academy.
Sharing Tools/Engines:
- Academics are always asking to use industry game engines to help with their work.
- Industry doesn’t want to inflict their barely-working engine on poor unsuspecting academics. (Engines are usually coupled with the team and processes that built them; just handing an engine to someone else won’t be much help.)
- Also, some companies treat their engine as IP.
- Memorable quote: “If someone stole all the code from Electronic Arts, it would probably hurt them more than help them.”
Knowledge Transfer:
- The people in the industry didn’t learn from textbooks.
- The industry is guild/apprentice like. No shared context, philosophy or vocabulary.
- When an academic tries to approach someone in industry, the response has more to do with timing than anything else: a developer under crunch won’t respond to your emails even if they’d really like to help you.
- The industry has a hard time with long-term commitment. The Academy can’t easily promise specifics or results by a given date. This makes it hard for the industry to fund formal academic research.
- Also, developers are skeptical of formal training, while academics are skeptical of the academic value of games. (Hopefully both of these will change in the future.)
What Next?
- Students are the key stakeholders in everything; put them first.
- More industry/academics working together; for now this is limited to 1:1 collaborations.
- Universities must understand that a game-focused curriculum is not just an interesting backdrop for the “real” education, or a diversion from it; game development courses are an invitation into a community and a chance to choose a future.
- Use iterative processes on different ways to collaborate:
- Lightweight participation is easy. That’s what we do now. We need more 1:1 successes until we get some critical mass.
- Bidirectional placement! Can a developer teach a course in their spare time (or take a year off to do so full-time)? Can a professor work in industry during their sabbatical year?
- Developers need to give academics more access to their efforts, so that good practice can be studied and documented.
- More student group projects! (Amusing possibility: each year’s crop of students must not only create their own game project, but also support the previous team’s software.)
- We need formalized grammar and vocabulary, but it’s uncertain where this will come from. Previous tries from academia were forced/mandated and didn’t work. Not coming from industry, either.
- Overall: we need energy, motivation, mutual respect, and people who understand both sides… like today’s students!
- Both sides need to balance reality with idealism.
Q: How valuable is it to teach students methodologies (e.g. agile development, time estimation)?
A: Specifics are not as important as the experience of trying – and understanding that game development is hard and can go horribly wrong!
Q: How can academics study the industry when it’s so secretive?
A: Indie studios may be more willing to open their doors. Or, cultivate relationships with many individual developers, and contact someone who just shipped a successful game and has some pull in their organization.
No comments:
Post a Comment