Friday, March 23, 2007

Doug Church on Academic/Industry Collaboration

The great Doug Church gave a keynote at the IGDA Educational SIG at GDC. Here are my notes from his session:

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.