The One-Person Game Studio: Complete 11-Book Library

AI can produce a character, a screen, or a working feature quickly. It can also leave you with a game whose assets do not belong together, whose details fall apart up close, and whose unfinished edges make it feel like nobody was in charge.

In Signed Off, I explain how I make games alone by treating AI as the team I direct. I replace prompt-and-accept with a production path: define the visual standard, write the brief, compare rough sketches, approve color, build a complete design sheet, inspect the final, and promote only the work that belongs in the game.

The book shows how to judge the right things at each stage, lock colors before they drift, keep generated detail honest, use simple geometry references when straight lines matter, and review a final both up close and at the size the player will see. It also covers the polish screenshots miss: stutters, weak motion, behavior without a reason, and code accepted only because it works.

No drawing or programming experience is required. The method is about deciding what right looks like, writing it down, and looking carefully enough to hold that standard from the first idea to the finished game.

An AI assistant can move quickly and still make every session feel like a restart. You repeat what a sketch means, which service to use, where files belong, and what must be checked, while the work slowly drifts toward the assistant's defaults.

In House Rules, I explain how I give later sessions a durable starting point. Standing rules record what is true in a project. Skills preserve the procedure for recurring jobs. Contracts capture workflows that already worked, including their stages, approvals, file destinations, self-review, and lessons.

The book shows how I layer those documents so every fact has one owner, separate durable procedures from live information, turn review corrections into lasting standards, and keep exceptions dated and narrow. It also covers scoped batch authorization, preflight checks before paid actions, release gates that fail closed, and project hygiene that is part of finishing rather than an afterthought.

No programming background is required. These are plain-language documents for solo developers and creators who direct AI-assisted game work. The rules make the work steadier; they do not approve it. I still inspect the result, maintain the standards, and decide what enters the game.

Generating another image is easy; keeping the intended asset consistent is harder. I explain how I turn a game asset into a deliberate request, starting with the concept and the kind of drawing I need.

I cover how to count, place, and size important elements, decide where detail belongs, assign each reference a job, and describe what the image must not become. The book follows requests through different production stages, then shows how I revise one decision and keep the request that worked as a starting point for the next asset.

Image models still miss. The aim is to make those misses easier to identify and corrections more controlled, not to promise a perfect result.

A popular model is not necessarily the right tool for every game asset. I explain how I define a real job, compare candidate routes, inspect results, and account for the cost of accepted work. Using examples from my own production, I show how I choose a small set of tools and decide when a change is warranted.

Working through one service can make different generators easier to manage, but it does not make their results interchangeable. I explain how I organize access, teach a repeatable workflow, track jobs and their outputs, and preserve settings for a family of assets. The book follows my own experience changing services while keeping the game’s production needs in view.

I explain why I chose to build an engine around the game I want to make, and the responsibilities that come with that choice. Starting with platforms and player experience, I discuss libraries, a playable path, separation of game logic and presentation, timing, and the boundaries that keep a growing project manageable.

A pleasing drawing or model preview is not yet a usable game asset. I follow a character from an approved design and multi-view sheet through a 3D route, inspection, color, rigging, and use in the game. My examples show how I resolve missing views and reject changes that break the design.

A good still image can hide motion that does not serve the game. I discuss choosing the representation the game needs, sketching beats, testing routes, and directing animation and effects through review. Examples from my own effects workflow show how references, timing, and repeated testing help clarify an action.

One good picture is only the beginning of a consistent 2D game. I explain how I carry a character design into sheets and sprites, inspect the frames as a sequence, and direct interface assets as a coherent set. My examples include a green slime and an interface kit, with attention to how each asset will actually be used.

A sound can be good on its own and still be wrong for the game. I explain how I brief original music and effects, compare small samples, inspect loops and transitions, and listen to effects in context. I also discuss voice and keeping a tested audio workflow for the next asset.

A practical guide to platform choices, budgets, and fair monetization for independent game creators. Worth Paying For explores how a solo developer can plan commercial decisions for a game.