Hollow Way
A calm isometric puzzle game for Android where a small robot crosses floating block islands through deterministic movement, material and hazard rules.
Role
Independent game and product engineer — mechanics, architecture, UI pipeline, tooling and release preparation
60 FPS
Mobile performance target
Deterministic
Turn-based simulation
EN / RU
Seeded localization
The product challenge
A small puzzle game can still become an unshippable collection of mechanics, screens and assets. Hollow Way is an exercise in treating interaction, visual language, content tooling and release operations as one product system.
The intended feeling is quiet, readable and satisfying. That makes response time, undo reliability, visual hierarchy and deterministic rules more important than spectacle.
Architecture for iteration
Pure rules stay separate from rendering and platform integrations, which keeps puzzle behaviour testable and lets presentation evolve without rewriting the simulation.
- Core owns grids, movement, pushing, stacking, hazards and undo; Presentation owns board rendering, cameras and effects.
- UI, save, economy, ads, purchases and localization sit behind their own boundaries.
- Editor tools generate and validate much of the interface and content, reducing fragile hand-wiring as the game changes.
Key product and engineering decisions
Determinism over hidden timing
Hazards and movement resolve turn by turn, so players can reason about failure and trust undo.
One source behind generated UI
Figma defines hierarchy and spacing; importers and builders own the runtime output so regeneration does not erase manual fixes.
Teach before combining
Levels introduce movement, pushing, height, materials and hazards in a deliberate order before asking for mixed-mechanic mastery.
Release boundary before content volume
Android stability, progression, store integrations and a coherent first campaign take priority over a huge level count.
What exists today
The project includes the grid simulation, movement and push rules, undo, scoring, save progression, deterministic hazards, main navigation, level selection, HUD, shop and the main completion and failure flows.
The remaining work is deliberately framed as release engineering: lock the campaign, reconcile a few mechanic decisions, finish the visual pass, replace test monetization configuration and validate the full loop on real Android devices.
Public case study, private source
Private sourceThe game source and production assets remain private while the product is in development. The public evidence focuses on system design, workflow and release judgment without distributing proprietary code or unfinished assets.
Next validation
- →Lock the v1 campaign and mechanic rules
- →Finish the Figma-to-Unity visual pass
- →Validate performance, save data, billing and consent flows on target Android devices
Technology