Ten seconds to the main menu

Stewry took about ten seconds to reach the main menu on a television. Not on a bad phone — on the machine with the fastest disk in the house.

Ten seconds is absurd for a game this small, so the launch was worth taking apart. It turned out the splash screen was not slow. It was patient four times in a row.

The launch was paying for itself four times over

The splash screen has four jobs: read the save file, sign in and fetch cloud progress, build the next scene, and get the input layer up. It did them like this:

read disk ──► then build the scene ──► then wait for the cloud ──► then animate the bar

Each one finished in full before the next began, so the screen lasted as long as the sum of them. On a console, where the scene build is slow and a cold network stack is slower, that sum was most of ten seconds.

None of the four ever needed another to have finished.

The worst offender was the scene build — the slowest job — sitting behind the disk read, one of the fastest. The reason was a comment claiming the player’s settings might decide which scene to preload. Nothing had ever decided anything; the target was a fixed field. A guess written down once, obeyed for a year.

The cloud wait was the second. The splash blocked up to five seconds on a network round-trip that the menu is perfectly happy to finish without — the menu already shows progress arriving late, because that is the normal case.

All four now start in the same frame and the screen lasts as long as the slowest one, not all of them. Each has its own deadline measured from the moment the screen opened, so a slow job spends the other jobs’ waiting time instead of adding to it.

The other thing that changed: the launch now logs its own timing.

Splash held 1.40s - save 0.20s, cloud 0.88s, input 0.10s, scene 0.10s.

Four overlapping jobs mean the only useful question is which one finished last, and that is invisible from the outside. “The splash screen is slow on my console” is not a report anybody can act on. That line is.

A loading screen that answers

An animation proves the renderer is running. It does not prove the game is still listening, and on a slow machine those are the two different things a player is actually trying to work out.

So the loading tips can now be steered — arrow keys, the d-pad, or the shoulder buttons. Press one and the tip changes on that frame. A screen that answers a button press is the only unambiguous proof the game has not hung, and it is worth more than any amount of motion.

The auto-advance keeps running underneath and simply stands down for a few seconds after each press. A tip that slides away mid-sentence because a timer was still counting is worse than no timer at all.

The menu inherits an input layer that has already settled

The start screen needs a lot on the frame it appears: the input system up, a device family chosen, the button-glyph artwork loaded, and every on-screen prompt resolved. Some of that used to land a frame or two late, which is why the prompts could be seen settling — keyboard art for a moment on a machine with no keyboard.

None of it needs the start screen. So the splash — a screen whose entire job is to wait — does it first, overlapping a scene build that is slower than all of it put together. The menu now draws its prompts once, correctly.

A phone layout, enlarged

The menu buttons were tuned on a phone, where two of them sit in the top corners and have to leave a gutter between them. Those numbers are a fraction of the screen width with an absolute ceiling, and on a big screen the fraction stops binding and the ceiling takes over.

Which made the Start button a third of the screen wide.

That is a phone layout enlarged, not a layout for a television. Past a certain size a button does not need to keep growing to stay comfortable — it only needs to stay legible, and the readability correction already handles legibility.

Buttons now take a smaller share of a wide frame:

	Before	After
Start	38% of the width	28%
Customize, Leaderboard, Settings	28% each	20%

Both the fraction and the ceiling scale by the same factor, which is what keeps Start proportionally bigger than the buttons beside it instead of everything collapsing to one width. Phones are untouched: the correction that shrinks the reference frame on a small screen is the same signal this reads, so a phone in portrait never triggers it.

Start then lost a little more, because it was mostly empty plate — a five-letter word in a very wide button.

A shrinking plate needs children that shrink with it

Narrowing the buttons broke the leaderboard card, and the way it broke is the useful part.

The card is a plate holding a heading and four rows, each with a small icon pinned to its own left edge. The rows were authored at a fixed width for the original plate. Narrow the plate and the rows do not narrow with it — so a row wider than its own plate hangs off both sides, and the icon pinned to that row’s left edge ends up outside the card entirely.

The rows now stretch with the plate, which is what the heading above them was already doing. And the plate has a minimum height, because its contents are a fixed-height stack: locking height to width is right for a button, which scales as a unit, and wrong for a column of rows.

The general rule, written down so it stops recurring: anything that resizes must have children that resize, or a floor that stops the squeeze. A child at a fixed size inside a responsive parent is a child that will eventually be outside it.

Two things that were simply wrong

The leaderboard’s column headings — #, RUNNER, SCORE — were in the dialog’s title strip at the very top, about 370 units from the rows they label, with the board name, the subtitle, your own placement and a divider in between. They now sit directly above the list, which is the only place a column heading means anything.

And the pause button on the HUD had no icon. Not a dark icon — no icon. It was a bare rounded plate at almost exactly the luminance of the surface behind it, which is why it read as invisible. Its three neighbours on the HUD all pair a dark plate with a light glyph, so the pause button now does the same thing they do.

Settings that cannot work are not shown

Stewry has a three-way screen-orientation setting: follow the device, hold landscape, hold portrait. It works by asking the operating system to lock rotation.

Desktops ignore that request. So did every other machine without a rotation sensor. The setting was a control that changed a stored value and nothing else — which is worse than no control, because the player presses it, watches the label change, watches the screen stay exactly where it was, and reasonably concludes the game is broken.

It now only appears where the device can actually be turned. The row removes itself, and the settings panel closes the gap so there is no hole where it used to be.

Said plainly: what is not fixed

Stewry ships on Windows, Linux and Android. A controller and a television are where a lot of this was found, but a console release is not a thing we are announcing — treat the console parts above as work, not as a date.

The one fix that is genuinely unconfirmed is the most important of them. On a console, the system owns when an application stops running; a game that terminates its own process does it behind the platform’s back, and the symptom is the game vanishing and then refusing to start until the console is made to forget it. Stewry was doing exactly that, because the Back button was wired to quit — sensible on a desktop, wrong on a pad.

That path is now closed. But the check that identifies the hardware can only be proven on the hardware, so the launch log states which decision it made and we will be reading it off a real machine rather than assuming.

One more, smaller: in portrait the leaderboard card is now taller than its compact layout intended. The rows were spilling out of it before, so this is the better of the two wrong answers, and it needs a decision about what that card should show on a tall screen rather than another nudge to a number.