For making game that is ultimately going to be about robots with swords, I’m fair bearing down on implementing gunplay right now. Well, the robots with swords will have guns too, so they will still need to be good — and most of the enemies will only have guns.

In the interests of simulated reality, enemy guns must function just like yours. They will require ammunition and they will require reloading… Unless the particular weapon does not require these things, of course.

How hard can it be?

Ammunition

It started off easily enough. I gave each weapon a counter that decremented each time it fired; when the counter reached zero, it caused the weapon to reload and then reset to maximum clip size.

That approach was a result of my simulationism — I want weapons to be triggered by their wielders, with the weapon then firing itself or reloading or cooling down based on its own internal circumstances. As if it was, you know, an actual gun.

The problem with that was that my weapon pairs got out of synch as soon as ammunition became limited; although the weapons are unique snowflakes, they are still fired as a pair by a single button. So if you’ve only got 10 shells left and each cannon has a clip size of 10, the first one in gets the 10 and the other one gets nothing — then you’re firing one-sided. If you then acquire some more shells, half-way down on one side, then they’re reloading at different times. Oh dear.

(This will be an issue again for sure if I ever implement left-right staggered firing rather than paired firing, but I’ll conspicuously not do that one for now, or at least limit it to non-player characters who don’t care about paired weapons being out of synch. Or I could explicitly put left and right guns on the UI, but that would take even more effort.)

So, take a step back. Dual-wielded — or, in the case of the alpha, m-m-m-m-monster-wielded — weapons need to only pretend to have individual clips. They need to share a single magazine behind the scenes to make sure they get their fair share of ammunition during reloading and thus remain in synch behind the single trigger.

Where to put that shared magazine, though? Although weapons are paired, there’s no bridging object in which to store common properties. Each weapon has a note of its paired companion plus which side it’s on, so we know which one is which, but there’s nothing more than that — and I’d rather not duplicate information on both sides.

This is where my utopian simulation starts to break down: it seems like ammunition needs to be handled by the wielder of the weapons, rather than the weapons themselves. Boo.

Luckily, weapons held by a unit are already controlled by an Ability, this being a future-proofing exercise for when other pieces of equipment or special capabilities are activated in the same way (i.e. the AP-AM’s sword-arms). In this case, I have a MultiFiredWeaponAbility, which can variably cope with the dual wielded rifles of a Delta or all eighteen of the Alpha’s cannons. In short, seemingly an ideal place to store the current ammunition information that needs to be common to every weapon in the set.

The thing is, holding ammo in the wielder rather than the weapon stops the dropping of weapons with half-spent clips in them — and the picking up of brand new weapons with a starter clip. Since the weapons themselves don’t actually contain ammunition anymore, I had to jemmy this behaviour in rather than getting it as a natural consequence of the simulation. Each weapon now has a StartingAmmo counter that is absorbed and zeroed on acquisition, then repopulated when the weapon is dequipped.

(When weapons eventually go into the inventory rather than getting dropped on dequipping, this should still be fine as Deus Ex always let you keep your weapons pre-loaded.)

That’s only half the story, though. I’ve said before that I want different ammunition types that all fit in the same guns. You know, normal bullets versus explosive bullets, that sort of thing. If you run out of the type of ammunition you’re currently using, then reloading becomes a lot more complex — it needs to find out if you’ve got another type of ammunition of the same “kind”, and swap over to that automatically.

So there’s more to an ammunition type than you might expect. Each weapon has a note of its ammo “kind”, the type of… types… that will fit into its mechanisms. The basic cannons can take 166mm shells (166mm is totes to scale, I measured the aperture on the gun model in Milkshape and everything), which might well be gas or EMP shells rather than normal explosive shells. The shard rifle takes 71mm shards which might well be … umm… red crystal rather than blue crystal?

The wielder’s inventory needs to do a good bit of mediation to support this. It indexes all the ammunition counts it has by kind so that, when the weapon ability requests a certain amount of ammunition of a certain type, if it can’t fulfil that exact request it can return the next different but still appropriate ammunition type in the pile. If there really is nothing, then it returns nothing and you’ll need to find another weapon.

Needless to say, you can still only carry one weapon (err… one dual-wielded weapon… two weapons) at a time at this point, but we’ll get there. These ammunition mechanics have made me start on basic inventory functionality, so I suppose a UT-style toolbelt of 1-9 weapons would be a good place to go next — with everybody falling back to the ammoless rams when they’re dry… (Funnily enough, I haven’t made the bots able to handle searching for ammunition yet so I’ve immediately programmed an infinite inventory that always returns ammo!)

But that, as always, will be another story for another day.