Working locally

Run the game, let your assistant see it, and know which jobs still belong in umicat.

A clone is the whole game — its code, its assets, its history. Almost anything looks possible from it. This page is about what actually is.

Running the game

A fresh clone has no dependencies yet:

npm install
npm run dev

That serves the game on localhost, hot-reloading as you edit. It is the same code the browser preview runs.

Let your assistant look at it

This is the part that is genuinely better on your own machine. Ask your assistant to playtest after a change:

Playtest it and tell me what you see.

It builds the game, starts the server, opens it in a headless browser, lets it run, and gets back the console errors, the assets that never loaded, and a screenshot it can actually look at.

That matters more than it sounds. The most common way a change goes wrong is not a crash — it is code that compiles, deploys, and draws the wrong thing. A build passing proves the types line up; it proves nothing about whether you can now do the thing you asked for. Locally, an attempt is free, so there is no reason for an assistant to claim a change works instead of looking.

Playtesting needs a browser. If Chrome or Edge is already installed it uses that and downloads nothing; otherwise your assistant will be told the one command that installs a small headless one. Nothing else here needs it.

What it will not do is play the game. Whether a jump feels right, whether a fight is too hard, whether the tutorial makes sense — still yours.

What does not work outside umicat

The game runs standalone, but anything that goes through the umicat page around it does not:

Works locally	Needs umicat
Rendering, input, physics, game logic	Living NPCs and AI opponents
Scenes, entities, assets already on disk	Multiplayer rooms
Saves (falling back to local storage)	Cloud saves that follow an account
Everything drawn on screen	Voice, and anything billed in credits
Cover, logo and screenshots	Publishing itself, and AI-generated covers

A feature built on those is finished locally and verified after pushing, in the umicat preview. Your assistant should say so rather than report it as tested.

Generating art is not local work — making it can be

Generating art, sound, music, tilesets and sprite sheets happens in umicat's own editors, against paid model APIs. There is no local equivalent for that, and no amount of code makes one. So the loop for a game that needs AI-made art is: make it in umicat, pull, wire it up here.

Making it with your own tools is a different story. If you model in Blender, draw in Aseprite or record in a DAW, ask your assistant to upload the result — it lands in the project's Assets Manager exactly like something made in umicat. That loop runs the other way: upload, then pull. See Art you made yourself.

Either way, everything around an asset is local work: load it, wire it into a scene, animate it, give it a hitbox, use it.

Layout has real editors, and code does not beat them

Entity placement, HUD widget positions, tilemap painting, region tags and hitbox shapes are all stored as JSON you can edit by hand. For a surgical change — nudge one number, rename one id — editing the file is the right tool and faster than anything.

For actual layout — "move these around until it looks right" — it is not. Those editors show you the result as you work; locally you would be guessing at coordinates and asking someone to check each guess.

It can open umicat's editors for you

When the answer is "that happens in umicat" — making art, painting a tilemap, laying out a scene, tagging regions, publishing — your assistant can open the right tool rather than leave you to find it:

Open the tilemap editor for this project

It opens your workspace with that tool as a tab — your chat on the left, every other tool a click away, exactly as if you had opened the project yourself.

Assets Manager, Asset Store, the Tilemap and Tileset editors, Spritesheet Editor, Dialogue, Documents, Data Tables, Playbooks, Code Viewer, the image, pixel, model, sound and music editors, settings, members, history, publish, and the game editor itself. Name an asset too and the tool opens on that file rather than on a picker.

Anything you change in those tools is committed to the project. Pull before going back to the code, or your next push will be refused.

Your assistant already knows the SDK

umicat's own agent runs with dozens of skills describing how the SDK expects scenes, HUD widgets, assets and dialogue to be built. A clone brings the ones for that game's engine with it, so your assistant writes code the platform actually accepts — a 3D game never carries the 2D set, and the other way round.

They live in .claude/skills/, are ignored by git, and are never committed. Restart your assistant after a clone so they load.

Assistants that do not read that directory get the same guidance as an AGENTS.md index written into the clone, pointing at those same files. That is the convention most of them read — Codex, Cursor, Copilot, Gemini CLI, Windsurf, Zed, CodeBuddy, Qoder and Trae among them — so Claude Code is really the exception, not the rule.

If your project already has its own AGENTS.md, it is kept as it is and nothing is written. Same if your assistant prefers a file of its own that outranks it.

If you cloned a game before this existed, or you have updated the server, ask your assistant to install the umicat skills for that project.