Make failure legible
This is the first principle and the one everything else follows from. When a player loses a point they should know why, immediately, without analysis.
That constraint rules out a great deal. It rules out physics complex enough that an outcome cannot be attributed to a single cause. It rules out randomness in the player's own shots. It rules out an opponent whose behaviour is opaque. And it rules out hidden state — anything affecting the outcome that is not visible on screen.
It is also why the ball's shadow is drawn so deliberately. In a top-down view without a shadow, a ball that lands short is inexplicable; with one, it is obvious in hindsight, which is exactly what a player needs to improve.
One variable per variant
With thirty games sharing an engine, the temptation is to differentiate by changing several things at once. That is almost always wrong.
A variant that changes gravity, drag, bounce, paddle size and opponent skill simultaneously does not feel like a new game — it feels like a random game, because the player cannot attribute any of what they experience to any particular change.
A variant that changes one thing is legible. Gravity Ping Pong halves gravity and lets the consequences follow: flatter arcs, longer flight times, more net clips. Everything a player notices traces to one cause, which means they can adapt deliberately rather than by trial and error.
The exception is a final boss or a flagship stage, where combining previously seen rules is the point — but only rules the player has already met individually.
Editor’s note
This principle was learned the hard way. The first physics variants changed three values each and tested as 'weird' rather than 'different'. Reducing each to one change made them immediately legible.
The opponent must be fallible
An AI that never makes a mistake is trivially easy to build and produces a game nobody wants to play. It is not a challenge, it is a wall, and a wall teaches nothing.
The Expert rating here keeps a ninety-millisecond reaction delay and roughly a three and a half per cent unforced error rate. Both are deliberate. The delay means positioning still matters; the error rate means patience is rewarded.
The more important decision is when the error is decided. Rolling it every frame produces an opponent that appears to fail arbitrarily at the last moment. Rolling it once when the ball is struck produces an opponent that moves to the wrong place visibly, which the player can see and exploit.
That difference — the same error rate, decided at a different time — is most of what separates an AI that feels fair from one that feels cheap.
Difficulty should come from the player
A timer-based difficulty ramp gives every player the same curve regardless of how they are doing. That means the game is hardest for the people least able to handle it.
Tying the ramp to performance — the rally count, the return count, the survival time — calibrates each run to its own player automatically. A player returning forty balls gets a harder game than one returning four, and both got the game they earned.
It has an elegant side effect: the score curve and the difficulty curve become the same curve. The shots that are hardest to make are the ones worth the most, which is a much cleaner relationship than most scoring systems achieve.
Cap everything
Every escalating system needs a ceiling, and the reason is the same in each case: an uncapped system eventually makes every run end the same way for the same reason.
- The tempo multiplier caps between 1.45× and 2.05× depending on the game
- The combo multiplier caps at eight
- Incoming ball speed in the reflex game caps at 280 units per second
- The difficulty ramp completes and then plateaus at Expert
- Ball count in the multi-ball game caps at six
Past the cap, the challenge changes rather than disappearing. Before the cap the game asks whether you can handle something new; after it, whether you can keep handling something familiar. Those are different skills and both are worth testing.
Design the failure state, not just the success state
A lot of design attention naturally goes to what happens when things go well. The moments that decide whether somebody plays again are mostly the other ones.
When a run ends here, the screen states the score, the personal best, whether the best was beaten, and a specific sentence about what happened — the longest rally, the serve accuracy, the stage reached, the opponent who won. Then it offers a button that starts another run immediately.
The specific sentence is the part that matters. 'Game over, score 4,320' is a conclusion; 'your longest rally this run was 24 — keep the paddle moving between shots and the next one will be longer' is an invitation.
The restart button is focused automatically, so a keyboard player can press space and be playing again without reaching for anything.
Accessibility is a design constraint, not a feature
Treating accessibility as something added afterwards produces games where it is impossible, because the control scheme was decided before anybody asked who could use it.
Deciding early that one game would need exactly one input shaped the whole engine. It forced the input layer to merge keyboard, pointer and virtual buttons into one state object, which turned out to be the right architecture anyway. It forced every audio cue to have a visual equivalent, which made the games playable with sound off. And it produced One-Tap Ping Pong, which is the game the largest number of people can play.
- Every game pauses, from the keyboard, the button bar or the touch pad
- Every control is keyboard reachable with a visible focus outline
- Every audio cue has a visual equivalent, so sound is optional
- The reduced-motion preference thins particle effects substantially
- Touch targets are at least sixty-two pixels tall and never overlap the playfield
- The canvas carries an accessible name describing how to play it
Know what to cut
More features make a game worse more often than they make it better, and browser arcade games are particularly vulnerable because they are cheap to add to.
Things deliberately not built here: power-ups that change the rules mid-rally, because they make failure harder to attribute. A stamina system, because it punishes long rallies, which is the thing the games are trying to encourage. Unlockable content, because a two-minute game should not gate itself. Difficulty settings on games whose difficulty is already a curve.
The most useful test is whether a feature makes the player better at the thing the game is about. A combo multiplier does, because managing it is a decision. A randomised power-up does not, because it happens to you.
Build the score around the fantasy
Every arcade game has an implicit fantasy — the thing it wants the player to feel good about — and the scoring should point directly at it.
In a rally game the fantasy is endurance, so rally scoring is quadratic and milestones are announced loudly. In a precision game the fantasy is control, so a placed ball is worth twenty-six times a safe one. In a reflex game the fantasy is quickness, so the score includes your own start time in milliseconds.
When the scoring and the fantasy disagree, players feel it immediately even if they cannot articulate it. A rally game that paid heavily for winners would teach players to end rallies, which is the opposite of what it is for.
Be honest about what the game is
The last principle is about presentation rather than mechanics, and it is the one most often broken.
A game that invents player counts, fabricates leaderboards, presents fictional opponents as real athletes or claims online play it does not have is making a short-term trade against being trusted. On a site with no server, a global leaderboard would be fabricated, so there is not one.
The same applies to the physics. These games are arcade games, and every guide that explains a mechanic says so. Claiming realism the model does not have would cost nothing immediately and would be wrong.
It is also simply easier. A game that only claims what it does never has to remember which claims it made.
Key takeaways
- Make failure legible: a player should know why they lost a point without analysis.
- Change one variable per variant, so everything a player notices traces to one cause.
- An opponent must be fallible, and its errors should be decided early enough to be visible.
- Tie difficulty to performance, which makes the score curve and the difficulty curve the same curve.
- Cap every escalating system, so the challenge changes rather than the game becoming impossible.
- Design the failure screen: a specific sentence about what happened beats a number.
Frequently asked questions
Why not add power-ups to a ping pong game?
Because they make failure harder to attribute. If a rally ended partly because of a power-up you did not choose, the player cannot learn from the loss, which breaks the first principle.
How do you stop an AI feeling unfair?
Give it the same information the player has, a real reaction delay, and decide its errors once per incoming ball rather than every frame. The same error rate feels fair when the mistake is visible and cheap when it is not.
Why cap the difficulty ramp?
Without a cap, every run ends at the same speed for the same reason, which measures nothing. With one, the challenge shifts from reaction to concentration, which is a different and more interesting test.
Is accessibility hard to retrofit?
Very. Deciding early that one game would need exactly one input shaped the input layer, forced visual equivalents for every audio cue, and produced better architecture overall.
How do you decide what to cut?
Ask whether the feature makes the player better at what the game is about. Managing a combo is a decision and belongs; receiving a random power-up happens to you and does not.
Why does honesty about the game matter for design?
Because invented statistics, fabricated leaderboards and unclaimed realism all trade trust for a short-term impression. A game that only claims what it does never has to keep track of its claims.
Alex Morgan