Starting Points

Perhaps a quick example is in order. Say a game designer feels the need to create a game based around the specific stories of Greek mythology. This would be starting from a story. Immediately this limits the type of gameplay she will be going for. Chances are a Civilization -style strategy game is out, since that sort of game really has nothing to do with the classical stories of Zeus, Heracles, Ares, and so on. A real-time strategy game is out of the question as well, since it is not good at telling stories involving only a few protagonists. A high-end flight simulator is probably not going to work either. The designer 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, the designer will need some way to communicate a lot of back-story information to the player. Thus there will need to be technology in place that can allow this. Furthermore, if the designer 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, unless one plans on being deliberately retro and opts for a 2D action-adventure in the spirit of Crusader: No Remorse . If a 3D technology is to be used, in order to tell the story of Greek mythology properly it 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 Unreal -style 3D engine is a big mistake. Just as if one tried to tell the story of the Greek gods through flight simulator gameplay, the game would simply fail to work. Herein lies the difficulty with many high-concept ideas, often the brainchildren of marketing specialists who want to capture disparate markets with one product. If the parts do not work together, it does not matter how many markets the concept covers ” no gamers will be interested in playing the final game.

Starting with Gameplay

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 what sort of story, if any, the game will be able to have.

Depending on the type of gameplay you are hoping to create for the player, you need to analyze what sort of technology that undertaking will require. Does the game need a 3D engine, or will 2D be enough or even more appropriate? What sort of view will the player have of the game-world? Will it be fixed or dynamic? Does the action transpire fast and furious with a large number of entities moving around on the screen at once? Are the game- worlds large or small? All of these questions and many more need to be analyzed to understand what the game s engine must accomplish in order to properly execute the gameplay idea. Of course the 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 not fight that technology with incompatible gameplay. Instead you should try to conceive of gameplay that 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 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.

Starting with 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 or pre-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 the sophisticated 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. 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 that technology.

Just as starting with a desired sort of gameplay dictates what type of engine should be created, starting with set technology requires that the game designer consider 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 technology 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. Often, when a project is using a licensed game engine, that technology will have been chosen with a certain type of gameplay in mind. The designer needs to seriously consider how far she 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 pushing it in directions its programmers never imagined. For instance, the oft-licensed Quake engine (in all its various incarnations) 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, one of the most artistically successful licensees thus far, Valve, retained much of the standard Quake gameplay that the engine excelled at for their game Half-Life. Certainly Valve added a lot of their own work to the engine, technology that was necessary in order to do the type of game they wanted. 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, at least not in their first title with the technology. 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 her game.

The designers of Half-Life smartly used the indoor first-person shooter gameplay established by Quake , the engine licensed for the game s creation. Pictured here: Quake II .

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 streaming technology that allows for the playback of 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 she must use. Trying to tell a story with an inadequate engine is just as likely to compromise the game as tying a particular story to inappropriate gameplay. Again using the example of Half-Life mentioned above, if the team at Valve had tried to set their game in Death Valley and involve the player battling gangs of twenty giant insects at once, the Quake engine would have ground to a halt 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.

Something else to always keep in mind when considering how your technology will limit your gameplay and story is how you can creatively work around your limitations. For example, if you are trying to do a game about massive battles with thousands of individual units, do all of the units need to be represented in 3D, or will a 2Drepresentation work just as well? Or, perhaps you never need to have all of the units in the world at the same time; you could tell the story of such a gigantic conflict from the viewpoint of a single soldier in that battle, with between-mission updates that show the larger picture. For an example out of my own past, my ill-fated game Gunslinger tried to capture the myths and storytelling of the OldWest. We had a technology that was perfectly suited to rendering sprawling outdoor environments in 3D, so it was a natural fit to the game. But if we had only had a 2D engine, there is nothing to say we could not still have done a tale about the legends of the Old West in a 2D game with a god s-eye view of the proceedings . As a game designer, it is possible to get stuck in a rut of how a game needs to be done and forget the potential for alternate implementations that may be a better fit for your technology.

Starting with Story

Finally, it is certainly possible that the brainstorming for your game may start with a setting you want to employ, a story you want to tell, or a set of characters you want to explore. This is probably a less common starting point than technology or gameplay. Indeed, since many games have no story whatsoever, the very concept of a game starting with a story may seem strange . At the same time, it is not unheard of 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 under the definition of starting with 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 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 general s-eye view of the game? In that case, gameplay that allows for the tracking of tactics and logistics should be used. Or does the designer want to tell the story more from the view of the soldiers who had to fight that battle? Then gameplay that would allow the player to track and manipulate her troops unit by unit would be appropriate. If conversations with non-player characters (NPCs) are an important part of communicating the story, the designer will need to design game mechanics that allow for such conversations, using typed-in sentences, branching dialog choices, or whatever will work best. The designer needs to find gameplay that will allow the player to experience the most important elements of whatever story she is trying to tell.

Of course, the technology will have to match up with the story as well, 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.

Maniac Mansion was the first of the story-centered adventure games from LucasArts to use the SCUMM system.

Good examples of story-centered or at least story-dominant game design are some of the adventure games created by Infocom and LucasArts. All of the adventure games from these companies used very standardized play mechanics and technology. The game designers worked with the company s proprietary adventure game creation technology, either the Infocom text-adventure authoring tool or LucasArts SCUMM system. By the time the game designer came onto the project, her process of creation could start more naturally with creating a story she 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. And of course, there was a lot of game design still to do, in terms of coming up with what the player s actions and choices would be in that specific story, what puzzles would be encountered , and so forth. Both Infocom s and LucasArts tools were general purpose enough to allow the designer to create a wide range of games, with a good amount of variation in terms of storytelling possibilities, even though the core mechanics had to consist of a typing-centered text adventure in the case of Infocom and a point-and-click graphical adventure for LucasArts. Thus the game designers primary driving motivation in the game s creation could be telling a story, with the designing of game mechanics and technology development much less of a concern. Just as film directors are limited by what they can shoot with a camera and then project on a 2D screen of a certain size 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 the mechanics of the medium were firmly established well before both the film director and the adventure game designer began their project, they were freed up to think beyond the nuts and bolts of the audience or user s gaming experience.