Gunship-X -- A.E.G.I.S. and Salvo Projectiles

As noted elsewhere, I've been slack and/ or busy of late so I haven't really been putting much work into my Gunship-X project. That changed last week, however, when I finally got some time to myself and put some work into the game. Aside from the prerequisite bug fixes, most of the work's been put into beefing up and enhancing the improving the feel of weaponry in the game (making it look a little nicer, feel more fun to use, etc), on modelling some ground structures, and on adding support code for said structures.

In the (admittedly low-quality) video you can see the new A.E.G.I.S defensive buildings able to be deployed in the mission by the Support class. They're relatively simple structures -- moderately heavily armoured, fitted with regenerating shields, and armed with a rapid fire (and unlimited ammunition) autocannon, that while inaccurate does quite a bit of damage and imparts no small amount of kinetic energy when it hits. They're not game-balanced yet, of course, so their accuracy and damage may be subject to change in the future. =)

Of particular note in this clip is the improvements I've made to the "salvo" projectile class (used by both the player's autocannon at the beginning and the A.E.G.I.S. throughout). This is a pretty cool piece of code that allows you to do extremely rapid-fire or shotgun-like weapons without having to worry about that annoying "don't always show up immediately when you fire them" bug that plagues Torque projectiles.

The autocannon on the Assault gunship is firing at a rate of around 1800 rounds a minute while the dual cannons on the A.E.G.I.S. are firing at around half that (each). As you can see, they put an awful lot of projectiles into the air -- with relatively little overhead (especially compared to stock Torque projectiles). I played around with shooting at higher rate of fire but there doesn't seem to be much reason to bother going much higher than what I've got. The additional processing expense and visual clutter just don't warrant it.

You can't quite see it in the video due to the quality but those very same "salvo" projectiles make use of some new material-based effects code that causes the projectile collision effects to change based on the surface they're hitting. They'll pop up rocks and dust hitting stone and earth, clods of mud hitting swamp, globs of molten rock hitting lava, sparks hitting metal, and so on. I've found the sparks-on-metal especially adds to the appearance of the game. They let you know just when you're landing hits on another gunship and it looks fairly cool to see a gunship covered in sparks from a hail of gunfire.


During my week of development I did have one doozey of a bug. It took over an hour and dozens of release builds to track down a bug that seemed pretty basic: in release builds, the A.E.G.I.S. turrets fired a single round and then ceased firing completely. Nothing I could do seemed to make them shoot again.

I looked through targeting code, prop states, triggers -- all sorts of stuff related to how the turrets acquire and engage their targets and couldn't find anything. I made changes to how they activate their weapons, the conditions under which they'll shoot, how they're animated and oriented at their target -- anything I could think of that could have a potential impact on the problem -- but I couldn't seem to find out what was wrong.

After an hour or so of of pulling out my hair going through code line-by-line, making small changes, and rebuilding the executable, I had finally had enough and opted to shut down all my programming stuff to go play a game of Left4Dead with some mates.

In the midst of closing down my programs -- as my cursor hovered over the Exit option in UltraEdit32 -- the answer hit me. I was looking in the wrong place. The problem wasn't in the code, it was in the script.

I'd spent so much time coding over the last few days that I was completely ignoring the scripting side of things. I was suffering from tunnel vision concerning the problem. If the bug only occurred with the new objects and the new objects exist only because of the new code, my reasoning went, then obviously the bug exists only because of the new code. While that's often true, it isn't a hard-and-fast rule. In this particular case, it was completely and utterly wrong.

So, after an hour of pure frustration and ultimately fruitless toil, I finally began looking in the right place. Ten minutes later I had my answer.

It turned out that the problem came from a little helper function (read: "cheat") I've got automatically-enabled in debug builds that grants you infinite ammunition (for testing purposes only, of course -- it's not like I've ever used it to wtfpwn someone in a game -- that I'll admit to anyway). In a debug build, you load up the mission, place an A.E.G.I.S. and everything's hunkeydorey. It starts shooting at enemies and continues shooting at enemies until it's destroyed or the mission ends.

In release builds, however, things occur slightly differently. Without the cheat enabled, the weapons platform fires once and then RUNS OUT OF AMMO. Given they're supposed to have infinite ammo, this is... problematic at best.

When all was done and said, the fix was a single line of script -- one static field in a prop state datablock that specifies whether or not the weapon uses ammunition. Set to false, the problem vanished. Go figure.

The lesson to be learned here is that you can often unintentionally blinker yourself to when and where bugs exist. Sometimes you're better off taking a step back and chilling out rather than trying to force your way through an issue. Though you can sometimes break through a roadblock by bashing your head against it over and over, usually you just end up with a headache. =)