Technical design


The central concept behind Terran Interceptor is arcade-y dogfighting. The player should have the tactile experience of controlling a powerful machine, in the context of other powerful machines. They should be able to control their machines and be rewarded for that skill, feel powerful, but still have limitations that, intuitively, make sense.

In other words:

  • Nimble units should be able to turn on a dime, heavy units should feel ponderous but powerful.
  • Mastery should reward the player.

From that concept, I derived the following.

Specs

  • Units have to be have unique characteristics in the physics implementation.
  • The height of units has to be affected by terrain, and should be available to other units for targeting purposes.
  • All abilities have to function in the context of the physics implementation and control scheme.
  • Enemy AI has to react to player within the context of the abilities and physics available — Enemy AI should play by the same rules as the player.
  • The UI should be informative but unobtrusive, with the camera presenting the right amount of information at all times.

And to put this feature list into perspective, here are the pros and cons of doing this in the StarCraft 2 Galaxy Engine:

Pros

  • Massive set of art assets.
  • Strong, modabble scripting system.
  • Easily repurposable UI.
  • Robust animation system.

Cons

  • No native support for momentum-based movement.
  • The scripting system can be slow due to round-trip communication.
  • Standard enemy AI wouldn’t be able to control units properly.
  • Critical UI elements don’t natively exist for this gameplay type.

The truth is this: It’s a bad idea to shoe-horn gameplay so divergent from the engine’s main focus as I did here. Hundreds of hours went into research and experimentation before there was a workable prototype.

Nevertheless, once there was a workable prototype, the engine’s other features proved to be useful, and having the wealth of assets to back it up proved to be invaluable.

Physics

The physics that are simulated are rather simple. Each unit has a set of characteristics that allow them to have distinct behaviors that match the desired effect, and no more. These included momentum, speed and weight affecting maneuverability, and units flying over terrain in a way that was gameplay-significant.

In order to get a calculation of momentum (which happens on a 2D vector) StarCraft 2’s own engine had to be circumvented. All the calculations happen in a persistent trigger that runs 60 times per second, looping through all the units simulating physics. This is the reason why all the other systems had to be redone.

Even so, if I had completely cut off the underlying movement system, I would’ve also lost things like height detection and animation, as these hook into movement at a deeper layer. Both of these features were essential for the experience that I was going for. In order to make things play nicely with one another, I left the movement system active, but reduced all its values to their minimum setting.

The performance hit was unavoidable. Units don’t respond as crisply as they could, but the lag didn’t raise to an unpleasant level. The game design was tolerant enough for it.

Heatseeker

One of the signature elements of dog-fighting games is the tracking missile vs. countermeasures gameplay. Terran Interceptor incarnates that element with its abilities “Heatseeker” and “Flares”.

Heatseeker is a two-phase ability:

  1. Lock-on
  2. Attack

Players trigger the lock-on phase, spawning a narrow search area that expands over time, pulsing a target search. This flow is described in the following slide:

Once a valid target is locked, the missile launches and pursues. The target can break the lock using “Flares”, which forces the missile to switch targets.

Given how the Galaxy engine is structured, the best way to implement both was to leverage the data layer . Going through the script layer would be easier, but make for less responsive abilities. For the ability to work properly in fast-paced combat, it needed better performance.

The search effect & UI animation speeds had to be synchronized so that the ability felt like it was working as advertised, allowing for counter-play by evading the search area — that also had to move with the fast-moving unit casting it.

The AI also had to be trained to use both heatseeker and flares appropriately so that light fighters could be an effective threat without “cheating”.

An accidental discovery is that flares can be used aggressively. Since the missiles are quite powerful and carry a moderate AoE effect, using flares while the enemy is in the lock-on phase would mean that they could get caught by the missile exploding right in front of them.

Lessons Learned

One of the harder lessons that I had to learn during the development of this map, and other maps that use this type of custom gameplay, was that if you change basic behavior, like movement as I did here, you will have to change everything else around it.

The AI had to change, the UI had to change, the way the camera behaves, the way maps are laid out, etc. I ended doing a fairly deep dive into the inner workings of the Galaxy engine as a result. It was a good experience to have since it made me more comfortable learning complex systems in game engines, but it did slow down development considerably.

The end result, nevertheless, accomplished the goals I had set for this project.