Building game worlds that follow the rules, not just look the part.
CraftAWorld is a procedural world-generation platform that lets game creators define their vision, express constraints and generate different, reproducible maps that respect those rules.
Status
Open alpha
Domain
Game development, procedural generation, constraint solving
My role
Founder, product vision, algorithm design, architecture and AI-driven engineering leadership
Four maps generated from one template, the Thorned Dominion world. Same places and rules, different geography each time.
01The spark
It started with a game I wanted to make
Origin
Thorned Dominion, my game concept
A new, large, consistent world on every playthrough
An exceptionally difficult engineering problem
CraftAWorld, a platform for every game creator
I've been a gamer for over 40 years. At some point, I came up with a game concept called Thorned Dominion, built around an idea I hadn't encountered in quite the same form.
One of its core promises was replayability at the world level.
Every new playthrough would give players a completely different, large game world. But those worlds couldn't be random collections of mountains, forests and settlements. They had to preserve the game's identity, design intentions and gameplay constraints.
I started building it and quickly discovered that this was an exceptionally difficult engineering problem.
Even with modern AI, you can't simply describe a world, choose a powerful model and expect a coherent, playable result.
Then I realized something: if I was struggling with this problem, perhaps other game developers were too.
Very few games I've encountered generate an entirely new, large and internally consistent world for every playthrough. I suspect the difficulty of doing it reliably is a major reason.
So I decided to turn the challenge into a platform.
Thorned Dominion was the starting point. CraftAWorld became the larger ambition: giving game creators the ability to build experiences that would otherwise be prohibitively difficult to produce.
02The product
From imagination to reproducible worlds
The intended experience is straightforward.
Describe your world in natural language. Explain its geography, environments, important places and the relationships between them.
AI translates that description into a structured world template. You can then refine it through an advanced editor, or build the template manually if you prefer complete control.
From vision to maps
DescribeYour vision
Geography, environments, important places and their relationships, in natural language.
Shipped
TranslateWorld template
AI turns the description into a structured template.
about a minuteShipped
RefineAdvanced editor
Adjust the template, or build it manually for complete control.
Shipped
GenerateSeveral 2D maps
Different maps from the same vision, each following the creator's rules.
a few more minutesShipped
NextTerrain and engine
Detailed 3D terrain specifications, then Unity and, later, Unreal.
In development
How a world gets made today, and the part still being built.
1 · Describe
2 · Review the plan
3 · Refine
Captured in the open alpha: a description, the plan AI drafts from it before anything is saved, and the resulting template in the editor.
Today, creating an initial template can take about a minute. Within a few more minutes, you can generate several different 2D maps based on that same vision.
And the differences are meaningful.
One generation might place an elven settlement near a lake and a dwarven fortress in the mountains. Another might produce a completely different geography. But both must follow the rules defined by the game's creator.
Those rules might include a lake within 500 meters of a settlement, a road connecting specific locations, or a river crossing the entire map in a defined direction.
Rules a creator might define
Generated blueprint
A lake within 500 meters of a settlement
A road connecting specific locations
A river crossing the entire map in a defined direction
Every valid map satisfies every rule.
Rules are the examples from the text above. The blueprint is a separate generated map, shown for scale and texture.
The same template can produce multiple worlds, each different yet consistent with the original design.
This is what I want CraftAWorld to enable: variety without sacrificing creative control.
The longer-term vision goes beyond 2D blueprints. A dedicated Terrain Planner is being developed to translate them into detailed 3D terrain specifications, followed by integration with game engines such as Unity and, later, Unreal.
Eventually, a studio should be able to design a world template once and generate a fresh playable environment whenever a player starts a new adventure.
03Decisions
Decisions that mattered
D1
A valid map must satisfy every constraint
Dilemma
Relax a requirement to produce a result, or let the generation fail?
The call
Every constraint is mandatory, checked before, during and after generation.
Trade-off
Not every attempt succeeds. No failed map is ever presented as valid.
One of my earliest architectural decisions was to treat every specified constraint as mandatory.
Imagine a world that looks beautiful but places a fortress on the wrong side of a mountain range, or a river where the game requires a road.
It might be visually impressive, but it isn't the world the designer asked for.
CraftAWorld therefore doesn't silently relax requirements to produce a successful-looking result.
Before generation, template validation detects many impossible or contradictory requirements. During generation, each algorithm verifies that it hasn't broken existing constraints and can backtrack when necessary.
Finally, a dedicated validation process checks the completed map against every constraint.
If the result doesn't pass, the generation fails.
That distinction is fundamental: not every generation attempt is guaranteed to succeed, but an unsuccessful map must never be presented as a valid result.
D2
Technically correct isn't necessarily good enough
Dilemma
Solutions that met the specification looked unnatural, or failed it altogether.
The call
Treat plausibility as a second quality bar, and direct the algorithmic exploration myself.
Trade-off
Considerable time analyzing failure patterns before the results improved.
One of the hardest early problems was biome placement.
The requirements seemed manageable. We knew the allowed sizes and proportions of different biomes. We knew the fixed locations and directional relationships the designer wanted.
Yet AI repeatedly failed to find satisfactory solutions.
Sometimes it couldn't satisfy all the constraints. Other times it produced technically valid results that looked completely unnatural, such as long, one-cell-wide stripes of individual biomes.
Formally validOne-cell-wide stripes
Also plausibleCoherent regions
Schematic, not generated output: the same biome mix arranged two ways. Only one would convince a player.
This exposed two different definitions of quality.
The world must satisfy its formal specification. But it must also look plausible to a human being.
I spent considerable time analyzing failure patterns, understanding how the models approached the problem and exploring alternative algorithmic directions.
My previous experience designing algorithms became critical. I developed and refined approaches with the agents, using pseudocode and visual evaluation to guide implementation.
The proprietary details aren't important here. The lesson is that meeting a mathematical specification and producing a convincing world are related, but distinct challenges.
D3
The terrain planner: Recognizing an architectural mistake
Dilemma
Unity was turning solved 2D maps into 3D worlds, and the details kept failing.
The call
Add a server-side Terrain Planner that resolves spatial decisions before rendering.
Trade-off
A new layer to build before the full pipeline ships. The engine is left to render.
My original architecture took a solved 2D map and asked Unity to turn it into a convincing 3D world.
The initial results were encouraging. From a distance, the terrain looked impressive.
But the details repeatedly failed my quality standards.
One example was a river widening into a lake.
Getting that transition to look natural took more than a week of work. At one point, we spent two days just agreeing on the four anchor points defining the river's entrance into the lake.
Different rendering layers disagreed about where the river ended and the lake began.
Unity · from a distance
Unity · up close
The same Unity prototype from a distance and up close. Up close, where the river meets the lake, the terrain breaks down. The green lines are a debug overlay.
Eventually, I recognized that I had made too large an architectural leap.
The problem wasn't simply getting Unity to render better. I was asking the rendering client to make too many spatial and algorithmic decisions.
That realization led to the Terrain Planner.
Where the spatial decisions are made
Original architecture
ServerSolved 2D map
Rendering clientUnity
Asked to render the world, and also to decide it:
Rendering
Spatial decisions
Algorithmic decisions
Too large an architectural leap. Details such as a river widening into a lake kept failing.
With the Terrain Planner
ServerSolved 2D mapShipped
Server · new layerTerrain Planner
Turns the solved map into a detailed terrain specification at 16-meter resolution.
In development
Rendering clientGame engine
Renders a world whose spatial decisions are already resolved. Unity first, Unreal later.
Prototype
Complexity moves to the layer best equipped to handle it.
Simplified. The planner moves spatial decisions to the server, so the engine renders a world that is already resolved.
Instead of moving directly from a 2D map to Unity, CraftAWorld will introduce a server-side planning layer that transforms the solved map into a detailed terrain specification at 16-meter resolution.
The game engine can then focus primarily on rendering a world whose spatial decisions have already been resolved.
The lesson was to move complexity to the layer best equipped to handle it, rather than continuously patch the symptoms downstream.
04Under the hood
A constraint-solving system
The 2D map generator currently uses a pipeline of eight algorithms.
The algorithms address interconnected aspects of world generation, including environmental layout, spatial relationships and the placement of world features.
Their ordering matters.
Large, foundational and difficult constraints must be resolved before smaller, more flexible decisions. Otherwise, later stages can invalidate important earlier decisions or make the remaining problem impossible to solve.
Validation at every stage
Before generationTemplate validation
Detects many impossible or contradictory requirements.
During generationEight ordered algorithms
Eight algorithms run in order, resolving large, foundational and difficult constraints before smaller, more flexible decisions.
Each stage verifies existing constraints and backtracks when necessary
Gap-filling biome capabilities address coverage.
After generationFinal constraint audit
Checks the completed map against every constraint.
PASSA valid map: every constraint holds.
FAILThe generation fails, and is never presented as valid.
Conceptual. The eight algorithms are shown only as an ordered sequence; what each one does is proprietary.
A template-validation module catches many inconsistencies before generation begins. Gap-filling biome capabilities help address coverage issues. Incremental validation and backtracking protect constraints during generation.
The final constraint audit provides another line of defense.
Failure handling is also part of the architecture.
Users can report unsuccessful generations with one click. I can retrieve the relevant template from the production environment, reproduce the failure locally and investigate suggested corrections.
Learning from real failures
1 · UserReport
One click on an unsuccessful generation.
2Retrieve
The template, from the production environment.
3Reproduce
The failure, locally.
4Investigate
Suggested corrections, then improve the engine.
Back into the engine, tested on a real case
The loop that turns a failed generation into an engine improvement.
This gives me a systematic way to improve the engine based on real failures instead of relying exclusively on synthetic test cases.
The challenge is not simply generating worlds. It's generating valid, reproducible and convincing worlds with sufficient reliability to support real development workflows.
05Building with AI
When the agents couldn't solve the problem
CraftAWorld taught me a great deal about what experienced engineers can accomplish with AI, and where human expertise remains essential.
My primary responsibility has been the product vision, requirements, priorities and algorithmic direction. AI agents have written the implementation code, while architecture, debugging and quality assurance have been collaborative responsibilities.
Who did what
MeJudgment
Product vision
Requirements
Priorities
Algorithmic direction
SharedTogether
Architecture
Debugging
Quality assurance
AI agentsExecution
Implementation code
Early on, I worked with Claude and Gemini to solve the biome-placement problem.
The agents researched established approaches, proposed solutions and implemented alternatives. Yet they repeatedly struggled with the specific combination of arbitrary constraints and natural-looking results.
At some point, more prompting wasn't helping.
I had to understand why the approaches failed.
Rather than keep asking the agents to fix the output, I began examining the patterns behind the failures and directing the algorithmic exploration myself.
This collaboration eventually produced better results.
The experience reinforced a principle: AI can accelerate implementation dramatically, but that doesn't eliminate the value of understanding the problem deeply enough to challenge the implementation.
From managing developers to managing AI agents
The project also changed how I organize engineering work.
I introduced roadmaps, prioritized epics and work items with measurable definitions of done.
The reason was practical. If an agent is going to work autonomously for an extended period, it needs an objective way to determine whether it has completed the task.
I then experimented with independent verification.
My first approach used an orchestrator coordinating separate builder and verifier agents. It improved the review structure, but coordination consumed too many tokens, duplicated testing and slowed delivery.
I simplified the architecture into what I call the Verified Workflow.
The primary agent builds the feature and interacts directly with an independent verifier. The verifier evaluates the work against the agreed definition of done, and rejects are returned for correction before I perform the final review.
Three ways to organize agents
OrchestratorFirst approach
Orchestrator
Builder + Verifier
Me · final review
Baseline
Better review structure, but coordination consumed too many tokens, duplicated testing and slowed delivery.
Verified WorkflowCurrent
Builder ⇄ Verifier
Definition of done
Me · final review
≈3× faster than the orchestrator
The builder works directly with an independent verifier. Rejects return for correction before my final review.
Single builderThe open trade-off
Builder
Me · final review
2–4× faster in some workflows
No independent verification. The verifier catches issues, but adds cost and latency.
Speeds are the relative figures from the text, not benchmarks. The balance is still being tuned.
This newer workflow is approximately three times faster than my original multi-agent approach.
But there's an unresolved trade-off.
A single builder without independent verification can still deliver features two to four times faster in some of my workflows. The verifier catches issues, but also adds cost and latency.
I'm still working to find the right balance.
My goal isn't to maximize the number of agents or the amount of autonomous activity. It's to maximize reliable output while controlling time, cost and my own involvement.
06Status
Where it stands
CraftAWorld is currently in open alpha.
Natural-language template creation and constraint-validated 2D map generation are operational. These are the capabilities available for experimentation today.
Shipped, in progress and planned
Natural-language template creationShippedAvailable in the open alpha
Constraint-validated 2D map generationShippedAvailable in the open alpha
Terrain Planner, 16-meter terrain specificationIn developmentAdvanced development
Unity integrationPrototypeWorking prototypes, below my quality bar for natural terrain
Full pipeline: vision, 2D map, terrain plan, enginePlannedNext major milestone
Product-led commercial modelPlannedFree tier, paid tier, future Pro offering with APIs
Studio adoption and willingness to payTo validateA commercial hypothesis, not yet validated
The Terrain Planner is in advanced development. The Unity integration has working prototypes but does not yet meet my quality standards for natural-looking terrain.
The next major milestone is a complete pipeline from game vision to 2D map, detailed terrain plan and game-engine realization.
Commercially, my planned approach is product-led growth.
The model is built around a meaningful free tier, a paid tier with generous usage quotas, and a future Pro offering with APIs for studios that want to generate worlds directly from their games.
Open-world generation is only the beginning of the longer-term vision. Dungeon generation is a natural next area, including applications where an existing game world contains different dungeons, encounters and treasures on every playthrough.
These remain product ambitions, not claims about functionality already released.
07Reflections
Technical conviction isn't market validation
There's an irony in this project.
I've spent years teaching entrepreneurs and product managers to validate their assumptions before investing heavily in development.
With CraftAWorld, I didn't follow that advice as rigorously as I normally recommend.
I relied on decades of gaming experience, my conviction that the problem was real and the fact that I could use the technology in my own games even if it never became a commercial success.
Those were reasonable motivations for exploring technical feasibility.
They weren't proof that studios would adopt the platform or pay for it.
That's still a commercial hypothesis I need to validate.
Nevertheless, CraftAWorld has already changed the way I think about software engineering.
It taught me that AI is remarkably powerful at accelerating implementation, but difficult problems still demand algorithmic thinking, architecture, quality standards and disciplined product leadership.
And perhaps most importantly, it reminded me that when a solution repeatedly fails, the answer isn't always to improve the implementation.
Sometimes you need to reconsider the problem, the architecture or the assumptions behind the entire approach.
