On A Scale Of One To Ten…

On A Scale Of One To Ten…

Posted by on Nov 4, 2015 in Game Development

Forging ahead with my UI work, I’ve decided to provide the user with a quick view of his crew and their current state. Managing the crew and responding to their concerns is going to be one (hopefully, one of a few) ways that the player can amuse himself in between jump-gates and stations. While I don’t anticipate FTL levels of crew micromanagement (you don’t tell them where to go within the ship or anything), you will need to keep an eye on them to ensure that they’re operating at peak efficiency.


One of the small issues that I’ve run into deals with the display of the crew member’s health. “Just show their remaining health!” sounds like a perfectly good suggestion, but hold up there, armchair. Let me tell you the story of my teapot tempest.

I planned ahead, having years of RPG experience under my belt, and built the CrewMemberDataObject with two properties to track health: TotalHitpoints and CurrentHitpoints. Like all of the other data in the game, crew members are entries in the database, but because they can have stats updated (levels, health, etc), they’re transient data objects. That means I have to save them with the save game file, unlike a weapon, which isn’t going to change through the course of the game.

On the display (shown above), there’s a hit point bar next to the crew member’s portrait. Here’s the big little question I’m struggling with: Should that health bar track actual health remaining, or is it enough to track percent health?

Currently, it’s using percent health. Each crew member button has a script which deals with managing the button: the portrait display, the click handler, and the health bar. It checks the crew member database for that crew member and calculates their health percentage based on the simple formula ((CurrentHitpoints/TotalHitpoints) *100). The benefit of this method is that the max value of the meter is always 100, regardless of how many hit points the crew member has when swapping members, or gains through leveling. Those values change behind the scenes and I only have to do the math to get the percent. The detriment of this method is that at higher values, smaller changes in health will register apparently large losses, and technically there’s only going to be about ten levels of representation that really “matter” in terms of display.

Using the actual values would provide the absolute most accurate representation of the health of the crew. There’s two problems, though. The first is that when a crew member’s maximum health increases, I have to update the individual button to make the meter reflect the change. That would require messaging (with the understanding that the button would need to know what message to listen for, based on the crew member in that slot!) and update code. Second, a small change to a very large number (such as 985 hitpoints out of 1000) wouldn’t even register. I guess technically it shouldn’t since that kind of a change is the equivalent of a hang-nail or a breaking in uncomfortable shoes, but not seeing the bar move would be kind of pointless.

I think I’m going to stick with the percent system, though, since it’s got fewer moving parts, allows the crew values to be handled through a crew management library and does not require the button to worry about anything other than knowing A) if we’re still talking about the same crew member, and B) if the crew member’s damage has changed.