It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.

Search articles, jobs, buyers guide, and more.

By Richard Rouse III
Gamasutra
September 10, 1999

This article originally appeared in the September, 1999 issue of:
Game Developer

Letters to the Editor:
Write a letter
View all letters


Features

 

Contents

The Task at Hand

What Went Right

What Went Wrong

The Team

What Went Wrong

1. Classic Game Should Have Been Emulated.

Despite our best efforts, the classic game that comes with Centipede 3D is not precisely the game that Ed Logg created. There are differences which any hard-core Centipede fan will notice, and both the PC and PSX mock-classic Centipede games don’t quite feel right. The new 3D visuals in the PC classic game don’t really do anything to make the game any more fun, and even though the PSX goes so far as to look and sound exactly like the original Centipede, it still just isn’t the classic.

conceptually evile
Concept art for the Evile level.

Though many software companies are wary of emulators and the income they may be "stealing," here is an instance where one could have worked wonders. Many such emulators exist on the PC side, and one had even appeared for the PSX, as used in Midway’s Arcade’s Greatest Hits: The Atari Collection. Instead of the great quantity of man-hours spent trying to recreate the classic behaviors and game play, the same amount of time could have been invested in writing our own emulator that would have permitted us to include the authentic Centipede with Centipede 3D. Perhaps if we had realized early on that we were going to end up with two completely separate games, instead of the single game we originally designed, we might have seen that emulation was the best solution to the challenges that lay ahead. No one fully realized how much work would go in to recreating such a simple game precisely and I firmly believe no amount of work on the mock-classic would have resulted in a game that was as good as the original ROM. When attempting to pay homage to the brilliance of a classic game, nothing does as well as presenting the actual game itself, functioning exactly as it did when it was released.

Flatten Wally
The Shooter - the ship the player controls throughout the game - has four different LODs. Since the default camera view is so far from the ship, most of the time players probably see LOD number three or four. Notice that Wally, the character in the Shooter, has turned into a plane by LOD four.

2. Game Was Too Hard.

From the beginning, Centipede 3D was supposed to be a mass-market title, a game anyone could pick up and play fairly well from the start. Definitely not aiming at the hardcore game player, Hasbro Interactive had seen wild success with its mass-market Frogger 3D and wanted Centipede 3D to appeal to exactly the same consumers. It was said that even Frogger 3D was too hard in places, and if we could make Centipede 3D easier, we’d be heading in the right direction.

But it was not to be. In the end, Centipede 3D turned out to be a far more challenging game than Frogger 3D. As a designer on the project and the one largely responsible for balancing the levels from a game-play perspective, I take full responsibility for this shortcoming. The usual problems that lead to excessive difficulty can be found to be true here. First of all, none of the people playing the game during its development — designers, programmers, producers, and testers — could really be considered members of the computer game mass-market. We were all adept at a variety of games, including many distinctly hardcore titles, and as such, we were far more experienced than the target audience. The members of the team who were not such avid game players were not encouraged to play the game as much as they should have been, and consequently, they didn’t voice complaints about its difficulty.

There were many complaints early on in the game’s development that it was too difficult. Accordingly, I did some work to remedy this, and by that time the complaints had disappeared. I concluded erroneously that the tweaks I had performed had fixed the difficulty problems, and hence stopped worrying about them. What had really happened, I suspect, was that I made the game just slightly easier, and that in the time it took me to accomplish that, the people who had been complaining about the game’s difficulty had gotten a lot better at it, and therefore stopped complaining. The solution to the challenge of testing the difficulty of a mass-market game, it seems, is always to test the product on a "newbie," someone who has never played the game before. Only then will one know for sure if the game is getting easier or harder.

Actually, I think Centipede 3D is just about as hard as the original Centipede, perhaps even a bit easier. A game on the classic version only lasts a few minutes for the majority of players, and was designed as such to maintain a steady flow of quarters. Though Centipede 3D was aimed at the home market from the start and as such should have provided a much longer average play experience for users, I like to think it was the game’s emphasis on being like the classic that made it so hard.

3. Extended Crunch Schedule Prevented Long-Term Planning.

When I started working on the PSX version of Centipede 3D in October of 1998, everyone involved with the project was estimating that the conversion had about two weeks remaining. Two weeks later, after I had spec'd out all of the game-play elements that were still missing from the PSX version, it was decided again that there were two weeks left to get all of those game elements working. This pattern continued as the project extended on for another six months. No one involved fully realized the scope of getting Centipede 3D to function on the PSX.

From a business standpoint, the project needed to be done in two weeks, but unfortunately, from a programming standpoint, there was no way this could happen. Being in perpetual crunch-mode and constantly thinking the game was nearly finished, programmers were inclined to hack systems together in the quickest way possible, not fully considering all the problems that might result from such hastily constructed code. In the end, much of the rushed code had to be rewritten to fix all the bugs associated with it, which further extended the development time. The ongoing feeling that the game was nearly finished, but then not having it work out that way was also horrible for morale. If anyone had fully realized how much time was left on the project, the programmers could have taken the time to port systems correctly, look at the project wholistically, and structure their work better. In the end, coming up with a more realistic schedule might have shaved a month or two off the total project time and resulted in a less stressful experience for the team.

4. Incompletely Ported Systems.

In porting the game over to the PSX, some of the key systems in the PC game were initially rewritten without fully understanding or considering all the functionality they had to include. In part because of the intense schedule we were working under, programmers would often look at how a given game system worked in a few situations and then make sure their implementation of the mechanism would perform all that they had observed, instead of going over the PC code and converting it line by line. Unfortunately, usually only the early levels were considered during this observation stage and it would turn out that on later levels the system had to do a number of additional things that its ported incarnation could not. In the worst-case scenario, the only way to get that system to include this additional functionality was to rewrite it from scratch.

One example of this problem was water. Centipede 3D for the PC uses a massive textured plane for its water, which is drawn before any terrain geometry is rendered instead of clearing the screen, and which could thereby extend to infinity past the edge of the game world. This caused us to design many of the game’s levels as islands set in the middle of infinite seas. The water also had the advantage that it could trivially be made to rise to any elevation, potentially flooding previous areas or the entire level, a feature we exploited when designing the game. Due to Z-buffer limitations on the PSX, Real Sports Games realized early on that it was impossible to implement water in the same manner in the console version. The developers at Real Sports went out of their way to create a water system for the PSX version that in some ways looked far better than the PC version’s water. Instead of being a flat plane, its water was composed of triangles which undulated up and down in beautiful, wave-like formations. This looked great on the early levels that had relatively small quantities of water. Unfortunately, the more space on the level the water filled, the more memory it took up due to all the vertex data. The levels that were tightest on memory were ones that featured a lot of water, and a lot of time was spent pruning other objects from these levels in order to prevent them from overflowing the PSX’s memory. Furthermore, the PSX version’s water, due to its memory-intensive nature, could not extend forever as the PC version’s water did, and consequently, the island levels looked ugly. If from the start the PC game’s water usage had been looked at on all the levels instead of just the first few, it is possible that a completely different implementation of the water on the PSX could have been undertaken, one which would have included all the necessary functionality.

5. No Updated Design Document.

In a project such as Centipede 3D, where two separate teams were working on two separate code bases on games that were supposed to share a design, a living, up-to-the-minute design document is an absolute necessity. Unfortunately, beyond outlines written early in the project, most of the design was understood by the two people who had to make it work — Mark Bullock and myself — and not by anyone else. Indeed, for the PC version it wasn’t necessary for anyone else to understand all the intricacies of the design, since we were working as such a close-knit team, and when anyone had questions about the desired functionality of a particular piece of code or art, they could come to us and ask.

Most of the game play and all of the levels for Centipede 3D were created between March and September. Given that intense crunch schedule to get the PC version out for Christmas, there really wasn’t any time for either Mark or me to maintain a complete and up-to-date design document, nor did anyone ever suggest we do so. Unfortunately, with a PSX development team a thousand miles away, a document that completely spec’d out everything that happened in the game was vitally important for keeping the two teams in sync. Without such a document, the PSX team didn’t fully understand all of the different bits of game play and AI found in the PC version, nor did they fully comprehend the scope of some systems.


The Team


join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2003 CMP Media LLC

privacy policy
| terms of service