DATA
Content lived in data assets
Buildings, items, recipes, companies, and research nodes were defined as ScriptableObjects.
That reduced repeated setup and supported an editor tool that generated item icons from prefabs.
All projects
Solo Unity systems case study · 2023–2024
Automation HavenA factory without a finish line.
Automation Haven was my attempt to build a deep factory-management game alone. Nine months of active development produced logistics, contracts, research, power networks, markets, and persistence. When I could no longer name the next task that would move it toward completion, I stopped and examined why.
I owned the game design, programming, technical architecture, UI, content setup, and project direction.
RoleSolo developer
EngineUnity 2022 LTS · C#
FocusAutomation · management
OutcomeArchived, with code and lessons reused later
The playable system
The loop worked. The project kept growing.
The player could turn raw deposits into delivered products and use the reward to grow. Contracts were added in December 2023 because an open sandbox needed a reason to produce, not just more machines to place.
Select a station to inspect what it did and what it cost.
Factory scope
Signal stable
This diagram holds optional systems back to show the route that should have been validated first.
01
Place miners on generated resource deposits
- Player purpose
- Choose where a production line begins and which material is worth developing.
- What I built
- Grid placement, building previews, resource-node generation, miners, and land plots.
- Design pressure
- Dynamic nodes and plots became world state that the later save system had to reconstruct.
Architecture under load
The systems were capable, and increasingly expensive to change.
The final repository uses data definitions, events, and logistics interfaces to make content easier to extend. It also relies on many global managers and distributed save responsibilities, which made changes across the whole simulation expensive.
Final prototype repository
- building definitions
- 30
- item definitions
- 73
- recipes
- 43
- project C# files
- 134
Project-authored scope, excluding obvious vendor source.
FLOW
Interfaces replaced machine-specific checks
Grabbers work through input and output interfaces, while events update inventory, contracts, research, UI, and power.
The power manager merges pylon graphs when they meet and splits them with a breadth-first search when a pylon is removed.
STATE
Saving touched almost everything
Saving expanded from individual objects to networks, prices, contracts, plots, research, and multiple worlds.
The save system covered a broad simulation, but every new global dependency increased the cost of changing old assumptions.
Changes that shaped the build
Contracts gave production a purpose
Company orders, deadlines, and reputation turned a freeform factory into a directed economic loop.
Interfaces became the direction
The item and logistics layers moved away from concrete class checks, making new endpoints easier to add.
Research became its own tree
Prerequisites and sections replaced an overloaded milestone system and made progression easier to reason about.
Saving became multi-world
Creating and loading separate worlds forced every dynamic subsystem to declare what state it owned.
The product decision
Why I stopped after July 2024.
The power network reached a working state more than once. Then the surrounding scope changed and invalidated its assumptions, leading to another pass. The same pattern touched inventory, UI, progression, and saving.
By July 2024, the next useful task was no longer clear. The issue was not a missing feature or one bad system. “Factory automation game” described a direction, while planned ideas such as competitors, pollution, and new power types could all look essential alongside the systems already built. Nothing defined the smallest satisfying ending.
I stopped development instead of starting another rewrite without a clear route to completion. Later retrospectives turned that pause into a rule for my work: define what the player does and where the game ends before building more infrastructure.
Root causeA genre was chosen. A minimum complete game was not.
Early production test · December 2023Connected prototype · 2024My check before expanding
- 01
Write the smallest satisfying player loop and ending.
- 02
Test that loop before adding adjacent systems.
- 03
Expand only when evidence shows which constraint matters next.
What I kept
Specific parts of the work moved into later projects.
The prototype was never released or validated in a completed external playtest. It still taught me how to break down a simulation, model content with ScriptableObjects, and recognize when shifting requirements are making an architecture unstable.
Where the work resurfaced
- 01
Camera controller
The free-fly camera was copied and adapted for a later prototype.
- 02
Save and menu work
Automation Haven code was revisited while I built Wilderness Chef’s persistence flow.
- 03
A finishable core
Echoes of Steel began with one stable loop, expanded from it, and shipped on Steam.
PUBLIC RETROSPECTIVE
I Abandoned My Dream Game (You Should Too)
The public retrospective covers the ambition, repeated rewrites, and why ending the project was the right product decision.
Watch on YouTubeLINE END / KNOWLEDGE TRANSFER COMPLETE