A game can be tracking hundreds of important things at once. An enemy’s suspicion level. The strength of a damaged door. How wet the floor has become. Whether a faction trusts the player. How much noise travelled through the room. Which route a patrol currently considers dangerous. How close a weapon is to breaking. Whether a fire is spreading, weakening, or about to turn the entire building into a very expensive loading screen. All of that can be working perfectly underneath the surface. The problem is that players don’t experience systems through code, spreadsheets, variables, or beautifully organised debug panels that only appear when a designer is standing behind the programmer asking why the guard has become emotionally attached to a wall.
Players experience systems through change. They need to see that something happened, understand enough about why it happened, and recognise what that change means for their next decision. If they can’t, the simulation may be deep, but the experience will feel random. A system the player can’t read is functionally very close to a system that doesn’t exist.
Rules Tell Players What Can Happen. States Tell Them What Is Happening
Rules and states are related, but they serve different purposes. A rule tells the player how the world normally behaves. A state tells them what is currently true inside that world. The rule might be that guards investigate suspicious sounds. The state is whether a particular guard is calm, curious, searching, alert, or actively trying to introduce the player’s face to the nearest piece of ammunition. The rule might be that fire spreads through dry material. The state is whether the nearby material is dry, wet, burning, extinguished, or dangerously close to something explosive. Players need both kinds of information. Rules allow them to form expectations. States allow them to apply those expectations to the current situation.
| Rules | States |
|---|---|
| Describe normal world behaviour | Describe what is true right now |
| Help players predict possibilities | Help players assess the current situation |
| Usually remain consistent | Change through play |
| Support long-term understanding | Support immediate decisions |
| Answer “What could happen?” | Answer “What is happening?” |
A player may understand the rule perfectly and still make a poor decision because the relevant state wasn’t readable. They knew enemies could hear footsteps, but couldn’t tell that the rain had stopped masking their movement. They knew electricity travelled through water, but couldn’t see that the puddle had dried. They knew the faction remembered violent behaviour, but had no indication that their reputation had crossed a meaningful threshold. The rule wasn’t broken. The state was hidden.
Insider Tip: When players misunderstand an outcome, check whether the problem is the rule or the current state. Teaching the rule again won’t help if the player simply couldn’t see that the situation had changed.
Hidden State Feels Like Randomness
Designers often assume that because a state is technically represented, it has been communicated. The suspicion meter moved. A tiny icon changed colour. An audio cue played underneath combat music, dialogue, an explosion, and someone in the next room deciding that now was the perfect time to operate a leaf blower. The information existed, but the player didn’t receive it.
From the system’s perspective, the outcome was logical. The player generated noise, the enemy’s suspicion increased, the threshold was crossed, and the enemy entered an alert state. From the player’s perspective, a guard suddenly detected them through a wall and ruined a perfectly good stealth plan. That gap between simulated logic and perceived logic is where trust begins to collapse. The player can’t learn from an outcome they can’t reconstruct. They don’t know which action mattered, which state changed, or what they should do differently next time. Eventually, they stop planning around the system and start treating it as unpredictable.
| What The System Did | What The Player Experienced |
|---|---|
| Increased suspicion after repeated noise | The enemy detected me for no reason |
| Reduced grip because the surface became wet | The controls suddenly stopped working |
| Changed faction behaviour after accumulated choices | The NPC became hostile without warning |
| Weakened an object through repeated damage | The object broke randomly |
| Spread fire through connected materials | The entire room suddenly caught fire |
Randomness isn’t always created by random numbers. Sometimes it’s created by invisible causality.
Insider Tip: If the player describes a deterministic system as random, don’t immediately rebalance it. First check whether the cause, transition, and consequence were visible.
Every State Change Needs Three Readable Parts
A meaningful state change should answer three questions:
- What changed?
- Why did it change?
- What can I do about it?
The player doesn’t always need a complete numerical explanation. They don’t need to know that suspicion increased from 63.4% to 71.8% because their left foot generated 4.7 units of noise against a tiled surface. That level of detail may be useful during development, but it’s rarely how people think while playing.
What they need is enough evidence to interpret the situation. The guard looked towards the sound. Their posture changed. They stopped following their usual route. The music tightened. Nearby NPCs noticed the guard’s reaction. The player now understands that suspicion has increased and that remaining still, moving away, creating another distraction, or preparing for confrontation could change what happens next.
| Readable Layer | Question It Answers | Example |
|---|---|---|
| Cause | Why did this happen? | A bottle shattered near the patrol |
| Transition | What changed? | The guard moves from calm to suspicious |
| Consequence | What does it mean now? | The guard investigates and watches the area |
| Response | What can I do? | Hide, relocate, distract, wait, or attack |
These layers don’t need to arrive through the same channel. The cause may be communicated through sound, the transition through animation, the consequence through behaviour, and the available response through the environment. Strong feedback works as a sequence, with each part reinforcing the others.
Insider Tip: Don’t ask whether a state has feedback. Ask whether the player can reconstruct the full chain from cause to consequence.
The Interface Isn’t The Only Messenger
When a system becomes difficult to read, the usual response is to add another icon, meter, outline, notification, marker, tooltip, colour, arrow, or small flashing object that quietly begs the player to please understand what the design team meant. Sometimes that’s the correct solution. Abstract information often benefits from an abstract display. Health, ammunition, time, score, currency, and complex resource values can become more useful when presented clearly through the interface.
The problem begins when the interface becomes the only place where state exists. If an enemy is furious but continues standing, moving, speaking, and behaving exactly as they did when calm, the emotional state belongs to the HUD rather than the character. If a weapon is badly damaged but looks, sounds, and performs identically until it suddenly breaks, the condition exists in a meter rather than the object. Readable states can be communicated through several channels:
| Feedback Channel | Best Used For | Example |
|---|---|---|
| Animation | Behaviour, physical condition, intention | Limping, searching, guarding, hesitating |
| Audio | Attention, danger, material response, distance | Raised voices, creaking supports, changing machinery |
| Environment | Persistent world conditions | Burn marks, footprints, broken cover, spreading water |
| Behaviour | AI priorities and relationships | Patrol changes, avoidance, investigation, cooperation |
| Interface | Precise or abstract information | Health, ammunition, reputation, timed states |
| Camera and effects | Immediate emphasis | Impact, danger direction, loss of control |
The strongest solution often uses more than one channel. A guard’s suspicion can be communicated through animation and dialogue before a small interface indicator confirms it. A damaged structure can bend, creak, shed debris, and finally display a warning when collapse becomes imminent. Redundancy isn’t always clutter. When several forms of feedback agree, the state becomes easier to trust.
Insider Tip: Try disabling the HUD during a playtest. If every important state becomes impossible to understand, the world isn’t carrying enough of the communication.
Readable Doesn’t Mean Completely Explained
There’s an important difference between uncertainty and obscurity. Uncertainty means the player understands the situation but can’t guarantee the outcome. Obscurity means the player lacks the information required to make a meaningful judgement.
A stealth player may know that a guard heard something without knowing exactly how long the investigation will last. A survival player may recognise that a storm is approaching without knowing its precise strength. A diplomatic player may understand that a character is losing patience without seeing a numerical relationship meter floating above their head. That uncertainty can create tension because the player has enough information to make a decision, but not enough to make the decision safe. They need to interpret, estimate, and take responsibility for the risk.
| Useful Uncertainty | Harmful Obscurity |
|---|---|
| The player recognises danger but not its exact severity | The player doesn’t know danger exists |
| The likely consequence can be estimated | The outcome appears disconnected from the action |
| Observation improves the player’s judgement | More observation provides no useful information |
| Risk remains part of the decision | Risk is only revealed after failure |
| Failure refines understanding | Failure exposes missing information |
Perfect information can flatten a system into calculation. Missing information can flatten it into guessing. Readable design lives between those extremes.
Insider Tip: Hide exact values when uncertainty supports the fantasy. Don’t hide the existence of a state the player needs to make a decision.
State Changes Need Priority
The overconnection problem becomes especially dangerous when several systems change at once. The player starts a fire, triggering smoke, visibility loss, enemy panic, sprinkler activation, electrical damage, route changes, resource loss, structural weakening, and a faction response. The simulation may be behaving correctly, but ten equally loud reactions don’t create ten times the clarity. They create noise.
State communication needs hierarchy. The player should understand the most immediate consequence first, followed by the changes that affect their next decision. Less urgent information can remain in the environment, appear after the pressure drops, or become discoverable through later observation.
A practical order is:
| Priority | Communication Goal |
|---|---|
| Immediate threat | Show what can harm or stop the player now |
| Action consequence | Confirm what the player’s behaviour changed |
| Decision opportunity | Reveal what new options or problems appeared |
| Persistent world state | Show what will remain after the moment |
| Supporting detail | Add texture without competing for attention |
This hierarchy doesn’t reduce systemic depth. It helps the player enter that depth in the right order. The simulation can continue processing every relationship, but the presentation needs to respect the limits of human attention.
Insider Tip: If everything demands attention at once, the player won’t interpret the system. They’ll react to whichever warning is largest, loudest, or most aggressively coloured red.
Feedback Should Change Player Behaviour
Good feedback isn’t decoration placed on top of a mechanic. It changes how the player understands and approaches the system. A sound indicator that confirms noise travelled through a space teaches the player to think about surfaces and distance. An enemy animation that distinguishes curiosity from certainty teaches the player when to wait and when to move. Environmental damage that remains after an encounter teaches the player that their actions can reshape future possibilities. The real test isn’t whether the feedback looks polished. It’s whether the player behaves differently because they received it.
| Feedback Result | What It Suggests |
|---|---|
| The player changes their plan | The state affected decision-making |
| The player predicts the next transition | The system is becoming understandable |
| The player experiments with another cause | The feedback encouraged learning |
| The player explains the outcome accurately | The causal chain was readable |
| The player repeats the same mistake without understanding | The feedback probably failed |
This is why playtesting readable state requires more than asking whether players noticed an icon. Ask them what they believe changed, why they believe it changed, and what they expect to happen next. Their explanation reveals whether the system has become usable knowledge.
Insider Tip: Don’t ask players, “Did you see the feedback?” Ask, “What do you think the game is doing now?” Recognition is useful, but understanding is the actual goal.
Run A State Readability Audit
A state readability audit can be done before the game is polished. In fact, it should be. Placeholder animation, simple audio cues, temporary colour changes, debug text, and rough environmental effects can reveal whether the structure of the communication works before the team spends weeks making it beautiful. Choose one important system and list every state the player needs to recognise. For each state, document what causes it, how it becomes visible, what decision it should influence, and whether players identified it correctly during testing.
| Audit Question | What To Check |
|---|---|
| What changed? | Can players identify the new state? |
| What caused it? | Can they connect the state to an action or event? |
| What does it affect? | Do they understand the immediate consequence? |
| What can they do? | Can they identify a meaningful response? |
| How long will it matter? | Can they tell whether the state is temporary or persistent? |
| What competes with it? | Is other feedback drowning it out? |
Pay particular attention to states that cross systems. If weather changes stealth, traversal, combat, AI, and resources, the player needs to understand which relationships matter in the current moment. If reputation changes dialogue, prices, assistance, and hostility, the world needs to communicate that shift before the consequences feel arbitrary. A complex system doesn’t need to explain everything at once. It needs to reveal the right information at the point where that information becomes useful.
Insider Tip: A hidden variable can create mystery. A hidden consequence usually creates confusion. Know which one you’re designing.
Final Thoughts
Readable game systems allow players to turn observation into decisions. Rules teach them what can happen. States show them what is happening now. Feedback connects their actions to the world’s response, allowing them to adapt, experiment, and take responsibility for what follows.
The goal isn’t to expose the entire simulation. It’s to make the important parts legible. Show the cause clearly enough that the player can learn. Show the transition strongly enough that they recognise change. Show the consequence early enough that they still have a meaningful response. When players can read the state, they stop waiting for the game to tell them what button to press. They start interpreting behaviour, predicting outcomes, and building plans from the world itself. That’s when the system becomes playable.
That’s it for this one! Subscribe to The Design Lab for more breakdowns and analysis. Please like, share, and comment if you found this article useful AND…
Need help applying these concepts to your game? Most games don’t fail because of bad ideas. They fail because the systems don’t work together to evoke immersion.
> Work with me:
https://thedesignlab.blog/services/
> Or go deeper into this framework:
Register for my upcoming book – Immersive Design Framework – below and get a second book, now, free!
Grab Myles’ FREE ebook now and find 15 indispensable design patterns that will equip you to craft exceptional Web3 gaming experiences. We’ll also notify you when his new book on immersive design is out!