Parameterized generation
Layout complexity is driven by a small set of knobs (size, turns, density), enabling controlled difficulty.
Game Case Study
AMAZE
A systems-focused puzzle prototype inspired by AMAZE, built to explore procedural level generation, solvability constraints, and rapid iteration through automation.
Overview
AMAZE is a procedural prototype where the core challenge comes from constrained movement and “paint/fill” style coverage. My focus wasn’t on reinventing the mechanic, but on building a generator that produces readable, solvable puzzles at different difficulty bands—so iteration becomes parameter tuning instead of hand-authoring levels.
Design goals
What I was trying to achieve.
-
Reliable solvability
Ensure generated puzzles are playable by construction, avoiding dead layouts that waste player time.
-
Readable challenge
Keep the path logic legible so difficulty feels “fair” and explainable, not random or messy.
-
Fast iteration through automation
Generate and test batches of levels quickly to tune constraints and difficulty progression.
My contribution
What I personally owned.
-
Procedural generator logic
Built and refined the generation approach, including constraints that shape layout structure and complexity.
-
Validation & tuning
Added checks/filters to reduce unsatisfying outputs and tuned parameters to create consistent difficulty bands.
-
Documentation for assessment
Framed the work clearly as a systems prototype, focusing on generation intent, iteration workflow, and learnings.
Process & learnings
How the project evolved and what I took away.
The biggest lesson was that “random” doesn’t automatically mean “varied in a good way.” Early versions produced plenty of levels, but many were either trivial or confusing. I improved results by treating generation as a design problem: constrain the search space, define what “readable” means, then iterate by adjusting a small set of parameters and testing output batches. That approach made progress predictable and made the prototype useful as a reusable pipeline rather than a one-off demo.
Core loop
The moment-to-moment flow I focused on.
Loop
Start a level → read the layout → plan a route → move to cover tiles efficiently → commit to decisions (limited reversals) → finish when the board is fully covered → next level.
Why it works
The loop rewards foresight: small mistakes compound, but solutions feel satisfying when the player “sees” the route and executes cleanly. Difficulty comes from constraints, not speed.
Key features
What’s implemented in the prototype right now.
Solvability guardrails
Filtering/constraints reduce broken or unsatisfying levels so output quality stays consistent.
Batch iteration workflow
Quickly generate many candidates, test, and adjust parameters—turning content creation into tuning.