Tutorials and menus

The wall of text

Kai and Remy's first Garden Defense opened with a wall of text: six paragraphs about planting, coins, sunflowers and pests. In the playtest, every tester skipped it in seconds. Then they sat on wave 1, not knowing what to tap, while the snails ate Sprig.

Players do not read before they play. A tutorial is the part of a game that teaches how to play, and the best ones barely feel like teaching at all.

Teach by doing

People learn a game by doing, not by reading. The famous first level of Super Mario Bros. (1985) teaches without a word: the first enemy walks straight at you, so you discover jumping in the first seconds.

Good tutorials follow a pattern: introduce one idea, let the player try it safely, then test it. Garden Defense wave 1 now has one slow snail, one glowing plant spot and a pointing hand. The snail waits until the player plants. A pause like that is called a gate.

The first 30 seconds

Many players decide whether to keep a game within the first minute, and plenty leave much sooner. So the opening must reach the fun fast.

• From tapping the app icon to playing should take seconds, not minutes.
• No sign-up wall. Let people play first, and offer an account later, once there is progress worth saving.
• Ask for permissions, like notifications, only when they make sense, and say why.
• Keep story scenes short, and let players skip them.

Bolt says: This course follows the same idea. You could start any lesson in any stage, and nothing was locked behind the ones before it.

Show, don't tell

• HighlightGlow, pulse or point at the one thing to touch next, and dim the rest.
• One idea at a timeWave 1: planting. Wave 3: sunflowers make coins. Wave 5: the first flying pest.
• A few words, at the right moment"Tap to plant" right next to the spot beats a paragraph on the menu screen.
• Let experts skipReturning players can skip the tutorial, and anyone can replay it from the menu.

Show, don't tell means teaching with what players see and do, not with long explanations.

Menus and pause

Menus should get out of the way. On the main menu, Play is the biggest button and the first thing your eye lands on. Every screen has a clear way back.

The pause screen needs Resume, Settings and Quit, and Quit asks "Are you sure?" so a slip does not wipe a wave. Games should also pause by themselves when they get hidden, for example by a phone call. In a browser game:

document.addEventListener("visibilitychange", () => { if (document.hidden) pauseGame(); });

Buttons for fingers

A fingertip is much bigger than a mouse pointer. Apple's design guide asks for touch targets of at least 44 by 44 points, and Google's asks for 48 by 48 dp, about 9 millimetres. Points and dp stay about the same real size on every screen. Leave gaps so a thumb does not hit two buttons.

Every press needs feedback within about a tenth of a second: the button sinks or lights up, and a click plays. A button you cannot use yet looks dimmed and says why: "Needs 50 coins".

Settings that stick

The settings screen is where players make the game fit them: separate music and effects volume, screen shake on or off, text size, controls and language.

Settings must stick. If a player turns the music down and it comes back loud next time, they feel ignored. A web game can save settings on the device with localStorage, a small storage space the browser keeps for each website.

Bolt says: Next lesson: accessibility, which turns settings like these into a game more people can play.