DEV Community: wabiplant

Running a One-Person Game Studio With AI Agents: What Actually Works

wabiplant — Sat, 07 Nov 2026 07:57:01 +0000

My "studio" is one person in Japan, a handful of shipped products, and an AI agent named Muse that works the operational side with me. The games include Samurai 100 Slash Lite (a Unity action RPG and still my most popular title), Acid Rogue Shooting (a Godot roguelite shooter with a two-player mode), a comedy quiz app, a chord-planning app, and a musician-matching web service — plus a beat-'em-up in development.

People imagine the interesting part is generating code or art. Honestly, the part that changed my life is dumber and better: the agent runs the operations — the repetitive, forgettable, absolutely essential work that used to eat my evenings. Here's what that looks like in practice, including the parts that don't work.

The morning numbers

Every day, a scheduled job collects the previous day's figures: App Store Connect analytics, ad revenue from multiple networks, website search data. It merges them into a single private dashboard — downloads, impressions, revenue, review movement — so I start the day looking at one page instead of logging into five consoles.

The value isn't the charts. It's that anomalies surface without me hunting: a product whose impressions fell off a cliff, a revenue line that stopped reporting because a data source broke. The agent also runs small, bounded improvement loops on store pages — promotional text experiments it may apply on its own, while anything that changes a title or needs a new build waits for my approval. That boundary (automate the reversible, escalate the irreversible) is the rule that makes the whole arrangement safe to run unattended.

The rejection detective story

My favorite example of agent work is an App Store rejection for Acid Rogue Shooting. The review said, in effect, "the tracking-permission dialog never appears." My first instinct was a timing bug — the dialog request firing too late or after the wrong screen.

The agent took the plugin apart instead. The ad plugin I was using turned out to have no API for requesting tracking permission at all. The dialog wasn't mistimed; it was structurally impossible — the code to show it could never have worked, no matter when it ran. That reframing changed the fix entirely: request permission in my own code before any ad initialization, and if the user declines, fall back to non-personalized ads. A resubmission on that basis moved the process forward, and I verified the refusal path myself on my phone: dialog appears, declining it skips the consent form, the game plays, a banner shows.

A human debugging that alone (me, at midnight) would have burned hours moving the request earlier and later. The agent's advantage wasn't speed — it was refusing to accept the framing of the problem until the structure underneath was checked.

The unglamorous bulk work

A Unity project of mine had grown to nearly 45 GB — years of imported assets, most of them unreferenced. The agent inventoried everything, separated what the current build actually uses from what it doesn't, moved the unused material into an archive folder (never delete originals — that rule is absolute), and rebuilt the project's version control from scratch. The project came back at under 5 GB, loads faster, and — verified by actually playing it — still works, with the battle results flowing into the game's RPG framework as before.

This category of work is where agents quietly pay for themselves: inventory, cross-referencing, careful bulk moves, then proof that nothing broke.

What doesn't work

Honesty section. Screen control is the big friction: when the agent operates the same computer I'm working on, our inputs collide — a window focus changes mid-task, a click lands in my document. Work that needs my machine's GUI goes best when I'm away from it, and some dialogs (a native file picker, for instance) are simply invisible to remote control, so file hand-offs are designed to avoid them — the agent leaves an instruction file at a known path instead of asking me to browse for attachments.

The agent also can't judge feel. It can prove a hitbox extends 10 pixels past the sword's visual tip; it cannot tell me whether the combo feels good. And its reports need discipline: left alone, it summarizes optimistically, so I require every report to separate "verified," "failed," and "not checked."

The shape of the thing

One person plus an agent is not a big studio. It's a small studio with an extremely reliable operations department that never sleeps and occasionally needs its homework checked. The products get steadier, the store pages get tended, the metrics get read — and I get to spend my limited hours on the part only I can do: making the games worth playing.

Indie game developer in Japan. I build games like Samurai 100 Slash Lite and Acid Rogue Shooting, and write about developing with AI agents. Portfolio: https://portfolio.wabiplant.workers.dev/

Muse vs. the Game: Teaching an AI Agent to Playtest My Beat-'em-Up

wabiplant — Sat, 07 Nov 2026 07:56:58 +0000

I'm developing a belt-scroll beat-'em-up set in Bakumatsu-era Japan — swordsmen, the Shinsengumi, lots of slashing. It's a browser game built with Phaser, and it has hundreds of sprite animations across a growing cast of characters. Every animation change has to be checked: does the character stay grounded, does the blade actually reach, does it look right on a phone?

I can't hand-test every motion after every change. So my AI development partner, Muse, playtests the game for me — in a headless browser, driving the real game through its real input paths. This article is about the most valuable lesson that process taught us, which was mostly a lesson about how not to verify a visual change.

The rig

The test setup loads the actual game, puts it into a practice mode with a training dummy, and plays it programmatically: keyboard input for movement and attacks, touch events dispatched the way a phone would produce them. A harness runs suites of checks — spawn this character, perform this combo, measure the result.

Two hard-won rules are baked into that harness. First, tests must exercise the production input path. Early on, we injected synthetic keyboard events that looked right but never reached the game's input handlers the way real keys do, and "passed" tests for input that was actually broken. Second, time in a headless rig doesn't flow like time on a phone — under load, the game may crawl at a couple of frames per second, so tests wait on game state ("has the thrown enemy landed?") instead of sleeping fixed durations.

The failure: correct poses, identical pixels

The defining failure came with an animation rework. The agent regenerated a set of motions, wired them in, and ran the checks. The tests verified the animation state machine: the character entered the right poses, in the right order, for the right number of frames. Everything passed. The report said the new motions were in.

I opened the game on my phone. The character looked the same as before.

Digging in, the truth was embarrassing: the new frames existed and the transitions were correct, but rendered on screen, the silhouettes were nearly pixel-identical to the old ones. The verification had checked the names of things — pose A follows pose B — and names don't tell you what a player sees.

The fix: measure pixels, not poses

We rebuilt the verification around a simple principle: a visual change is only verified when the rendered pixels measurably change in the intended way.

Concretely, that now means:

Sprite sheet audits with numeric gates. Before a sheet even enters the game, we measure foot width, character height, and the ground-contact line for every pose, directly from the image data. If a "wider stance" pose doesn't actually measure wider, the sheet is rejected before it wastes a playtest.
In-game screenshot measurement. The rig captures the running game and measures the sprite's on-screen width and extent per pose. A claim like "this attack now reaches further" has to show up as numbers.
Guard against empty measurements. A snapshot API in our rig could return a blank buffer, and ratios computed from zero pixels happily report "1.000 — perfect match." Measurements now require a minimum count of actual content pixels before they're allowed to pass anything.
Real-device conditions. Headless screenshots at desktop density missed problems that appear on an actual phone, where the canvas is scaled up. Verification captures now emulate a phone's resolution and pixel density, including zoomed crops of the result.

Both orientations, always

The other structural rule: every test suite runs in landscape and portrait. This exists because of bugs that only existed in one direction — a UI element whose explanation text was hidden behind another panel in portrait, a button that rendered at text height because a padding value was read from the wrong place. A coverage checker now scans the test suites themselves and fails the whole run if any suite lacks dual-orientation coverage. The tests have tests.

What "done" means now

Today, when the agent reports a visual fix, the report has to include the measurements: before and after, in pixels, on an emulated phone screen, in both orientations. "The pose transitions are correct" is accepted as a statement about plumbing, never as a statement about what the game looks like.

The funny part is that this discipline turned out to be exactly what a good human QA lead would insist on. The agent didn't lack effort or honesty; it lacked a definition of done that matched what a player experiences. Once we wrote that definition down — measure the screen, not the data — the playtesting became something I can actually trust, and my own phone checks turned from "catch the agent's mistakes" back into what they should be: judging whether the game feels right.

Indie game developer in Japan. I build games like Samurai 100 Slash Lite and Acid Rogue Shooting, and write about developing with AI agents. Portfolio: https://portfolio.wabiplant.workers.dev/

How I Build Games With an AI Agent (Muse) as My Dev Partner

wabiplant — Sat, 07 Nov 2026 07:56:56 +0000

I'm a solo game developer in Japan. I ship iOS games and small web services by myself — design, code, art direction, store operations, marketing, support. For the past stretch of work, a large part of that operation has been running with an AI agent called Muse as my development partner. Not as a chat window I occasionally ask questions, but as a persistent worker: it lives on a virtual machine that runs around the clock, has access to my project files, my notes, and my schedules, and takes on tasks the way a very tireless junior colleague would.

This is what that actually looks like, including where it works and where it doesn't.

The setup: one human, one agent, several products

At any given time I'm maintaining multiple released products — a few iOS games, a web service or two — while developing a new browser game. A solo developer's real bottleneck is rarely writing code. It's the hundred small things around the code: checking store metrics, resizing a project that has bloated to tens of gigabytes, investigating why a build got rejected, writing release notes, preparing promotional posts, keeping track of what was decided last week.

The agent handles a surprising amount of that outer ring. It collects store and ad revenue numbers every morning and assembles them into one dashboard. It runs bulk file operations on game projects. It drafts articles and posts. It watches for security advisories that match my tech stack. My job concentrates on the center: game design, feel, and final decisions.

How I give instructions

The single biggest lesson: the quality of the output is mostly determined before the work starts, by how the task is framed.

Give a goal, not just a step. When I delegate through a goal-oriented mode — a clear statement of the end state I want, not a sequence of micro-instructions — the work runs to completion much more reliably. When I only gave step-by-step prompts, sessions tended to stall halfway, waiting for the next nudge.

Keep tasks small, with a hard stop and one verifiable result. "Fix the hitboxes" is a bad task. "Extend the combo hitbox slightly past the visible tip of the blade effect, for these three characters, and prove it with the test suite" is a good one. Small tasks fail small.

Demand evidence, not conclusions. I require reports to say what was actually measured: which tests ran, what the screenshots showed, what was not verified. This rule exists because of real failures, which I'll get to below.

Write decisions down once. Every settled decision — controls are frozen at this version, this character's size ratio is final, never re-propose option A — goes into a persistent memory the agent reads. Without that, you re-litigate the same choices every session, and the agent cheerfully re-suggests things you rejected last week.

What the agent is genuinely good at

Tireless verification. Running the same test suite in two orientations, auditing hundreds of sprite frames against numeric gates, re-checking a deployed page byte for byte. Humans get bored and skip; the agent doesn't.
Bulk and patience work. Sorting tens of thousands of asset files by whether anything references them. Reading long official documentation and cross-checking my assumptions against it.
Operational memory. It remembers that three weeks ago we decided X, and applies X consistently at 3 a.m. when I'm asleep.
Drafting. First drafts of articles, store text, and documentation — which I then edit for taste.

What it is bad at

Judging how something looks and feels. The agent once reported a motion fix as complete because the animation frames existed and the pose transitions were correct. On my phone, the character looked essentially unchanged. Numbers said "done"; eyes said "no." Pixel-level measurement helps (I wrote about that separately), but final visual judgment stays with me, on a real device.
Knowing when a report is overconfident. It will phrase a partial check as a full verification unless the reporting rules force it to enumerate what was actually tested. The fix is process, not trust.
Taste. Which of twelve character designs is right, whether a joke lands, when a feature should be cut — these are mine.

Where the human keeps the wheel

Three things I never delegate. First, anything irreversible that faces the public: submitting a build for App Store review always needs my explicit approval, even though bug fixes themselves can proceed automatically. Second, identity and privacy: my real name and home address never appear in anything public, and the agent is under a standing rule to keep it that way. Third, creative direction. The agent can generate a hundred variations; choosing the one that feels like my game is the job I actually enjoy.

Working this way hasn't turned one developer into a studio of fifty. It has turned one developer into maybe two and a half — with the extra capacity mostly spent not on making more, but on verifying better. For a solo operation, that trade has been worth it.

Indie game developer in Japan. I build games like Samurai 100 Slash Lite and Acid Rogue Shooting, and write about developing with AI agents. Portfolio: https://portfolio.wabiplant.workers.dev/