be employed to make a large group of AI agents look like they are working independ-
ently 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 2D implementation be just as good? Resourceful and deter-
mined designers will be able to find clever solutions to what at first seem like
unsolvable problems.
The Case of the Many Mushrooms....................
When working onCentipede 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. ButCentipede’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 3Dto 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 accelera-
tion. 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 withCentipede 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 limita-
tions 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 technol-
ogy? 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
54 Chapter 3: Brainstorming a Game Idea