ONESHOTGEMS

For game developers

Let portrait layout support the game’s main decision

A portrait game is not a landscape scene squeezed into a tall rectangle. Decide what the player needs to notice and do in the next few seconds, then arrange the view so those things remain visible together. Prototype one encounter at the narrowest supported viewport before building a long level.

Reserve a readable playfield

Sketch the phone screen as three regions: active play, persistent status, and temporary prompts. Give the mechanic first claim on the center; place score, lives, and pause information where they can be glanced at without hiding hazards or goals. For a vertical platformer, keep the next landing area visible above the character. For a word puzzle, protect enough width for the clue and active tile row rather than letting overlays crowd them.

Use the viewport width rather than a guessed handset resolution. MDN explains how the viewport meta element tells a mobile browser to use the device width for its page layout. Check the playfield separately: a correctly configured page can still contain a canvas or panel that assumes a fixed size.

Choose how the game adapts

Decide whether the world reflows, the camera follows, or unused space becomes a border. Reflow works when the rules tolerate more or fewer columns; a camera works for a world larger than the screen; letterboxing preserves a designed playfield when aspect ratio should stay fixed. Avoid stretching characters or moving goalposts just to fill every pixel.

Check system UI and notches before pinning controls to an edge. Apple’s layout guidance describes safe areas and recommends keeping important material clear of hardware features; for Android, test phone and tablet ratios separately if both are targets. A portrait-only game should still handle a player rotating the device gracefully, with a clear layout policy rather than a broken half-screen scene.

Review one complete round

Run the tutorial, a busy moment, and the end screen at a narrow phone width and a larger device width. At each point ask whether the player can see the goal, the immediate threat, and the current status at once. Fix clipping and hierarchy before adding stages.

Questions about portrait mobile game design

Should a portrait game support landscape too?

Only if the game design benefits from it. A portrait-only decision is valid, but provide a usable layout when the device rotates rather than relying on a particular orientation lock.

Should the HUD always stay at the top?

No. Place information where it remains visible without competing with the mechanic. Test during active play, overlays, and the end screen because the best location depends on the playfield.

Sources and further reading

Report a correction · How these guides are made

Follow your curiosity