My Life in Games
I started writing game code full-time in 2000 when I got my first job in the industry. Twenty-five years later I am still writing game code, with long detours through engine architecture, design direction, studio leadership, and now AI-engineering practice.
From 2003 to 2011 I was at Big Huge Games, a core engineer on Rise of Nations, Rise of Legends, the XBLA port of Catan, an Age of Empires II expansion, and Kingdoms of Amalur: Reckoning. I built the multiplayer underneath those games: matchmaking, stats, the online experience, gameplay logic, scripting systems, and more. For my last two years there I was lead designer on a turn-based, Rise of Nations–derived strategy title for iOS that never shipped.
From 2011 to 2018 I was Design Director at Sparkypants Studios. I directed design and production on the PC RTS Dropzone, and I prototyped, planned, and pitched several other projects to publishers and investors.
In 2018 and 2019 I worked on emerging prototype projects as a Design Director at Bad Robot Games.
From 2019 to 2021 I built and led the internal game-development team at Legends of Learning. I handled everything from hiring, board presentations, investor pitching, product design, team management, and even did a lot of the implementation work myself. Our team shipped Awakening World, which won the 2022 SIIA CODiE Award for Best Educational Game, and I helped close the company’s first institutional round.
Since 2022 I have run Wood Fired Games full-time: an independent studio focused on strategy and simulation games, funded in part by selective consulting for AAA and emerging studios. Most of that work is under NDA. The public credit from it is shipped work on Homeworld: Vast Reaches.
I have two first names and an unusual skill set
Most senior game developers have not been both engineering lead and a game design lead. Out of the ones that have, very few have a current AI practice. Most people with a current AI practice have never shipped a game much less led both engineering teams as well as game design teams. I sit in the small overlap. I can talk through the Rise of Nations gameplay loop, tell you how the over-the-wire protocol was implemented, and I can pair-program with Claude across a multi-repo codebase, under an observability stack I built myself.
What is mine to claim is the work that overlap produced: MECS, the engine under every game and service I work on; wood-fired-tasks, the open-source coordination layer for fleets of AI coding agents I released in May 2026; and the cross-vendor observability stack I continue building to measure what the AI is actually worth. The evidence — commit volumes, source-line deltas — lives on /practice, where it can be weighed instead of asserted here.
My life with AI in three acts
The way I work with AI has moved through three phases. /practice is the long version, with the charts. Advisor (early 2024 to mid-2025): an assistant inside the IDE that I consulted constantly and never let touch the code. Collaborator (late 2025): it began authoring whole features that I reviewed at the diff; the persistent-entity system was the first I trusted that far. Workforce (2026): orchestration using my task-based approach, the source-generator migration that made the engine AI-legible, and a shift from reviewing the code to reviewing the systems that grade it.
AI can write the code. It can’t ship the game.
AI observability and governance
The problem I keep coming back to is measurement. Everyone is spending on AI, and almost no one can say what they got for it. For the last few months I have been building the instrumentation to answer that for my own studio: a vendor-neutral, on-prem stack that captures every model call across every provider and ties spend to outcomes, on hardware I control.
The goal underneath it is a real metric. Token investment against real-work output. Not lines of code, not commit counts, but shipped value: tickets closed and verified, features that land and stay landed. Until you can measure that, you cannot optimize AI use. You can only guess at it. Building that metric is the work I am most interested in right now.
The tools
I build a lot of my own tools. wood-fired-tasks is the open-source one: coordination infrastructure for fleets of AI coding agents, with a REST API, a CLI, and an MCP server over a shared service layer, plus the tasks-verifier and integration-auditor agents that enforce my verification discipline at the handoff between them. It is one piece of a larger toolchain I have built solo: the MECS engine and its editor, the backend platform services, the Unity systems, and the observability stack underneath. The full catalog is on /tools.
What I validate now is not the code. It is the systems that grade the code. Tests describe the behavior. CI runs the tests. Cross-vendor audits grade the CI. The layers check each other, and I read the verdicts.
The training-data asymmetry
Two years of practice across both backend and game-development work has surfaced one observation I will defend. AI is far more capable on server, DevOps, and SaaS work — Docker, CI, REST, OAuth, SQL, Blazor — than on game development proper, because the public training corpus skews heavily toward backend code. Game-development tooling is graphical, the engines are mostly proprietary, and the patterns the industry actually uses rarely reach public repositories.
AI is not failing at game development because it cannot reason about games. It is failing because almost no one has taught it how the work is actually done. The implication for adoption is concrete: AI capability is not uniform across software work, and a one-size policy will under-invest where the upside is largest and over-invest where the friction is structural. Adoption strategy has to be surface-specific. I am the rare person who can tell you, from first-hand evidence, exactly why AI is better at running your backend than at writing your gameplay.
Building for AI
When AI hit friction navigating the human-optimized authoring pipeline for the MECS engine, I did not try to teach it the pipeline. I redesigned the pipeline for its new primary user. The asset database flipped from source of truth to generated artifact. Code became the source of truth. The GUI became a view. AI now drives the whole pipeline from a single surface, and the migration retired over a hundred hand-coded boilerplate files in one pass.
The principle is portable. When AI hits friction in a workflow, the highest-leverage move is rarely to teach it the workflow. It is to ask whether the workflow was built for the right user, and rebuild it for the new one.
Education
B.S. Computer Science, Georgia Institute of Technology (1996–2000). Research assistant 1998–2000 under Dr. Amy Bruckman, in the virtual-community and educational-computing lineage.