UI has come a long way since the 8-bit era, when bosses would flash shades of yellow or red at an accelerating tempo when they were teetering on the brink of defeat.
These days, character models serve as a kind of sophisticated UI of their own, and conveying complicated systems like stamina or damaged systems to players without the use of big garish red bars or dry percentages is an art unto itself.
To get a closer look at how developers use models as UI we reached out to three studios working on very different games, with very different protagonists, and very different needs in terms of communicating information to the player in a way that feels unobtrusive and intuitive. How you show damage differs dramatically, it turns out, if you’re displaying it on the galvanized steel of a giant battle mech or a starship instead of the fragile flesh of the human body.
Designers have been playing with the idea of characters as UI for a long time with human protagonists, from simple implementations like the “strawberry jam” effect of flashing or glazing the edges of the screen with red when you take damage, to more nuanced approaches like showing individual wounds or bullet holes on 3rd person models.Undead Labs’ State of Decay 2 expands on this idea even further, altering behavior and animations based on factors as subtle as a character’s mood.
“When viewing all the members of their community, we use different stances to communicate injuries, ailments, and the morale of each member,” says Jørgen Tjernø, one of the game’s programmer’s. “Greeting VO lines are changed to indicate that a person has taken serious injuries or is feeling sick, and we replace idle and walk animations to indicate significant injuries.”
The same consideration extends to NPCs, as well. “The way we apply injuries works the same for all humans – for example an enemy NPC will receive the same kind of injury from falling too that a player would. This also applies to friendly NPCs that you aren’t currently controlling.”
But one of the challenges of that deeper approach is that slight inconsistencies can break the entire system.
“As an example, we received feedback that it seemed very incongruous that the character was limping, yet their response when talked to was chipper and up-beat,” Tjernø says. “When the player sees behavior that is inconsistent with the story the systems are telling about the character, it is easy for them to lose their sense of immersion. That kind of dissonance is important to address.”
According to Brian Giaime, State of Decay 2’s senior system designer, one of the ways of avoiding those kind of jarring contradictions is a judicious approach to showcasing injuries.
“Just having an injury doesn’t immediately change a character’s visual state to where they’re limping, etc.,” Giaime tells me. “That triggers when a character is either completely out of stamina, or below a ‘critical health’ threshold. We use injuries to inform players that they’re taking a more permanent kind of damage; they can come from being too close to explosions, getting hurt by our ‘Freak’ zombies, or falling from great heights.”
The game treats injuries the same way it does traits, which Giaime says lends “narrative scaffolding for players to tell stories around. We use these when we want something to instill dread and long-term recovery cost.”
Perhaps even more important than the net loss of health, though, is the game’s stamina system; running out of juice when you’re trapped by a large group of zombies or a handful of powerful Freak variants can be an automatic death sentence. You won’t be able to sprint long enough to escape them, and your attacks will come too slowly and spaced too far apart to effectively keep multiple enemies at bay.
“Fatigue is a separate system meant to represent a character’s long-term stamina dwindling due to a lack of rest or an abundance of exertion. The longer a character stays out, and the more they exert themselves, the more fatigue they’ll accumulate, eventually having enough for it to ‘activate’, appearing as lost max stamina on the stamina bar. Once that happens, any action which consumes stamina flashes the bar, and increases the fatigue bar, reducing the player’s max stamina further, making each fight more dangerous and increasing the pressure to return home or to an outpost to switch characters, letting the fatigued character rest.”
"When the player sees behavior that is inconsistent with the story the systems are telling about the character, it is easy for them to lose their sense of immersion. That kind of dissonance is important to address."
Deeply fatigued characters can only run in staccato bursts before staggering and slowing to a torturous limp, and if they’re also badly wounded they’ll grip broken arms or ribs, or practically double over in pain. But Giaime says the team was careful not to make being injured and exhausted a guarantee that a favorite character would never make it home; they also wanted to use those states as a learning tool.
“Our ‘wounded/tired state’ is a coherent but fundamentally binary way of hindering players. Getting to this state means you’ve taken a critical amount of damage, or are completely out of stamina. Both of those cases are things players ought to avoid, and so we reduce your ability to successfully fight in these cases, hopefully teaching players early on to develop combat tactics which avoid them.
“Managing stamina, dodging attacks instead of absorbing hits, or just training up your characters to provide more room for error are all natural takeaways from these mechanics, and the tuning is such that we believe people won’t have to do much, if any, learning through dying.”
And beside just making it obvious through behavior that characters were wounded, and training players to take better care of their charges, the team built in a buffer to make even very dire situations potentially escapable.
“Our most significant tool to help players learn how to survive, without having to lose characters to permadeath, is our ‘fight for life’ system. This system gives players that get in over their heads a chance to recover some health and stamina after losing all of their health but not all of their max health. Only a total loss of max health results in death. In this way we ensure that consequences remain significant for players who are overconfident, without being overly punishing to players who are still learning the ropes.”
Applying the same sort of systems to a complicated machine designed to plumb the depths of space is a completely different beast, simpler in some ways and much more complex in others. Instead of the familiar patterns of human behavior when we’re tired or hurt, designers are faced with subsystems and weapon platforms, sensor packages and flight dynamics.
In Mark Abent’s case, the lead gameplay programmer on Star Citizen, the remit from the beginning was to create beautiful, complicated, and fully destructive craft that would showcase every scoring laser hit or armor shattering explosion.
“Ever since I started here, the whole point has been ‘if you see something on a ship, you can blow it up,’” Abent says. “We don’t want ‘shoot the ship for a long time until it explodes;’ we want ‘shoot the ship, hit components, critical, minor or whatever.’ Components get damaged, they break, they impact the performance of the ship. If you shoot a Hornet and its wing breaks off, the pilot will feel it, and the attacking player will see it.”
And it’s not just about visual effects. “We want to make sure that when something breaks or fails, you feel it, hear about it, etc. There are a ton of indicators – particle effects, like a fire on a wing, that would indicate your flight isn’t fully functional. Each piece will have individual health pools – so you work to damage and destroy an engine block, and that impacts the flight performance. The engine should cut off, you might be able to use backup systems or divert power, but you’re going to see a dramatic decrease in flight performance.”
Abent envisions the final game weight factors as granular as projectile size and weight when determining damage and how it’s displayed.
“A peashooter might dent a ship over time but a rail gun can take out a chunk in one shot. As locations on the ship get weaker, it takes less force to continue damaging them. Big parts of the ship now have built in visual changes that we put in as we create the ship, so you get a shortcut to visible damage on certain sections.”
The problem is, Star Citizen isn’t (just) a game about fighters. The game simulates a broad scale of craft, from small, darting interceptors to freighters or capital ships, massive ships that come with their own set of difficulties and demands.
“The hard part is, how do we display this across huge spaces, with ships of varying shapes and sizes? We’re making ships of varying shapes and sizes, from things that look and feel like a car, to others that are massive, like the size of city blocks. How do we program the game logic to incorporate different health states across different ships? Does a power coupling on a ship the size of a city block have the same strength as one on a small racing craft? There are a lot of questions that we need to answer to make these systems reality.”
The first step to answering these questions is creating a pipeline that allows the team at Cloud Imperium Games to break big problems down into smaller, manageable chunks. Originally, the team was doing all this chassis and system damage modeling by hand, a huge drain on resources and manpower. Now, new tools like an in-engine editor have significantly streamlined the process.
“When someone damages shields enough, you’ll lose power. Then the crew inside has to repair the power plant to get shields back up. However, it’s very time consuming to place these by hand inside the ship. We’re creating tools in the editor that allow us to pick out entities, export them and place them within the ship in seconds.”
"We want to make sure that when something breaks or fails, you feel it, hear about it."
It’s an iterative process that happens in multiple stages.
“That’s one of the reasons we sometimes ‘reissue’ ships that are already in the game,” Abent says, “to bring their tech and code up to par with the new systems we design to govern ship damage, power, heat, etc. We also create these systems piecemeal. We aren’t saying ‘tomorrow, your ship will have breakable pieces, a governing power system, overheating mechanics, or degradation,’ but instead we design the system once we understand the final aiming point and go about implementing it in pieces. Eventually, all these components will be part of a more cohesive system that makes your ship maintenance something that all SC pilots and crews will have to consider in minute-to-minute gameplay.”
The goal is to make ship damage a strategic consideration, to force players to think about any combat encounter not only tactically but in terms of the bigger picture, the potential for profit/loss.
“Even if I won, and I didn’t take much damage, I may have put a ton of strain on my systems, lost a wing, I could be running out of ammo. I can’t just go into battle because it’s fun, we want it to be a strategic decision. Ship damage is what makes that happen.”
It’s become a core mechanic around which a lot of the game’s other systems have been constructed, key to everything from player progression to how battles are conducted and scaled.
Abent frames it in easily digestible terms. “Think of it this way: in The Last Jedi, an X-wing pilot disables the defenses on a Super Star Destroyer, enabling his fleet’s slower bombers to creep in and destroy the ship. Those are interacting and overlapping strategic decisions, and it’s how we envision Star Citizen working, but without ship damage and damage states it’s almost impossible. But when you can have a fleet of fighters disable systems on a huge capital ship, launch a dropship at the disabled ship, board and take over? Bring in bombers and blow it out of the sky? Salvage some of the valuable pieces you shot off, while the other side is trying to recover them? You’ve created emergent gameplay.”
The model damage in Battletech is actually a holdover from its genesis as a tabletop game. A wireframe of each mech was displayed on a record sheet with a certain number of empty circles allocated to each section (its center torso, for instance, or each leg). A dice roll indicated which area was hit and every time the mech took damage, players would fill in circles in that area, until all the circles were full and the entire piece was destroyed.
“Being able to dynamically reflect that visually in gameplay is an advantage we have in a video game over the tabletop game,” says Steve Rynders, Battletech’s principal character pipeline artist at developer Harebrained Schemes. “Fortunately, Piranha Games shared their Mechwarrior Online assets with us and the models were already built in a way that supported damaging and destroying geometry. Aside from it being awesome to see an arm blown off and its pieces rain down on the terrain along with the sparks and explosion, it helps to reinforce and communicate to the player that there has been a state change.”
To show off meaningful systems or parts damage, Rynders and the team dynamically toggle between different assets.
“Our implementation swaps between an undamaged skinned mesh group and a group of damaged geometry that is either still skinned to the animation skeleton, or a physics body (which are the pieces that fall to the ground). When a piece is destroyed, the appropriate groups are turned off and on, and the physics bodies become active and VFX like explosions, smoke, and sparks are played at the appropriate joint locations.”
Determining when a unit has taken enough damage to cripple a system or cause a limb to get blasted into molten shrapnel also goes back to the extensive foundation laid by the tabletop game.
“In a lot of ways these kinds of questions are already answered for us by 30 years of play, feedback, expansion, and rules tweaks,” says lead designer Kiva Maginn, “but we did make some moderately significant changes to the original game model. For instance, tabletop BattleTech includes a concept called ‘through armor critical.’ A TAC is a chance that any attack might bypass a ‘Mech’s armor to inflict damage on internal systems, leading to weapons being destroyed, ammo exploding, and otherwise awful consequences.”
“We eventually decided not to include it in our adaptation. The reasoning is that while it’s fun to take a TAC that blows up your whole ‘Mech when you’re sitting around a table with your friends, eating pretzels and rolling dice, it’s a lot less fun when a faceless, emotionless AI does the same thing to you.”
"Aside from it being awesome to see an arm blown off and its pieces rain down on the terrain along with the sparks and explosion, it helps to reinforce and communicate to the player that there has been a state change"
Instead, damage in the video game is simulated through the use of ablative armor over a more fragile structural layer. After the armor is destroyed, any hits on the structure may trigger critical damage to one of the systems stashed in that part of the mech, destroying crucial elements like weapons, ammo, or heat sinks.
“Once all the points of structure are lost on the location, the whole location is destroyed,” Maginn says. “It’s an arm, we animate it popping off and falling to the ground, and if it’s a leg, your ‘Mech falls on its butt. When a location is destroyed, anything equipped there is also destroyed, and torso and head destruction result in the instant death of the ‘Mech and its pilot.”
As in the tabletop game, further damage to a destroyed section is applied to an adjacent piece closer to the center of the mech, inwards towards the center.
“In a sense, while locations like arms and legs are functional places to mount equipment and weapons, they’re also another form of ablative defense: if your arm is being damaged, at least it’s just an arm, and not the much more vital center torso or head.”
It’s one of the ways the game is designed to keep players in the fight even after taking damage and to avoid the kind of one-hit kill scenario of the tabletop game’s TACs. Another is the way players are encouraged to spread weapons and systems across the entirety of their mechs, so losing an arm or a leg isn’t an automatic game over.
“If you take a lot of fire to your left arm, you’ll eventually lose that arm. That means that serious, gameplay-affecting damage is generally focused on one part, or system, or weapon. If you have a Medium Laser in your left arm, losing that arm is going to take your laser away. But all the other weapons you’ve got equipped are still perfectly functional; if your ‘Mech is also carrying an AC20 in its right torso, losing that left arm isn’t really much of a change to your overall effectiveness.”
Maginn points out that locational damage is also a good way to make players think tactically in three dimensions. “By maneuvering carefully, you can present different facings to the enemy, so that as one arm is damaged, you can switch over to taking damage on the other arm.”
As in State of Decay 2, damage to AI mechs is handled the same way it is for player units. The principal AI director, Kevin Maloney, says the AI is forced to deal with the same locational damage and systems destruction, and is constantly calculating how to effectively roll with whatever punches the player manages to land.
“The AI cares a lot about getting the most damage it can dealt to hostiles. So in terms of destroyed systems it just factors that when thinking about how to hurt you the most. For example, if a Catapult (that by default is equipped with Long Range Missiles, Medium Lasers and Jumpjets) loses its LRMS and Jumpjets it will then move to the place where it can do the most damage with its lasers and not give a thought to jumping. The AI is regularly checking on not only the state of its systems but heat, its weakest armor side, stability and numerous other factors so it can make the best decision it can with the most current information.”
