Making a browser game feel good: juice, onboarding and end screens

We have released more than 100 free browser games at PN Scripts: small arcade, puzzle, card, rhythm and strategy games that run in a browser tab on a laptop or a phone. Building that many taught us something uncomfortable. A game can be finished, bug-free and fair, and players still close it after twenty seconds. The difference between a game people put down and a game they replay is rarely the core idea. It is the first ten seconds, the feedback on every action, the pace of the difficulty and the screen that appears when a round ends. This article is the checklist we now apply to every game, with examples you can play.

#1. Teach in ten seconds, without a wall of text

Nobody reads a rules screen in a browser game. Our rule is that a new player should understand what to do within ten seconds of pressing Start. What works:

• A ghost hand. An animated hand or finger shows the first move, then disappears once the player does it. In Skyfennel, a vertical shooter, a ghost hand shows the drag control, and enemies hold fire for the first six seconds so the player learns to move before anything can hit them.
• Coaching on the playfield. In Cragdrift, a lunar lander, a ring around the landing pad says SAFE or TOO FAST while you descend, and the first moon draws an arrow to the pad. The player learns the rule by seeing it, at the moment it matters.
• A first level that cannot be lost. Mossdelve, a hex minesweeper, guides the first reveal; Stitchwold, a nonogram puzzle, starts with guided first pictures.
• One-time tips that appear once, when the situation first comes up, and never again.

The test is simple: give the game to someone who has never seen it, say nothing, and watch the first ten seconds.

#2. Every action needs an answer

"Juice" is the name game developers use for feedback that makes an action feel physical: a small burst of particles, a number that pops up and floats away, a sound, a brief flash, the camera nudging on an impact. None of it changes the rules. All of it changes how the game feels.

• A hit, a catch or a match should have a sound, a visual and a number at the same time. In Clattermoss, a pinball game, every bumper hit shows a pop-up score.
• Show the cause and the effect. Rillgate, a pipe-routing puzzle, previews the water flow live while you place pipes and marks open pipe ends, so a mistake is visible before it costs anything.
• Reward the small steps. In Rungwick, a word ladder, each correct step gives off sparks.
• Keep it short. Feedback that lasts longer than the action becomes a delay. Most of ours lasts a few hundred milliseconds.

All the sound in our games is synthesised in the browser with the Web Audio API, so feedback costs nothing in download size. Remember the mute key, and make sure it does not clash with the game: in typing and word games, the letters P and M must reach the game instead of pausing and muting it.

#3. Ramp the difficulty, and let players see their progress

A game that is hard from the start loses beginners; a game that stays easy loses everyone else. What we do:

• Start below the player's ability and raise one thing at a time: speed, then number of enemies, then a new mechanic.
• Give short sessions a goal: medal times in Skidlark, a kart racer where you also race your own ghost; par times and gems in Halfglow, a platformer.
• Offer a daily level or map. Many of our games, from Swaybloom to Puttlewick, have one, and it gives players a reason to come back tomorrow.
• Make board games adjustable. In Duskturn, a Reversi game, the AI gets stronger each time you press Next.

#4. The title screen is a trailer

A static title screen with a Play button wastes the moment when a visitor decides whether to stay. A short attract mode playing behind the title shows the game in motion: the AI plays against itself on the Duskturn title, traffic already flows behind the title of Signalbrook, a traffic light game, and four AIs battle on the title of Starsow. The player has seen the game before the first click.

#5. One clear end screen

The end of a round is where a player decides to play again or leave. A good end screen says what happened (score, best score, what the player achieved), offers Retry as the obvious first button, and then Next or Menu.

Our most common bug here was not in the logic but in the drawing. Several games drew their own result banner on the canvas while the shared game shell also showed its result card on top, so the player saw two panels over each other. An automated test that played every game to the end reported them all as passing, because the game did reach its result state. We found the problem only by looking at screenshots of every end screen, on a phone-sized screen too, where the card covers the whole canvas. The rule we use now: one panel only, owned by one piece of code.

#6. Phones are not small laptops

• Touch targets of at least 44 by 44 pixels. Where a puzzle needs small cells, as in Stitchwold, a magnifier under the finger helps.
• No hover-only information.
• Controls that work with a thumb: tap zones on the sides of the screen, or one-button games such as Gustling, where you hold to climb and let go to sink.
• Test touch separately. In a penalty shootout game we found that aiming also reacted to taps outside the goal; it now locks only on the goal.

#7. Test like a player, and look at the result

Each of our games ships with a smoke test: a headless browser opens it, checks that there are no console errors, starts it with Enter, plays it with a simple built-in bot until the result screen, and starts it again on a phone-sized screen by touch. That catches crashes. It does not catch a game that is no fun, a tip that covers the start button or two panels drawn over each other. For that, someone has to play the game and look at every capture. In our release review of four batches, a quarter of the games were held back on those grounds, and most came back only after a repair pass.

If you want to see these ideas in practice, all of our games are free to play on games.pnscripts.com and on itch.io. For a deeper look at 3D in the browser, read browser games with three.js and WebGL; for planning your own, planning a game prototype and a vertical slice.

#Frequently asked questions

What does "juice" mean in game design?

Feedback that makes an action feel physical and rewarding without changing the rules: particles, pop-up numbers, sounds, small screen shakes, flashes and easing on movement.

How long should a tutorial be in a browser game?

As short as possible. Aim for the player making the first meaningful move within ten seconds, and teach the rest when each situation first appears.

Can too much juice make a game worse?

Yes. Effects that last longer than the action slow the game down, and constant screen shake tires players. Keep feedback short and in proportion to the event.

Are the PN Scripts games really free?

Yes. All of them are free to play in the browser, with no account and no in-game purchases.