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

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 limitations may come in the formof 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 limitations she is faced with if she hopes to create a good game in the final analysis.

Established Technology

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 may be 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. Even if the designer is fortunate enough to be able to seek out a technology 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 . Engines are becoming increasingly versatile and affordable, but it will be some time before they can be used for all game types on all budgets .

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 she wants. Of course this is not the case, as the designer will quickly be limited by her own skills as a programmer and by the amount of work she can actually accomplish by herself. Except in rare cases, no single programmer is going to be able to create a fully featured 3D technology to rival what can be built by the large team at Criterion or John Carmack and his id Software cohorts. It is simply not possible. Functioning as the 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 and the technology is not specifically built to support this, the frame rate is going to be languid. Throw in some truly sophisticated AI for each of those creatures and your game will slow to 1 FPS, becoming, in essence, a slide show. If she must make that game, the designer has to wait until the processing power required is available, which may not be for years to come. Unfortunately, suggesting that a project be put on hold until the technology improves usually has the direct result of causing the publisher to stop making milestone payments.

Of course, if a designer is truly committed to making a certain game, before giving up she may need to be more clever in how she implements it. Are there tricks that can be employed to make a large group of AI agents look like they are working independently when really they are using a relatively cheap flocking algorithm? How high-poly do the environments truly need to be? Or the really big question: does the game truly need to be 3D at all, or will a 2Dimplementation be just as good? Resourceful and determined designers will be able to find clever solutions to what at first seem like unsolvable problems.

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 that was in the spirit of the original arcade classic. But Centipede s gameplay hinged on the presence of a lot of mushrooms on the screen at once, with similarly large numbers of other insects , arachnids, and arthropods flying around the world, threatening to destroy the player s 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 product s minimum system requirement had been predetermined to be a 133 MHz Pentium with no hardware graphics acceleration. On top of all that, Centipede s 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 polygons 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 game s models 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 3D s already somewhat surreal game-world. Embrace your limitations! I proclaimed in the midst of this discussion, not unlike a weary scientist might finally shout, Eureka! All present thought my proclamation 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 to convert 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 minimalist game.

But in general I still believe that game developers need to embrace their limitations 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 limitations that 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 simplest 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 her, she will pick the best play to show off the particular skills of that 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 responsibility of the project s 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 herself: 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 of such a large number of complex levels and heavily scripted behaviors that they cannot 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, your publisher 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 budgetary-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 programming skills, but at least these are the only limitations. When creating art, there is a lot to be said for not being beholden to the person writing the checks.