|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
What Went Right 1. The Scripting Language. Centipede 3D made heavy use of Leaping Lizard Software’s proprietary scripting language. Created to allow easy implementation of game-world objects with unique behaviors, the language was in part intended to allow non-programmers to make modifications to the game. But, as it turned out, this wasn’t really the case; John Marzulli (a programming intern) and I did the vast majority of the scripting work in the game, and were able to do so only because of our programming backgrounds. Indeed, we pushed the scripting language far beyond what its creator, Chris Green, ever imagined it would be used for. The support for "#define" and "#include" style functionality made the scripts quite versatile and powerful. Except for the Centipede’s behavior, all enemy AI in the game was implemented using the scripting language. Because the scripts are interpreted at run time, no recompiling was required when a script was changed, and only the scripts used on a particular level were even loaded into memory. For the PSX version, however, Real Sports Games decided early on that a run-time interpreted scripting system was simply not going to work. In addition, floating-point numbers were used heavily throughout the scripts, and the PSX is notoriously slow at floating-point emulation. Some effort was put into hand-converting scripts into C code. But once the sheer number of scripts used in the game was fully understood, team members began to realize that perhaps there were simply too many scripts to convert in the time available. Chris Green came up with the idea of writing a converter that would take the scripts and convert them into C++ code, substituting fixed-point values for floating-point numbers in the process. The scripts, by their very nature, were completely platform-independent and lent themselves to direct porting. Chris’s script converter worked out extremely well, and its success meant that once we had a one-to-one correspondence between functions called by the scripts and functions available in the PSX version, we instantly had all monster AI and other world-object behaviors converted as well. As a bonus, nearly all of the converted scripts were bug-free, since they had already been through a fairly rigorous testing cycle on the PC. Due to their strange syntax and frequent use of nested function calls, CodeWarrior took hours to compile the converted scripts and it generated a fairly large amount of code. But due to the PSX version’s use of application chaining, only the scripts used on a given level were actually included in the executable, thereby allowing the game to fit in memory despite these inordinately large compiled scripts. 2. Studying the Classic Game. In creating the mock-classic game that was included with Centipede 3D, we had to spend a lot of time studying in fine detail the behavior and balance of all the elements in the original Centipede. We spent many hours in front of our authentic 1981 Centipede coin-operated game analyzing the game play. We came to understand the vital game-balance dependencies between the Flea, Spider, Centipede, and the mushrooms. Remove any one of them or alter how they work or when they appear, and the game falls apart.
Though the classic recreation game included with Centipede 3D didn’t live up to anyone’s hopes, studying the exact play mechanics of the original Centipede did help us immeasurably in designing the modern game. Understanding the classic game-play mechanisms was key to recreating the feel of the original game and allowed us to mimic exactly the movement patterns of the core monsters. Though the renderings of the insects in the new game are nothing like the classic, when players watch the monsters’ mimicked movement patterns in the new game, they see a visual echo of the classic, thereby instantly reminding them of it visually. In the end, much of the game play that succeeds in Centipede 3D is the direct result of studying the game design work that Ed Logg did nearly two decades ago. 3. Correct PSX Decisions. In the process of developing the PSX conversion of Centipede 3D, several seemingly insurmountable obstacles presented themselves. Fortunately, at these junctures the programmers were able to make the right decisions, which, had they been incorrect, could have doomed the project completely. Looking back now it’s easy to see that the choices made were the only ones that could have worked, but when the decisions were made the programmers were relying primarily on intuition and gut instinct. One of the earliest of these crucial decisions was to write tools which would convert the PC level and model files into PSX-usable form, primarily by removing all of the floating-point numerical data. Real Sports Games had bandied about the idea that perhaps new levels should be crafted for the Playstation version. But Real Sports Games decided that there was nothing that the PC levels did from a design standpoint that couldn’t be accomplished on the PSX as well, and since these were well balanced, thoroughly tested levels it was the right decision to use them in the console version instead of discarding them. As the PSX development proceeded and the converted script files were added to the game, it soon became obvious that there was simply not going to be any way to fit all of the code into the two megabytes of main RAM found in the PSX. Once we had acknowledged that something had to be done, PSX project lead Brian Rice decided that application chaining was the only way to get the game to work, arguing down nay-sayers and cynics along the way. As a result of Brian’s quick and authoritative decision making, the game has not just one, but 11 separate executables, with different applications able to quit and run each other as the player moves from menus to game play, or from level to level in the game. By separating out code that was used only in certain sections of the game and removing it from the executables (something which Code-Warrior’s dead-code stripping capabilities simplified greatly), each of the 11 applications was squeezed into the two megabytes available. Without this application chaining, there is simply no way the game would ever have worked on the Playstation. 4. Separate "Classic" and "Modern" Versions of the Game. Centipede 3D started out to be one game but turned into two along the way. Hasbro Interactive, having learned that what people liked best in Frogger 3D were elements that most resembled the original, wanted Centipede 3D players to have a game very much like the one they remembered from the early 1980s. Initially, the designers considered including all of the features that players would expect from a new console-style game — level-based play, exploration, power-ups, and so forth — in some of the levels, while having other levels which matched the classic game play exactly. The two styles of game play were to alternate throughout the levels, thus giving players both new and old style games in one.
But in attempting to mix the two modes of game play, neither was going to work out very well, and players would be confused and frustrated by the constantly shifting styles. The whole team soon realized that having completely separate games was the way to go. One game would feature modern-style game play that would be reminiscent, though quite different from, the original Centipede, and this style would be consistent through the whole experience. The other "classic" game would give the user game play identical to that found in the original game, though presented in a new isometric 3D view. For the PSX version, the classic game was taken one step further, using 2D graphics and sounds identical to the original game’s. In this way, the two different styles of game play could exist separately, with players who wanted precise Centipede game play able to get that, while the modern game was allowed to flourish as a separate entity, no longer tied down to the constraints of the original game. 5. Designer Multi-tasking. There were two designers on Centipede 3D, and both of us were actively involved in the implementation of our design ideas. I served as both designer and programmer on the project, while Mark Bullock was both designer and artist. Together we worked out all the game’s design issues and made all the levels found in the game. By being intimately involved with both the programming and art in addition to our design responsibilities, we were able to come up with design ideas and then implement them almost instantly. Mark could throw together a concept sketch, model the piece, and then I could make the game element actually function in the game world. Instead of having to explain our vision to someone else, we were able to just "make it so" and see how well it worked in the game in a very short time. Though I have nothing against designers who are neither programmers nor artists, our ability to multi-task allowed us to achieve a certain Zen-like state during the game’s creation, which let us crank out the game’s levels in record time. Though we delegated art and programming responsibilities to other members of the team, because we had full understanding of the programming and art limitations of the project, we were able to avoid impractical or unaccomplishable design ideas, and instead focus on what we knew we could get to work in the limited amount of time we had to make the Christmas deadline. |
|
|
Features
