UX & Interface Design · July 6, 2026

Title Screen and Menu Flow Design for Indie Shmups

Players who already know they want to play don't want to click through four submenus to start. The best title screens in the genre get out of the way in one or two inputs, and everything else exists behind a clearly marked options path.

Published July 6, 2026

It's easy to under-invest in the title screen because it's not "gameplay" — the temptation for a solo developer is to throw a logo and a "Press Start" prompt on screen and move on. But the title screen is the single most-visited menu in the game by definition; every session passes through it, and every returning player sees it dozens or hundreds of times over a game's lifetime. A flow that adds unnecessary friction there compounds across every one of those visits.

Structure the primary path around the returning player, not the first-time player

First-time players are a small fraction of total sessions once a game has been out for more than a few weeks; most sessions are a returning player who already knows what they want. Design the default flow for that majority case: "Continue" (or straight into the last-played mode) should be the fastest possible path from title screen to gameplay, ideally a single button press. Bury the onboarding-heavy options — tutorial prompts, "New Game" confirmation dialogs warning about overwriting a save — behind an explicit choice rather than showing them by default to a player who's launched the game for the fortieth time.

This doesn't mean hiding options from new players; it means ordering the menu so the common case is the fast case. A "New Game" option that's one press away is fine. A splash screen, a forced tutorial prompt, and a confirmation dialog stacked in front of "Continue" for a returning player is the kind of friction that shows up in playtesting as quiet frustration nobody quite articulates.

Keep menu depth shallow and the back path predictable

Every additional menu layer is a place a player can get lost, and shmup players in particular are used to fast, responsive input — a menu system with laggy transitions or inconsistent "which button goes back" behavior feels out of place next to tight bullet-dodging gameplay. A flat structure (title screen branching directly to Play, Options, and Extras, rather than nested sub-menus three layers deep) keeps navigation predictable. Whatever button cancels or backs out of a submenu should do exactly that consistently everywhere in the game — a back button that sometimes exits to the title screen and sometimes just closes a tooltip is a common and avoidable source of confusion.

Respect state across sessions

A menu that resets to its default tab every time the game launches forces a returning player to re-navigate to whatever they were last doing — reselecting a difficulty, reopening the loadout screen, scrolling back to where they were in an options list. Remembering last-used state (last difficulty selected, last stage played, scroll position in a level-select screen) removes small friction that adds up meaningfully across dozens of sessions, and it costs little more than persisting a few extra fields in the local settings file.

Menu navigation is itself an accessibility surface

Menu flow interacts directly with input and accessibility work covered elsewhere on this site. If your rebinding system (see rebindable controls and input remapping) lets a player customize their controls, make sure the menu itself respects those bindings rather than hardcoding its own separate navigation scheme — nothing is more confusing than a game where gameplay controls are fully custom but the menu still only responds to the original default keys. And because menus are read by screen readers in many accessible builds, following standard focus-order and labeling conventions — the kind documented in the W3C ARIA Authoring Practices Guide for interactive widgets — pays off even in a game engine context, since the underlying focus-order logic is the same problem regardless of platform.

The state machine underneath all of this — how the game tracks which screen is active and how transitions between them are handled in code — is covered in more technical depth in scene and state management in shmups, which is the natural next read once the UX flow described here is mapped out.