BUILD NOTE
Short browser sessions reward immediate clarity. A player opening a small game during a break is unlikely to read a long manual, install anything, or search a settings menu before the first action. Controls have to be close to the start of the experience, written in ordinary language, and repeated on the project page for people who want to check before launching.
Practical note
Netherguard and Block Smash use different kinds of attention. Netherguard asks the player to read clues and avoid unsupported guesses. Block Smash asks the player to aim, launch, and react quickly. Because the mental load is different, the control notes should also be different. A single generic “use mouse or touch” line is not enough for every game.
Clear controls also reduce false bug reports. If a player knows that a game expects pointer input, visible reset controls, or a browser that supports modern canvas behavior, they can describe a problem more accurately. That makes the contact page more useful and the update log easier to maintain.
The rule for this lab is to keep control notes short but specific: what starts the game, what the primary input does, what can be reset, and what kind of device has been checked most recently. If that information changes, the project page should change with it.