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
Brainstorming a Game Idea
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. Similarly, a
good game designer, at any given moment, will be able to
come up with no less than five solid ideas she would like to
try to make into a computer game. There is no shortage of
ideas in the gaming world.
Brainstorming a Game Idea
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,
selling a game idea to a company is so rare that one
should consider it an impossibility. Almost all of the
challenge in game development is not coming up with a
good idea, but in following through and being able to craft a
Brainstorming a Game Idea
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 two areas. So when a game designer
starts thinking about the game she is hoping to make — thinking
about it in terms of gameplay, technology, or story—it is
important that she consider how that initial idea will impact all
Gameplay
Beginning with gameplay is one of the most common starting points for game
development, 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 simulator!” “It’s a 3D action/adventure like Super
Mario 64!” “It’s a first-person shooter like Halo!” Often a game developer will
have enjoyed a game in one of these genres and will want to apply her own
spin to it. With a general idea for a game that is interesting to her, the
designer will want to work out what her particular 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 she wants to create, the designer should start
thinking about how that will impact the technology the game will require and
Gameplay
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 technology you choose to employ for your gameplay must
actually run on the target system, whether it be a PC, console, or 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 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 next. If
you are starting out with a gaming engine that must be used, it is in your best interest to
Gameplay
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 substantial 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 discussed 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 she wants to tell and a type
of gameplay she 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 limited 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.
Technology
Going into a project with a large portion of the game’s technology already
developed 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 programmer and her team are best
equipped to create a certain type of engine, be it indoor or outdoor, real-time
orpre-rendered, 3D or 2D, with a complex physics system for object
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 new technology and tasked with coming up with a game that will exploit
Technology
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. Though some of these licensed engines are
becoming more and more robust and as a result can allow for a fairly broad
number of games to be made with them (Criterion’s RenderWare is certainly
a good example of this), many licensed engines are still developed with one
game genre in mind, and no engine is without its fundamental limitations.
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.
Sometimes 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
Technology
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 she
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 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 on
the machines of the day and the game would have been miserable to play. In
the Death Valley scenario, Valve might have been telling the story they
wanted, but no one would have cared since the game would have been
miserably slow and looked horrendous. For the greater good of the game, the
story and the technology must be compatible with each other.
Story
Finally, it is certainly possible that the brainstorming for your game may start with
asetting you want to employ, a story you want to tell, or a set of characters
you want toexplore. 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 for a game designer to think of
a story she wants to explore, and only then start exploring what sort of
technology and gameplay will be best suited to telling that story. Frequently, a
particular setting may inspire a game designer, such as the adventurous
world of Errol Flynn or the dark and gritty crime world of Sin City. A designer may
not care too much about the specifics of the plot, but may have a strong
desire to work in a world filled with swashbucklers or grim private detectives.
For my purposes in this chapter, I consider these inspirational settings to fall
Story
Any good game designer who thinks up a story or a setting will have a tendency
to think of it in terms of how it would translate into 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. Indeed, not all stories
will translate very well into games, and thinking of gameplay possibilities early
can help you rule out settings that simply will not work out in games. 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 central 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 fantastic world full of hostile creatures, a first-person shooter with
teammates might be appropriate. Any sort of story that involves the player
talking to a large range of characters and going on “quests” for those
Story
Of course, the technology will have to match up with the story as well, primarily
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 players to
look anywhere they want with the game camera. The designer may find that
specifically scripted events are important to communicating aspects of the
tale; players 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 designers the ability to implement these scenes. The
technology is the medium of communication to the players, and thereby the
story is directly limited by what the technology is capable of telling.
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.
Working with 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 her 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. One designer may consider
these requirements to be limitations, while a more positive designer may
consider them to be simply constraints. Indeed, many people do their best
work when operating inside constraints; having limitless options can be quite
intimidating and confusing. It is the designer’s job to establish what
constraints the project has, find the perfect parts that fit within those
limitations, and finally make all the pieces fit together in a compelling game.
Working with 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 her 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. One designer may consider
these requirements to be limitations, while a more positive designer may
consider them to be simply constraints. Indeed, many people do their best
work when operating inside constraints; having limitless options can be quite
intimidating and confusing. It is the designer’s job to establish what
constraints the project has, find the perfect parts that fit within those
limitations, and finally make all the pieces fit together in a compelling game.