Game Development

Blog 773: Kill Your Darlings

Since long before I started work on Exon, I was gripped by one action-RPG ideal: that if your sword intersected an enemy, then it should damage them. I suspect this arose from the likes of Morrowind‘s secretly dice-roll-based combat, where visually hitting somebody was no guarantee of actually hitting them.

Exon is broadly a game of melee attacks, so obviously when I started building the game I immediately implemented a system that does exactly that: using physics colliders, sword blades deliver damage as soon as they intersect a viable target.

Objective achieved, job done. So why does this system cause me so much concern?

Kill Your Darlings

The practicalities of such a system are, in fact, not simple or reliable at all. The world of video games is, after all, composed almost entirely of smoke and mirrors, where forcing the mechanics to adhere precisely to the visuals creates a whole host of problems.

Perhaps the biggest problem comes from the fact that Exon is a top-down game, not a first- or third-person game. At such a remove, with your avatar being relatively small on screen, the difference between the sword hitting or not hitting is a few millimetres and it often feels like you’re not landing hits that you should be landing. To compensate for this, a while ago I started making blade colliders much longer and wider than the blades themselves.

Next up is a more tactile one — the melee attack animation has to carry the sword in an arc that means it will intersect at all! Suddenly, all my animations have to be much more constrained than I might like. This is why the mechs all do simple vertical slashes: a more curved or diagonal arc simply might not intersect an enemy in the direction the player is aiming enough to deliver a blow.

There are other constraints — the turret is independent from the legs, so I can’t make the whole body flex as the sword comes down either. The attack animation is split into three segments whose speeds are adjusted at runtime, so while the timing looks a bit off here the actual swing part is much faster in-game.

There is also quite a large technical problem with this kind of system, when it comes to physics. The physics world that governs the intersections does not run at the same frame-rate as the visual world, so the intersections are detected at increments along the arc of the sword rather than its full path (or rather, it could detect the full path, but at a considerable performance cost). This is at odds with melee attacks because they need to look fast — a sword swung slowly would just clang off somebody, not rip their mech to pieces. Increasing the size of the blade colliders helped with this a bit too, but by this point things are looking decidedly fudgey and we’re a long way from the precision I originally envisaged.

The final problem is actually with the spin attack. This is when the mech pirouettes to damage all units around it, for reduced damage but knocking them backwards: ideal for use when you get surrounded to open up a way out. Except, if the blade only damages one unit at a time, in order, as you spin around slowly enough for the physics engine to keep up, then by the time you’ve completed the spin the first enemies have had time to close in again!

All in all, my dreams are in tatters. Not only is having accurate sword strikes technically irritating, it’s actively detrimental to gameplay too.

There’s another problem with the spin attack visuals, in that the mech’s shoulder actually can’t articulate high enough to get the blade sweeping out very far without the shields clipping into the shoulders. The blade is still angled a bit too far downwards in this animation to give it the best chance of physically intersecting nearby opponents.

So what’s the answer?

In a traditional action-RPG, attacking is based on whichever unit you have highlighted under your cursor, so this problem pretty much doesn’t exist: you simply damage that thing at a certain pre-determined point in the animation and call it quits. This is not ideal for me, because you need to be able to hit things without them being under the cursor.

Because that is, of course, how my favourite action-RPG Nox works. Indeed, in Nox, crates and barrels don’t highlight for selection at all. Instead, you slice in whatever direction you’re facing, and if something is in the way, it takes a hit. This is actually what I need.

Because it is a close arc, you can still hit more than one enemy with a strike if they are both right in front of you. I might fine-tune this, or add in a cleave attack mode that deliberately offers a wider arc (for reduced damage).

Of course it makes life a whole load simpler to just hit everything in a small arc in front of you at a specified time, instead of having an animation tell a sword to turn itself on and then off again at the end. Units already have complex systems that keep track of all nearby units, so just like the bots’ sight cones filter out the enemies they can actually see, the melee attack system can filter the objects directly in front of the unit.

(Crucially, this can include units that cannot be seen: if somebody was invisible, you’d still be able to slash at the space they occupy. I have no idea if this will ever be relevant, but it pays to be thorough, right?)

So there you go. I rebuilt my attack system and in doing so killed one of my oldest game development darlings. Am I falling apart?

(I am also working on dropping the symmetrical weapon/shield pairs and moving to a more traditional sword-and-board arrangement, because it will vastly simplify another heap of systems and make things clearer to players. Will anyone even recognise the game anymore?! … Having said that, unit symmetry was never much of a darling, it was more something that just kinda happened as the mech designs evolved.)

That thing where you do a load of work to make the game look and act exactly the same.

And you tell me...

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.