Mobile Browser Game UX: Lessons from The Journey

A browser game can fit inside a phone screen and still be difficult to play. The controls may compete with captions. A finger can leave a button while the game still thinks it is held down. Browser controls can change the usable height halfway through a session.

In The Journey, the mobile experience depends on the interface around the canvas as much as the scene inside it. These are several implementation choices worth examining when turning an interactive project into something people can use on a phone.

Size the experience to the available viewport

The active game uses a fixed container and a progression of viewport-height declarations: a conventional viewport height, then small viewport height, then dynamic viewport height.

The distinction matters because mobile browser chrome changes the visible space. Small viewport units describe the more constrained viewport, while dynamic units respond to changes in browser UI. MDN explains the trade-offs in its viewport-relative length reference.

This is not a universal instruction to use dynamic height everywhere. A scrolling article and an active game have different needs. For the game, the goal is to keep the active surface and controls within the space currently available.

Portrait and landscape also deserve separate decisions. The Journey contains dedicated coarse-pointer layouts for both orientations. A narrow screen should not simply inherit desktop button placement at a smaller scale.

Reserve room for fingers and captions

The canvas is only one layer. Controls, captions, pause actions and memory overlays all need space.

The Journey reserves a lower band for touch controls and moves portrait captions above it. That relationship is more useful to review than the size of either element in isolation: can someone read the current story beat while still reaching the controls?

Safe-area insets add another constraint. The implementation uses the browser's safe-area values when positioning controls and overlays. CSS environment variables expose those insets, as described in MDN's env() reference.

A layout review should include the moments with the most competing elements: a caption, an active control and an overlay transition. An attractive empty game screen tells you little about those states.

Treat a cancelled touch as a normal event

It is tempting to model a button as two events: press and release. Browsers have more ways to end an interaction.

A pointer can be cancelled, capture can be lost, or the page can lose focus. The Journey's controls include pointer-cancellation and lost-capture handlers, and the game clears input when the page becomes hidden or loses focus.

The practical requirement is simple: an interrupted interaction must not leave the character moving indefinitely.

The pointercancel event documentation describes situations in which the browser stops a pointer interaction. Those are ordinary mobile conditions, so they belong in the design and the checks.

For manual review, hold a movement control, interrupt the page, then return. Also try moving a finger away from the control before releasing it. Observe the character, not just the button's visual state.

Offer another way to experience the story

The Journey has separate Play and Story modes. They serve different visitor intentions. Some people want an interactive challenge; others want to follow the narrative.

Providing both is a product choice about access to the material. It does not establish complete accessibility by itself. Each mode still needs readable content, understandable controls, keyboard behaviour where relevant, and testing with the people expected to use it.

Keeping the mode choice explicit also makes the landing experience easier to understand. Visitors can decide how they want to engage before committing to the game.

Spend rendering detail deliberately

The Journey's canvas sizing accounts for device pixel ratio and caps its contribution to the rendering surface. That bounds one source of rendering cost on dense displays.

A smaller rendering budget is not evidence of smooth performance on every phone. Scene complexity, browser behaviour and device capability still matter. The relevant question is whether the game remains readable and responsive on the devices being tested.

The same caution applies to automated checks. The repository checks aspect-ratio calculations and several mobile layout rules. Those checks help catch regressions, but they do not replace playing on a physical phone.

Review complete moments

A useful mobile review follows a sequence: enter the experience, choose a mode, read a caption, use the controls, interrupt the session, return, and leave again.

Watch what happens between those moments. Does input stop when it should? Does an overlay dismiss cleanly? Can the visitor recover without guessing?

Those transitions are where a small browser project starts to feel dependable. They are also where an otherwise polished scene can become frustrating.

Try The Journey, and read the story behind its creation.