Sometimes, you just have to admit that you’ve ended up melding critical gameplay logic with artwork, and maybe that’s not such a great idea.

Yes, as I was working on beefing up my Milkshape model importer to automatically generate entire units, I stumbled into… well, an issue that had been on my mind for a while (as well as realising that making a model wholesale generate a unit is also a bad idea). Time to do a whole universe of rewiring to achieve absolutely no visible impact!

Past Mistakes

I’ve mentioned a thousands times how I grew up modding Warcraft III. In there, gameplay and art are completely distinct — you can swap Arthas to look like a Footman, and barring the Footman not having quite the same timings or animations available, it’ll Just Work. Hell, you can swap Arthas to look like a Barracks or a Rock Spire and he’ll still be the same old This Town Must Be Purged dingbat.

Unity doesn’t have that same hard separation of art from everything else. When Unity imports a 3D model, animated or otherwise, it becomes a structure identical to anything else in your game world — a blob of GameObjects, Transforms parented under each other with Components dangling off them. Sure, some of those components are MeshRenderers and Animators, but anybody else could have those added manually. There’s nothing strictly “this came from a model file” about the end result.

When I was first building Exon, this led me to do a few things that are, in hindsight, a little bit daft. Take my Equipment Slot system: of course it makes perfect sense that the Right Hand equipment slot should literally be on the Right Hand bone. It’s a hand and it’s logic to manage the hand. Keep it all in one place. Right? Right?!

The Undercarriage equipment slot is maybe a better example. I recycle the “Delta Legs” for both the bog-standard Delta that does not have any Undercarriage slot and for the Epsilon that does (your player character is an Epsilon mech, so it has all the slots). That puts me in a bind: do I add the Undercarriage slot directly to the Legs model, and thereby give it to units that shouldn’t actually have it? Or do I duplicate the entire leg assembly and give the slot to the Delta version and not the Epsilon version?

I took the latter option, but that is the root of my problem: it means building a new unit involves a huge amount of manual effort, to process the incoming artwork and add all its gameplay logic pieces… and it’s manual effort that has to be repeated even if I’m recycling an animation set. That’s No Good. (Not to mention that this incredibly awkward manual step also spoils our secret quest for moddability.)

So phase one is to get those Equipment Slots out of the models. They’re a factor of the unit’s type rather than its patchwork of visual art pieces, so let’s not munge them together, no matter how “intuitive” it feels.

Luckily, there’s nothing intrinsic to the logic of an Equipment Slot that requires it to be in any particular place. The only thing that needs to be linked up is that the Slot has to know which bone it should attach the item art to — so, for example, the sword gets waved around appropriately by the attack animations. “You are Main Hand, and items for you are attached to the Hand_R bone (at this Offset).” Bang. (The fact that a sword is also both art and a huge blob of logic is another problem for another day. Or maybe it’s not a problem at all? Who knows!)

I’ll spare you the details of how much shit that conceptually simple rearrangement actually involved. It wasn’t pretty. Then, of course, I had to migrate all the forty-odd unit types I’ve already got in the game (though to be fair, most of them are Arena combatants who use the same underlying components but with different colour schemes).

This rabbit-hole also dragged me towards another system that was maybe always a bad idea but seemed reasonable at the time.

The engine behind Exon has been designed and built from the start to handle “mechs” — that is, machines that move independently but only gain attacks and abilities from interchangeable pieces of equipment. But if you’ve played the demo, you’ll know that the world is also populated by creatures. These giant transgenic animals don’t have interchangeable equipment slots, they have claws and teeth. They can do melee attacks with those claws and teeth, so they need to use the same damage-arc logic as the mech sword attacks, but they don’t use swords to do it and they won’t drop swords when they die (unless they ate some).

Except, of course, because I couldn’t be bothered dealing with it properly at the time, I simply gave them invisible, fake swords. The Rust Mite had a Jaw equipment slot and a Mandible “blade” socketed into it. These kinds of idiosyncractic solutions are the bread and butter of gamedev, sure, but this once again costs a whole heap of extra effort to build a unit: not only do I have to add an equipment slot to something that shouldn’t have it, I have to build a whole separate “weapon” item to go into it and plop that into the skeleton too.

The answer I have now taken on, the one I should have done all along, is to build out the concept of an “innate” attack ability. This hijacks the attack animation logic — which controls pulling back, lunging forward and recovering, adjusting for speed buffs and so-on — but instead of being locked into using a sword item to determine damage, it allows for generic flat damage or even launching a projectile instead. That means it covers the Spark Mite’s lightning bolt as well as the Rust Mite’s mandibles, with only a smidge of data entry. No faffing with wiring fake items into fake equipment slots and ignoring screeds of values that don’t need to be there.

So yes, if you’re wondering why I haven’t shipped The Rest of the Prologue (or bonus adventure Ultralight) yet, then this is why: the Milkshape importer work opened a can of worms and oh me oh my, I simply cannot resist trying to close a can of worms. (Also I bought Skyrim.)