Pre-production and The Cerny Method

Mark Cerny is a designer of video games and former president of Universal Interactive Studios. Currently he runs Cerny Games and works as a consultant for game development studios (sharing his knowledge regarding what people tend to like and what comes off as good gameplay and what will be boring, as well as pacing/difficulty issues). He has worked on the Crash Bandicoot, Jak & Daxter and Ratchet & Clank series, of which the latter two are amongst my favourite series. That's why I hold this guy in such high regard.

Mark has defined a certain "way" (referred to as the Cerny Method) detailing the development process of a game to get the best results. This includes an extensive pre-production phase and lots of open testing. The method is quite focused on the types of games he has worked on (Ratchet & Clank for example) and needs a bit of tweaking if you're trying to implement it on the development cycle of a wildly different genre like sports. Nevertheless it's a very good basis for game development since game development itself doesn't exactly have any rules and is a very creative process. Different developers have wildly different ways of approaching tasks even though there are many similarities too. Take, for example, the fact that some developers have cola machines and bean bags in the working areas of the office whilst others might have tightly packed cubicles and a separate "game room" for R&R.

I'm going to go through the different phases and main concepts of the Cerny Method and give my own opinions on them as well as write what I know about the game design and development process.

A basic game design process from start to finish goes as follows:

Basic concept -> Design documents -> Technology documents -> Build the technology -> Build the game

- Pre-production -

The Cerny Method focuses heavily on the pre-production phase during which you create your basic game flow and a short working section of the game itself. The production of the game itself (if it ever gets to that stage) is more about creating assets, taking those assets and implementing them into the world(s) within the game and tweaking gameplay.

Before you totally commit to a project it's important to figure out what it really is you want to do. That's a given. 20 years ago 1 person could make a game, nowadays games can have near 1000 people working on it. During pre-production the publisher would already be paying for you to create something nice. Ideally. But even before that you need an idea that's interesting so the publisher puts any money into play. During pre-production you're trying to prove to the publisher that your game is worth making. Or if you're working from your own funds it depends a lot on how the studio is structured, do you have other people working on another game, possibly a sequel to another successful franchise already, or how do you handle all the other people without a real job at the time. Pre-production is a smaller scale process that involves only a few people really. Some coders, artists and designers (the core team, most possibly team leaders). Not even sound and music is necessary. You're trying to make the First Playable.

- First Playable -

The First Playable is something that shows you know what you're doing basically. It showcases your game. 1 level. This is where the Cerny Method differs a bit from some genres because you can't exactly have 1 "level" in an ice hockey game. While trying to get to this goal you are keeping the publisher informed of all your choices because they're the ones who, in the end, will either green-light or cancel the entire project. If they choose to cancel the project generally they keep the rights to the game as well as all assets you've created but they're not allowed to further use them to create their own game. Why? Because they've paid for everything up to now. You can however buy the game and rights back from them. The price comes from the amount of money + time they spent on your studio. The publisher is still left at a disadvantage because they're paying for it and don't know when your project will be ready. They however have an accurate budget and the costs aren't very high yet, plus they're running other projects most likely at the same time, so it's not like the end of the world for them if your game doesn't work out. For you it might be though because your future work depends on that green light.

During pre-production your core team will be creating prototypes and testing different things. You can try anything out, like jump height, character movement speeds, etc. during this phase but once you are past pre-production all of the core mechanics must be set in stone. Changes have been made in some games later on and some games have even failed because of them. Adding in a big feature very late in development will most likely cause problems with previous mechanics and how the game is played, but not always. A well planned (designed) game has a much bigger chance of succeeding in the market than one that is designed while making it. The Cerny Method states that around 5 versions (no less than 3) of the game should be made and the 4 first ones discarded. This doesn't mean starting from scratch every time, but finding different ways for the character to move and creating new levels. This way you learn, I agree with that, but starting out with the knowledge that you're going to discard your work isn't a good premise. I would focus on making the character move very well around an empty level. Make the character responsive and pace it well so that running speed is good and jumping doesn't slow down the pace too much (for example) and after that create 5 levels around the speed constraints. Then again sometimes your first level will be the best one like the very first onslaught level ever made for Unreal Tournament 2004, ONS-Torlan by Hourences. Discard anything that doesn't work and possibly re-use good ideas from the discarded ones in new and improved levels. Maybe that's what Mark meant though, I never got a chance to ask him.

The other good thing about pre-production is that you don't have any milestones. You'll need an ending date which might be 3-12 months from the beginning of pre-production but all in all you won't have to worry about timetables too much. A good way to cut back on the time spent in this phase is to use middleware if possible. Create a Total Conversion for one of the Unreal Engine games for example, you can use the same assets in your own engine since file formats are quite easy to manipulate. Depends what kind of game you're creating obviously so check what engines are available. The best way is to create your own engine still but using middleware is an option.

- The 3 Cs -

So, what do you need in order to define your game? Mark says "Character, Camera and Control" (the 3 Cs).

My interpretation is that by Character he means an interesting premise (story and the people who inhabit your world) as well as something that sticks your game out above the rest. Something that gives your game character, like the time manipulation element in Max Payne, the environment in Bioshock or the realistic free sandbox world in GTA.

By camera I'm quite sure he is referring simply to what you see because in many games the camera is still a problem and can twist and turn into weird unexpected angles. It's a hard one to program and sticking to preset camera angles alleviates that problem but causes other restrictions. Resident Evil 1 was annoying with its static cameras because you couldn't see something your character saw and enemies could move from screen to screen as if the world was real unlike the enemies in Ninja Gaiden: Dragon Sword (analysed below). God of War has another solution for the camera, it moves along predefined paths and thus doesn't mess up whilst still giving the game a more dynamic feel as opposed to static cameras. It works very well for a game like that but a choice like this has to be made very early in development because with a predefined camera you don't need to draw certain walls and a world built around predefined camera paths might look boring, simple and "uneven" if given a free-look camera all of a sudden. There's always an exception to the rule though since Metal Gear Solid 3: Subsistence gave a freely controlled to the player and it worked out fine.

Control means exactly what I explained a bit higher up on this post. This is something I would focus on a lot. You want your character to move fluidly and at a consistent pace. You pretty much determine the speed of your game by this because this is what the player will see most of the time. Control also would refer to how you interact with the world and what affects your character. Menus and inventories aren't that important yet.

Apart from these 3 Cs you want to have extensive chats with your art lead about how your game should look. The look is the first thing that gets people excited and personally I would rank it among the top 3 requirements for any game (Mood - looks and sounds good, Control - fun to play, FPS - good technology) but that's another story. Remember the first pictures you saw of Bioshock? What about GTAIV? On second though GTAIV might not be a good example because a lot of the excitement came from the previous installations of the game. Bioshock was a bit of System Shock too though but still vastly different. You want your game (and especially First Playable level(s)) to look amazing.

Your key technologies should be in place after the pre-production phase is over. These are things like lighting, AI, pathfinding and terrain drawing algorithms for inside and/or outside areas. This sounds like a lot but you can always tweak them further later. The basic concepts should be in place because you want your game to be in a fairly working condition for your First Playable. Remember holistic design if your game is an open world like in GTA, Crackdown or Saints Row. This means that with so many different game mechanics sort of "colliding" with one another, you need to be aware how all the little bits and pieces will affect each other and create a whole. For the First Playable on a GTA-type of sandbox game, you could simply have a small area of your town playable as well a car to drive around in.

- Vital Chaos -

In a nutshell what pre-production is is, as Mark puts it, vital chaos. What he means is messing around with all sorts of ideas and trying things out now because later on you should be generating content for your game instead of playing around with the basic building blocks which you're basing the rest of the game on. Try different jump heights, try different graphics, and so on.

- End of Pre-production, First Playable & Macro Design -

At the end of pre-production you will have completed 2 things. The First Playable and the game's Macro Design.

The First Playable, as mentioned above, is a level (or segment) of your game that is good enough to be released to the public. Obviously it never will be released because it's a rough cut from within your game and makes no sense on its own really when the story is taken into consideration. It's meant to be a showcase of what your game is about so your publisher will green light your project and accept to fund it.

The First Playable includes: player and enemy behaviour, items, missions/tasks/quests, NPCs, basic technology (like I said above, you can tweak this later), the art direction your game will take, variety, scope of the game, and so on. Basically you will know exactly how your game will work. "You" meaning the lead designer and possibly the entire core team working on pre-production.

Macro Design refers to simple documentation about your work. It's good to document things you do but Mark seems to prefer having as little on paper as required. I see his view on this as well but documenting all your ideas helps you evolve and advance on those ideas and thus end up with the best ones in the end. People don't remember everything. The simplest way is to have a mobile phone with a recording capability and as a game designer always record your ideas. A PDA is even better (because of the touch screen you can write on) if you're on the bus and don't want to be seen speaking to yourself (even in the age of hands-free telecommunication) or you don't want to let others around you hear your "best idea ever".

5 pages is enough during pre-production for a Macro Design document. Apart from that you could have notes of whatever you want to keep in mind. Post-its work too and sticking the newest ones on your monitor is something I've seen many developers do. The Macro Design document however, is quite short and contains: character information and move set (what (s)he can do), simple story outline, game mechanics (are there vehicles, guns, ..), level/world structure, level/world content (what do you do?), overarching structure (how does everything work together? bosses, missions,..), and a Macro Chart. Your Macro Chart will list everything that the game will hold, all the game mechanics, etc. This is like an Excel chart detailing the flow of your game, like how levels are structured, what NPCs you meet and where, and so on. Notice though that in Bioshock for example, a lot of the game's world story elements were implemented later on during the design phase. The Macro Design document doesn't have to be restricted to 5 pages. You can go over if you have concept art (always helps) or other non-linear attributes that need explaining (like if you're working on an RPG) for example. The idea is to keep it short though. Don't go into too much detail.

- Cancelling Projects -

Here's the hard part then. Mark says that if at any phase during pre-production you notice that the game project isn't working out and the game lacks features that make it truly fun and unique, you should scrap the project. I find this quite hard to accept though. If you've decided on going ahead with some idea and gotten this far it might be extremely hard to cancel something. I'm not saying it can't happen but a lack of passion in the first place might get you caught up in a situation like this. Therefore make sure you, as the lead designer, and the rest of the core team really feel like this is a game you all want to make. When coming up with ideas as to what game you want to work on next (and possibly take into pre-production) make sure your ideas are current. See what's been posted on Kotaku during the last 10 minutes. What are the current trends. Study other games and how they've tackled some obstacle. You see this in games a lot, smoke effects look the same in some games, even core mechanics have been copied (Diablo -> Hellgate: London, some of the same development team or Knights of The Old Republic -> Mass Effect, same company). Sometimes you'll notice during pre-production or full on development that someone else is working on a game very similar to yours. Don't be let down and don't let this affect your choice to cancel the project! Unless your game isn't working out anyway. 2 games that are based around the same themes will always end up being vastly different because so many people have their own little inputs in both projects. David Jaffe spoke about this once referring to a case when he felt discouraged by finding out that some other developer was making a game based on the same themes that he was. The point is that cancelling a project can be something you don't even see as an option because of all the time spent on the game and the emotional value, but keep a clear head and always make sure you are doing something worth your player's time. We're here to make money too.

- After Getting The Green Light -

So, when you get green-lighted, what happens?

You begin full development of the game. Your core mechanics are all in place but everything needs to be fine-tuned and tweaked to be better and all the actual content has to be made. The story needs to be fleshed out from the outline you had set. During pre-production you might have, for example, determined that killing the stone golem boss gives your character the ability to turn into stone, during actual development you might add a conversation your character has with the stone golem before fighting him as well as other NPCs thanking you for killing the golem because he used to terrorize their cats during the night. Remember to also tweak the difficulty because this is something that's hard to do before the full game starts to come into place. Do you want guide posts (optional) or on-screen tutorials (compulsory) helping the player?

You also focus on the Micro Design. Take your Macro Chart and for every concept or line of text/Excel cell there, write a detailed description. You need to explain what your game really is about. Write character/world/game flow definition documents, and technical specifications for your game. Don't worry though, the more technical documents are handled by the technology lead generally. This is where Mark suggests writing more, and I agree that there will be quite a few documents (or pages in a document, depending how you want to format it), just try to keep it simple and easy to understand if a new person is brought in on the project because they need to know where to find the information you've agreed on with the development leads a year ago. Documents are also extremely useful to simply keep track of things in, you know who said what. Print them out or have them on the company Intranet, doesn't really matter. You can even colour-code documents by printing them on differently coloured paper so you know which one you're talking about in meetings when someone takes out the blue one.

- Testing -

Finally, I'll mention testing because the Method lists this as something quite important. I agree. This is referring to gameplay testing and not searching for bugs or compatibility issues. It's hard to know what the public sees as hard when you've been involved in your own game from the start. Someone might find the character movement to be too clumsy to get over a box in the game world. You're not making a game only for yourself, you're making something that the largest amount of people possible will be interested in.

Gameplay testing should be done as early as possible and obviously in-house. You can't start sending your game files to anyone. No amount of DRM will protect your game enough and alpha versions have leaked of many popular games. The higher profile the release the better care you need to take.

Mark says to test your game when you're 1/3rd done, which is quite early. This helps programmers to keep their code clean as well because you don't want bugs to appear and if they do you want to eliminate them fast. It's not cool if your game crashes when you've just called in 10 people from the street to test it. Your game will not represent its final state but you'll know how people see it and what might need changing. The core mechanics need to be in place of course but things like difficulty and level design can be changed quite drastically at this stage. Test your game 2-5 times during production. It's easy to get students from a nearby school for example. Just put up an announcement on their bulletin board and you will without a doubt have at least 5-10 interested people. They don't need to be paid anything because it's exciting enough to see something the rest of the world will only see maybe 1-2 years later. Make sure they sign some papers though so none of the information leaks and if some story element contains a big plot twist you don't need to show it, it's mostly about testing playability anyway. Watch them play and see where they get stuck, how long it takes to complete a level, where they die, who died and does the player have any experience with these types of games from the past. Also, try to get a wide variety of testers, not just fans of your game's genre. You want a broad look. However, people who play action games will mostly buy your game so test with your focus audience too.

The rest of it is production which involves lots of crunch time, tough milestones and the publisher making sure they're getting their money's worth. That's another story though and because there aren't any "rules" as to how you develop an entertainment product like a game you can do it a number of ways. Team communication, a good Intranet, good SCM tools..

Even though games are a creative art (yes, games are art) it can be controlled to an extent to make the process clearer. Imagine if you're in a band and actually found a formulae to make hit songs. This is basically what the Cerny Method tries to do for games. Even though it doesn't guarantee a blockbuster, I'm quite sure having a good battle plan will lead you that much closer to victory. And if that's not enough then contact Mark Cerny at Cerny Games and ask him to come work as a consultant for your game. Although I'm not too sure his services are that cheap, and he might not have time.

The Cerny Method surely has good points but it's not applicable to everything and, as noted, requires quite a bit of fine-tuning for certain projects. Then again with all the talk of the game industry being such a bad place to work (especially in big companies) how can you manage such an extensive pre-production phase? Smaller studios seem happy like Insomniac but the people working for big names such as EA (remember the 'EA Spouse' blog?) might not be. It might be the fact that big companies employ lots of people and if you piss off lots of people, they'll write about it and thus it'll seem like everyone working in the game industry is overworked, tired, pissed off and poor because smaller company employees don't feel the need to write about how "good" their work is. I'm sure lots of small companies have problems too. There's pressure in every line of work and maybe people who work in entertainment thought they'd get off easy because it's.. entertainment. I do not know but I don't give a fuck if I'm seen as the blue-eyed newbie who'll work his ass off for minimum wage, I'll be there and prove that I can be the next Kojima.

Damn that sounded lame. :) At least you can have high goals. Keep truckin'.

I do have a few questions that I'd like answered though:
- Isn't it hard for new developers to find funding (a publisher) in the first place even for the pre-production phase without a lot to show yet?
- What do the rest of your team do when you're in pre-production?
- When do you create the development tools?