Loading Mini Maze runtime…
engineering.case-study
Die Systemgrenze von Mini Maze im Detail.
Was Spieler erleben, wofür die Implementierung tatsächlich verantwortlich ist und wo die Aufgaben eines Produktionssystems beginnen.
A maze is a deterministic navigation puzzle: reach a goal while respecting a fixed set of walls. This demo is included as a client-engineering boundary rather than a wagering game, focusing on rendering, input normalization, and collision behavior.
- Move the player with keyboard, touch, or on-screen controls.
- Each requested step is checked against the fixed collision map.
- Valid moves update the canvas and counters; blocked moves leave position unchanged.
- Reaching the goal completes the local run.
The entire loop runs in the browser with PixiJS. Input, player position, collision checks, elapsed time, and completion state are local; there is deliberately no backend or RNG boundary.
InputPixiJS loopCollision mapGoal stateUI feedback
- Input Adapter
- Keyboard, touch, and button commands.
- PixiJS Loop
- Rendering and frame updates.
- Collision Map
- Which deterministic moves are valid.
- Goal State
- Completion and local feedback.
- Use a fixed maze so behavior is repeatable.
- Normalize multiple input methods into the same movement command.
- Check the next bounding box before mutating position.
- Keep this client-only to make its trust boundary explicit.
- Unsupported input does not mutate state.
- A blocked move is ignored rather than clipping through a wall.
- Refreshing the page resets the run because no persistence is promised.
- There is no server reconnect or reconciliation path because no authoritative backend state exists.
No RNG is used. The map, movement step, collisions, and goal are deterministic.
MazeState- playerX- playerY- moves- elapsedTime- completedCollisionMap- walls- bounds- goal