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.
Vagrant Cursor 
Is there a program or path to working in Narrative Design? I have a good friend who writes amazing D&D modules, and is a big gamer. I think he would be amazing at it, but how does one get a job or experience in that field?
We’re still figuring out what narrative design is as a discipline, so we really have to make our own path. The problem is making the rest of the disciplines in game development, starting with production, to understand the importance of narrative in games, that it is a production challenge, and that narrative is not only the cutscenes.
A portfolio of D&D modules is a great start; being a literate gamer helps, although the big thing is having experience implementing them as videogames. Expanding one’s portfolio by making RPG modules (e.g. in Skyrim Toolset) may open up a few doors in the industry; working with others in making those mods and proving that you can work and communicate with others certainly gives an advantage over most other people.
I agree with this! I doubt we have it perfected yet, but ITU’s “Game Development” course has this as its goal (though he’s not here anymore, Alessandro Canossa largely set up this emphasis). Students make games over the course of a semester in 6-8-person teams, but the emphasis of the course is on the mechanics of working within a team to make the game, not so much the end result. A big focus is on production pipelines and communication, e.g. when you “make something” (say a 3d asset), who did you get information from in doing so (a concept artist?), who do you give it to (a texture artist? a programmer?), and are you taking into account possible contingencies (e.g. how your assets fit into the design on the one hand; how your assets may cause technical problems for the programmers on the other hand, or how they might cause artistic problems for the texture artists on the third).
So, they’re graded mostly on this process and communication: what was planned, how did plans change during the production, risk-assessment, contingency plans, establishing and being aware of pipelines and their relationship to the rest of the team and the overall production, etc. In terms of formalities, we do this by having them keep a development diary during the semester, which they then have to edit down into a 5-6-page development report summarizing the overall production and their role in it, split into pre-production, production, and polishing phases. Grades are weighted more heavily towards good planning, good communication, and good reflection on the process (mistakes are okay if diagnosed), than on the quality of the final game. Although really good final games perhaps are some evidence of a team that successfully worked together.
Clara, in your own projects… do the students end up working through into their spare time? I’m just wondering that students like nothing better than to dedicate themselves to creative projects like this and it’s easy to fall into that mindset of “my work is my life!” or “don’t worry, this is just for this project” while unwittingly setting yourself up for the future.
Students do want to work on their spare time, yes. They would also try to crunch in secret, but the version control server would give them away. As an instructor and manager, my job was spotting off-hours work and address it. The immediate consequence of after hours work is that they are working on their own and not communicating with the rest of the team, giving opportunity to duplicated efforts or working on wrong assumptions. Late nights and tiredness are greenhouses for bugs and sloppy work too.
My way to address it was explaining these things to the team to prevent off-site work, and checking if we had to cut features immediately. The other part of the job is to warn students about doing certain things that would be a time-sink or produce errors (e.g. tools are your friends!).
What I learned in the last couple of games was that, at times, crunching is necessary; if this is the case, it has to be accounted for, scoped, and everyone has to be in the room working together. In the end, it all comes down to knowing how much you can get done that is still good quality, and cut features as much as you can without betraying the core vision of the game. I’m still figuring out game production like everyone else, but I try to learn from game to game and teach that to students. The industry does not have that kind of knowledge legacy.