Make abilities or die trying pt II

In many games things like the ability to stand/sit/move are considered fundamental for the game unit. Behaviour and restrictions to these functions, if any, are hard-coded.

In our case, ability is tied to the body part. When there’s no body part, there’s no ability.

Idea worked well with one-time abilities: equip the gun and you can shoot, drop it — ability goes away. On contrary, it doesn’t work at all with continuous abilities like standing. Particularly it’s hard to handle the failure situation — when your unit loses a leg due to the unforeseen circumstances.

What is standing, anyway? It is a one-time use ability, and you can call it to, say, get upwards from ducking. No problem here. But it’s also a process which is running continuously while the unit stands,  something that must be checked from time to time to see if we could still maintain it.

Marking ability as maintainable is no big deal. Checking it regularly and fail when the requirements are no longer met is easy as well. But to handle these fails is a complicated matter, and not only because it will require additional scripts. The problem lies in the generic nature of the abilities themselves. The question is: how exactly we should fail?

Let’s take  a look at this graph


This is a well defined graph of the generic unit. All the stances are well known, as are the cases of switching between them, at compile time.

In our situation, it’d be


It’s not clear what should happen in case of failure. Abilities are isolated from each other, and there are no predefined rules.

There are several different stances that could be active at the time. Take the “stand” and “aim”, for example. Does the failure of one causes the failure of other? It depends.

There could be additional, attachable stances defined by the equippable items like jetpacks, and all of them shouldn’t be aware about each other. Also stances could be dependent on multiple body parts, and those dependences could overlap, creating potential chains of failures, and so on.

The most pressing problem for me was a concept of entities requiring energy and structural integrity to maintain their stance. When you stand, you need to actively keep standing, and when you can’t — gravity forces you down. It’s also true that some positions are stable as they require no energy to maintain. For instance, tank will keep standing as it is, no matter how badly damaged.

So, each background ability now could be marked as supportive — and if no such ability was active at the moment of actor updating, we could assume that the unit could be safely set to its zero-level state. There’s a small problem here yet — support mechanic is whole-body wide, and is not working very well with part connections (in fact, lots of the mechanics are oblivious to the way the parts connected to each other, I reckon it would be a problem later). That is said, it’s impossible to disable hands, for example, while body is still standing (or they would be rendered lying down, which is not correct, though might be mildly amusing). But for now I’ve got what I wanted — take off somebody’s legs, and he will fall down.

Next in the list — ability expansion. I’ve been experimenting with the script code here and there, and stopped on the “ability as the object” concept. This way I can enforce the three methods each ability should have: Start, Update, End. Background abilities might have another one: Check. That’s how they work:


With this system in check we could finally proceed to make a firing range or simple local multiplayer game for two players. Of course, there are many questions left unsolved, like the workload distribution (robot could stand on 4 and 3 legs, but could not stand on two. Bonus difficulty: for heavy loaded robots three legs is not enough as well), or starting initialization (what abilities should be active on start? when actor is unstunned, what abilities should he try to use to restore its position?), and several more. But I’d rather not to be sucked into some meta-architecture shit, straying from the final goal.