Full Auto

The player takes the role of a free-lance driver who has recently started operating on the planet. During the course of their first few missions, they begin to discover evidence that the robots are sentient beings; a fact the corporations are covering up so that they can continue to strip the planet's technological wealth. However, it develops that the robots don't intend to stand by quietly; they have their own plans to rid their planet of the pesky humans. Pursued by the corporations, the player must fight both them and the robots to save the sentient inhabitants of both sides.

The game utilised a portal based, real-world physics game engine developed by Pseudo Interactive's President, David Wu. Among other features it included real-time collision modelling, damage skins, reflection maps, variable gravity (in both amount and direction), state-based AI, a robust (and quite complex) scripting system, and a pretty nifty particle system.

The capabilities that using such an engine gave us were phenomenal; instead of having to create discrete animations for actions such as "how a walker robot would react when hit by a car", the physics engine would calculate the forces and vectors involved from the contact of the two moving masses, and the robot would then sway, tumble, stagger, or go flying wildly as the laws of physics demanded, while it's AI continued trying to track you with it's weapon and it fought to regain it's balance. Playtesters often ended up ignoring the plot of the levels and instead repeatedly driving into crates, barrels, light posts, other vehicles, the mechanoids, and the walls just to marvel at how their vehicle and the world around it interacted.

Saddly, being the company's first game it suffered from problems such as feature creep, code bloat, and scheduling overruns, and was eventually cancelled shortly after being featured at Microsoft's Gamestock '99 press event. However, the publisher was impressed enough with the potential shown by the game to continue their working relationship with PI. which is how PI came to be one of the first third party developers working on a title for the XBox console...the title that would in the end be known as Cel Damage.

Being a first project for the company, our work flow and building methods changed a number of times - in some cases, such as when we decided we needed to develop several standardized tunnel sets, necessitating the partial or complete rebuilding of levels. As level designers, we were allowed a substantial amount of input into the development of game features and editing tools; have a cool idea for something in your level that needed a new scripting function today, and with luck (and David having the time to spare to code it), you could have a new toy to play with in the editor by tomorrow. Using nothing more then the in-editor tools, it was easily possible to build very complex machines that not only performed complex actions, but could be controlled in some degree by the player.

I particularly remember one of the missions I was working on, where the player was using a falsified company ID to break into a top secret research facility, in order to steal an item from their vault and then sabotage as much of the facility as they could on the way out. It was decided fairly early on in development that it would be nice if there was a large machine of some kind that the player had to go through in order to gain access to the restricted area of the compound. We called this machine "the sorter".

In one of the earliest versions of this level, the sorter was a giant cylindrical room, within which a large bucket-like structure moved around to accept loads of barrels and then dump them down holes spaced around the cylinder. The player could drive in one end of the cylinder, then drive around on the walls (gravity within the cylinder was set up to always be "down" relative to the moving bucket) and into any one of four openings in the floor. Each opening led to different areas in the complex; in all cases the chutes led to areas where the barrels were subsequently being destroyed, though with ways for the player to avoid being chopped up, burnt, or melted in acid themselves. One of these areas was within the resticted area. In an observation room overlooking the sorter was a screen where the player could view the fate of the barrels as they were dropped down the assorted holes, and from this figure out which route they needed to take.

This initial rather simple version of the sorter required over 400 seperate scripting messages in order to operate...and it didn't even do any real sorting.

By the time the level was revisted for further work half a year later, most of its terrain, architechture, and textures were obsolete by our current building standards, and the scripting tools had gained a number of new features. The level ended up being rebuilt essentially from scratch, during the course of which the sorter was totally redesigned. Instead of the cumbersome multi-gravity cylinder, it became a circular conveyor belt, much like an airport luggage carousel. In a nearby area, items of four different types were "delivered" (randomly generated out of a chute) onto a conveyor belt that then dropped them onto the carousel.  As the carousel circled, the objects passed through sensors at each exit chute which tested to see if they were the right type of object for that chute. If they were, they would be snared and pulled into gravity tubes leading to the areas where they were processed; a grinder, a giant food-processor like blade, a blast furnace, and to an enclosure of small garbage-scavenging alien robots who destroyed and "ate" boxes. There was an observation room overlooking the belt, and a monitor that could be toggled to view each of the different destinations that the objects being sorted were going to, making it clear to the player that only one destination was surviveable. In addition, there was a station where the player could activate a maintenance function of the sorter that lowered the gravity tube of any one chute down to the belt level, enabling the player to then drive around and onto the belt, and be sucked off to the destination of that tube.

Not only did the machine now really sort different objects in a much more complex and compact system...it took less then half the scripting messages that the original "simpler" machine had required.

I greatly enjoyed working on this project and deeply regret that it never reached the stage of being a published game. My particular favorite tasks were the creation and scripting of complex movers, and working on tying together messaging and AI states to make the enemy robots and vehicles operate in seemingly intelligent ways in response to what the player was currently doing.