Game Design Theory

The Illusion of Difficulty: How to Cheat in the Player's Favor

If a game accurately simulates reality, players will usually say it feels "clunky" or "unfair". Good game feel often relies on a series of hidden illusions that subtly bend the rules of physics and probability to favor the player.

IntermediateGame FeelPsychology7 min read

Why Reality Makes for Bad Gameplay

Computers process inputs in milliseconds, tracking pixels with absolute mathematical precision. Humans do not. When a player presses the "jump" button exactly as their character runs off a ledge, human perception tells them they were still on the platform. The computer knows they were 1 pixel past the edge, so the jump fails. The player gets frustrated and blames the "clunky controls".

To solve this, game designers have spent decades developing techniques that bridge the gap between absolute mathematical reality and human perception. At Supagames, we use several of these techniques across our platformers and action games to ensure the player feels powerful and in control.

Coyote Time (Grace Periods)

Named after Wile E. Coyote, who famously runs off cliffs and hovers in mid-air before falling, "Coyote Time" is a hidden grace period that allows a player to jump for a few frames after they have walked off a ledge.

💻 HTML/JS Editor

<canvas id="game" width="300" height="300" style="background:#222; border-radius: 8px; width: 100%; height: 100%;"></canvas>
<script>
const ctx = document.getElementById('game').getContext('2d');
let player = { y: 200, vy: 0, grounded: true, coyoteTimer: 0 };
let jumping = false;

// Try changing coyote time to 0 to see how hard it is!
const COYOTE_TIME_FRAMES = 12;

function update() {
    ctx.clearRect(0,0,300,300);
    
    // Simulate platform moving away
    let onLedge = (Date.now() % 3000) < 1500;
    
    if (onLedge) {
        player.grounded = true;
        player.coyoteTimer = COYOTE_TIME_FRAMES;
        ctx.fillStyle = '#444';
        ctx.fillRect(0, 250, 300, 50); // Platform
    } else {
        player.grounded = false;
        player.coyoteTimer--;
    }

// Apply Gravity
    if (!player.grounded) player.vy += 0.5;
    player.y += player.vy;
    
    // Floor collision
    if (player.y >= 200 && onLedge) {
        player.y = 200;
        player.vy = 0;
        jumping = false;
    }
    
    // Respawn if fallen
    if (player.y > 350) { 
        player.y = 50; player.vy = 0; jumping = false;
    }

// Draw Player
    ctx.fillStyle = jumping ? '#ffd93d' : '#4d96ff';
    ctx.fillRect(130, player.y, 40, 50);
    
    // Text
    ctx.fillStyle = 'white';
    ctx.font = '16px sans-serif';
    ctx.fillText('Coyote frames: ' + Math.max(0, player.coyoteTimer), 10, 25);
    ctx.fillText('Click anywhere to Jump!', 10, 50);

requestAnimationFrame(update);
}

// Click to jump
document.addEventListener('mousedown', () => {
    if ((player.grounded || player.coyoteTimer > 0) && !jumping) {
        player.vy = -10;
        player.coyoteTimer = 0;
        jumping = true;
    }
});

update();
</script>

In games like Sky Dash, 150 milliseconds of Coyote Time completely eliminates the "I swear I pressed jump!" complaint. The player feels skilled, and the game feels flawlessly responsive.

Input Buffering

What happens if the player presses the jump button 50 milliseconds before they hit the ground? In a strict simulation, the jump command is ignored because they are still in the air. When they land a fraction of a second later, they don't jump, and they run straight into an obstacle.

Input buffering solves this by remembering the player's button press for a short window and executing it as soon as the action becomes valid.

if (input.jump) {
    player.jumpBuffer = 0.1; // Remember the press for 100ms
} else {
    player.jumpBuffer -= deltaTime;
}

// Execute the buffered jump if they land shortly after pressing it
if (player.jumpBuffer > 0 && player.isGrounded) {
    player.velocityY = jumpStrength;
    player.jumpBuffer = 0;
}

When you combine Input Buffering with Coyote Time, you cover human error on both sides of a jump: pressing too early and pressing too late. This combination is the industry secret behind every platformer that is praised for its "tight controls."

Asymmetric Hitboxes

In the real world, objects have physical boundaries that match their visual boundaries exactly. In game design, aligning hitboxes directly to the sprite's pixels is often a mistake.

The Player's Hitbox: Should almost always be slightly smaller than the visual sprite. If an enemy bullet grazes the very edge of the player's cape, the player feels they dodged it. If that counts as a hit, the game feels unfair.
The Enemy's Hitbox: Should be slightly larger than their visual sprite. When a player swings a sword and the animation barely misses the enemy by a pixel, letting the attack connect makes the player feel powerful.
Collectibles: Coins and power-ups should have massive, generous hitboxes. Players hate having to backtrack just to touch a coin they missed by two pixels.

Manipulating Probability (RNG)

Humans are notoriously bad at understanding true probability. If a player has a 90% chance to hit an enemy, and they miss twice in a row (a 1% probability—unlikely, but entirely possible), they will perceive the game as "broken".

To counteract this, many strategy games use a "Pseudo-Random Distribution" (PRD). Instead of every attack having a flat 90% chance, the game might start the chance at 70%, and increase the hidden probability by 20% every time the player misses, guaranteeing a hit very quickly. Alternatively, many UI readouts lie: if the game says "95% chance to hit", the actual background code might treat it as a 100% chance to prevent extreme frustration.

Conclusion

A designer's job is not to build a realistic simulation; it is to build an experience. By bending the rules of physics, time, and math in the player's favor, we bridge the gap between human imperfection and computer precision. The result is a game that feels fair, responsive, and immensely satisfying.