GAMES

Designing one-touch browser games: lessons from building the Mobitoss arcade

What we have learned designing simple browser games that work with a single tap or swipe: one clear verb, readable rules, fair difficulty, instant restarts and short sessions that still feel satisfying.

The games in the Mobitoss arcade are small on purpose. Each one is built around a single idea that a player can understand in a few seconds and play with one hand on a phone or a mouse on a laptop. Small games are not easier to design, though. When there is only one thing to do, every detail of how that one thing feels matters.

These are the principles we keep coming back to.

1. One verb, clearly stated

A one-touch game should have a single main action, a verb, and the player should know what it is before they start. In Hero Jump and Bunny Jump, the verb is jump. In Dagger Aim, it is throw. In Pile Up, it is drop.

When a game needs a second action, the two should be clearly separated. In DreamLine, the screen is divided by a line: tap above it to rise, tap below it to dive. In ShadeZing, the verbs are split by gesture: swipe to move, tap to shoot. Two verbs mapped to two obvious inputs are easy to learn. Two verbs mapped to the same input are not.

2. Teach by playing, not by reading

Instructions are necessary, but most players skip them. The first few seconds of a game should teach the rule by making the player use it in a situation where failure is unlikely. A first platform close enough that any jump reaches it; a first target that is hard to miss; a first block that lands squarely.

We also keep a short written explanation on each game's page, because some players do read, and because a clear description of how to play is useful to anyone deciding whether the game is for them.

3. Make failure feel fair

Players accept losing. They do not accept losing unfairly. In a short game, fairness comes from a few things:

  • Hit areas that match what the player sees. If a character looks like it landed, it should have landed. Being slightly generous here almost always feels better than being exact.
  • No hidden information. Obstacles should be visible before the player must react to them.
  • Consistent physics. A jump of the same length should always go the same distance.
  • Clear cause. When the run ends, the player should know why.

If a player's reaction is "that wasn't my fault", the design has failed, however skilful the game is.

4. Raise difficulty gently and predictably

Difficulty in a one-touch game usually comes from speed, spacing, timing windows or the number of things to track. Raising one of these at a time, gradually, keeps the game learnable. Raising several together makes it feel random.

A useful pattern is to let the first 20–30 seconds stay comfortable, then increase difficulty in small steps, with occasional easier moments that let the player recover. A game that becomes hard immediately loses newcomers; one that never becomes hard loses everyone else.

5. Restart in one tap

In short games, players will fail often. The time between losing and playing again should be as short as possible: a score, a best score, and a button to go again. Every extra screen between failure and retry costs players.

Showing the previous best score also gives the player a reason to try once more. Beating yourself is the most common goal in an arcade game.

6. Feedback for every action

When the only input is a tap, the game has to confirm every tap. A small animation, a sound, a change in the score, a slight shake on impact: these tell the player their action registered and make the game feel responsive. Without them, even a technically fast game feels sluggish.

Feedback should also be readable at a glance. In a game played in short bursts, the player should never have to search the screen to find out what just happened.

7. Design for a phone first

Most casual players are on a phone, often holding it in one hand. That means:

  • controls within reach of a thumb;
  • nothing important hidden under the player's finger;
  • text and score large enough to read without zooming; and
  • a layout that works in portrait.

We cover the technical side of making games run smoothly on phones in building HTML5 games that run well on phones.

8. Short sessions, real satisfaction

A good one-touch game can be played in a minute and still leave the player feeling they did something: a new best score, a level passed, a stack taller than last time. That sense of progress, more than complexity, is what brings players back.

Key takeaways

  • Build each game around one clear verb, or two verbs mapped to two obvious inputs.
  • Teach through the first seconds of play, and keep a clear written guide.
  • Make failure fair, difficulty gradual and restarts instant.
  • Confirm every action with feedback, and design for a thumb on a phone.

You can play all of these games free at games.mobitoss.com, and read more about the collection on our games page.