The Game on a Handheld

The starting point for the game's console and handheld support was not a mature codebase with a port to trim down. As the developers describe it, roughly a year earlier there was no version for the newest Nintendo hardware at all, and the PlayStation version that existed was badly out of date. A great deal of what now ships was written from scratch.

That included the unglamorous problems of obtaining development hardware and building the whole toolchain around it. The studio's own account of the process is that it was chaotic and that the results exceeded what anyone involved expected, given how recently none of it existed.

It is worth stating plainly because the work is invisible in the finished product. A player who picks the game up on a handheld sees a puzzle game that runs; what that represents is a year of engine, shader and platform work carried out largely in parallel with the design of the game itself.

The overworld is the most demanding scene in the game, which is not obvious from looking at it. It is a wide view containing more geometry, more background effects and more moving parts than any individual puzzle room, and it is where performance problems show up first.

On a handheld, the overworld runs comfortably above the display's refresh rate once the settings are tuned, and individual puzzle levels run faster still. The early demo build, by comparison, was considerably slower in the same scenes — a gap that the developers attribute to a sustained pass of shader and gameplay code optimisation in the months between the demo and release.

The practical consequence for a player is that the frame rate can be capped well below what the hardware can produce in order to extend battery life, and the game will hold that cap without visible strain. The overhead is not wasted; it is what makes the cap possible.

One of the more interesting decisions in the porting work is what the team declined to do. Modern upscaling techniques, of the kind that render a game at a lower resolution and reconstruct the detail, depend on motion vectors — per-pixel data describing how the image moved from the previous frame.

This game does not generate them. Rather than build that machinery in order to enable upscaling, the developers chose to spend the effort on making the game run faster at its native resolution. That is a real trade, and it explains why the game's performance story is about raw frame rate and settings tiers rather than about reconstruction quality.

The reasoning fits the game. A puzzle game is not attempting to sell spectacle; it is attempting to keep a board legible. Optimising so that the image is sharp and the frame rate is stable serves that goal more directly than adding a reconstruction pipeline that would soften the very detail the puzzles depend on.

The game's graphics menu is built to answer the question players actually have, which is not 'which setting is highest' but 'what does this cost me'. The scene sits behind the menu, so changes to the settings are visible immediately, and the frame rate counter updates as the player moves between tiers.

That design turns a chore into an experiment. Dropping a tier and watching the counter settle, then raising it and watching it fall, tells the player exactly where their device's comfortable line is, without requiring them to read a guide or guess at hardware equivalences. A handheld that cannot sustain a high-quality mode at a good frame rate can be tuned down until it can, in a few seconds, in the menu itself.

It is a small piece of user experience that most games get wrong, and it matters more on a handheld than on a fixed machine, because handhelds vary so much in what they can sustain.

The deeper reason the game travels well to modest hardware is the same reason it looks the way it does. A fixed camera means the engine never has to render a scene from an angle it was not designed for. A legible grid means the important information is in flat shapes and clear colours rather than in fine detail that would fall apart at lower resolutions. Layered atmosphere effects are done in ways that scale down rather than ways that break.

This is the payoff of the art direction described elsewhere: a game built around legibility is also a game that degrades gracefully. The same decisions that keep a puzzle readable on a large screen keep it readable on a small one, and the performance headroom that legibility buys is what the porting team spent.

None of it was accidental. The engine is the studio's own, written in the studio's own language, which means a system that is not performing well can be drilled into and fixed rather than worked around. Owning the whole stack is expensive, and this is the kind of result it buys.

The handheld version ends up being a good demonstration of what this kind of game actually requires from its hardware. It does not need cinematic fidelity or high frame rates for their own sake. It needs a clear image at a resolution the screen can deliver, a stable frame rate, and controls that make single-step movement and instant undo feel precise.

Those requirements are modest, and the game meets them with room to spare — enough that a player can trade frame rate for battery life and lose nothing that matters. For a genre that is often associated with sitting still and thinking, that portability is a genuine change in how the game can be played, and the work behind it was not small.

The broader point is that the technical story here is the same story as the design one. Restraint in the visuals bought headroom; headroom bought performance; performance bought the ability to play the game on a handheld without compromise. The choices line up.