Building the Game

The best way to build your game is incrementally. Instead of working a little bit on all the different components of the game, you should try to complete one system before moving on to the next. Work on the most basic and essential systems first, and then build the systems that depend on that system. This allows you to implement a system, test it out, see if it feels right, and only then move on to the next system. That way, if you must change the underlying system to get it to work properly, your subsequent systems can be changed accordingly , before you have gone to the trouble of implementing them. It can often lead to disaster when you have a number of programmers concurrently working on coding up a variety of systems that work together. If one system has to change, other systems may need to be radically reworked. Better to build a solid foundation before trying to build on top of it. Programmers often enjoy working on their own isolated part of the code without fully considering how it will have to interface with the rest of the project. It is important for your programming team to be constantly focused on the big picture of making the game playable and fun.

Core Technology

Of course, all computer games rely on an underlying technology that has very little to do with the gameplay, usually referred to as the game s engine. Certainly you need to make sure that this underlying technology functions at a certain level before any work can be done on the gameplay. However, you do not need the engine to be perfect or feature complete before you can start building your prototype. Indeed, on a project with a cutting-edge engine, waiting until the engine is truly finished may mean it is too late to spend enough time refining the game itself. The peril of working with unknown technology is designing around projections of the capabilities of the technology. If you design your game thinking you will be able to have ten enemies on the screen at once and your engine turns out to be able to handle only three, you will need to radically alter your design to accommodate this restriction. It should be no surprise that the best-designed games are often ones that did not use the most cutting-edge technology available when they were released.

If the technology is simply not ready, I know a number of game designers who start off prototyping their game using technology from a previous project. It is rare that technology will actually make or break a game design, though it may make or break the game itself. But technology, as unpredictable as it may sometimes be, is still more of a known quantity than game design, so it makes sense not to worry about it when you are first prototyping your game. Since the first few areas you create should probably be thrown away later anyway, it is not that wasteful to get them working using a technology that you will eventually throw away as well.

Licensing technology can be a tremendous boon to game development, and is becoming increasingly common. Pictured here: the oft-licensed Unreal engine being used in Unreal Tournament 2004 .

In recent years engine licensing has become much more common in the industry. This takes the form of using technology from a specific game such as Half-Life or Unreal or from a technology-only company that creates more robust engines designed to work for a variety of projects on a variety of platforms; examples include Criterion s Renderware and NDL s Gamebryo. The proliferation of licensed engines means that the majority of projects no longer need to wait for their technology to be built and more and more game developers have the luxury of starting out knowing what they will and will not be able to accomplish technically.

Incremental Steps

Once your technology is to a point where you can start developing the gameplay as I mentioned earlier, try to break down the game design into the most fundamental tasks that need to be accomplished and then the tasks that build on those. For example, suppose you are building an action game in which players navigate a humanoid character around the game-world, fighting insurance agents with a flyswatter while collecting kiwi fruits. Getting the player s navigation system working is a logical first task to tackle. First, get the character moving forward and backward and turning, allowing for basic navigation of the world. Work on this movement until it feels pretty good, until you find yourself enjoying playing the game in this simple, navigation-only way. Now you can build on that by adding more movement options, such as strafing, crouching , and jumping. As you add each new movement type, make sure that it does not break any of the previous types of movement and that they all work well together. Only once that is firmly in place should you try adding the ability for players to use the flyswatter. With the flyswatter fun to use, at least in some limited way, it makes sense to add the insurance agents into the game. The AI functionality can be broken down into building blocks just like the players movement was. First, get the AI agents in the world so that players can whack them with the flyswatter. Next, get the agents moving around the game-world before finally adding the ability for them to do their audit or excessive paperwork attack. Finally, you can add the kiwis to the world and the ability for players to pick them up and launch them with their flyswatter. What is essential in this step-by-step process is that at each step along the way the game is still playable and fun. When you add something to the game that breaks a previous portion or simply makes it less fun, you must address this problem immediately. Now is the time to alter your design as necessary, before the game swings into full production.

Throughout the project s development, I think it is important to always keep a version-of your game playable. You should get your game playable in some primitive form as soon as possible, ideally from day one, and keep it that way until you ship. Often programming teams will go for a long time coding up various pieces of the game without having a functional version that someone can sit down and play. It is very easy to lose sight of your gameplay goals when your game languishes in an unplayable state for much of the time. Certainly the game can be broken in many ways, with various components that do not yet work as they are supposed to and with placeholder art used in many locations. But as long as you always have a playable game, team members are able to pick it up and play it, and see what they are working on and how it impacts the game. And if anything added or changed makes this playable version of the game less fun, you can immediately discover this problem and rectify it.

A Fully Functional Area

Once you have many of the elements of your game mechanics working and you are happy with them, the next step is to make an entire section of the game that functions just like you want it to play in the final game. In many game genres this means one particular level of the game. You may think you have all of the components of your gameplay functional, but once you actually try to make an entire area playable you will quickly discover what you forgot to implement or failed to anticipate. Concentrate on getting this one level as close to a final state as possible before moving on to the creation of other levels. If you are observant you will learn many lessons about how level design must work for your particular game through the creation of this one level, lessons that will help to eliminate the element of guesswork from the creation of the other levels in the game. Once you are done with this level, it will no longer be the best you can do; you will have learned a lot, and subsequent levels you create will be better planned from the beginning. Though you do not need to throw away this prototype level yet, keep in mind that you should probably scrap it before the game ships.

The first network level made for Damage Incorporated , pictured here, was also the worst one in the game. It would have been better to scrap it and construct a new one.

One example of this is from the development of my game Damage Incorporated . The very first level I created for the single-player game was done before I fully understood the game mechanics or the level creation tools I would be using. As a result it was far from fun to play and was quickly thrown away. The next level I made, though certainly not the best in the game, was good enough to make the final cut. For this level, I had deliberately picked a map from the middle of the game, so that it would not be the very first content players would see since I knew my mapmaking ability would improve after I had a few more under my belt. It is often a good idea to start developing your content from the middle of the game. Early parts of the game need to be at the highest level of quality possible, so you want them to represent your more seasoned efforts, while levels at the end of the game will often tend to be more atypical and hence will not represent the regular gameplay that you want to have working first.

Damage Incorporated also included death-match style multi-player, which used a completely different set of levels. Due to time constraints, I spent significantly less time balancing the network play than I would have liked . In particular, the first level I created for the network game, My Mind is Numb, My Throat is Dry, ended up not being much fun to play. It had a number of cool areas but they did not flow together very well and a number of sections in the level were unfair and unbalanced death traps. One of my playtesters even suggested it would be best to throw it away and start a new level from scratch. Unfortunately, I did not have the time to make a replacement and it ended up shipping with the game. Fortunately there were seven other network levels that were significantly more fun to play. Nonetheless, it would have been better if I had completely scrapped my first attempt at a network level and made a new one instead.

On The Suffering , the first level we built was the first level of the game. Interestingly, it ended up shipping in a formfairly close to how it was originally planned, and was one of our strongest levels. In part this was because we were a fairly experienced team working with a relatively known gameplay mechanic (a shooter). An equal part of the level s success was luck. Though it succeeded from a game design standpoint, from a technological standpoint that first level was built in such a way that it was a nightmare for level designers to edit and constantly pushed the limits of our technology. It was also one of the more complex levels in the game, with the player able to return to it later in the game-flow, thus making it contain double the amount of logic found in most levels. Because of the lessons learned from that level, subsequent levels were far more conservative. Though building the first level first worked out creatively in the case of The Suffering , the many problems we faced with it from a production standpoint demonstrate the problems with building the first level first.

Something you must be conscious of as you are building the first fully playable section-of your game is how difficult the game is to play. Often difficulty can be adjusted and tweaked later in the development process, during playtesting and balancing. However, games also have a fundamental difficulty, which is more intrinsic to their nature and which cannot be easily adjusted late in the development cycle. As you are working on getting your gameplay prototype working, try to look at it honestly in terms of how difficult it will be for novice players to get into. Bring in some friends or coworkers and have them play the game. Observe how easily they manage to pick up the controls and mechanics. It is much simpler to make a game harder than to make it easier. If you find that your game is turning out to be harder to play than you had hoped, now is the time to alter the game design in order to make the game easier to play, before it is too late. I encountered an instance of this problem in Centipede 3D , a game that was far more difficult than we had hoped when it shipped. This was in part because it was based on a coin-op arcade game that was designed to kill the player within four minutes of play, and partly because we developers had played the game so much it did not seem difficult to us. By the time we realized the game was too hard it was too close to shipping to fix it. Because of the game s simple mechanics (the player and her adversaries all are killed by a single hit from adversaries) there was little that could be easily tweaked to make the game easier, short of redesigning the way the AI agents worked. If we had identified our difficulty problem earlier, we could have made fundamental changes to the game to make it easier to play.

Going Through Changes

A big part of the organic process of game design is being able to throw away your own work and, potentially , that of the rest of your team. This includes art, code, levels, and even general design itself; all of the game s content may need to change as your gameplay evolves. A particular asset may not be flawed in and of itself, but if it does not gel properly with the way the gameplay is working out, you may need to abandon that asset and start from scratch. Many developers are unwilling to do this, and it shows in their games. Either their games are shackled to an initial design document that turned out not to work as well in practice as it did in theory, or their games retain a hodgepodge of components from before their direction was finalized. Once a designer decides that the game s direction needs to change, all of the assets of the game must be assessed to see if they can fit with that new direction. If they cannot, they must be reworked or remade.

As I have discussed, Centipede 3D changed course significantly in the middle of development, which caused us to throw away a large amount of work. Fortunately, no one on the team was unhappy to do so, since we all realized it was in the best interests of the project. With other projects I have worked on, I have been more stubborn and ignored the pleadings of coworkers and friends when they said something needed to be reworked or changed. I was reluctant to throw away perfectly good work, even though it no longer fit with the game. Thus I can say from my own experience that sometimes the first step in fixing the problems with your game design is admitting that you have a problem.

Of course, you have to be careful not to go too far in the other direction by discarding -usable content. As you work on a project, you are likely to become overly familiar with some of the content you have created, and familiarity can breed contempt. For example, after working with a level for a long time, a designer is likely to become sick of looking at the same geometry day after day. The designer may then feel the need to rework that level, not because it really needs it, but simply because it will be something new. This is wasted effort, since for first-time players, the level will be new and exciting. Changing your game s content just for the sake of changing it can lead to extra debugging time, delays in shipping your project, and general frustration for team members who do not know why perfectly good work is being thrown away and redone.

First impressions are very important, especially in game design. Always try to remember how you first felt when you played a level or tried to pull off a particular move. Was it too hard or too easy? Was it intuitive or confusing? Another big problem with working on a project for a long time is that the designers can grow accustomed to flaws in the design. Maybe the controls are unintuitive or a particular enemy attacks players in an arbitrary and unfair way. As they play the game repeatedly, designers will learn to overcome and avoid these problems in the game design, giving them the false impression that nothing is wrong with the game. Playtesting is an essential tool for revealing the weaknesses in the game design that the development team has grown accustomed to, as I discuss in Chapter 25, Playtesting. However, before you get to the playtesting stage, try to always remember your first impression of a particular aspect of the game. It may even be appropriate to take notes when you first play a mechanic or section of the game; do not assume you will remember your impressions later. You may not fix everything in these notes right away, but for problems you keep in the back of your mind as needing improvement in the future, the notes will prove invaluable. As you near the end of development, ask yourself if the problems you saw back when you first played the game have been fixed or if they are still present, creating frustration for others who experience the game for the first time. Whenever possible, even if you do take notes, it is best to fix these problems as soon as you observe them because over time you are likely to forgive the game s subtler problems.