Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
June 16, 2019
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Wash your game's windows

by Lars Doucet on 03/28/19 01:29:00 am   Expert Blogs   Featured Blogs

3 comments Share on Twitter    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Ever played one of those games where you have no clue what any of the mechanics actually do and you just kind of muddle through? Playing this kind of game is like peering through a dirty, smudged window. What a game like this needs is some Windex.*

*Windex is ammonia-based glass cleaner fluid, for those unfamiliar with American brands.
Image credit: Crystal de Passillé-Chabot

I've already talked about adding "Juice" and "Oil" to your game designs; Windex is a third metaphorical game design fluid to add to your chemistry set.

To recap, Juice is all about making each individual input explode with ostentaious flavor and delight, whereas Oil is about quietly removing frustration and pain from the act of performing inputs in the first place.

Windex is about making it abundantly clear what the heck your game mechanics are actually doing, and removing as much obfuscating dirt and grime that gets in the way of that.

After all, what's the point in driving a juicy, well-oiled car if you can't even see through the windshield?

The all-new 2019 Ananaswurstwagen from BMW. The smoothest, juiciest car on the road.


To be clear, "add some Windex" isn't fully general advice -- there are some games that benefit from intentionally obscuring information from the player. Examples are games like Dark Souls and Bloodborne where uncertainty about how certain things actually work heightens the sense of mystery, magic, and horror. The key word here is intentional. By all means, smudge that glass -- or even board the windows up -- if it helps you achieve your design goals. But if you're not going for that sort of thing, consider whether the player actually understands your mechanics, because it greatly affects how they're going to play.

In the beginning were the little white numbers

Perhaps the simplest way to tell the player how your game works is to print a number whenever they do something that makes that number go up or down, particularly if it's an important number. A simple and early example is scoring points in early arcade games. The most important number is your score, so any action that increases it is signalled with a notification that pops up right where the event occured. If not for this, it'd be easy to misunderstand (or miss entirely) what actions actually makes your score go up.

Gobbling a ghost in Pac-Man:

Jumping over a barrel in Donkey Kong:

These are both actions that you might normally do just to survive, but the game goes out of its way to let you know that it also increases your score, and by exactly how much. It gives you all the information you need to maximize your score, right when you need it, in the place you're most likely to notice (where you're already looking). Games like these also printed instructions with point values to help players:


But that's an external reference that takes you out of the game -- nothing beats the steady reinforcement of well-designed, properly timed visual feedback.

Give important visual feedback right where the player is looking

By the time the home console revolution was under way, these little white score numbers slowly changed from clarifying agents to irrelevant bits of noise. Nobody really cares about their high score in Super Mario Bros., for most people the point of the game is to get to the end. Here little white numbers started to smudge the windows instead of cleaning them.


Granted, we're still in a transitional period here, so it's not like the numbers don't serve any purpose -- each subsequent hop doubles the bonus points, eventually terminating in a 1-up if you can keep it going, so there's that. It also tells players used to arcade mechanics, "hey, you did a good thing! Keep doing that!" A minimally invasive bouncy number like this isn't too big a deal -- but by the time we roll around to, say, Super Mario World on the SNES, it would have been fine to just let the high score tick up silently in the corner.

Still, Mario games are great examples of games with transparent and clear mechanics. Stomping a koopa causes it to immediately change visual state (it ducks into its shell). The creature stops moving and adopts a submissive pose, implying that it is less dangerous (for now) -- if it had simply frozen in place, it would be unclear whether touching it would still kill you or not.

Little white numbers persist to this day, most prominently in RPG's where they are used to indicate damage, and colored variants communicate a variety of effects such as healing, poison, etc.

Next, let's look at unclear mechanics.

Incomprehensible stats

Final Fantasy I on the NES is a great example of a good game with smudgy windows.


When buying and equipping weapons, you receive no information other than its name. There's no indication of what stats it changes, its elemental strengths, whether it has special powers, or even who can equip it. The only way to discover any of those things is trial and error, or read a guide.

FF1 gets a pass because it came out such a long time ago, but I routinely see modern games that lack some of these essential bits of information!

Now let's look at the stats screen:


The experience section is very clear -- you have this much XP and need this for your next level up. The lower right panel seems straightforward: okay I do this much damage, I have this % chance to hit, I'll absorb this much damage from incoming attacks, and I have this much chance to evade attacks. But the numbers seem strange -- do I really only have a 10% chance to hit an enemy? Will I really dodge attacks more than half the time?

And what about all this stuff on the left? We've got what I assume is Strength, Agility, Intelligence, Vitality, and Luck, but I only have a vague idea what those are supposed to do.

Turns out it's all really complicated, and there's even a few bugs in the implementation that foil the original intent of the designers!

As I surmised, I don't really have a mere 10% chance to hit an enemy, it's just an input into a hidden derived stat (base chance to hit) that then feeds into a calculation. I get that RPG's often rely on somewhat fiddly formulae like these that can't easily be presented to the player in their entirety, but at the very least we can avoid actively misleading them with "Hit: 10%" which sounds very much like "10% chance to hit."

As for the left-hand stats, it turns out these are character attributes that influence how your right-hand stats grow with each level up. Strength increases attack power by (Strength/2), agility increases evasion by (Agility), Intelligence is apparently bugged and does nothing, Vitality increases HP by (Vitality/4), and Luck is supposed to increase your chance to escape from battle but because of a bug has very little influence on that.

To my knowledge, these left-hand stats can't be directly influenced and are tied to your character's class -- there's no equipment or items that change them. Given that, it seems like it would be better to replace them with a preview of how my main stats (the ones I actually use in battle) will change on the next level up.

Here's a revised version of the screen, that shows my current battle stats on the left, and the changes I'll get on my next level up on the right:


RPG's in particular will always struggle to perfectly communicate what exactly is going on, but a few small tweaks can go a long way to adding needed clarity.

Show the player the information they actually want

Next, let's look at a game that not only makes its mechanics clear, but doubles and triples down on that premise. I am speaking of course about...

Into the Breach

Just take a look at this screenshot:


Hoo boy, there's a lot going on here. This is a turn based tactics game made by the developers of FTL, and unlike many other such games, there is not a single bad thing that can happen to you by surprise -- literally everything is telegraphed in advance. See that building in the center with the red arrow and the bug next to it? That enemy will attack that building next turn (unless I do something about it). See those red arrows on the buildings in the upper left? Artillery enemies have projectiles aimed at them. See that yellow outline on the blocks on the lower right? Those squares will fall into the abyss thanks to an earthquake on the next turn (and from the looks of it, this screenshot was taken right after the turn was passed and the earthquake was underway). The emerging holes with red arrows indicate where new enemies will spawn next turn. And so on and so forth.

Any crucial information that isn't immediately visible can be gleaned by inspecting the relevant thing and getting a complete and handy readout. You can even push a button to get an exact breakdown of the order in which each unit and environmental event will take their turns -- essential information in a game like this! The information is expertly "layered" so that you can easily get the big picture (my power grid has 4 health left, I'm 1 turn away from victory), and then drill down to medium details (this is the current state of the battle) and fine details (here's a tooltip readout of this enemy's strengths and weaknesses).

Now, perhaps your game doesn't take the hard "nothing by accident" line that ITB does, maybe you're comfortable with a bit more RNG and surprise and chaos in your tactics game, or whatever other genre you're working in. Even still, it's good to think about how we present our mechanics to players. If they don't understand how and why things happen, they get frustrated, and chances are they'll experience the game in a way we didn't intend.

Zach Gage has a much better explanation of this and many other principles in his GDC 2018 talk, "Building Games That Can Be Understood at a Glance", which I highly recommend you go read.

Organize info in layers relative to its importance

Next, I'll talk about how I applied (some) of these principles to my own work.

Defender's Quest Skill Trees

Defender's Quest is a series of tower defense / RPG games where each "tower" is a persistent character in your party that levels up, uses equipment, and learns skills -- which come in two forms, boost techniques, and passive bonuses/traits.

Defender's Quest 2 (newsletter here, discord here) is the long-awaited sequel to Defender's Quest: Valley of the Forgotten, and is based on an improved version of the same engine. I'm making steady progress on it, and right now I'm working on skill trees.

The primary skill type in both games is a "boost technique" -- a maneuver (typically an attack) your characters perform in battle. During a battle you "boost" defenders with energy gained from killing monsters; boosting increases power and unlocks advanced skills. Weaker skills are available as soon as the character is placed, whereas more powerful ones require X number of boosts.

Defender's Quest 1

Here's how the Ranger's skill tree looked in the original version:


And here's how it looks today, two re-skins and an HD engine upgrade later in DQDX:


The DQDX version is less cramped and noisy, adds unique icons for each skill, and doesn't require a separate button to upgrade. In the former design hovering on "upgrade" would show what adding a point would get you, in the latter it's broken out with green +X bonus text directly in the stat readout.

Even so, neither of these is particularly clear.

In the first version I relied on generic sentences like "Hits up to X foes for Y DMG each" that was meant to cover almost any attack type by slotting in variables. These dynamic, generic descriptions were both a pain to localize and clumsy to read, so I later replaced them entirely with a "stat grid" that just broke the skill down directly into columns of raw statistics.

The DQDX version is an improvement in certain ways, but honestly neither design just comes straight out and says what the skill actually does, which is: "shoot three arrows in a spread pattern."

The first design obliquely hints at it with the phrase by saying the attack can somehow hit "up to 3 foes", and the second design says "Hits: 3 per foe," which is even more confusing because it's a bug and is actually wrong! It should say "Hits: 1 per foe" followed by another line that says "Targets: up to 3". But even if I had gotten that right, the player would still have to read between the lines to actually understand what the skill does. Sure, once you've used it in battle it becomes apparent, but that's annoying, especially since investing skill points is semi-permanent.

Say what you actually mean.

(as simply and clearly as possible)

Defender's Quest 2

DQ2's skill trees are a bit different from DQ1's -- they still have boost techniques, but global passive traits are now replaced with technique-specific bonuses, none of which have any prerequisites other than the parent technique.

Below you'll find a (untextured, unstyled, very WIP) skill tree design for DQ2. Although all the DQ2 classes are new, the "Long Shot" (placeholder name) is roughly similar to DQ1's Ranger. Here we're inspecting their second technique, "Spread shot":


"Fires 3 shots in a spread pattern."

There we go. Rather than try to cover every technique with a limited set of generic sentences, or try to convey everything with abstract numbers alone, we do a little of both: a simple unique sentence that says exactly what this skill does, and then sprinkle in the most relevant stats below.

The top stat is a new addition -- DPS, or as some will recognize, damage per second. In DQ1 I only provided damage (per hit) and cooldown time, but neither of those alone is particularly useful when comparing two different skills. When the player has a skill point to spend, they want to know which investment has the best payoff for their play style; and in tower defense, DPS is the best measure of basic attack power.

Do the math for me.

(that's why I have a computer)

Let's look at bonuses next. So our boost level one technique, "basic shot", has a bonus for increasing damage, and a bonus for adding a poison status (we'll ignore the third bonus for now). Let's look at damage first:


What does the "Damage" bonus do? It increases damage! I'm going for icons and names that are as "exactly what it says on the tin" as possible.

Okay, how much extra damage do we get? Looks like +4.3 points of damage per skill point. And our overall DPS gets +18.7 -- wow! Why is the DPS number so much bigger? Because our cooldown is small; DPS = damage / (cooldown + animation time).

So I'll do 18.7 more damage per second if I put one point here. What about poison? Is that a better investment?


Whoa! One point of damage is good for an additional 28.75 damage per hit. The vanilla "more damage" bonus makes my attack do +4.3 damage per hit, but just one point of poison gives me over six times more extra damage per hit. Granted, it takes 5 full seconds to get that extra damage, but that's almost always going to be worth it.

This is obviously a huge balance problem in the current version of the game, and I'll fix it eventually, but I'm intentionally pointing it now.

What's clearer to the player is also clearer to the designer

(making it easy to find glaring balance issues like this)

Note that I put the total damage value up front by multiplyling the damage per second times the total duration of the effect:

"Foe takes 28.75 dmg over 5 sec"

Would the overall impact have been as clear if I had said this instead?

"Foe takes 5.75 dmg/sec for 5 sec"

I don't think so. In my experience with DQ1, most players (including myself!) pretty much just gloss over this and either think, "Okay, I guess it does some poison damage" or get falsely anchored by the lower damage number and underestimate its potency. Sure, some die-hards data-mine the game and write long min-max articles on wikis, but if it takes that much accounting to make a decision, I've failed as a designer and I've likely got balance issues lurking simply because I can't see them.

There's a tension here between giving all the information, and giving relevant information. This dose of poison will hit 5 separate times for exactly 5.75 damage each with a one second delay between each one, not 28.75 all at once with a 5 second wait. That distinction matters sometimes -- if the enemy has fast enough regeneration it might emerge completely unscathed by the time 5 seconds elapses. However, given that regenerating enemies and other edge cases are rare exceptions in DQ games, the most relevant information is the full damage payload. I still include "(5.75 dmg/sec)" after the main sentence, because it's useful to have the full context, properly subordinated.

Summing Up

Let's list all of our "Windex" lessons so far:

1. Give important visual feedback right where the player is looking
2. Show the player the information they actually want
3. Organize info in layers relative to its importance
4. Say what you actually mean
5. Do the math for me
6. What's clearer to the player is also clearer to the designer

"Windex", like "Oil" and "Juice" is a specific design tool that needs to be applied carefully, but is an excellent way to spruce up an otherwise confusing game simply by telling players how the world is reacting to their inputs. A big part of that is often letting the player know that the game is reacting to their inputs at all, and in this sense there's some overlap between Windex and Juice.

Not all windows need washing, but when called for, it can really make your game shine.

So go ahead. Put some Windex on it.


Related Jobs

Legends of Learning
Legends of Learning — Washington, DC, District of Columbia, United States

Senior Unity Engineer - $140k - Remote OK
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Lead Game Designer
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States

Senior World Builder
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States

Senior Content Designer

Loading Comments

loader image