CASE STUDY — GAME DEV · IN DEVELOPMENT
Bush League Baseball
A Unity 6 baseball roguelite, in development. I'm building it the way I build web products — a real design system governing every pixel of UI, domain logic under test, and an AI art pipeline for the characters. Design-system thinking, ported to game dev.
- 13
- modular C# projects clean boundaries
- TDD
- on domain logic mandated, not optional
- Brand bible
- token-driven UI one design system
The problem
Game codebases rot in a specific way: untested logic tangled with rendering, UI styled ad hoc scene by scene, and art assets that drift out of any coherent look. I wanted to see whether the discipline that keeps web products maintainable — a design system, tested domain logic, clean module boundaries — holds up in a game engine. Bush League Baseball is that experiment, in the shape of a baseball roguelite.
The build
It's built on Unity 6 with URP, structured as thirteen modular C# projects rather than one sprawling Assets folder. The domain logic — the rules of the game, the roguelite progression — is TDD-mandated, so the parts that have to be correct are provably correct and stay decoupled from rendering.
The UI is governed by a token-driven "brand bible" — the same design-system approach I use on the web, expressed as tokens the game reads at runtime. Character art comes from a Scenario.gg fine-tuned model trained for the game's look, and runtime tint-masking shaders recolor sprites on the fly so a small set of source art yields a large, consistent roster.
Stack decisions
Why thirteen projects instead of one. Boundaries. Keeping domain, UI, and rendering in separate C# projects means the compiler enforces the architecture — you physically can't reach across a line you shouldn't.
Why TDD on the domain. Roguelite systems are combinatorial; bugs hide in the interactions. Tests on the domain logic are the only way I trust the game to be fair when the systems stack up.
Why a fine-tuned art model plus tint shaders. A consistent visual identity at the scale a roster needs. The fine-tuned model keeps every character on-brand; the tint-masking shaders multiply that art into variety without multiplying the asset count.
Outcomes
Still in development — this one's honest about that. But the thesis is already holding: design-system rigor and tested logic make a game codebase as maintainable as a good web app. Turns out the discipline travels.
Like how I think about systems?
Design systems, tested code, clean architecture — I bring the same rigor to client work. Let's talk.