03 Brainstorming
-
Upload
darren-coleman -
Category
Documents
-
view
255 -
download
0
Transcript of 03 Brainstorming
-
8/3/2019 03 Brainstorming
1/17
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
42
-
8/3/2019 03 Brainstorming
2/17
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
3/17
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
4/17
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
5/17
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
6/17
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
first-person
shooter
gameplay
established by
Quake, the
engine licensed
for the games
creation.
Pictured here:
Quake II.
-
8/3/2019 03 Brainstorming
7/17
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
8/17
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-
centered
adventure
games from
LucasArts to use
the SCUMM
system.
-
8/3/2019 03 Brainstorming
9/17
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
10/17
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
Nemesiswere
designed around
the games story.
-
8/3/2019 03 Brainstorming
11/17
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
Damage
Incorporated
(pictured) had its
origins in the
licensed
Marathon
technology.
-
8/3/2019 03 Brainstorming
12/17
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
13/17
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
Centipedewas
based on the
classic bug
shooter
gameplay found
in the original
Centipede.
-
8/3/2019 03 Brainstorming
14/17
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
15/17
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
16/17
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
17/17
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