AI-led Unity game prototype
GuildSim
A completed guild-management demo exploring autonomous AI development, deterministic simulation and disciplined project closeout.
Status: Archived- Category
- AI-led Unity game prototype
- Technologies
- Unity, C#, EditMode Tests, PlayMode Tests, PowerShell
Summary
GuildSim is a completed technical demo of a guild-management game built through an AI-led development experiment. It delivers a playable management loop and a documented closeout while keeping technical completion separate from product validation.
My role
I set the product direction, defined the operating charter, reviewed playable builds and made the final product decisions. AI coding agents handled most implementation work under documented architecture, testing and delivery rules.
Problem
The project tested two questions at once: whether an autonomous AI workflow could deliver a maintainable Unity prototype, and whether a compact guild-management loop could become engaging before more content and polish were added.
Users and use case
The playable demo is for players curious about lightweight guild management and for developers evaluating what an AI-led workflow can produce when architecture, tests and stop conditions are treated as first-class constraints.
Constraints
The experiment used a solo product owner with AI agents, a fixed technical charter and existing production constraints. The prototype had to remain deterministic, testable and buildable while avoiding continued investment before its core loop proved fun.
Solution
Players manage a guild roster, select contracts, assemble a party, prepare supplies, send the group on expeditions and review the results. The connected flow is sufficient to test the management premise without pretending the demo is a finished commercial game.
Architecture and workflow
The Unity codebase separates domain rules, application orchestration and presentation. Deterministic randomness supports reproducible outcomes, save operations are handled atomically, and localization, audio, validation and build tooling are kept inside the delivery pipeline.
Key decisions
The key decision was to close the project after the technical objective was met but the central fun hypothesis remained unproven. Preserving the build, source and closeout evidence created a useful reference without allowing sunk cost to become the reason for more development.
Testing and delivery
The delivery process uses Unity EditMode and PlayMode tests, validation checks, automated build scripts and a Windows smoke-test path. Testing concentrated on deterministic simulation, core flows, persistence and whether a release candidate could be reproduced reliably.
Current limitations
The closeout found that decisions still felt too numerical, expedition routes lacked variety, narrative feedback was thin and some information was difficult to read. Those are product-level weaknesses rather than unfinished engineering tasks.
Lessons and next steps
A mature architecture and passing tests do not prove that a game is fun. The strongest lesson is to validate the grey-box loop early, define a stopping rule before investing in presentation, and treat an honest closeout as a successful project outcome.