[Archive] Of Game Engines and Swarm Missiles

Posted by Rampant Coyote on September 1, 2015

Editorial Note: This is an article that first appeared in the previous blog back in January 2006. Yeah, it’s old, but still valid. I’ve edited it to bring it up to date. Although I must admit, working with Unity has provided me with a lot fewer ugly surprises than some other engines.

In early 1995, I was working on both Warhawk and Twisted Metal for the then-upcoming Playstation (the first one) 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 “kittywampus,” matrices would get turned around, and sometimes the game would freeze. 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 engine 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 multi-million 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 that sounded so huge to these guys, they decided they never really needed to test to see if you exceeded that boundary (although 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, plus fixing the 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 is there the moral of the story?

Not really. Just that as developers we’re always building on someone else’s foundation… even down to the O.S. level, and nothing non-trivial is bug-free. Whether it’s a full-on game engine or using a third-party piece of code. I absolutely love working with Unity, but even so I run into some major problems from time to time that I assume must be my fault, especially when the developers won’t acknowledge them (like light-mapping issues with the new light engine… grumble, grumble). I’ve had the problem with Microsoft APIs that are super-mature (albeit not super-popular) and have been around since at least the Windows NT days. How could someone else not have run into this problem before me?

The trick is recognizing the problem for what it truly is. Beginners tend to be a little too quick to blame their tools, and sometimes the veterans may be a little too slow. Trying to figure out what to do from there… is it possible to fix it yourself, or get the developer to fix it, or can you come up with a work-around?  Tough decisions.

Filed Under: Programming - Comments: 4 Comments to Read



top