(Update: I wrote about how the presentation went, and uploaded the slides, in a newer blog post.)

Next week I am giving a presentation on production at ENJMIN, a game development school in Angoulême, France.

I roughly know what I want to talk about and I've been generating a lot of material. I felt I had reached the point where the structure was somewhat clear to me. Sometimes working with physical objects is much more pleasant than using a computer, so I fiddled around with index cards.

You can see the result here:

World's most boring video, I know. Anyway, here's a little more detail on each sub-topic:

Don't waste effort. This is the overriding goal, the takeaway, if you want. Why am I telling you this? So maybe you'll waste less effort.

Games are multi-disciplinary and You don't know what you need to build. These are two central themes I keep referring back to. This is why you need the techniques I am going to present, if you want to waste less effort.

Breaking the baguette. I intend to buy a baguette and a plastic bag and demonstrate this live :). This is me explaining the concept of task dependencies and the critical path, project management concepts that few developers know, but should. And it ties into:

Decouple production chunks. In programming, loose coupling reduces complexity and thus difficulty (of implementation, maintenance, etc.). The same goes for production. Example: Rock Band. Their 3D band rendering is very loosely coupled to their actual gameplay, which I bet makes things easier than a typical 3D game. On the other hand, Uncharted 2, with its super-tight integration of gameplay, graphics and story is all the more admirable when you realize how complex it must have been to make, because a lot of the game is very tightly coupled.

Iterate the right way. There's a couple of rules of thumb we tend to use at work when deciding what to do next, and they're all tied to iterating. Bang for the back, ROI, low-hanging fruit are terms we throw around a lot. Also: do the thing that lets you the learn the most fastest (which works on lots of different scales). And my personal metaphor: walking up a hill is easier than jumping a ravine.

Integration integration integration. Because making games takes many different disciplines, you need to integrate early, and stay integrated, or you'll have people working hard but not towards a common goal. And integration takes more time than you think. Setting the right goals also helps here.

Make your workflows flow. You need two workflows in a game team: the personal workflow, which needs to be fast, and the team workflow, which needs to be robust. This is the central engine of your production: get this right and you can actually build a game. But! responsibility for this is not obviously tied to one discipline, so it often falls between the cracks (an interesting dynamic in itself).

"Bonus rounds", aka stuff I can use to fill time and/or I don't know where to put yet but feel passionate about:

When is a task done? Dedicated to everyone who stayed in the office till 1 AM because a coworker claimed they were 'done' at 5 PM and left.

Testability. Really workflows again, only for testing. Not so much bug reporting and fixing, more being able to test anything at all. Forget this, and your QA people will want to kill you.

Project planning the quick & dirty way. Bonus material. My personal gut feeling / back of the envelope planning method. Great at parties. Start at the end, then do the start, then divide up the middle with some sensible-sounding milestones.

Localization. Again, workflows. If you're not prepared for managing a localization kit and efficiently integrating translations into your game, you will be in a world of pain. I wanted to submit just this for GDC Prime 2011, but my honeymoon interfered with me working on it.

Making 13 games in 1 year. Because that's what we did in our first year at Mi'pu'mi Games, and it was kinda cool even if the games were quite simple DS/DSi titles. And we used some of the techniques I discuss here.

It's a bit heterogenous, as my talks tend to be, but I don't think it's entirely all over the place. I may still split up or rename some of the topics - this is the first draft of the structure.

What do you think? Does this make sense? Is this a nice structure? How would you present this?