Game Design: Theory & Practice- P10 pps

Chapter 13 Getting the Gameplay Working “Those who wish to be must put aside the alienation, get on with the fascination, the real relation, the underlying theme.” — Neil Peart 248 TEAMFLY Team-Fly ® H ollywood has a system. It is a well-known system with a well-defined goal, where the largest unknown is “where is the money coming from?” not “how will we ever make this film?” Hollywood producers and talent know how to go from a treatment to a script, through multiple revisions of that script, and then how to bring together the personnel that will make that script into a film, on time and on budget (usually). Hollywood as a whole has much less of a handle on whether the final film will be any good or not, but they do at least know how to get the film made. Seldom does a film already in production have its script completely rewritten, its personnel trimmed, or more people added willy-nilly to its cast and crew. Customarily, films are completed months and months before they are sched - uled to be released. Granted, sometimes the film may never make it beyond the script stage or, once completed, may not get released as originally intended. But, overall, Hollywood has an efficient system for creating films. On the other hand, computer game developers have no such system. The devel- opment of a game design is a chaotic, unpredictable process filled with problems not even the most experienced producer, designer, or programmer can foresee. Cus- tomarily, development on computer games continues until the absolute last possible second, with changes made right up to the time the gold master disc is shipped to the duplicators. For PC games, usually a patch follows shortly thereafter, since the game was never properly finished in the first place. Why is computer game devel- opment so unpredictable while film production is so predictable? Granted, Hollywood has been making movies for a lot longer than the computer game industry has been making games, which gives them a leg up. But beyond that, Hollywood is making a much more predictable product. Different movies may have unique stories and characters, and may even use a variation on cinematic tech - niques, but a lot of film-making is a known quantity. Original games, on the other hand, are a totally new animal every time. Part of the problem is the shifting technology targets, where programmers must learn about new consoles, operating systems, and 3D accelerator cards for each project, and the fact that so many games feel the need to have a cutting-edge graphics engine. But purely from a design standpoint, a truly original game is far more unique compared with other contemporary games than a movie is from other films being made at the same time. Consider games like Civilization, The Sims,orDoom. The gameplay contained in these games was radically different from anything that came before them. Granted, many games are far less experimental and innovative than the games I just listed, and games that have followed more of a formula have had a much better success rate in terms of coming out on time and on budget. This includes titles such as the Infocom adventure games, the Sierra adventure titles, the annual revisions of sports games, or the new versions of arcade driving games. However, these are games which, though perhaps including new content in terms of Chapter 13: Getting the Gameplay Working 249 new stories and graphics, offer gameplay that is very much the same as the previous year’s offerings. When a game tries to implement a new form of gameplay, even if it is only a variation on a proven theme, all hope of predictability in its develop- ment is thrown to the four winds. Only really good designers have any hope of predicting what is going to be fun or not in a game, and even the most experienced designers will tell you that they use a lot of prototyping, experimentation, and general floundering around until they come up with the gameplay they want. These talented veteran designers do not have crystal balls; they only have an improved chance of anticipating what will make for compelling gameplay. They do not truly “know” more than anyone else. The closest thing game development has to a reliable system for developing an original game is to get some small part of the gameplay working first, before mov - ing ahead to build the rest of the game. This may be called a prototype, a demo, a proof-of-concept, a level, or simply the current build of the game. This is not merely a demo to show off the game’s technology. Instead, it is something that shows off the game’s gameplay, which includes all of the features described in the game’s focus, as discussed in Chapter 5. This demo should be something any mem - ber of the development team can pick up, play, and say, “Yes, this is fun, I want to play this.” By concentrating on getting a small piece of the game fully functional and enjoyable, the developer can get a much better sense of whether the final game is going to be any fun or not. If the gameplay just does not turn out as anticipated, the prototype provides an early enough warning that the game needs to either be redirected in a more promising direction or, in the worst cases, aborted entirely. 250 Chapter 13: Getting the Gameplay Working Doom offered gameplay so different from any game that came before it that the game’s development was something of a bold experiment. The Organic Process In the games I work on, I prefer to keep the development process as organic as pos - sible and I try not to plan anything out too thoroughly. This may be the opposite of the approach many development studios prefer, but I find it to be the most effective method for developing the best game possible. Due to the highly unpredictable nature of game design, which I discussed above, a more organic process leaves me room and time to experiment with how the gameplay will work. Instead of writing a mammoth document, I can first try to get some portion of the game to be fun before I start adding detail and length to the game. Adding too much content to the game too early can be very wasteful, if not actually restrictive. This obtrusive detail can take the form of an elaborate design document, a script for the game’s dialog, detailed maps of the various areas the player will encounter, or even fully built lev - els for the game. It makes no sense whatsoever to create these elements of the game until you have a firm grasp on what the gameplay will be, and have a working pro- totype that proves the gameplay to be fun. Too Much Too Soon The problem with creating scripts, documents, or levels without a prototype is that these assets will make assumptions about how the gameplay will function, assump- tions which may turn out to be incorrect once the gameplay is actually functional. If a designer builds an elaborate game design on principles which turn out to be flawed, that entire game design will probably need to be reworked or, more likely, thrown away. But if people have devoted large amounts of time to creating these flawed assets, they are going to be understandably reluctant to throw them away. If a designer gets too attached to those ideas, even if they later prove to be unwork - able, he may try to cling to them. After all, a lot of work went into planning the game in advance with a long design document, how can it all just be thrown away? Cannot the assets be reworked to be usable? If you are not bold enough to throw away your inappropriate content, in the end you run the risk of producing a game that is patched together after the fact instead of built from the start with a clear sense of direction. When I set about working on my first published game, Odyssey: The Legend of Nemesis, admittedly I had little idea of what I was doing. I had inherited a game engine and some portion of the game’s mechanics from the previous developer. At the time, the project was very meagerly funded, and as a result, the publisher only requested a meager amount of documentation about where the game was going. I drew up a six-page document which described, in brief, all of the adventures the player would go on. First of all, none of these documents were very detailed, with just one page per major island in the game. That left me lots of room to maneuver. Chapter 13: Getting the Gameplay Working 251 Second, by the time I had implemented the first two islands, I had learned enough about how the game truly worked that I decided to throw away the last three islands and design them over again. Since I had only written brief outlines of the gameplay in the first place, I did not actually lose much work. Another interesting aspect of Odyssey’s creation was that I developed the game entirely using place-holder art. Along with the game’s engine, I had inherited a fair amount of art from another project, and kept using that as much as possible. Since the project was underfunded, I did not have an artist to work with during most of the game’s development, so this decision was made more out of necessity than fore - sight. However, it did mean that by the time I had the money to hire artists to finish the project, all of the game’s design was done and fully playable, and as a result the artists created almost no art for the game that went unused. Using the place-holder art had not hindered the game’s development in the slightest. I concentrated first on getting all of the gameplay working, and then was able to focus on the visuals. Since I was not constrained by the thought of losing already created art assets if I changed the design, I was able to take the design in whatever direction seemed most appropriate while I was working on it. On Centipede 3D, a significant amount of work was done before the gameplay was actually fun, and almost all of that work had to be thrown out as a result. The original idea for the gameplay had little to do with how the original Centipede func - tioned from a gameplay standpoint, and featured a more meandering, less-directed style of gameplay. Using this original gameplay conception, six levels were actually 252 Chapter 13: Getting the Gameplay Working Keeping the development documentation light and using place-holder art kept Odyssey’s development extremely organic. built and numerous other levels were planned out on paper. For various reasons, the gameplay simply was not much fun, and we began to look at what could be done about that problem. In the end, we made the enemy AI function more like the origi - nal game’s enemies and adjusted the gameplay accordingly. When we tried it we were not sure if it would work, but that gameplay style turned out to work quite well. Unfortunately, much of the level design work that had been done was lost. All of the levels that had been designed on paper were thrown away because they were incompatible with this new style of gameplay. Of the six levels that had been actu - ally built, three had to be discarded in order to support the new gameplay, while the others had to be changed significantly in order to play well. Looking back, if we had focused on making the gameplay fun before making a large number of levels, we could have avoided a lot of extra work and wasted effort. With the gameplay functional, we were able to draw up documents describ - ing how the rest of the game would function. For the most part, we were able to hold to those documents throughout the remainder of the development process, with only minor changes necessary. Of course it would have been catastrophic to the project if we had been unable or unwilling to throw away the work we had already done. If we had tried to keep all of the levels without changing them signif- icantly, the game would have shown it and those levels would have been greatly inferior to the ones made with the proper gameplay in mind. If we had been foolish enough to stick to the initial design completely, the entire game would have suf- fered and the end product would not have been as fun as it turned out to be. Keep It Simple Early in development, it makes sense to work with only your focus instead of a long design document. The focus is short enough that it can easily be completely rewrit - ten if your game changes direction. Yet, at the same time, the focus will give you a clear direction for what you are trying to achieve with the gameplay you are attempting to implement. In the prototyping stage, the focus may change many, many times as you shift the game’s goals to match what you find to be working out in terms of gameplay. When your prototyping is done, you will have a solid focus that you can reasonably hope to follow for the rest of the game’s development. Unfortunately, you may not always have the option of keeping the game design process organic. If you are working at an established company, you may have a fully staffed team working on your project from the very beginning, and those peo - ple need to be kept busy making art, building levels, or coding up systems, even though there may not yet be a functional and fun gameplay prototype. It does not take a large team to get the initial gameplay working, and indeed such a large team may only get in your way as you try to keep them busy while experimenting with how the gameplay will work. You may also have demands from whomever is Chapter 13: Getting the Gameplay Working 253 funding your project’s development, whether it is your employer or the publisher. Whoever is paying the bills may want to see a complete design document or script up-front, before a prototype of the game has been developed. You may be forced to abandon those documents later as the gameplay turns out to work differently than you had anticipated. Obviously, crafting these documents prematurely can be quite wasteful, yet you are forever beholden to whomever is providing the funding for your project. In some ways, if at all possible, it may make sense to self-fund the project until you have a fully functional prototype. Work on it “under the radar” if you are at a large company, or work on the gameplay prototype before you try to find a publisher. Besides, a playable demo will make the game easier to sell to a publisher or a green-light committee. Nothing proves to the financiers that your game is moving in the right direction better than a compelling prototype. 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 imple- ment 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 prop- erly, your subsequent systems can be changed accordingly. 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 sys- tems 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 which has very lit - tle 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 be 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 tech - nology. If you design your game thinking you will be able to have ten enemies on 254 Chapter 13: Getting the Gameplay Working the screen at once and your engine turns out to be only able to handle 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 cut - ting-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 cre - ate will 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. 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 which build on those. For example, suppose you are building an action game in which the player navigates a humanoid character around the game-world fighting insurance agents with a fly- swatter 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 the player 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’s functionality can be broken down into building blocks just like the player’s movement was. First, get the AI agents in the world so that the player 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 the player to pick them up and launch them with his 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. Chapter 13: Getting the Gameplay Working 255 Throughout the project’s development, I think it is important to always keep a version of your game playable. 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 spends a lot of time in an unplayable state. Certainly the game can be broken in many ways, with various components that do not yet work as they are supposed to and with place-holder 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 some - one adds or changes 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 func- tions 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. Con- centrate 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 which 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 thought out 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. One example of this is from the development of my game Damage Incorpo - rated. 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 second level I made, though certainly not the best in the game, was good enough to make the final cut. The game also included death-match style networking, 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 that 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 256 Chapter 13: Getting the Gameplay Working 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. 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 bal - ancing. 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 game. 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. 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, lev - els, and even general design itself; all of the game’s content may need to change as Chapter 13: Getting the Gameplay Working 257 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. [...]... who is actually designing the game So much of implementing your game design relies on personal “gut” reactions that it is no wonder people have great difficulty designing games for people other than themselves This is why so many games that are aimed at the “mass market” but which are designed by people who are hard-core gamers turn out to be so terrible The hard-core gamer doing the design wishes... part of game design is done, and the rest of the game s development is simply repeating it effectively Chapter 14 Interview: Chris Crawford Today, Chris Crawford is probably best known for his contributions to the dialog of game design, including his founding of the Computer Game Developer’s Conference, publishing the Journal of Computer Game Design, and writing the book The Art of Computer Game Design... Unfortunately, the recovery surprised everybody by its shape The initial collapse discredited video games, but not really computer games as much Unfortunately, at the time, most computer games were just copies of video games Hence, many computer game companies that were deriving all of their sales from video games collapsed It was really bad for a while there I couldn’t get a job, I couldn’t get anything... suggested to people that perhaps serious games might have a future, or at least games that weren’t video games And there was a lot of excitement about exploring some of those ideas The other games that were a big success back then were the whole series of Infocom games, which continued to do well right through the crash Because they were clearly different from video games Yes And you put those two together,... Advanced Squirrel Hunting wants in its games Often features will be added to a game at the behest of marketing, over the protests of the development team These features are always the worst in the game, not necessarily because they are bad ideas, but because the development team does not understand why they need to be added to the game or how they might improve the gameplaying experience In the end, it... the Gameplay Working Game developers do their best work when working on games they care about and enjoy The excellent Grim Fandango appears to be a perfect example good game that you yourself do not enjoy playing If you do not enjoy playing it, it is unlikely that anyone else will either, even if they technically fall into the demographic you were so carefully targeting The first step in designing a game. .. fundamental nature of the gameplay while keeping the additional content new and interesting Now that you know that your game design is a good one, it may finally make sense to craft a thorough design document that explains that gameplay and explores what variations on it may be used for the rest of the game This will provide a valuable guideline for the rest of the team in fleshing out the game In some ways,... sense of what makes games fun In the end, there are an infinite number of small decisions that programmers make which will have a profound impact on the gameplay, details that no designer can anticipate These little details have an enormous impact on the final game, determining how the game “feels” to play Often, unmotivated or disinterested lead programmers can be found to be behind games that seem like... listed as Game Designer” or “Programmer.” I remember people saying, “Gee, you know, if we put our titles down as Game Designer, we may not be able to get another job.” And I think we ended up going with Game Programmer.” But game design was nowhere near the thing it is today, it was just a very obscure thing I remember telling people when they’d ask me, “What do you do?” And I’d say, “I design games for... 2K game And I did one called Wizard, which I think was rather clever and worked in 2K Although I got it done in record time, I finished it just as Atari was starting to get its 4K games out Everybody started realizing that the 4K games were not just a little better, but immensely superior to the 2K games So there was a feeling that anything that was marketed is going to be compared against the 4K games, . the game that func- tions 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. such as the Infocom adventure games, the Sierra adventure titles, the annual revisions of sports games, or the new versions of arcade driving games. However, these are games which, though perhaps. Getting the Gameplay Working 249 new stories and graphics, offer gameplay that is very much the same as the previous year’s offerings. When a game tries to implement a new form of gameplay, even