William Goldman said of the film industry: “Nobody knows anything.” The games industry, in its cinema envy, is taking that to heart. This is painfully evident when we hear about the tortuous process of production of failed games. Even the successful ones  are painful to make, if one trusts the postmortems of videogames in industry publications.

The leaked information on why Aliens: Colonial Marines is a trainwreck is an example of the kind of unhealthy, stupid practices that are too common in the industry. The moral of the story is that, if there’s anything that budding game developers should learn is basic, healthy production habits: iteration, scoping, scheduling, communicating, and learning what the different relevant aspects of production are. Game curricula are too focused on technical aspects to remember that games are made by humans for humans. (There are many other things I need to complain about game curricula, but I will just focus on this one thing today.)

Making games is hard. Making huge AAA titles involving hundreds of people and where a lot of money is at stake must be a nightmare. The problem is that game development, big or small, still makes very stupid mistakes. Common sense turns out to be the least common of senses in game production.

Gearbox dropped Aliens: Colonial Marines on the lap of TimeGate, who thought they had to complete a game but ended up having to make the game from scratch. It’s one of those situations in which the developer has to deal with somebody else’s mess. TimeGate was in a pickle. As I read through the article, however, I saw how the developers themselves were wringing a thick noose around their own necks with every decision.

The first red flag in the postmortem is that they immediately put some of the blame on the narrative designers, who changed the script and that forced level designers to scrap whole levels. First of all, the fact that they were working on a narrative game should have triggered off all the alarms in production, because content can spiral out of control very soon and very fast. It is also sad that some people call themselves narrative designers if they are only doing writing. Narrative design is a new discipline, which we’re defining as we go, but if there’s something that should be clear by now is that the writers should have worked with the level designers side by side. It does not sound like communication between writing and design was clear either, which is a serious production issue. It is as bad to design a game and then call the writer to stick a story on top of it as to write a script for a game and then ask levels designers to overhaul what they want. Narrative design bridges both writing and design, but it does not seem that it was really happening in spite of people working under that title at the company.

A bigger red flag is when TimeGate compares their work ethic with Gearbox’s: they’re all about shipping, while Gearbox does “work, work, work, iterate, iterate.” The deadline that they were given was surely unrealistic and the amount of work was probably insane, because that’s how the AAA games industry rolls. What I don’t understand is what they mean by “working to ship.” I believe Gearbox also ships games (and pretty successful ones for that matter). The fact that they had limited time does not mean that they did not have room for some iteration. If you don’t iterate you’re not designing a game. In fact, TimeGate should have been iterating, since they said they had to change the game when the script changed. Isn’t that an opportunity to iterate? Did they really scrap their work and start over?

Which takes me to what is probably the pinnacle of dumb practices that was the final undoing of the game. While producing the demo, someone in power told the developer (publishers? external producers?) “Don’t worry about performance, just make it awesome”, which is the kind of vague, meaningless direction that sounds like a knell to any game. (This is why educators must teach our students to communicate sophisticated ideas in a clear, constructive way.) The developer then went on to make an awesome demo which astounded everyone but wasn’t playable, plus it needed the kind of computer they use at NASA instead of the PC that you can buy at the store. This is the complete opposite of a philosophy that aims at “shipping the game.” It seems that it didn’t even occur to them that they had to fit the game in a disk. “Scoping” does not seem to be have been a word in their vocabulary. If you have limited time, you try to figure out how much you can get done, which will still be over-ambitious, then cut, and then cut some more.

Then they had to spend a lot of time shrinking it and re-doing their work (rather than iterating) to be able to ship it somehow. Then, oh surprise, they run out of time, and Sega, the publisher, refused to give them any more time because they had been waiting for their game six years. Their philosophy of “working to ship” then became cobbling together a game and putting the sorry result on a disk.

The sad thing is that the story of Aliens: Colonial Marines is all too common. I know of plenty of successful games that went to similarly dysfunctional production woes. Thing is, nobody seems to learn their lesson, and this keeps happening. Hey, we shipped, so it’s okay.

Of course it’s easy for me to say these things from outside and in hindsight. It’s difficult to see what the problems may be when you’re mired in the middle of production. The games I’ve worked on are way smaller and not as technically complex. But we also worked under insane constraints: 8 1/2 weeks to make a game with students who had not make a game before, and then most of your team would get on a plane and go on with their lives. We also made mistakes, we learned from them, and we tried not to repeat them again. We’re all figuring it out, making games big or small; the difference is how willing we are to be self-critical and to admit we may be wrong.

The Aliens: Colonial Marines fiasco tells us that future game developers, the same that are attending our schools, need to learn basic production practices, from understanding what narrative design means to clear communication, iteration and scoping. Students have the room to make mistakes, and teachers should help them think about what worked and what didn’t, not just give a grade to the final result. Some of us are working really hard to emphasize the human factors in making games. But the whole team needs to know these practices: the publishers and producers seem to be the most at fault here, but the whole team needs to understand these practices. Bad production habits lead to wasted effort and talent, as well as to insane crunch and eventual burnout. As educators, we should teach students not only healthier practices, but also to reflect on the process of game making. Technologies will change a lot really fast, but humans tend to repeat their mistakes.