If you looked at the rough structure I posted earlier, you will noticed I changed things around a bit. Although this is not the first presentation I’ve done, I feel I learned more from the process. Which is why I like doing presentations.

The slides come with notes but naturally it won’t fully convey everything I said during the presentation.

Update: Right, forgot to mention this. If you were at the presentation, I mentioned two things. First, Andrew Chen’s blog. Read this to see how internet / web thinking can apply to games. Second, Darius Kazemi’s series of articles about networking. Enjoy!

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?

Well, I am happy to announce that about 6 months later, I have finally given the slides a final polish and converted them to an accessible format. It only took me a few hours. I have no idea why I kept pushing it back. Alex Champandard even encouraged me to record the talk afterwards (since I forgot to record it during the conference – d’oh!), but somehow I just never got to it. Speaker’s block? I don’t know. Good thing I am not a ‘pro’ blogger.

This talk may interest you if you are interested in productive game development or being in a leadership position in a game development team.

You can download the slides here (it’s a 1.6 Mb PDF).

Please let me know what you think.

[Writing in games] has to get better, and better, and better, and be more like the best dialogue lines from movies, but it’s done in an interactive, nonlinear system, that — let’s be clear — 99 out of 100 writers don’t even understand how to do, and never will.

So, it’s hard to find the talent, it’s hard to train the talent.

It’s good to keep this in mind.

We are extremely lucky that BioWare is run by two guys who are dedicated to the idea of story, so that’s what they want to do. They’re dedicated to the idea of dialogue and narrative, and that storytelling has to have great, punchy writing.

It’s hard to get the dedication from a [parent] company that’s never done it, to say, “Hey, we’re going to do it.”

[...]

It sounds like, the way you’re describing it, it’s almost more of a challenge in terms of content and commitment rather than actually being a big game design problem. Is that the case?

DE: There are numerous game design problems, but I would not say that they are insurmountable game design problems.

So much in game development, especially classical, ‘core’ game development, is about commitment. It’s about wanting to do it enough, even though it’s hard, and even though it’s not how things were done before. This goes way beyond writing.

Erickson later talks about Bioware’s three month writer training program, which I find very interesting, and how leading a group of writers is like being a magazine editor. Or, as Lee Sheldon would probably say, like being a show runner.

I see every piece of content, every single piece of content at every single stage, and make sure that we’re all keeping to a voice and a tone, the same way a good magazine editor would.

It’s an interesting interview.

Leadership Track:

• Building the Perfect Team
• Leadership Lab
• Death By 1000 Ideas: Managing Designers and Creatives
• Managing Engineers
• Managing Artists and Art Outsourcing for Next-Gen Games
• Communication Breakdown: How to Prevent This on Your Watch
• Caught in the Middle: Managing Staff, Teams and Executives
• How Not To Dine In Hell: Next-Gen Development Without Killing Your Team

Production Track:

• How Not To Schedule A Project
• Agile Implementation
• Something from Nothing
• Working with Publishers as a Developer Producer
• Local Anesthetic: Painless Game Localization
• Cross Discipline Team Collaboration
• Leveraging Outsourcing to Enhance Development
• Dilemmas of the Publisher’s External Producer

Keynotes:

• Ultimate Objectives: Lessons Learned From Building BioWare
• 10 Surprising Ideas for Leaders on the Future of Games

All of the feedback was good so far. I am really too close to the presentation and have no opinion on it. It was a very touchy-feely talk in some ways and I was worried it wouldn’t cohere enough. Luckily I was able to spend some time yesterday with Daniel Miller, a friend who is a great producer and communicator and he helped me improve the structure of the talk.

Now I can enjoy the rest of the conference without stress! Slides will be posted in some form pretty soon – I just need to clean them up for public consumption. Too bad I forgot to record the audio myself, I probably could have done so, bah.

Tell me I’m wrong.

*) Except for my current clients ;)

There are a number of reasons why you might be in this situation:

1. You don’t have the budget for another person on your team.
2. The people making recruitment decisions are not convinced you need a game designer (that’s why I wrote that essay).
3. You were not capable of finding the right person, but you have to keep developing your game. (Bonus points if you had a game designer but he or she left.)
4. You have a game designer, but he or she is not senior enough to really be effective. Kind of a special case, but keep reading anyway.

If you can’t have a full-time game designer on your team, you can still make sure game design happens. What counts is that the job gets done. Having a full-time game designer is typically the best solution for this, but producing a game is all about knowing what your risks are, where to allocate resources (whether that be the team’s, or your own) and how to make the best of situations that are not ideal, because situations are never ideal, and the best is the enemy of the good.

Here’s a very simple breakdown of what a game designer does on a typical game development project:

• Generate the game’s design.
• Maintain the game’s design.
• Implement the game’s design

Let’s look at each in turn:

Generating the game’s design

This usually begins in the concept phase and continues in the preproduction phase. Typically, you start with an initial brief (which rarely comes from the game designer). This might be something like ‘Make a game based on this license’ or ‘Make a casual game that is finished in 4 months or less’ or ‘Make an exciting action game using this setting’. From there, an initial set of features, mechanisms, level concepts, etc. is developed. Hopefully, this initial design will lead to a game that fulfills the brief, is implementable, and is entertaining.

This can be almost completely outsourced, but you should take the following into account:

1. The buy-in from your team can be lower than when you generate the game design in-house. If your team is not too immature, this typically can be dealt with by managing expectations and involving them in the reviews of the game design as it is being produced (this should happen anyway).
2. A game design document is not a perfect blueprint for a game. If you don’t have the author of the game design around during production, there is a risk you’re not building the game that was envisioned, because the design document is not clear enough, and because you can never fully predict what game you’re making in a document. Outsourcing the game design during preproduction effectively means you’re choosing the waterfall model, with all that that implies. A good free-lance designer can compensate to some degree. You can also organize follow-up reviews with the designer during production.

Maintaining the game’s design

Typically, during production, you will find out that parts of the game design document are unclear or don’t work. The more ambitious your project is relative to your capabilities, and the shorter your preproduction phase was, the higher the risk is that this will happen. Additionally, new ideas will come up that need to be considered.

All of the above will lead to changes in the game design document. If you don’t have a full-time game designer, you can still have a game design process. Essentially, it’s a change management process:

1. The need for a change is identified. Normally, this just means someone on the team walks to the game designer and asks a question. When you don’t have a game designer, you can still designate someone to be the contact person for questions about the game design document. This can be the person who owns the game design process (e.g. the producer), but it doesn’t have to be.
2. Possible solutions are generated. A game designer could do this alone or he or she could ask for feedback from the team. Without a game designer, this can be done by a group of people or the entire team. The important thing is to make sure the process doesn’t stall.
3. A decision is made about which solution will be used. This is probably the hardest part. Again, you can use a group (for instance the leads) to discuss the possible solutions. However, it is vital that you have one person making the final decision. This greatly clarifies things, it helps keep the process moving, and it increases the odds that the decisions are made in a consistent manner. Also, this person can then own this process and be accountable for it, which is good. The producer is typically a good candidate to make these decisions. He or she may not have game design sensibility (about which more later), but at least the decisions should take cost and feasibility into account, and the producer’s focus typically generates a certain disinterested pragmatism that helps here.
4. The solution is documented. Finally, the solution must be written down and communicated to the team. This can be done by anyone who is capable of clear expression. Just be sure it gets done consistently.

Make sure people know how to bring up questions or issues regarding the game design. Since you have less game designer time to work with, you can avoid wasting time on trivial questions by funneling the questions through the leads, who hopefully can answer some of them before escalating them into this process.

Additionally, make sure the process keeps running. Try listing all the currently open questions (for instance in a wiki) and handle them on a regular basis. I recommend weekly meetings for this. Make sure people see the process is active.

Implementing the game’s design

By this I mean balancing and tweaking: data needs to be conceived, entered and adjusted. I can’t think of a generic solution for how to do this without a game designer. It really depends on your team. If your game design process described above works well, try partially running it through that. If you have someone on the team who is interested in doing it, have them do it. It might be a gameplay programmer, a level designer or a project manager. Just make sure it gets done.

As with any work delegation: be sure everyone involved knows what is expected. You probably want your project manager to go back to managing the project after tweaking enemy data, so watch out when he shows up for work wearing a black beret. Your lead programmer needs to know how long the gameplay programmer will be entering weapon data. And you should especially be clear about what the outcome of the balancing / tweaking tasks will be. For instance, in a realistic shooter, you probably don’t want shotguns to blow people through walls.

The risks of not having a game designer

It is important to remember that the solutions I’ve described above are essentially crisis management techniques. Assuming a typical industrial approach to making games and a certain team size (say, 10 to 20 people), you may be able to make a decent game despite the lack of a dedicated game designer. However, you should be aware of several risks.

For one, you may not have design capability on your team. Call it talent, skill or awareness: game design is not easy. You can outsource game design to some degree, but you still need a minimum of design sensibility. Also beware that many people think they understand game design, but they really don’t, just like many people think they can write, only they can’t.

Second: Game design tasks may not get done. If there is no clear responsibility for game design, there’s a good chance it won’t happen. Values won’t get tested and tweaked, decisions won’t be documented and communicated. The lack of a game designer is probably not the only problem in your project, so there will be stress and urgency. Under these conditions, people will focus on their own areas of responsibility, because that is so much safer. The worst case occurs when player entertainment is no longer the focus of development. Every feature or asset is ticked off, but nobody cares anymore whether the game is fun. If you find yourself in this situation, you have a tough choice to make:

1. Pull the emergency brake. Force everyone to take a step back, reorient, and refocus. This costs an enormous amount of courage and energy (especially if you’re not the producer) as well as time and money.
2. Finish the project anyway. Sometimes this is the best solution. Your team, your publisher and your players may hate you for it, but at least it’s over and you can try to do better the next time. Finishing the project may ensure there is a next time.
3. Cancel or quit. Some projects can’t be salvaged. Some projects won’t finish. Some organizations won’t improve. Don’t throw good money after bad, or good years of your life after bad ones.

Welcome to the games industry. You just got a look at how those sausages are made. Like I said: it’s a tough choice. Try not to end up in a situation where you have to make it.

Every team and project is different, so what works in one case may not work in another. I could go into way more detail, but this post has already become very long. Still, I hope I’ve given you some ideas for what to do if you don’t have a full-time game designer on your team. Please let me know what you think in the comments.

I added the info on where to get them to my earlier post.

And Al Lowe, creator of Leisure Suit Larry, has posted the game design documents for six of his games on his website. Thanks to Vlummi for sending me this.

I could’ve sworn there was a game design document for a Bubsy game flying around somewhere on the Internet, but I can’t find it.

Know of more ‘real’ game design documents? Please post a comment or send me an email, and I will update this post. Thanks!

Update: Tobi just sent me a few more links – thanks!

The original Doom bible from 1992 is online.

There is a ton of old Atari coin-op documents on Andys Arcade Web Site. These obviously refer to very old games, but it is still very interesting, especially if you are really into Pole Position and Crystal Castles.

Update: I just got some more links from Tobi (thanks again). Radical Entertainment, a very well-organized developer in Canada, is cooperated with the Computer Science department of the University of Calgary for a computer game programming course. As part of the course, they provided various game documents from their titles: game designs, high concept documents and technical game designs for titles such as Dark Angel, The Hulk, etc. They can be found here and here.