03 brainstorming

Author: darren-coleman

Post on 06-Apr-2018




0 download

Embed Size (px)


  • 8/3/2019 03 Brainstorming


    Chapter 3Brainstorm in g a Gam eIdea: Gam eplay ,T echnology, and Story

    You know whats the number one dumbest question I get

    asked when Im out at some great university lectur ing? Im always

    asked Where do you get your ideas? For about forty years Ive

    been yanking their chain when I answer Schenectady. They stare

    at me, and I say, Yeah, Schenectady, in New York. Theres this ideaservice, 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


  • 8/3/2019 03 Brainstorming


    Harlan 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.

    Thats 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

    games 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 makethink-

    ing about it in terms of gameplay, technology, or storyit is important that he

    consider how that initial idea will impact all aspects of the final game.

    Starting PointsPerhaps 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

    Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 43

  • 8/3/2019 03 Brainstorming


    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.

    Start ing wi th 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. Its a racing game! Its a flight sim-

    ulator! Its a 3D action/adventure like Super Mario 64! Its a first-person

    shooter likeDoom! 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 gamewill 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 games 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 games 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 teams existing technology work or will they

    44 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story

  • 8/3/2019 03 Brainstorming


    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 toyour gameplay and go with it.

    Starting with Technology

    Going into a project with a large portion of the games technology already devel-

    oped is also a fairly common occurrence. If this is not the development teams 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

    Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 45

  • 8/3/2019 03 Brainstorming


    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-licensedQuake 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 gameHalf-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

    46 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story

  • 8/3/2019 03 Brainstorming


    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 isjust as likely to compromise the game as tying a particular story to inappropriate

    gameplay. Again using the example ofHalf-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.

    Star ting w ith StoryFinally, 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

    Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 47

    The designers ofHalf-Lifesmartly

    used the indoor




    established by

    Quake, the

    engine licensed

    for the games


    Pictured here:

    Quake II.

  • 8/3/2019 03 Brainstorming


    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

    players 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-

    tures, a first-person shooter with teammates might be appropriate. Any sort of story

    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.

    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

    the designer want the player to have a generals 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, usingtyped-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 observeunique 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

    48 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story

  • 8/3/2019 03 Brainstorming


    companies used very standardized play mechanics and technology. The game

    designers worked with the companys 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 Infocoms 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, eventhough 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 games 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.

    Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 49

    Maniac Mansionwas the first of

    the story-



    games from

    LucasArts to use

    the SCUMM


  • 8/3/2019 03 Brainstorming


    Working w ith Limita tionsExperienced 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 games 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.

    Od yssey: The Legend of N emesis

    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

    50 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story

  • 8/3/2019 03 Brainstorming


    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 startedwith 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 games epic tale.

    Damage Incorporated

    In the case ofDamage 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 inMarathon 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

    againstDoom. WhatMarathon 2 lacked in fast-action battles and the atmosphere of

    menace thatDoom 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 theMarathon games so much, I decided

    to make my game embrace the technology and gameplay thatMarathon had

    Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 51

    Levels inOdyssey: The

    Legend of


    designed around

    the games story.

  • 8/3/2019 03 Brainstorming


    established. I would craft my game around the technology that had been licensed

    and use that technology to the greatest effect I possibly could.

    With a starting point of technology, I crafted gameplay and a story that could

    succeed using theMarathon technology. Of course, we added features to the

    gameplay and engine. The primary addition to the game mechanics was the players

    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 withMarathons game mechanics, I

    involved characters through the players teammates, who would chatter amongst

    themselves as the player maneuvered them through the game-world.

    One of the games weaknesses was that at the start of the project I did not fully

    understand the limitations of theMarathon 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, asMarathon 2 had done, was

    one thing, but creating environments that looked like the woods in Nebraska was

    another. Around half of the levels inDamage Incorporatedare 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.

    52 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story



    (pictured) had its

    origins in the




  • 8/3/2019 03 Brainstorming


    Interestingly, at the same time I was using theMarathon 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 likeMarathon 2 as

    much as I did, and wanted to create more of aDoom-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 Targetteam spent a much greater amount of time modifying the engine to

    suit their needs than we did. Because of this Prime Targetbecame a significantly

    different game from eitherMarathon 2 orDamage 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.

    Centip ede 3D

    The Centipede 3D project was started when the publisher, Hasbro Interactive,

    approached the games developer, Leaping Lizard Software, about using their

    Raidertechnology for a new version ofCentipede. Hasbro had recently found suc-

    cess with their modernization ofFrogger, and wanted to do the same for Centipede,

    the rights to which they had recently purchased. Producers at Hasbro had seen a pre-

    view forRaiderin 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 utilizingsimple, elegant arcade-style gameplay, and adapting it to a 3D world would be a

    unique challenge.

    For the development ofCentipede 3D, the origin of the games development lay

    in gameplay. Re-creating the feel of the original Centipede was at the forefront of

    everyones minds throughout the projects 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

    LizardsRaiderengine 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.Raideremployed 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 3Ds 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

    Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 53

  • 8/3/2019 03 Brainstorming


    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 Centipede3D, not the story. The classic

    arcade style of gameplay simply did not call for it. The primary effect of the mea-

    ger story line was to provide a setup and to affect the look of the game, to explainwhy 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 games 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 gamehow 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

    designers job to make all the pieces fit together, and to find the perfect parts to

    make a compelling game.

    54 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story

    The new, 3Dversion of


    based on the

    classic bug


    gameplay found

    in the original


  • 8/3/2019 03 Brainstorming


    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.

    Esta b li shed Technol ogy

    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 maybe 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 ofQuake III,IV, orXIII. It is simply not possible. Functioning asthe 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 todays 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 Centipedes gameplay hinged on the

    presence of a lot of mushrooms on the screen at once, with similarly large numbers

    Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 55

  • 8/3/2019 03 Brainstorming


    of other insects, arachnids, and arthropods flying around the world, threatening to

    destroy the players 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

    products minimum system requirement had been predetermined to be a 133 MHz

    Pentium with no hardware graphics acceleration. On top of all that, Centipedes

    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 games 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 3Ds 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 toconvert 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 limitationsthat 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

    56 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story

  • 8/3/2019 03 Brainstorming


    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 projects 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 ofsuch 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, yourpublisher 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.

    Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story 57

  • 8/3/2019 03 Brainstorming


    If You Choose Not to Decide, You StillHave Made a Choice

    So often producers, programmers, artists, and designers fail to consider the limita-

    tions of the game idea they are planning to develop. Whether it springs from notions

    of gameplay, suggestions of technology, or thoughts about a story, as soon as a

    game idea takes on form it begins limiting what the game can be if it is to be suc-

    cessful. Game developers need to understand that not every technology will work

    with every game design, nor every design with every story, nor even every story

    with every technology.

    Often developers will try to take a bunch of compelling concepts and attempt to

    stuff them all into one game. The lead programmer may be interested in developinga cutting-edge inverse kinematics system. The lead game designer might have

    wanted to try a real-time strategy game ever since he playedAge of Empires for the

    first time. The games writer may think theres entirely too much violence in com -

    puter games and therefore wants to write a tale of romance. If the producer is a

    fool, she may even be thrilled that the members of her team are so excited about

    what they are developing and that, by combining IK, RTS, and romance, the result

    will be a breakthrough game.

    Of course anyone with a whit of sense knows this game is doomed to fail. If, at

    the brainstorming session, the team were able to decide which aspect of the game

    they wanted to concentrate on, the team could work to make the game as a whole as

    good as possible. Suppose they choose the IK as what they all think would make

    for the best complete game. Then the designer can mull it over and realize a Street

    Fighter II-style fighting game would probably make the best use of an IK system.

    And the writer could come up with a story about a human fighting one by one

    through the pantheon of Greek gods, hoping one day to meet his true love, Hera.

    This game has a fighting chance of being fun to play, because all of the components

    are working together. In the end, you do not want your game to consist only of an

    excellent technology or a compelling story or a brilliant game design. If none of

    these components support each other your game will be just as bad as if you were

    working with a hackneyed story, a thin game design, and an incomplete technology.

    58 Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story