Sometimes even the most basic seeming thing in a game isn’t so basic. It seems so obvious that you just make it without a second thought, and then it sits there being Just Good Enough™. While this is fine, if you’re anything like me Just Good Enough™ will fester in the back of your mind because it’s now Just Not Right™.
This post is going to be a bit Unreal-centric, but hopefully the underlying message will make sense to other places (possibly not even games!).
Let’s talk about something that I, until alarmingly recently, would just make without a second thought, and would be one of the very first things I would make when starting a game project.
Let’s talk about good old HealthComponent.
HealthComponent is doing some pretty basic stuff. You’ve got a current health level that is almost certainly a number, out of a max health level that is almost certainly a larger or equal number. You subtract from the current health when you take damage, or add if you are healed. If you run out of health, then you’re (probably) dead (don’t get me started). You might also just want to do insta-death, so set the health to zero regardless.
Honestly? This served me well for many years (hindsight note: actually no it didn’t), so I never bothered to change it. It only gets a bit weird when you have multiple numbery things to track.
So let’s make it more complicated. Now you want to cast spells. Enter ManaComponent.
Superficially, this guy looks like a different component entirely. In reality, all I’ve done is changed the words and given him a snazzy wizard hat.
To really belabour the point: You’ve got a current mana level that is almost certainly a number, out of a max mana level that is almost certainly a larger or equal number. You subtract from the current mana when you cast a spell, or add if you drink an ether. If you run out of mana, then you (probably) want to inform the player. You might also just want to do insta-OOM, so set the mana to zero regardless.
I could go away and put endless hats on HealthComponent and call it a new name. What about Poise or Stagger? What about Encumbrance? What about Experience Points (yes, I’m assuming that you can lose Experience Points, which is a thing we did in the dark ages)? What about Ammunition for your vast array of guns? What about Money?
At which point, you’re probably thinking “Money? Pix has gone insane.” No really, if it’s a number, you can put a different hat on the same underlying structure, and have that structure represent something else.
Wibble Principle
I’m going to take a step back here to show a little creative thinking exercise that I tend to use when I’m trying to unpick something that feels wrong in code.
Put simply, I take the description of the feature, and start replacing the proper nouns with a nonsense word. I like to use wibble, because it’s fun to say. Somebody a lot smarter than me called it a ‘metasyntactic variable’, I call it Wibble Principle.
So let’s try and make a wibble component.
So why wibble? What is wibble? The beauty of wibble is: we don’t care what wibble is. It doesn’t have to mean anything. I could have used plerbs, or blorts, or fliblets. The point being, that wibble can replace all of the more specific concepts like health, mana, poise etc. and the underlying structure still holds.
We still modify wibble when something wibbly happens. We still notify the player when they are out of wibble (what does that even mean? Do we care? Nope!). I added notifying the player when they have a full complement of wibble, because it seems useful regardless (why not wibble harder when your wibble is maxed?). We also can force wibble to the minimum or maximum values, and the minimum doesn’t even need to be zero.
I use this when I’m trying to extract the core structure from a rather fluffy gamey feature, and that generally results in a) a more flexible design but b) more confused people around you if you actually mention wibble. Don’t actually call it WibbleComponent.
The Final Structure
Knowing that we can extract a whole bunch of concepts (i.e. anything that could be represented as a bar, or a resource gauge, or a percentage, it’s just numbers) out into one generic structure means that in Unreal-land, we can just have one ActorComponent that houses more than one of these ‘resource’ structures. In effect, we have our HealthComponent with all its different hats in one place, under one component, and the hat becomes all that it should have been in the first place: A Decoration, or an Identifier.
But why?
I’ll be honest, if you really want to have multiple functionally similar (or even identical components) to manage different resources, then I won’t stop you. However, consider the following:
- What if we want to redirect health damage to a depletable shield? How about if we only want to redirect a portion of the damage?
- What if we want to lose money instead of health when we’re wearing specific armour?
- What if we want casting spells to cost crystal shards (or whatever) instead of Mana, but only if you’re a Crystal Wizard?
- What if you actually do have Wibble, and if you have wibble, it’s consumed instead of something else?
Multiple components here becomes messy, you’d need to have something that comes in and marshals the function calls to the correct redirected component. It’s doable but it’s either a function on the character, or yet another component. If you have all this under one component structure, you can just modify whichever resource that the incoming damage is set to modify. You don’t have to care what the modification is or where it came from. Just that This Damage Changes This Resource.
The flip side of this is that depleting a resource becomes a listener that is waiting for the deplete, and the actual “what happens” bit lives elsewhere. So e.g. Death does not live on the HealthComponent, just “I have died, please do something about this”. Given how complicated and messy Death can be (I swear I’m still talking about games), this is actually more of a blessing in my eyes.
Further Wibbly Applications
Once you’ve embraced wibble (or nonsense word of choice), it opens up other possibilities. You’ve boiled your system down to its base principles, and you’re free to think of all of this in a systematic and abstract way.
Which means you can get creative with it. Or at least make yourself laugh.
As a final takeaway, what this model of resource mangling can produce is: You could model a transaction in a shop the same way that you could punch someone in the face.
- You: “Hello shopkeep. Just these please!”
- Shopkeep: “That’ll be £5”. And then he punches you square in the face.
- You don’t even flinch, it didn’t hurt. But you look in your wallet and £5 is gone.
- Shopkeep: “Cheers mate, see you next time!”
Leave a Reply