Working with Limitations

Experienced game designers already understand the limitations placed on the creation of games by the technology, gameplay, and story. When they take part in brainstorming sessions, these game designers have a good gut sense of how making certain choices about the game in question will limit its creation further down the road. For each decision that is made about the game, many doors are closed. When enough decisions about the nature of the game have been made, it may be that there is only one type of game that can possibly accomplish all that the designers want. The stage for making major decisions is over, and now all that lies ahead are the thousands of smaller implementation issues.

For four of the games I have completed ” Odyssey: The Legend of Nemesis , Damage Incorporated , Centipede 3D , and The Suffering ” I began development from different starting points. Coincidentally, one game started with story, another with technology, the third with gameplay, and the final with a combination of setting and gameplay. Throughout each game s development I made every effort to remember where the game was coming from and what it was hoping to accomplish. The origins and objectives limited everything else about the experience, resulting in only one acceptable game that achieved the goals I had set.

Odyssey: The Legend of Nemesis

Odyssey started with a story. I actually inherited this project at a point where a significant 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.

Levels in Odyssey: The Legend of Nemesis were designed around the game s story.

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 her 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 I was primarily interested in the story, the game s levels were not designed with exciting battles in mind and combat situations in the game were not as compelling as they could have been. 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. But I do not think that these problems arose because it was a game whose development started with a story. This may be a rare way to begin game development, but it can still be a viable starting point. If I had possessed a better sense of game design at the time, I could have taken efforts to make the rest of the game as interesting as the story was, while never undermining or diminishing the impact of the game s epic tale.

Damage Incorporated

In the case of Damage Incorporated , the publisher, MacSoft, had obtained the license to a sophisticated (at the time) technology that they wanted to use for a game. It was the engine Bungie Software had created for use in Marathon and Marathon 2 , two games I enjoy and admire. In particular, Marathon 2 remains one of the best first-person shooters ever made, easily holding its own against its PC contemporary, Doom . What Marathon 2 lacked in fast-action battles and the atmosphere of menace that Doom created so well, it more than made up for with a compelling and complex story line, superior level design, and a good (though simple) physics model. Indeed, Bungie s Halo built upon Marathon s many innovations, finally bringing them to a wider audience. As a result of my having enjoyed the Marathon games so much, I decided to make my game embrace the technology and gameplay that Marathon had established. I would craft my game around the technology that had been licensed and use that technology to the greatest effect I possibly could.

Damage Incorporated (pictured) had its origins in the licensed Marathon technology.

With a starting point of technology, I crafted gameplay and a story that could succeed using the Marathon technology. Of course, we added features to the gameplay and engine. The primary addition to the game mechanics was the player s ability to order teammates around the game-world, thereby adding a real-time strategy element to the mix. We added to the engine numerous enhancements that allowed for swinging doors, moving objects, and other effects necessary to create a game-world that more resembled the real-world. I was still concerned with story in the game, though not to as great an extent as I had been with Odyssey . Since having conversations with NPCs did not really fit in with Marathon s game mechanics, I worked interesting characters into the game experience through the player s teammates. These fellow marines would chat among themselves as the player maneuvered them through the game-world.

One of the game s weaknesses was that at the start of the project I did not fully understand the limitations of the Marathon engine. It was best suited to creating indoor environments, so outdoor areas ended up looking fake, especially when they were supposed to represent real-life locations on Earth. Modeling the exterior of an alien world in the engine, as Marathon 2 had done, was one thing, but creating environments that looked like the woods in Nebraska was another. Around half of the levels in Damage Incorporated are set outside, and none of these outdoor areas ended up looking very good. If I had understood the technology better, I could have designed the game to take place in more indoor environments, thereby better exploiting what the engine did well.

Interestingly, at the same time I was using the Marathon 2 engine to create Damage-Incor porated, MacSoft had another team using the same engine to create a game called Prime Target . The members of that team did not like Marathon 2 as much as I did, and wanted to create more of a Doom -style shooter, with faster, simpler, more intense combat. Instead of starting with the technology and running with the type of gameplay it handled well, they started with a type of gameplay they wanted to achieve and modified the engine to better support that. As a result, the Prime Target team spent much more time modifying the engine to suit their needs than we did. On the other hand, they were wise enough to set their game primarily indoors, an environment much better suited to the technology. Because of our different decisions in how to use the technology, Prime Target became a significantly different game from either Marathon 2 or Damage Incorporated . Not a better or worse game, merely different. The differences can be traced back to the origins of the idea for their game, and the way they approached using a licensed engine.

Centipede 3D

The Centipede 3D project was started when the publisher, Hasbro Interactive, approached the game s developer, Leaping Lizard Software, about using their Raider technology for a new version of Centipede . Hasbro had recently found success with their modernization of Frogger , and wanted to do the same for Centipede , the rights to which they had recently purchased. Producers at Hasbro had seen a preview for Raider in a magazine, and thought it might be well suited to the project. Hasbro had a very definite idea about the type of gameplay they wanted for Centipede 3D : game mechanics similar to the classic Centipede except in a 3D world. The team at Leaping Lizard agreed. At the time, few games were utilizing simple, elegant arcade-style gameplay, and adapting it to a 3D world would be a unique challenge.

For the development of Centipede 3D , the origin of the game s development lay in gameplay. Recreating the feel of the original Centipede was at the forefront of everyone s minds throughout the project s development. When Hasbro set out to find a company with a technology capable of handling the game, they knew to look for an engine that could handle larger, more outdoor areas, because those were the type of locations a modernized Centipede would require. They knew not to go for a Quake -style technology in order to achieve the gameplay they wanted. Leaping Lizard s Raider engine was a good match with the gameplay, but not a perfect one. Much work was required to modify it to achieve the responsiveness of a classic arcade game. Raider employed a physics system that was by and large not needed for Centipede 3D , and so the majority of it was stripped out. Thus the technology was molded to fit the gameplay desired.

The new, 3D version of Centipede was based on the classic bug shooter gameplay found in the original Centipede .

Centipede 3D s story was the simplest of any of the games I have worked on. In part this is because one of the traits of a classic arcade game is its lack of any real storytelling. For games like Centipede , Pac-Man, and 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 realized that it was the simple, addictive gameplay that would draw players into Centipede 3D , not the story. The classic arcade style of gameplay simply did not call for it. The primary effect of the meager story line was to provide a setup and to affect the look of the game, to explain why the player is flying around blasting centipedes and mushrooms, and why the game- worlds change in appearance every few levels. Just as the original Centipede used the setting of a garden and bugs to justify the game s gameplay, so did the remake. In the end, Centipede 3D was all about the gameplay.

The Suffering

My most recent game, The Suffering , had its origins in a combination of setting and gameplay. The game s publisher, Midway, suggested to the game s developer, Surreal Software, that they wanted an action game, preferably a shooter, set in a horror milieu. Surreal was excited at the prospect of working in a horror space, but we were not big fans of the game mechanics that up until then had dominated the genre . Games such as Resident Evil and Silent Hill , though very good games, relied on scaring the player by limiting their ability to look around the environment with the camera, by having awkward and unresponsive controls, by strictly limiting the available ammo, and by using fairly weak central protagonists. This had the effect of distancing players from the game, forcing them to think about the camera and controls, and making them realize that they definitely were not playing themselves. In short, these games were not as immersive as they could have been, and being big first-person shooter fans we knew that immersion was fundamental to truly frightening someone. Making the game more of a shooter got us a more action-oriented experience and increased the game s potential for immersion.

The Suffering originated with the idea of combining shooter gameplay with a distinctly disturbing horror setting.

So our origins were truly in a combination of gameplay and horror, with both dependent on the other. It was only through the combination of these two elements that we were going to differentiate ourselves among the many games that were available for the PlayStation 2 and Xbox. Certainly, there were many shooters on the market, and also plenty of horror games, but no game that combined both. Without considering both setting and gameplay simultaneously from the very beginning, our game design would not have evolved into a game that accomplished what we wanted.

Though The Suffering was built on existing technology that Surreal had most recently used for Drakan: The Ancients Gates , that engine was significantly stronger at outdoor environments and thus was ill-suited to the dark and shadowy confined spaces of a horror game. From the beginning of the game we knew we wanted to include outdoor environments as well in order to add much-needed variety to the game, but we also knew we would have to rework our technology significantly to pull off our action/horror ambitions. Thus our technology was significantly reworked to use portals that allowed us to include complex and detailed indoor spaces in addition to outdoor ones. Since our primary starting point for the project was gameplay and setting, our technology was forced to change and adapt.