Game Design: Theory & Practice- P3

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:30

Thêm vào BST

Báo xấu

86
lượt xem 13
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Game Design: Theory & Practice- P3: My earliest recollection of playing a computer game was when I stumbled upon a half-height Space Invaders at a tiny Mexican restaurant in my hometown. I was perhaps six, and Space Invaders was certainly the most marvelous thing I had ever seen, at least next to LegoLand.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Game Design: Theory & Practice- P3

38 Chapter 2: Interview: Sid Meier have you create your own really cool mental images based on some suggestions that we give you on the screen. You were one of the first game designers to get your name above the title on the box. I was curious how that came about. Well, the way that happened goes back to Pirates! That was the first game that had my name on it. In those days I was Y working at FL Microprose and my partner was Bill AM Stealey who did the business/marketing side of things while I TE did the develop- ment/creative stuff. F-15 Strike Eagle And the previous game before Pirates! was one of the flight simulator games, and I said to Bill, “Well, I’m going to work on this game about pirates.” And he said, “Pirates? Wait a minute, there are no airplanes in pirates. Wait a minute, you can’t do that.” “Well, I think it’s going to be a cool game.” And he answered, “Well, who’s going to buy a pirates game? Maybe if we put your name on it, they’ll know that they liked F-15 or whatever, and they might give it a try, OK.” There was a real concern that there was this pirates game coming out, but nobody’s going to be interested, because who wants a pirates game? People want flight simulators. So it was to say, “Sure, you want a flight simulator, but maybe you might want to try this pirates game because it was written by the guy who wrote that flight simulator that you’re playing.” I guess it was branding in a very crude, early form. It was because we were making this big switch in the type of game that I was working on, and to try to keep that connection between the games. So it wasn’t your lust for fame? [laughter] No, no. Even today, fame is not a computer game thing. I think it’s good. It’s still a pretty non-personality oriented business. I think that people remem- ber great games, and they know to a certain extent who’s involved. But there’s not a cult of Robin Williams or, you know, movie stars who really have a cult of person- ality. I think it’s good. Once we get the idea that we can get away with anything just because we’re who we are, that’s not a good thing. Team-Fly®
Chapter 2: Interview: Sid Meier 39 But that sort of confidence led to Pirates!, didn’t it? [laughter] Well, it was a good game. Had it not been a good game, that strategy would not have worked. A lot of your games have had sequels of one kind or another, but you have never been the lead designer on one of them. Why is this? I think they are a fine thing to do in general, especially if they’re done well. I seldom go back to a topic primarily because I haven’t run out of ideas yet, so I’d rather do a dinosaur game than go back to an older title. I don’t have a lot of energy to get too involved in the sequels. Some of them turn out well, some of them turn out not quite so well. As opposed to letting the topic fade away, I think doing a sequel is often a good idea. In an ideal world, I’d like to be involved in everything, but I can’t really do that. So I tend to be more interested in being involved in a new product as opposed to a sequel. It’s certainly gratifying that people want another Railroad Tycoon or Civilization, et cetera, I think that’s great. I’m happy that it can be done. On Civilization III, since it’s being done inside of Firaxis, I’m able to take a more direct part in that, which I think is good. I would have liked to have done Railroad Tycoon II and do a new Pirates!, et cetera, if I had an infinite amount of time. But it’s just not feasible. I hear a lot of people talking about storytelling in games. Usually by storytelling they mean using cut-scenes or branching dialog trees or devices like that. Your games have never been very concerned with that side of storytelling. To me, a game of Civilization is an epic story. I think the kind of stories I’m inter- ested in are all about the player and not so much about the designer. There are players that are more comfortable in situa- tions where they’re making small deci- sions and the designer’s making the big decisions. But I think games are more Civilization interesting when the player makes the big
40 Chapter 2: Interview: Sid Meier decisions and the designer makes the small decisions. I think, in some sense, games are all about telling stories. They have a story created more by the player and less by the designer, in my mind. I think in Civilization there are fantastic stories in every game, they’re just not in the more traditional sense of a story. We have, amongst our rules of game design, the three categories of games. There are games where the designer’s having all the fun, games where the computer is having all the fun, and games where the player is having all the fun. And we think we ought to write games where the player is having all the fun. And I think a story can tend to get to the point where the designer is having all the fun or at least having a lot of the fun, and the player is left to tidy up a few decisions along the way, but is really being taken for a ride. And that’s not necessarily bad, but our philosophy is to try to give the player as much of the decision making as possible. Though Gettysburg! had a multi-player option, by and large your games have been single-player only for a long time. What do you think of the emerging popu- larity of multi-player gaming? I think down the road I would like to get more into multi-player, perhaps even a game that is primarily multi-player. But I still enjoy essentially single-player games, so I’m not sure exactly when or how that’s going to happen. Online multi-player gaming is probably the only revolutionary development in our technology we’ve seen since I started writing computer games. Everything else has been pretty much evolutionary. Better graphics, better speed, more memory, et cetera. But the multi-player online thing was a revolutionary change in the tools that we had to make games. I’m interested in doing something along those lines, but I’m not sure what it would be right now. In an old Next Generation magazine interview, you said, “Games are going to take over the world. It’s going to take a while, but there’s something inherently more engaging about computer games than any other form of entertainment.” Board games have certainly been around a long time, but have not yet taken over the world. I wondered what it is about computer games that you find so compelling. Yeah, I think I stand by that statement. I think that it’s the element of interactivity that makes them unique. They interact personally with you as a player, as opposed to movies, television, or music, which don’t. There’s this phenomenon of watching television and using the remote control to desperately try to make it an interactive experience, going from one channel to another... [laughter] But the interactivity of computer games is what differentiates it and makes it so very power- ful. Now, we’re still learning how to use that tool and in a lot of other ways we’re not as good as television, movies, et cetera. But I think that as we learn to use the advantages that we have, they’re more powerful advantages than the advantages of other entertainment media.
Chapter 2: Interview: Sid Meier 41 I think that board games are kind of interactive, but they require other players. The computer brings a lot of power to the equation that board games don’t take advantage of. If anything, the advent of the Internet and multi-player play, that com- bined with interactivity seems to me like a really powerful combination. I think as we learn to use that element of our technology too, games can be very very compel- ling. The question that pops up is do people want games that are that interesting to play? There was the whole Deer Hunter phenomenon, and there was Slingo and things like that and I’m still working to integrate that into my model of the world, and I haven’t totally succeed in doing that. But what that tells me is that there’s a broader range of potential gamers than I am really familiar with. And part of our learning process is going to be to integrate them into the way that we design games and the way that we create games. But I still think we’re going to take over the world. Sid Meier Gameography Hellcat Ace, 1982 NATO Commander, 1983 Spitfire Ace, 1984 Solo Flight, 1984 F-15 Strike Eagle, 1985 Decision in the Desert, 1985 Conflict in Vietnam, 1985 Crusade in Europe, 1985 Silent Service, 1986 Gunship, 1986 Pirates!, 1987 F-19 Stealth Fighter, 1988 Railroad Tycoon, 1990 Covert Action, 1990 Civilization, 1991 Colonization, 1994 (Consultant) Civilization II, 1996 (Consultant) Gettysburg!, 1997 Alpha Centauri, 1999 (Consultant)
Chapter 3 Brainstorming a Game Idea: Gameplay, Technology, and Story “You know what’s the number one dumbest question I get asked when I’m out at some great university lecturing? I’m always asked ‘Where do you get your ideas?’ For about forty years I’ve been yanking their chain when I answer ‘Schenectady.’ They stare at me, and I say, ‘Yeah, Schenectady, in New York. There’s this idea service, see, and every week I send ’em twenty-five bucks, and every week they send me a freshly picked six-pack of ideas.’ ” — Harlan Ellison 42
Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 43 H arlan Ellison might scoff at the idea of trying to explain where ideas come from. Certainly, if you are a novelist having trouble coming up with ideas, it may be time to wonder if you have chosen the right profession. Simi- larly, a good game designer, at any given moment, will be able to come up with no less than five solid ideas he would like to try to make into a computer game. There is no shortage of ideas in the gaming world. Aspiring game designers often think they can sell their idea to a development company. They seem to be under the impression that game developers are just sitting around waiting for a hot idea to come around so they can spend several million dollars to make it a reality. On the contrary, the challenge in game development is not coming up with a good idea, but in following through and being able to craft a compelling game around that idea. That’s what the rest of this book endeavors to explore. In the arena of computer game design, the process of coming up with a game idea that will work is complicated by a number of factors fiction authors do not need to worry about. In part this is because computer game ideas can come from three distinct, unrelated areas of the form: gameplay, technology, and story. These different origins are interconnected in interesting ways, with the origin of the game’s idea limiting what one will be able to accomplish in the other areas. So when a game designer starts thinking about the game he is hoping to make—think- ing about it in terms of gameplay, technology, or story—it is important that he consider how that initial idea will impact all aspects of the final game. Starting Points Perhaps a quick example is in order. Say a game designer feels the need to create a game based around the specific stories of Greek mythology. This would be starting from a story. Immediately this limits the type of gameplay she will be going for. Chances are a Civilization-style strategy game is out, since that sort of game really has nothing to do with the classical stories of Zeus, Heracles, Ares, and so on. A real-time strategy game is out of the question as well, since it is not good at telling stories involving only a few protagonists. A high-end flight simulator is probably not going to work either. She could, however, still pursue it through an action game, a role-playing game, or an adventure game. Similarly, the technology is limited. In order to tell the story of the Greek gods, she will need some way to communicate a lot of back-story information to the player. There will need to be technology in place that can allow this. Furthermore, if she chooses the technology to be employed by the game at this point, this will have still further impact on what type of gameplay will be possible. For example, choosing an isometric 2D engine will best lend itself to an RPG or an adventure game instead of an action game. If a 3D technology is to be used, in order to tell the story of Greek mythology properly it
44 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story will need to support both indoor and outdoor environments, which immediately eliminates a lot of 3D game engines. For each decision the designer makes about the game she is hoping to create, she needs to understand how that limits what the game will be. If the designer tries to fit a type of gameplay around an ill-suited engine the game will suffer in the end: trying to do a Populous-esque “god-sim” using a first-person, indoor Quake-style 3D engine is a big mistake. Just as if one tried to tell the story of the Greek gods through flight simulator gameplay, the game would simply fail to work. Herein lies the difficulty with many “high-concept” ideas, often the brainchildren of marketing specialists who want to capture disparate markets with one product. If the parts do not work together, it does not matter how many markets the concept covers: no gamers will be interested in playing the final game. Starting with Gameplay Starting with gameplay is one of the most common starting points for game devel- opment, especially for designer or management driven projects. Thinking about a style of gameplay is often the easiest core for someone to latch onto, especially if that gameplay is similar to an existing game. “It’s a racing game!” “It’s a flight sim- ulator!” “It’s a 3D action/adventure like Super Mario 64!” “It’s a first-person shooter like Doom!” Often a game developer will have enjoyed a game in one of these genres and will want to apply his own spin to it. With a general idea for a game that is interesting to him, the designer will want to work out what his particu- lar game is going to accomplish in terms of gameplay. What type of racing game will it be? What aspects of racing are we trying to capture for the player? With a more specific idea of what type of gameplay he wants to create, the designer should start thinking about how that will impact the technology the game will require and what sort of story, if any, the game will be able to have. Depending on the type of gameplay you are hoping to create for the player, you need to analyze what sort of technology that undertaking will require. Does the game need a 3D engine, or will 2D be enough or even more appropriate? What sort of view will the player have of the game-world? Will it be fixed or dynamic? Does the action transpire fast and furious with a large number of entities moving around on the screen at once? Are the game-worlds large or small? All of these questions and many more need to be analyzed to understand what the game’s engine must accomplish in order to properly execute the gameplay idea. Of course the technol- ogy you choose to employ for your gameplay must be one that will actually run on the target system, whether it be the PC, a console, or a custom-made arcade cabinet. You must also ask if the game’s programming team is up to creating the required technology. Technological feasibility may end up limiting the scope of your gameplay. Even worse, will the engine team’s existing technology work or will they
Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 45 need to scrap it and start from scratch? Is there enough budget and time to trash it and start over? If you find that you need to adapt your gameplay to match the engine, you really are not starting out with gameplay as the origin of your idea, but instead with technology, as I will discuss below. If you are starting out with a gam- ing engine that must be used, it is in your best interest to not fight that technology with incompatible gameplay. Instead you should try to think up your gameplay idea in terms of what is well suited to that engine. The type of gameplay your game will employ similarly limits what type of story can be told. An RPG can tell a much more complex and involved story than an action/adventure game, and in turn an action/adventure can tell a more substan- tial story than an arcade shooter. Certain types of stories just will not fit with certain types of gameplay, such as the Greek mythology in a flight simulator example dis- cussed previously. Similarly, a romantic story might not fit with a strategy game, and a tale about diplomacy would not fit so well with a fast-action first-person shooter. Since you made the choice to come up with your gameplay style first, you need to ask yourself what sort of story is best suited to that gameplay, and try to tell that tale. Sometimes a designer will have both a story he wants to tell and a type of gameplay he wants to explore, and will attempt to do both in the same game, even if the two do not go well together. Do not try to cobble an inappropriate story, either in terms of complexity or subject matter, around gameplay that is ill suited to that type of narrative. Save the story for a later date when you are working on a title with gameplay that will support that story better. And while your technology is lim- ited by what your team is capable of accomplishing in the time allotted, the story is limited only by your own ability to tell it. You should pick the story best suited to your gameplay and go with it. Starting with Technology Going into a project with a large portion of the game’s technology already devel- oped is also a fairly common occurrence. If this is not the development team’s first project together at a new company, then it is likely that there will be an existing technology base that the project is supposed to build from. Even if the project is to use a “new” engine, this often only means an older engine updated, and as a result, the style of game best suited to the engine will not change significantly. Even if an engine is being written from scratch for the project, it is likely that the lead pro- grammer and her team are best equipped to create a certain type of engine, be it indoor or outdoor, real time or pre-rendered, 3D or 2D, with a complex physics sys- tem for movement or something more simple. The programmers may be interested in experimenting with certain special lighting or rendering effects, and will create an engine that excels at these objectives. The designer is then presented with this
46 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story new technology and tasked with coming up with a game that will exploit the sophis- ticated technology to full effect. Other times it is predetermined that the project will be using an engine licensed from some other source, either from another game developer or a technology-only company. Sometimes the project leaders have enough foresight to consider the type of game they want to make first and then pick an engine well suited to that. More often, the engine licensing deal that seems to deliver the most “bang for the buck” will be the one chosen. Then, with an engine choice decided, the team is tasked with creating a game and story that will fit together well using that technology. Just as starting with a desired sort of gameplay dictated what type of engine should be created, starting with set technology requires that the game designer con- sider primarily gameplay that will work with that sort of technology. If the engine is 3D, the designer will need to create a game that takes place in a 3D world and uses that world to create interesting 3D gameplay. If the engine is only 2D, a first-person shooter is out of the question. If the engine has a sophisticated physics system, a game should be designed that makes use of the physics for puzzles and player movement. Of course, the designer does not need to use every piece of tech- nology that a programmer feels compelled to create, but it is always better to have your gameplay work with the engine instead of fight against it. Usually when a pro- ject is using a licensed game engine, that technology will often have been created with a certain type of gameplay in mind. The designer needs to seriously consider how far he should deviate from that initial technology, for it is surely going to be easier to make the engine perform tasks for which it was intended instead of push- ing it in directions its programmers never imagined. For instance, the oft-licensed Quake engine was created for handling an indoor, first-person perspective, fast- action game involving a lot of shooting. Though some teams that have licensed that engine have tried to push it in different directions, the most artistically successful licensee thus far, Valve, retained much of the standard Quake gameplay that the engine excelled at for their game Half-Life. Certainly Valve added a lot of their own work to the engine, technology that was necessary in order to do the type of game they wanted to do. But at the same time they did not try to do something foolish such as setting their game primarily outdoors or using only melee combat. When technology is handed to a game designer who is told to make a game out of it, it makes the most sense for the designer to embrace the limitations of that technology and turn them into strengths in his game. The technology can also limit what sort of story can be told. Without a sophisticated language parser, it is going to be difficult to tell a story in which players need to communicate with characters by typing in questions. Without an engine that can handle outdoor environments reasonably well, it is going to be difficult to make a game about mountain climbing. Without robust artificial intelligence it is going to be hard to make a good game about diplomacy. Without
Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 47 The designers of Half-Life smartly used the indoor first-person shooter gameplay established by Quake, the engine licensed for the game’s creation. Pictured here: Quake II. compression technology that can store and play back large sounds, it will be hard to have huge amounts of dialog and hence hard to have characters whose dialects are important to the story. Without the ability to have large numbers of moving units on the screen at once, it will be impossible to tell a story where the player must participate in epic, massive battles between armies. The game designer needs to consider how the story line will be communicated to the player through the engine that he must use. Trying to tell a story with an inadequate engine is just as likely to compromise the game as tying a particular story to inappropriate gameplay. Again using the example of Half-Life mentioned above, if the team at Valve had tried to set their game in Death Valley and involve the player battling gangs of twenty giant insects at once, the Quake engine would have ground to a halt and the game would have been miserable to play. In the Death Valley sce- nario, Valve might have been telling the story they wanted to, but no one would have cared since the game would have been miserably slow and looked horren- dous. For the greater good of the game, the story and the technology must be compatible with each other. Starting with Story Finally, it is certainly possible that the brainstorming for your game may start with a setting you want to employ, a story you want to tell, or a set of characters you want to explore. This is probably a less common starting point than technology or gameplay. Indeed, since many games have no story whatsoever, the very concept of a game starting with a story may seem strange. At the same time it is not unheard of
48 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story for a game designer to think of a story she wants to tell, and only then start explor- ing what sort of technology and gameplay will be best suited to communicating that story. Any good game designer who thinks up such a story will have a tendency to think of it in terms of how it would transpire in a game, how the player can interact with that story, and how the story may unfold in different ways depending on the player’s actions in the game-world. So a designer may not be thinking solely of the story but also of the gameplay. But the story can be the jumping-off point, the cen- tral vision from which all other aspects of the game are determined. Of course the type of story to be told will have a dramatic effect on the type of gameplay the project will need to have. If the designer wants to tell the story of a group of friends battling their way through a fantastical world full of hostile crea- Y tures, a first-person shooter with teammates might be appropriate. Any sort of story FL which involves the player talking to a large range of characters and going on “quests” for those characters might be addressed with more RPG-style mechanics. AM Telling the story of the battle of Waterloo could be perfectly addressed in a project with wargame-style strategic play, with the gameplay adjusted in order to best bring out the aspects of Waterloo with which the designer is primarily concerned. Does TE the designer want the player to have a general’s eye view of the game? In that case gameplay that allows for the tracking of tactics and logistics should be used. Or does the designer want to tell the story more from the view of the soldiers who had to fight that battle? Then gameplay that would allow the player to track and manip- ulate her troops unit by unit would be appropriate. If conversations with non-player characters (NPCs) are an important part of communicating the story, the designer will need to design game mechanics that allow for such conversations, using typed-in sentences, branching dialog choices, or whatever will work best. The designer needs to find gameplay that will allow the player to experience the most important elements of whatever story she is trying to tell. Of course, the technology will have to match up with the story as well, primar- ily in order to support the gameplay the designer decides is best suited to telling that story. If conversations are an important part of communicating the story, the programming team will need to be able to develop a conversation system. If world exploration and discovery are a big part of telling the story, perhaps a 3D engine is best suited to the gameplay, one that allows the player to look anywhere he wants with the game camera. The designer may find that specifically scripted events are important to communicating aspects of the tale; the player must be able to observe unique events that transpire at specific times in different parts of the world. In this case, the programmers will need to give the level designer the ability to set up these scenes. The technology is the medium of communication to the player, and thereby the story is directly limited by what the technology is capable of telling. Good examples of story-centered game design are some of the adventure games created by Infocom and LucasArts. All of the adventure games from these Team-Fly®
Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 49 Maniac Mansion was the first of the story- centered adventure games from LucasArts to use the SCUMM system. companies used very standardized play mechanics and technology. The game designers worked with the company’s proprietary adventure game creation technology, either the Infocom text-adventure authoring tool or LucasArts’ SCUMM system. By the time the game designer came on to the project, his process of creation started with creating a story he wanted to tell. Certainly the story had to be one that was well suited to the adventure game format and that could be implemented using the existing tool set. Both Infocom’s and LucasArts’ tools were general purpose enough to allow the designer to create a wide range of games, with a good amount of variation in terms of the storytelling possible, even though the core mechanics had to consist of a typing-centered text adventure in the case of Infocom and a point-and-click graphical adventure for LucasArts. The game designers’ primary driving motivation in the game’s creation was the telling of a story, with the designing of game mechanics and the developing of technology much less of a concern. Just as a film director is limited by what she can shoot with a camera and then project on a certain sized screen at 24 frames per second, the adventure game designers at Infocom and LucasArts were limited by the mechanics of the adventure game authoring system they were using. Since for both the film director and the adventure game designer the mechanics of the medium were firmly established well before they began their project, their primary concern became the telling of a story.
50 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story Working with Limitations Experienced game designers already understand the limitations placed on the creation of games by the technology, gameplay, and story. When they take part in brainstorming sessions these game designers have a good gut-sense of how making certain choices about the game in question will limit its creation further down the road. For each decision that is made about the game, many doors are closed. When enough decisions about the nature of the game have been made, it may be that there is only one type of game that can possibly accomplish all that the designers want. The stage for making major decisions is over, and now all that lies ahead are the thousands of smaller implementation issues. For three of the games I have completed, Odyssey: The Legend of Nemesis, Damage Incorporated, and Centipede 3D, I began development from a different starting point. Coincidentally, one game started with story, another with technology, and the third with gameplay. Throughout each game’s development I made every effort to remember where the game was coming from and what it was hoping to accomplish. The origins and objectives limited everything else about the game, resulting in only one acceptable game that achieved the goals I had set. Odyssey: The Legend of Nemesis Odyssey started with a story. I actually inherited this project at a point where a sig- nificant part of the 2D technology and RPG game mechanics were in place. Some story existed but it was by no means complete, and I was not terribly excited by it. As my first game project that was actually likely to be published, I immediately set to work rewriting the story into something in which I was personally invested. For years I had been wanting to get into game development in order to tell interactive, non-linear stories, and so I immediately set to writing just such a story, wherein the player would be presented with moral choices beyond just “to kill or not to kill.” I wanted to create a game in which the choices the players made would actually change the outcome of the story in a meaningful way. So I charged blindly forward, with the story as my only concern. Fortunately, the technology and game mechanics that were in place by and large supported this story I wanted to tell. Where they did not, I changed the game mechanics as necessary. When NPC AI had to function in a certain way to support the story, I made the AI work that way. When forced conversations became required, where an NPC could walk up to the player and initiate a conversation with him instead of the other way around, I implemented the appropriate game mechanic. The levels were designed with no other goal than to support the story. Since the levels were not designed with exciting battles in mind, combat situations in the game were not as compelling as they could have been. I was not interested in
Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 51 Levels in Odyssey: The Legend of Nemesis were designed around the game’s story. the combat so much as the story. The constant conflict with strange, marauding creatures was something people expected in an RPG and so it remained in, but I made combat such that it was very much secondary to exploring the story. This ended up turning the game into almost more of an adventure than an RPG, but that was fine with me, since it was what supported the story best. Looking at it today, I can see that Odyssey has many flaws in it. But I do not think that these problems arose because it was a game whose development started with a story. This may be a rare way to begin game development, but it can still be a viable starting point. If I had possessed a better sense of game design at the time, I could have taken efforts to make the rest of the game as interesting as the story was, while never undermining or diminishing the impact of the game’s epic tale. Damage Incorporated In the case of Damage Incorporated, the publisher, MacSoft, had obtained the license to a sophisticated (at the time) technology that they wanted to use for a game. It was the technology Bungie Software had created for use in Marathon and Marathon 2, two games of which I remain very fond. Marathon 2, in particular, remains one of the best first-person shooters ever made, easily holding its own against Doom. What Marathon 2 lacked in fast-action battles and the atmosphere of menace that Doom created so well, it more than made up for with a compelling and complex story line, superior level design, and a good (though simple) physics model. As a result of my having enjoyed the Marathon games so much, I decided to make my game embrace the technology and gameplay that Marathon had
52 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story established. I would craft my game around the technology that had been licensed and use that technology to the greatest effect I possibly could. Damage Incorporated (pictured) had its origins in the licensed Marathon technology. With a starting point of technology, I crafted gameplay and a story that could succeed using the Marathon technology. Of course, we added features to the gameplay and engine. The primary addition to the game mechanics was the player’s ability to order teammates around the game-world, thereby adding a real-time strat- egy element to the mix. We added to the engine numerous enhancements which allowed for swinging doors, moving objects, and other effects necessary to create a game-world that more resembled the real-world. I was still concerned with story in the game, though not to as great an extent as I had been with Odyssey. Since having conversations with NPCs did not really fit in with Marathon’s game mechanics, I involved characters through the player’s teammates, who would chatter amongst themselves as the player maneuvered them through the game-world. One of the game’s weaknesses was that at the start of the project I did not fully understand the limitations of the Marathon engine. It was best suited to creating indoor environments, so when it did create outdoor areas, they ended up looking fake, especially when they were supposed to represent real-life locations on Earth. Modeling the exterior of an alien world in the engine, as Marathon 2 had done, was one thing, but creating environments that looked like the woods in Nebraska was another. Around half of the levels in Damage Incorporated are set outside, and none of these outdoor areas ended up looking very good. If I had understood the technology better, I could have designed the game to take place in more indoor environments, thereby better exploiting what the engine did well.
Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 53 Interestingly, at the same time I was using the Marathon 2 engine to create Damage Incorporated, MacSoft had another team using the same engine to create a game called Prime Target. The members of that team did not like Marathon 2 as much as I did, and wanted to create more of a Doom-style shooter, with faster, sim- pler, more intense combat. Instead of starting with the technology and running with the type of gameplay it handled well, they started with a type of gameplay they wanted to achieve and modified the engine to better support that. As a result, the Prime Target team spent a much greater amount of time modifying the engine to suit their needs than we did. Because of this Prime Target became a significantly different game from either Marathon 2 or Damage Incorporated. Not a better or worse game, merely different. The differences can be traced back to the origins of the idea for their game, and the way they approached using a licensed engine. Centipede 3D The Centipede 3D project was started when the publisher, Hasbro Interactive, approached the game’s developer, Leaping Lizard Software, about using their Raider technology for a new version of Centipede. Hasbro had recently found suc- cess with their modernization of Frogger, and wanted to do the same for Centipede, the rights to which they had recently purchased. Producers at Hasbro had seen a pre- view for Raider in a magazine, and thought it might be well suited to the project. Hasbro had a very definite idea about the type of gameplay they wanted for Centi- pede 3D: game mechanics similar to the classic Centipede except in a 3D world. The team at Leaping Lizard agreed. At the time, not many new games were utilizing simple, elegant arcade-style gameplay, and adapting it to a 3D world would be a unique challenge. For the development of Centipede 3D, the origin of the game’s development lay in gameplay. Re-creating the feel of the original Centipede was at the forefront of everyone’s minds throughout the project’s development. When Hasbro set out to find a company with a technology capable of handling the game, they knew to look for an engine that could handle larger, more outdoor areas, because those were the type of locations a modernized Centipede would require. They knew not to go for a Quake-style technology in order to achieve the gameplay they wanted. Leaping Lizard’s Raider engine was a good match with the gameplay, but not a perfect one. Much work was required to modify it to achieve the fast responsiveness of a classic arcade game. Raider employed a physics system which was by and large not needed by Centipede 3D, and so much of it was stripped out. Thus the technology was molded to fit the gameplay desired. Centipede 3D’s story was the simplest in any of the games I have worked on. In part this is because one of the traits of classic arcade games was their lack of involvement in any real storytelling. For games like Centipede, Pac-Man, and
54 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story The new, 3D version of Centipede was based on the classic “bug shooter” gameplay found in the original Centipede. Space Invaders, setting was enough; all the games needed was a basic premise through which the gameplay could take place. Furthermore, everyone working on the Centipede 3D project had as their primary concern the gameplay, and story was simply less important. As we envisioned the game, it was the simple, addictive gameplay that would draw players into Centipede 3D, not the story. The classic arcade style of gameplay simply did not call for it. The primary effect of the meager story line was to provide a setup and to affect the look of the game, to explain why the player is flying around blasting centipedes and mushrooms, and why the game-worlds change in appearance every few levels. Just as the original Centipede used the setting of a garden and bugs to explain the game’s gameplay, the new Cen- tipede 3D used the story line only to support the gameplay. In the end, Centipede 3D was all about the gameplay. Embrace Your Limitations In many ways, developing a game is all about understanding your limitations and then turning those limitations into advantages. In this chapter I have discussed how the designer must understand where his game idea is coming from: gameplay, story, or technology. With this understanding, the designer must recognize how this limits the other attributes of the game—how a certain gameplay calls for a certain type of story and technology, how one story requires a specific technology and gameplay, and how technology will lend itself to specific types of games and stories. It is the designer’s job to make all the pieces fit together, and to find the perfect parts to make a compelling game.
Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 55 It is a very rare case indeed for a designer to be able to think of whatever game she wants and then search out the perfect implementation of that idea. In almost all cases, the designer is limited by the situation that is presented to her. The limita- tions may come in the form of the technology available, the team she has to work with, the budget available to develop the game, and the amount of time allowed for its creation. Though the producer is primarily responsible for making sure the game is on time and on budget, the designer must concern herself with all of the limita- tions she is faced with if she hopes to create a good game in the final analysis. Established Technology Often a designer at a larger company is required to work with whatever technology that company has. This may be an engine left over from a previous game, or it may be that the programming team only has experience working in 2D and as a result the only technology they will be able to viably develop in a reasonable time frame will be 2D as well. Even if the designer is fortunate enough to be able to seek out a tech- nology to license for a project, that designer will still be limited by the quality of the engines that are available for licensing and the amount of money she has to spend. If the developer is a lone wolf, working solo as both designer and programmer on a project, one might think the designer could make whatever he wants. Of course this is not the case, as the designer will quickly be limited by his own skills as a programmer and by the amount of work he can actually accomplish by himself. No single programmer is going to be able to create a fully featured 3D technology to rival the likes of Quake III, IV, or XIII. It is simply not possible. Functioning as the sole programmer and designer on a project has many benefits, but it certainly limits what one will be able to accomplish. Even if a programmer is able to create the perfect engine for her game, what if it is simply too slow? If a large number of fully articulated characters in an outdoor real-time 3D environment are required for your gameplay, on today’s technology the frame rate is going to be languid. Throw in some truly sophisticated AI for each of those creatures and your game will get down to 1 FPS, becoming, in essence, a slide show. If she must make that game, the designer has to wait until the process- ing power required is available, which may not be for years to come. Hearing that a project has been put on hold until the technology improves usually has the direct result of causing the publisher to stop making milestone payments. The Case of the Many Mushrooms When working on Centipede 3D, we were constantly troubled by our frame rate. Remember, for that game, our primary concern was to achieve gameplay which was in the spirit of the original arcade classic. But Centipede’s gameplay hinged on the presence of a lot of mushrooms on the screen at once, with similarly large numbers
56 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story of other insects, arachnids, and arthropods flying around the world, threatening to destroy the player’s little “shooter” ship. Furthermore, the gameplay necessitated a top-down view which provided a fairly large viewing area of the game-world, so that the player would be able to see the maneuverings of those deadly creatures. The end result was that there could be several hundred 24-polygon mushrooms, twelve 40-polygon centipede segments, and numerous other creatures all on the screen at once. On top of that, Hasbro wanted Centipede 3D to be a mass-market title, so the product’s minimum system requirement had been predetermined to be a 133 MHz Pentium with no hardware graphics acceleration. On top of all that, Centipede’s fast-action gameplay required a similarly fast frame rate to be any fun at all. While working on the project, we were constantly confronted with the problem of escalating polygon counts, with artists always attempting to shave a few poly- gons off of the much-used mushroom model. At one point, one artist suggested that perhaps if we could reduce the mushroom to two pyramids sitting on top of each other, we would have the absolute minimum representation of a mushroom, while using only six or eight polygons. Indeed, it was suggested, if all of the game’s mod- els went for a minimalist representation, we could use the polygon limitation to our advantage, creating a unique game-world filled with objects that looked as if they were created by a cubist. It would certainly be a unique look for a game, and would fit in quite well with Centipede 3D’s already somewhat surreal game-world. “Embrace your limitations!” I proclaimed in the midst of this discussion, not unlike a weary professor might finally proclaim, “Eureka!” All present thought my procla- mation to be quite funny, but thinking about it later I decided it was actually quite true for game development. Unfortunately, we were too far along in development to convert all of our art to the minimalist implementation we had thought of, not to mention the potential troubles of trying to sell the publisher on the idea of a mini- malist game. In general, though, I still think that game developers need to embrace their lim- itations as soon as they discover them. When presented with an engine that must be used for a project, why go out of your way to design a game that is ill suited to that technology? Your game design may be fabulous and well thought out, but if the technology you must use is not capable of implementing it well, you will still be left with a bad game in the end. It is better to shelve an idea that is incompatible with your technology (you can always come back to it later) and come up with a design better suited to the tools you have. Once you have identified the limitations that the engine saddles you with, it is best to embrace those limitations instead of fighting them. This is not to suggest that a designer should always design the sim- plest game that she can think of or that sophisticated, experimental designs should not be attempted. If a shrewd theater director knows a given actor is interested in working with him, he will pick the best play to show off the particular skills of that
Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 57 actor. Similarly, a designer should consider what the technology lends itself to and use that as the basis for the game she designs and the story she sets out to tell. The Time Allotted Limitations that I have not discussed much in this chapter but which are nonetheless very important in game development are the budget and schedule with which a designer may be presented. Though these are primarily the concern and responsibil- ity of the project’s producer, the game designer needs to know how these factors will limit the project just as the technology, gameplay, or story may. When choosing the technology to be used, the designer must ask himself: can it be completed in the amount of time scheduled for the project? Can it be completed in time for level implementation and balancing? Does the suggested design call for the creation of such a large number of complex levels and heavily scripted behaviors that they can- not be completed in eighteen months by only one designer? Just as the timeline will limit the amount of time that can be spent on the project, the budget will affect how many people can be working on the project during that time. It may be that, given double the budget, the game design could be easily completed in a year and a half, but with only half the budget the designer will need to scale back the design to come up with something feasible. Again, if development is running six months late with no end in sight and as a result the publisher pulls the plug, it does not matter how brilliant your game design may have been in theory. No one will get to play your game because you failed to fully consider the logistics of implementing it. And if you fail to allocate enough time for fine-tuning and balancing the gameplay, your publisher may demand you ship a game you consider unfinished. What might have been a great game will be a bad one because there was not enough time to really finish it. Lone wolf developers have it a bit easier in terms of time constraints and bud- getary limitations. If a single person is creating all of the art, code, and design for the game, and is developing the game on her own time without relying on income from its development in order to survive, she is much more free to follow wherever her muse takes her, for as long as she likes. Of course, she is still limited by her own talents, by the quality of the art she can create, and by the limits of her pro- gramming skills, but at least these are the only limitations. In terms of creating art, there is a lot to be said for not being beholden to the person writing the checks.