In this article, I want to explain how responsive and adaptive layout works in my game Stickers Merge.
The Problem
Poki games need to work on desktop, mobile, and tablet. The official Poki requirements say that on mobile the game should cover the entire screen in portrait or landscape, and supporting both orientations gives the best player experience. The game also has to scale to the full canvas across devices.
In real development this means:
- the game should not break inside different iframe sizes;
- portrait and landscape are two different UX cases;
- desktop players usually want to use screen width;
- mobile players often play in portrait and use screen height;
- UI should not just shrink until it becomes unreadable;
- gameplay space must be recalculated too, not only visual UI.
In Stickers Merge, I do not solve this with one giant resize handler. The responsive system is split into several layers.
Overall Architecture
There are three levels:
- Engine screen layer - calculates virtual canvas size, orientation, and emits
SCREEN_CHANGED. - Engine layout primitives - reusable components for common responsive tasks: positioning, scaling, fitting by bounds.
- Game composition components - scene-specific components that know the UX rules of the game: how many columns to show, where to put the panel, how to rebuild the physics playfield.
This split is important. The engine owns screen math and reusable layout operations. The game owns meaning and UX.