Game Design Dirty Little Secrets

Three years ago, the designer Jennifer Scheurle started a very interesting Twitter thread on “brilliant mechanics in games that are hidden from the player to get across a certain feeling“. In this thread, she invited designers to share the design secrets they have used, which should not be seen by the players in order to trigger specific behaviors, feelings, or reactions while experiencing their games.

And this tread got a lot of traction! This became a great source of trivia and little design tricks, like these ones:

  • In Hellblade, the starting warning message has been carefully crafted to make players believe there is a permadeath system in the game if the player is dying too many times while, in fact, this system doesn’t exist.
  • Pacman can take corners in a sharper way than the ghosts, giving the player a little hidden edge.
  • In plenty of shooters, the last bit of health of the player is worth more than the rest of the bar, in order to increase the “barely made it” feeling. For the same purpose, in System Shock, your last bullet will hit 4 times harder.
  • Oppositely, Shadow of Mordor slightly increases some enemies’ life dynamically to make epic fights last longer.
  • The Director (AI) of Left 4 Dead 2 will target on purpose players that had it safe so far or are far from their group.
  • In Bioshock and Devil May Cry, enemies slow down their attack pattern while behind the player, to avoid frustration and keep the player in control.
  • In Xcom, missing too many shots in a row will give the player a hidden bonus for the next shots to come. Also, if players stay passive for too long, the enemies ramp-up their aggressiveness.
  • Heartstone, though unofficial and debated, has strong evidence of Pity Timers in place. Plenty of other games infamously used them other the years.
  • Resident Evil 4 will spawn fewer enemies after too many deaths to give the player a better chance to pass a tough moment.
  • Bloodborne temporarily disable enemies collisions when the player is reloading. This is interesting knowing that common beliefs picture Souls-like as particularly unforgiving games.
  • Every racing game has an adaptative AI to make the competition more fierce.
  • And the list goes on and on… It’s a fantastic read and beautiful insight into the Tips and Tricks of famous games and designers!

Re-reading it, I realized that I, too, have plenty of these little tricks and that sharing them could help you consider design a bit differently. So let’s dig into them and try to extract the purpose of such tricks, as always looking through the lens of the player experience.

Why cheating or bending “reality”?

First of all, we should ask ourselves why would designers cheat. Aren’t games better without artificial tricks? Well, let just say for now that games and their rules are already artificial in essence. Players have learned through decades of gaming that there are unique codes and paradigms that apply in the game world, and only there.

Think about it: every platformer hero only needs the tip of a toe to hold on a ledge, can double jump, and change direction mid-air. We also know from every shooter that a shot to the heart is less lethal than one to the head (but that you can die from a sniper bullet in the foot) and that a silencer is completely muting a gun. Racing games taught us that off-road only makes your supercar slower and that fences and street-lights are easily breakable. RPGs made sure that every quest will be a rewarding one, and that the player will be acknowledged for it, something real life won’t ever be able to provide.

In this article, we won’t talk about classic video game tropes or the artificial codes that define genres or specific games. Instead, we will focus on the sneakier kind of rules-bending: the ones hidden from the player. All the little moments where designers forget to mention something, up to the instances where they straight-up lie to their players. Why would anyone do that?

Well, there is actually plenty of great reasons for that:

  • To make players feel empowered.
  • To keep players in the flow.
  • To raise tension and pressure, or to keep it high.
  • To be “fair” with your players.
  • To make them play more.
  • To make them pay more (this one is out, we won’t be discussing predatory technics).
  • To create more diversity in a game.
  • To drive specific players’ behaviors.
  • etc.

You will notice the quotation marks around the word “fair”. This isn’t innocent. Players are human beings and come with so many biases and downsides, listing and studying them all would take forever.

But the thing is: we do not accept well true fairness! A very good example would be with displayed probabilities, a feature that many games have. These games, by displaying the guts of their algorithms, want to be very transparent, like in this example from Xcom2:

99% hit chance! Pretty safe, and yet not perfect: there will always be this 1% chance to fail the shot. Unfortunately, humans are terrible at understanding probabilities, particularly when it’s not in their favor. Internet forums are filled with players calling the system broken because of a missed 90% hit-chance shot. And yet it will happen on average once every 10 times, not so rare all of a sudden!

Interestingly, nobody ever complained about getting a successful hit that only had a 5% hit-chance to succeed. No, this one is ok, the player just got lucky! Right?

Another series was plagued by this issue: Total War. And there are strong beliefs that the displayed probabilities, yet extremely detailed have been patched to be modified in the background: a visible 80% would instead mean 90% for example. The game stays unchanged, but the players aren’t complaining anymore.

Which raises the question that we will try and answer together: is it ok to do things like that? To answer it, we will have to look at the motives that make designers consider such tricks.

And the biggest motive, which encompasses our previous statistics example and countless other ones is very straight-forward: our players are spoiled.

Pampering players

We will start this topic with the most common trick of all: preventing players to fail while making sure they believe they survived solely because of their insane skills (or luck). This trick is found in almost every game in a way or another:

  • Most PVE shooters have an auto-miss feature for enemies: if the player is low on life, or retreating into cover, enemies will voluntarily shoot around the player. It keeps the pressure high with bullets flying around while making sure the player will make it.
  • This auto-miss is also often applied at the start of the fight. You don’t want players to take a headshot out of nowhere. Instead, enemies will miss a few shots first, to signal the danger (and their position). Convenient and organic.
  • Games like Doom will pretend that the health bar of the player is almost empty while still keeping a bit more stored, for some dramatic moments.
  • Control will never kill a player that isn’t in a dying state already. A rocket that should kill the player will instead empty the bar until 1HP remains, asking for another shot to finally display the death screen.

Examples like those ones are legion (and we haven’t even dug into players’ auto-aiming mechanics), and for an excellent reason: a fail state breaks the flow. The music stops, the action is over, a long loading screen appears, the scene restarts, the tension is flatlining… This is a terrible thing!

Super Meat Boy alleviates this issue beautifully with an instant restart and a continuing soundtrack, making death part of the game flow. But this is a rare occurrence that many games cannot afford (tech or design-wise). And this brings us to one complex problem: on one side we want the player to fail. Where would be the challenge in a game you cannot lose? On the other, failing is brutally damaging the player’s flow.

The different answers all these games are using could actually be summed up with a single guideline:

The game will be perceived harder than it really is. The difference between perceived and real difficulty will depend of the stakes and player’s engagement at this specific moment.

And don’t get me wrong: I am not telling designers to lower their game’s real difficulty, I’m telling them to make it look even worse than it really is in the opportune moment.

Fighting a god

I ran directly into this issue a few years ago while designing the underworld sequence of Assassin’s Creed: Origins. The mandate was clear: the player was going to be dragged on the boat to the Duat (the Egyptian path to the afterlife) and will fight Apep, the snake god, the embodiment of chaos, with the help of Ra that would lend the player his bow of light.

This fight was to be a highly engaging moment, a pure moment of flow. The player is actively fighting a god to try and save his soul after all! But this was bringing the problem we were just discussing: this fight was to be designed to be relatively easy for a player at that point in the game but should look like a very hard sequence that the player overcomes like the hero he is.

The first trick we used to solve this issue was the following: at that point in the game, players would know that when their life bar is below 10%, a red overlay will appear on the screen. So we removed the entire UI, health bar included (for a more cinematic effect), and bumped the trigger of that red overlay from 10% to 30%. Players would find themselves easily “close to death” (and fricking out) while actually having a reasonable amount of life remaining.

Though playtests showed us that this was a very efficient solution, they also showed us that players were confused and frustrated by the disappearance of the health bar. This was an element too core in the gameplay for us to remove it. So we went for another technic, one that is still in the game today (and visible in that upper video at 1:10, but also 2:30 where the player is barely making it).

On one side, we made Apep’s attacks extremely dangerous: they would deal high damage, cover big areas of this small boat, and give very little time for the player to react. Fitting of a god. On the other hand, ACO has an interesting mechanic that makes the player refill his entire life bar should he exit the fight state and not receive damage for a few seconds. So, in the end, we carefully made Apep briefly exit combat at some key-moments of the fight (when he is navigating away from the player).

A player being overwhelmed would still die, but a player managing to avoid 1 out of 2 attacks consistently would always keep enough life to finish the fight.


But pampering our players isn’t only about exacerbating their perception of danger, or saving them just for a bit more, or preventing their frustration by manipulating numbers in the background… It is a philosophy that could be applied to most aspects of our games.

It’s about being generous with our players.

Hitboxes & Hurtboxes

Let’s jump for a short moment in the world of combat design, particularly on the topic of hitboxes and hurtboxes. I’ll dedicate a full article on that point in my Keys to Combat Design series but there is one specific point that particularly interests us here.

In short, a hitbox is the dangerous part of a weapon or character, that triggers during attacks. It is often implemented as one or more simple geometrical shapes, usually boxes, encompassing said weapon. When this box collides with the hurtbox of the opponent, which is a box around its weak areas, a hit is registered.

Simple enough, and yet there are plenty of subtleties that can make a fight go from great to epic. What interests us here, is the opportunities it gives to be generous with our players.

These boxes are placed manually by designers, usually attached to the bones of the 3D skeleton. They often look very similar, but their shape and size are completely up to the designers to decide, and nothing prevents them to expand one box or shrink another. And guess what: this is exactly what most of the games do!

Let’s look at Middle-Earth: Shadow of Mordor. The picture below is but a rough overpaint to illustrate my point, but I’m fairly confident I am not too far off:

There are 4 boxes here:

  • The hitbox of the player around his weapon. It is stretched to make his sword slightly longer than visually represented on screen.
  • The hitbox of the enemy. It is this time precisely positioned on the edges of his weapon (some games make it even shorter than the visual of the weapon)
  • The hurtbox of the player. It follows carefully the shape of the torso and will ignore most of the limbs and extra bits sticking out.
  • The hurtbox of the enemy, this time spreading way beyond his geometry.

Of course, this isn’t an overlook. Remember: players won’t accept true fairness, and in a fast-paced, hectic fight, there are plenty of occasions to feel frustrated or feeling that the game is “cheating”. The above scenario is, in fact, a very good approach to avoid such feelings: players won’t accept being hit if the enemy’s weapon simply brushed the hand of their character without clearly going through it, thus why we focus on the head+torso block. Players also won’t accept a miss on their side if they believe their weapon to be in range from the enemy, thus the slightly oversized hurtbox.

Take your favorite fighting game, the one that you feel the most engaging and snappy, and really study that particular point. You will probably be surprised to notice how generous this game is with you, accepting situations like the one below.

This time, it is a real situation of Shadow of Mordor, where the player gets a successful hit while visually completely missing the enemy.

This feels ridiculous right? And yet I can promise you, this is something players won’t notice (or will pretend it never happened) as these attacks happen extremely quickly (cf: the Anatomy of an Attack article).

This design secret got actually so important, some game genre made it one of their trademark to push it to the extreme: the player hitbox of bullet-hells games like DoDonPachi is but few pixels wide in the center of the model.

Here is a clear example from Enter the Gungeon, where a player dodges a seemingly unavoidable bullet. This game would have felt totally different should the designers at Dodge Roll were less generous.

Combat design, in general, is a crazy interesting place to look for extra generosity: we could talk about enemies pretending to reposition to give players enough time to heal, or enemies disabling completely their attacks patterns if they aren’t in the frame of the camera to prevent a backstab and keep players in control…


But, all in all… Are we still talking about pampering spoiled players? Or are we talking about providing them with accessible, generous, enjoyable experiences?

Maybe, instead of patronizing our players, we could instead try to look at this whole topic from a different angle. A more caring one.

Guiding players through their experience

Let’s look back at some of the reasons why designers would resort using such tricks: keep players in the flow, balance tension and stakes, drive behaviors… This isn’t about pretending the game is something different anymore, but about shaping the game’s experience through the perception, beliefs, mental states, and choices of the players.

Rubber-banding

If you ever played a racing game against AI opponents, you will know this feeling: you are crushing a race, way in front of everybody else, when suddenly your opponents seem to grow wings and catch-up magically with you. Or, oppositely, the cars in front seem to be waiting for you, breaking on purpose for you to still have a chance to win. Well, this is rubber-banding. And a bad one.

Every racing game if facing the same issue: there is an enormous variance in result for just a slight change in inputs. Take a curve slightly too wide or break just a bit too early, and you will find yourself hundreds of meters behind the car that did it better.

The result? After the first curve of a race, all the cars will be completely spread apart, and the player will spend most of the race driving alone. Way to go to kill the flow! Of course games like Need for Speed cannot accept that: so they cheat!

Imagine that the car of an AI is tied to the player’s car by an imaginary rubber band. the further they are apart (in a direction or another) the more this rubber band stretches, the more the AI will accelerate or break to go back to the resting band position: right in front or behind the player.

The result is what you can imagine: a very tight and thrilling race start to finish! A face-off of (seemingly) equally skilled drivers!

Designers are like magicians: smoke and mirrors are everywhere. But the moment a player notices one, the magic is gone. Car games go to a great length to not make you notice it: breaking the rubber band randomly, disabling it for some time after a successful catch-up, making sure AI cars cannot break rules (maximum speed for example) when catching up, or simply turning off the entire system in the last 10% of the race to keep the organic feeling of a finish line…

Have you ever noticed that racing games often have a formula: (number of AI opponent) = (max number of players) * [x]? It’s not decided at random, but ensure that players will all have at least one AI opponents rubber-banded to their car. Doing that ensures that even a terrible player, way behind the other, will still get to experience the thrill of the race against his personal AI rival.

Understanding our players

There are 2 examples that to me are beautiful examples of features built with the players in mind, and that I’d like to detail a bit.

The first one is in Half-Life 2. We talked about shooters giving a bit of extra buffer to our dying players, many of them having enemies miss-firing. Well, Half-Life 2 not only have enemies miss-fire but also specifically miss-fire in the direction of VIP targets: explosive barrels, surfaces that create loud sounds or VFX on impact… It’s not only about saving the player anymore but to give him a blast while doing it!


The second example is one from Hollow Knight. This game has a beautiful mapping mechanic: every time players enter a new zone, they will have to discover it blindly until they find Cornifer, the Cartographer NPC, that will sell them the map of the area.

Each new area then turns into a treasure hunt: Cornifer being hidden in a unique spot, and the player scouting for some subtle breadcrumbs to follow (some pages on the ground and the faint singing of Cornifer in the distance. It’s a beautiful mechanic.

But then comes Deepnest, the worst area of the entire game: it’s dark, it’s deadly, and its level design is built like a maze to trap players. Venturing in it without a map would lead to many deaths, frustration, and the risk for the exciting exploration moment to be completely destroyed.

This is where Team Cherry is slightly cheating: not only did they place Cornifer extremely close to the entry point of the area, and on the main path, but they also placed 2 of them: one for each possible entry the player may take. The moment the player discovers one makes the other disappear from the game, ensuring that every single player will have a map at that moment. It’s elegant, it’s caring, and it’s another subtlety that makes this game such a masterpiece.

Is it ok to lie to the player?

Here we are… The tough question. Every trick presented here is, in a way or another, about lying to the player. No, players didn’t survive death only because of their skill, nor were they exactly in range of this enemy when they killed him…

But does it make it ok if the player doesn’t notice it? Or are these tricks something we should fight against for the future of our industry? Well, this is a question that you will have to answer for yourself. What I can give you though, is a specific scenario where this very question fell upon me, and the choice I made.


The Crew is a game we always referred to as a “Driving Game” in development (in opposition to the racing genre). We tried our best to have fluid, uninterrupted driving sessions. You could decide to go for a full circle road trip around the US, and it would end up being a 3 hours uninterrupted driving experience through the country. Bliss.

We made sure also that these random road trips would enter the global player’s progression: the game as 500 bite-size challenges that players can trigger in the world while driving through them, and that we carefully crafted to be as little invasive as possible (as described in Menus & HUD: the Temporality Perspective). These challenges would reward players with money, XP points, and new parts to equip on their car for each medal they were getting.

So far so good. At least until a gameplay programmer gave me the bad news: in order to equip a new part on a car, we needed to rebuild the entity completely. This meant fading the screen to black (or move the camera away from the car), destroy the car, apply the modifier, rebuild the car, spawn the car, bring back the camera. And this tech specificity destroyed my plans for a perfect flow.

I had globally 2 choices:

  • We do not lie to the player! If a new piece is equipped (we are talking about metrics from 0.1% to 1%, almost impossible to feel), then the player deserves to play with his fully equipped car: fade to black, upgrade of the car, and respawn stationary on the side of the road, even if the player was full speed on the highway when the “equip” button was pressed.
  • Let’s lie to them, Flow comes first! If a new piece is equipped, we will pretend to upgrade the player’s car, update the UI and all, but in reality just stack the bonuses until the next cut-scene (crash, race, etc.) that the player will trigger, which effectively will rebuild the car and apply the proper updates and bonuses on it!

Well, younger me got offended we would consider lying to our players and break the purity of the game, so I pushed for honesty, and we went with the first option. The designer I am today believes it was a terrible mistake. There is something bigger at play than just pure and honest systems. Call it Flow, “the Zone” or whatever else, but these moments of magic are what makes our medium so amazing to me.

We are Game Designers Masters

What I believe today, is that game designers are more than that. We are creating the cues, systems, interactions, rules our players will play with, and we decide what is right or wrong, accepted or not, true or false. We are the game masters of our own games.

Imagine all the tricks we talked about in this article, but from a Dungeon Master perspective:

  • “As you enter the room, bullets fly over your head and embed themselves in the door: it’s an ambush!”
  • “You run for your life! Miraculously, you manage to hide as a hatchet flies next to your head with a threatening ‘woosh’!”
  • “As your food stock emptied and you thought all hope was lost, you spot an orchard in the distance!”
  • “Only a few hundred meters left for you to win the Nascar championship. But as you start dreaming of the cup, your rival appears in the rear-view mirror…”

How epic an adventure will be is both the responsibility of your players and yourself. But, as designers, you have the final word over the experience. You can bend the rules, you can favor players or punish them, you can throw a twist when the gameplay stall. Use this power!

But be careful, the best Game Masters are the ones who know how to set their player free.

GDKeys community Tricks

We discussed this article in great length on our Discord and devs started sharing their own tricks. I will keep this list growing, so feel free to come back and check it out here and there!

RoboQuest

The guys at RyseUp Studio are developing an awesome Rogue-like FPS called Roboquest. Be sure to check them out as this is an extremely promising game and their team is amazing.

Here are their own tricks (and they promised that many more will come in due time):

  • Aerial Jump | you can still jump for 0.25 seconds after leaving a platform, this was made because in FPS you still see the platform beneath you in the edges of your screen even if your character has left it, meaning you think you’re still landed while you’re not, leaving to a frustration feeling when trying to jump at that moment”
  • Low Health Threshold | damaging an enemy down to a threshold (from 1% to 5% based on enemy max health), will always kill it, effectively reducing / removing the effect ‘I left the enemy at 1 hp'”
  • Incremental Chance | perks with a % chance effect will slowly increase their chances if they failed to activate”
  • Slower Projectile | enemy projectiles heading towards the players are slowed in a small cone in front of him, this makes them easier to dodge, leading to the player thinking he’s always ‘perfectly dodging'”
  • Slow Warmups | rushing forward an enemy and entering a small cone in front of him will slow down his attack pattern, this was made to promote forward combat and let the player ‘have the initiative'”

Coyote time and percentages bending are fairly usual best practices, and just good game design to me. But the other 3 are very interesting: Low Health Threshold is taking the classic “prevent the player dying” and spin it on its head to create a “make sure enemies die” scenario. And Slower Projectile and Slow Warmups are awesome tools to empower the player and encourage him to take risks and push forward, raising the intensity of the fight organically. These are crazy good!


Do you have your own game design secrets? Drop them in the comments or come and share them on Discord. I love these pieces of genius hidden design and would gladly expand this list with yours!


Do you want to get regular quality articles on Game Design and join an awesome community of devs and designers on our private Discord to discuss design, learn, and review each other’s games? Then consider supporting GDKeys.

5 thoughts on “Game Design Dirty Little Secrets

Add yours

  1. Has there been any game (in your experience) where they change the hitbox/hurtbox of the player or enemy during the game?

    I’m thinking of the player suffering a CURSED state whereby their attacks are more likely to whiff, while that of the enemies have a greater chance of success.

Share your Experience

Up ↑