On Game Engines and Swarm Missiles
In early 1995, I was working on both Warhawk and Twisted Metal for the then-upcoming Playstation 1 for Sony. Both games started with the same code base, and then diverged, but parts of the code (specifically the graphics and sound engines) remained shared between them.

We had a rather bizarre problem in Warhawk where suddenly everything would go haywire - usually when you were shooting the ever-popular "swarm missiles" at enemies. The cockpit would go "skittywumpus" (is that how you spell it?), matrices would get turned around, and sometimes the game would CRASH. Since the symptoms almost always appeared when the player was firing swarm missiles, and I was the man who'd written the code for all the weapons, the bug fell upon my head to "fix the swarm missiles." I had the bug on my list for WEEKS, and I had assumed (rightly so) that somewhere in my code I was clobbering memory that didn't belong to me.

It was especially nerve-wracking, as the cluster of six swarming, bobbing, 'flocking' missiles dancing around each other as they shot towards a target was a major 'seller' for the game in demos, and you do NOT want the game to bug up during a demo! Our executives were told only to show the the swarm missiles in the "pyramid level" (level 1), as it was harder to cause the problem on that level.

I was getting desperate one morning, and began tracking the logic through the engine code (We didn't have very good debugging tools for the Playstation in early 1995 ). Now, this WAS an in-house engine --- I'd mucked around in it before, and was familiar with the basic logic, but I wasn't one of the principle developers. THAT honor belonged to some of the guys, headed up by Randy Zorko, who had spent several years at the simulation company Evans & Sutherland. These guys were used to working on multimillion-dollar simulators for the military and civilian industries. They were also used to the limitations of these incredible super-computers.
As it turns out, one of the limitations they were used to was the number of "Coordinate systems" (read: independent, fully 3D models) in an environment. I think some of the best E&S systems could only handle something like 14 of these objects in the world at a time. So you'd have the user's plane, and maybe six other planes, and potentially six missiles in the air at a time. So they'd created a buffer of these objects which you could acquire from the engine, and they guessed some ASTRONOMICAL number of models which the engine could handle - something like sixty. Because the number was something so huge, they decided they never really needed to test to see if you exceeded that boundary (though theoretically the function was supposed to return a failure if there were none left).

Any programmers reading this can immediately spot the problem.

Every time you fired the swarm missiles in Warhawk, you created TWELVE new "coordinate systems" in the game. Six missiles, and six contrails (which were models that were built on-the-fly, a trick I also used in Void War). When our executives were giving demos to people, they were always playing in "God Mode," which gave you unlimited ammo and invulnerability. This meant they could fire a LOT of Swarm Missiles. It was quite possible to get three or maybe even four sets of missiles up in the air simultaneously. Add to that all the enemy planes, gun turrets, tanks, and enemy-fired missiles, and you can blow past that 60-CS boundary without too much trouble.

Randy was able to fix the problem in the engine in about five minutes, expanding the boundary to something like 90, AND adding a check to make sure you didn't blow past that (I don't think we ever did, in the ten games or so that used that engine). And the Swarm Missiles became famous.

So the moral of the story? I dunno. I was reminded of this as I was back in the "hate" phase of my love-hate relationship with the Torque Game Engine a few days ago (I'm back in the "Love" stage now; Torque was very nice to me yesterday). Building stuff on top of someone else's code is almost never a "free win", or even an easy win. The documentation is almost never adequate, and there's always a bunch of assumptions built into the engine (also undocumented) as to how and why its going to be used that rarely mesh with your own ideas of how its going to work. The bigger the engine (and Torque is HUGE), the more digging is going to be necessary to understand it and figure out how to change it to match your own expectations and needs.

Fortunately, Torque has a pretty solid community behind it, so while it's not quite the same as having the genius mastermind designer of the whole thing like Randy Zorko at your beck and call, it has helped reduce the gravity of some of the real hair-pulling problems I've run into so far.

Labels: programming, retro

- posted by The Rampant Coyote @ 3:46 PM (Permalink)