Game UI/UX & Interactive.
HUDs, menus, and browser-native experiences. We set a frame budget on day one and ship under it.
Problems we solve
- —Game UI designed by an artist and coded by a systems engineer — in separate rooms
- —Configurators built as one-offs with no design system behind them
- —Browser experiences that look great on a retina screen and stutter at 20 fps everywhere else
Approach
How we run a game project.
- 01
Performance budget first
We agree the frame budget before any assets are produced. Then we stay under it.
- 02
Design system as foundation
HUD primitives and menu patterns defined once, reusable everywhere in the game.
- 03
Composable, not monolithic
Every interactive component built to survive a re-skin or a feature extension without a rewrite.
Stack we reach for
The only page on the site where stack appears. Tools are means; the system is the goal.
- WebGL
- Three.js
- Canvas2D
- Y.js
- Cloudflare Durable Objects
Common questions
What people ask before they book a call.
- What is a performance budget and why does it matter for game UI?
- A performance budget is a hard limit on frame time your UI is allowed to consume. We agree the number before any assets are produced — typically 2 ms per frame for UI on a mid-range device. Every design decision is made with that number visible. UI that looks great but drops you from 60 fps to 45 fps is not shippable.
- Do you design the UI or just implement it?
- Both. Most projects come to us without a UI design system. We design the HUD language, component library, and interaction model, then implement it. If you have existing designs, we audit them for performance feasibility before building.
- What is a browser-native game experience?
- A game or interactive experience that runs in a standard web browser without plugins — built with WebGL, Canvas, or CSS/JS animation. We have shipped browser games at 60 fps on five-year-old laptops at 1.4 MB total JS weight.
- Can you work with an existing game's design language?
- Yes. We have extended existing UI systems for projects mid-development. The first step is an audit of the current component structure before we extend it — adding to a fragile system without understanding it is how you introduce bugs.
- How do you handle UI across multiple screen sizes and resolutions?
- We design to a reference resolution and implement a scaling system on day one. Safe zones, anchor points, and resolution-independent units are part of the foundation — not a retrofit.