Have you ever played a game where dodgy collision detection screwed you out of a victory? A 3D action game where the camera got itself stuck in an awkward spot and forced you to fall down a hole? A racing game with cheating opponents? A fighting game bot that repeatedly stun-locked you and pummeled you to death with cheap attacks? An unexpected death at the hands of an invisible trap or an off-screen enemy you had no idea was there? An MMORPG where you lost to another player because they had all the pay-to-win upgrades and you didn’t?
Sometimes these things are unfortunate technical bugs that should have been fixed, and sometimes they are more fundamental issues with the design itself. Either way, almost any time the game forces the player to take a penalty for no error of their own it can lead to aggravation and a sense of the game being unfairly broken, unenjoyable and a bad investment of one’s time and energy.
The exception to this is in situations where occasional unfairness may be a key part of the game and the player is clearly aware that this is a possibility. Sometimes when you’re playing Pokémon, your monster will miss in battle – the player is aware this can happen, and can accept it as bad luck and part of the game.
Often, too, when playing Mario Party, the player can roll a 1 – this is understood to be something that “just happens sometimes” when rolling a dice, and that all of the other players have an equal chance to get the same outcome. Of course, this is done deliberately to level the playing field in a party setting, so that novice players can have a chance against veterans; in a way, we might consider this “fair unfairness.”
In most situations, though, your game should be thoroughly, deeply fair, and if the player struggles it should be because they didn’t pay attention, made a bad input, didn’t plan properly, or some other failing of their own – not because the game behaved unexpectedly or incorrectly.
Let’s look at some ideas and principles to make sure your game is playing nicely with the other kids.
Generous collision detection
In this instance, I’m taking it as read that all of your collision detection works correctly – obviously, if your players are falling through walls and the like, you’ve got fairness problems that you don’t need me to point out.
Even in a correctly-functioning collision system, though, there may be further design-type considerations for making your hitboxes as kind as possible. You can give your power-ups, pickups and collectables big, generous hitboxes, and give your enemies small, conservation collision; if it’s a platformer, you can also make the collision area of the platform extend a bit beyond its visible limit, so that if the player falls off, they definitely fell off.
In essence, you should always give the player the benefit of the doubt with all their intended actions – if they kind-of touch a power-up we let them have it, and if they lightly brush an enemy or hazard we don’t consider that a penalty.
Giving the player enough information
I think a good rule of thumb is to always try to design games that don’t require any prior knowledge to beat. If the player has to die at least once to figure out what they’re supposed to do, that’s just sloppy game design (unless that’s a key part of the concept and/or design of that game – I’m not talking about games like 1001 Spikes, which gives the player 999 lives and throws them into challenges that are designed to be learned through repeated, iterative failure).
In most cases, a player should in theory be able to see a level for the first time and understand everything they need to know to beat it, and even if they fail they should be able to look back and see that they had been forewarned, that they disregarded a vital clue, or that they simply made a mistake trying to complete a challenge they understood fully. The player should always understand why they died.
You should always be on the lookout to work on things things that might catch players off guard (unless it’s a horror game with deliberate jumpscares…). For example, here’s an enemy from my own upcoming game, Cornflake Crisis:
This lemony enemy spits seeds when the player is in close proximity; he is the first projectile-firing enemy encountered in the game, and I was concerned that he could conceivably take a new player by surprise and cause them to unavoidably take damage. To try to mitigate this, I’ve done a number of things:
- His idle animation suggests that he might have something in his mouth.
- He performs an exaggerated, telegraphed spitting animation before every projectile is fired.
- Perhaps most importantly: the first time this enemy is encountered, his behaviour can be observed from a distance before the player has to interact with him. In the screenshot above, you can see that the player is safely elevated away from the enemy; there are also golden collectibles to encourage the player to linger on the safe platform, giving them a little longer to notice that the enemy below is spitting projectiles before they jump down and face him.
Note that this isn’t babying the player! I can now use this enemy to create deviously hard challenges later in the level if I like, but I should always make sure the player understands how everything works in general before I start to seriously make demands on their skill.
Considering the extremes of random systems
If your game is a more procedural, systems-driven experience with a lot of randomisation – perhaps a roguelike or a Minecraft-type product – a lot of unfairness could lurk at the limits of your generation system, and you’ll need to identify possible ways that could manifest.
What do I mean by this? Well, let’s imagine a simple game with a battle system based on dice rolls. It’s not very likely that the player would consistently roll a 1 every single turn, while the enemy rolls a 6 time after time, but it is possible. Congratulations: by not allowing any provisions for outlying probabilities, we have designed a game with the potential to be maddeningly unfair.
If a game generated a random landscape and spawned the player in a random place, would it be conceivable that the player might spawn in the middle of a lava lake, or ten miles from any useful resources, or in the middle of an enemy camp? The chances of a given thing happening may be 1000-to-1 – but if a thousand people play your game, it’s eventually going to happen to somebody, and they’re going to have a totally not-cool experience.
In these types of games, the mantra is: if it can happen, it will happen, so fix it.
Sometimes in order to make a game seem fair we actually end up doing a bit of what I call Secret Fudging. This is when a game does something behind-the-scenes, unknown to the player, to promote an illusion of fairness or increase the likelihood of things working out in the player’s favour.
It happens more than you might think – for example, one of the developers of BioShock has mentioned that a first shot from an enemy character will always miss the player (the point of the first shot being not to catch the player off-guard, but to give them a heads-up that they’re being fired upon). In DOOM, your last bit of health lasts longer than the rest of it does; in The Legend Of Zelda: Breath Of The Wild, Link’s stamina when climbing rock faces lasts a little bit longer than it says it will, just to give the player a tiny extra chance to reach the top before they finally fall.
This allows for a greater number of dramatic and engaging moments of “just barely making it”, and also results in players successfully fulfilling their intentions slightly more often than they would otherwise.
Many, many games do things like this. Platformers, for example, have long employed a Secret Fudge that some developers have dubbed “Coyote Time” after Wile E. Cotoye – which in essence amounts to allowing a jump input for a few extra frames after the player already fell off of their platform. Ideally, it should be a short enough duration that the player doesn’t really notice this is happening, but it allows them to slightly more frequently achieve the jumps they intended to (and it means that if they do fall down a pit, they really, really fell down that pit!)
Without this, a struggling player might be consistently timing their jumps too late and convincing themselves that the game is ignoring their input. Here’s an example of “Coyote Time” in action in my own game – notice that the player actually “jumps” from a point in the air slightly after leaving the box:
In essence, unless you’re making a Kaizo game, you probably won’t want the main emotional reaction to your game to be frustration. The best challenges are those that are hard, but clearly doable; there should always be the sense that failure occurs for fair and understandable reasons, and that if a player tries again and plays better they will stand a good chance of completing their goal successfully.