Starting over: rebuilding our sushi game from one design brief, at twice the resolution
Six parts in, our game had problems no patch could fix. So we wrote one page of design brief and let Claude Code rebuild it from scratch: inventing sushi first, guests who ask for flavours, and pixel art at 640×360 with faces that can act. Part 7. Play the new first five minutes.
What we asked“Build Neta from scratch in this folder, following DESIGN.md. This first session builds the foundation and one city, Tokyo: the look at 640×360, the shop, inventing sushi on the prep board, customers who ask for flavours, card packs that give ingredients, upgrades and saving. The first five minutes should make a new player want to keep going.”
What happened
- Read the design brief and the first version (kept read-only as a reference for its rules, odds and save format, not its art)
- Drew a new key image of the Tokyo shop at 640×360 before writing game code
- Built the shop, the prep board, guests who ask for flavours, packs, upgrades and saving
- Put each city in its own folder and wrote a guide for how a later session adds the next one
- Sent two helpers off in the background: the pack-opening scene, and bots to balance the economy
- The session ended while the helpers were still working, and headless mode stopped them. We resumed it once, telling it to finish their work
For six parts we grew Neta one system at a time, from a pixel sushi bar to a chain of six cities with music for each. Every part worked. Then we played the whole thing and found three problems no single patch could fix:
- The best part was a side screen. Inventing sushi came in part 3, after the shop already worked with fixed nigiri, so you could play for an hour without touching it.
- The art was too low. 320×180 with 12–16 pixel people leaves a face of about 4 pixels: no room for expressions.
- Six cities, one room. The chain came last, so every city was the same layout in different colours.
Each of those is built into the code the earlier parts wrote. Fixing them one by one would cost about as much as starting over, and it would still feel patched. So we started over, with one difference: this time we knew what the game is.
One page of brief
Instead of growing the game prompt by prompt, we wrote a one-page design brief from everything the first six parts taught us, and put it in an empty folder with the skills. Its main points:
- Inventing is the core. Cards are ingredients only. A dish exists only once you make it on the prep board.
- Guests ask for flavours, not dishes: "something fresh and sour", "something delicate". A dish that fits pays more, and a perfect fit is an event.
- A scripted first minute. Your first guest's wish leads you to invent your first dish within about 30 seconds.
- 640×360, with people 44–52 pixels tall and food in three sizes.
- Each city in its own folder, so later sessions can build cities separately.
- The old version stays in a read-only folder: reuse its rules, odds and save format, not its art or screens.
Read the whole brief (one page).
Play the new first five minutes
Follow the chef's hints. Click to turn on sound. This version only has Tokyo; reaching its goal shows "next city in a future update". Open full screen (that one saves your game).
1. Before and after
The same Tokyo shop, the first version on top, the rebuild below. People are about three times taller, with glasses, grins and heart eyes you can see. The window shows a rainy street, the lanterns glow, and the chef works where you can watch him.
The art-polish skill (below) explains the choice of 640×360: it is the only common size that scales by whole numbers at 1280 and 1920 wide, and shows crisp at 1× in a 720-pixel blog post. Hyper Light Drifter and Stardew Valley sit around 480×270; we went a step bigger because our people need faces that act.
2. The first minute
About 40% of players of one idle game quit before its first goal (dev.to), so the brief scripts the start. Claude played it in a real browser at normal speed:
| Time | What happens |
|---|---|
| 0:03 | The first guest sits and asks for "something fresh and sour". The chef points at the prep board. |
| 0:10 | You add yuzu to salmon, "Acid cuts fat" fires, the dish gets an A and goes on the menu. |
| 0:22 | The guest loves it: A PERFECT FIT!, hearts, +12 coins, and the shop opens to everyone. |
| 0:45 | The free pack: squid, aji, shiso, kelp cure and a torch. Sparkles mark cards that can fire a rule you haven't found. |
| 0:51 | A second invention teaches a new rule, and the guided part ends. |
3. Guests who ask for flavours
In the first version, guests ordered a dish by name, so a menu of plain nigiri was enough. Now each guest wants a flavour and picks the menu dish that fits best. That one change makes the prep board the reason you play: a new wish you can't serve well is a reason to invent something.
The food got the same upgrade as the people: every topping in three sizes, a piece for the counter, a plate, and a close-up for new dishes.
What went wrong
To work faster, Claude handed two jobs to helper agents running in the background: the pack-opening scene and the balance bots. Then the main session finished its own work, and in non-interactive mode Claude Code stops background helpers 10 minutes after the last turn. The pack scene was done, but the bots were half-written and had left the game far too fast. We resumed the session once with "your two background agents were stopped; finish their work yourself". It wrote the missing checks and retuned the economy in six logged passes. If you run Claude Code in scripts, set CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0 so it waits for its helpers.
What it cost
Two runs of the same session: 84 minutes and $22.30 in total, the most expensive part so far, for a whole new game foundation instead of one feature.
Still weak: income levels off around minute 22 instead of 30; better rice takes almost all of the best bot's spending; after about 5 minutes the eight stools are full and new guests walk past. And there is only one city.
Next: the other five cities, at the same time
Because each city lives in its own folder, the next sessions can build Osaka, Toyama, Kanazawa, Sapporo and Fukuoka in parallel, each a different room with its own local fish and twist.
Start over yourself
- When patches stop working, write down what the game is in one page: the core loop in order of importance, the first minutes, the look with numbers, and how it should grow.
- Put the brief, the skills and the old version (read-only) in a fresh folder, and ask for the foundation and one level or location first.
- Check its report against the brief: the first-minutes timeline, the measurements, and what it says is still weak.
The skill that made it work
The design brief did most of the work in this part; you can read the whole brief. Of the five skills the session had, this is the new one: how to take low-resolution pixel art to high detail. Copy the rules below, or download it with its references on resolution, the image-model pipeline and making places distinct.
- Never change how it plays. The simulation, its numbers and its tests stay exactly the same. Art and layout live on the rendering side. Run every measurement before and after; they must match.
- Move to 640×360. It scales by whole numbers at 1280 (2×) and 1920 (3×), shows crisp at 1× in a 720 px blog embed, and keeps `pixelArt: true`. Re-lay out the scene and UI for the new size rather than upscaling the old art: the old sprites are a sketch of what goes where.
- One key image first, again. Before redrawing everything, make one full mockup of the first shop at 640×360 with the chef, three customers in different moods, food on the counter, the UI bar and a pack button. Look at it at 1× and 2× next to the old version. Fix the direction until it is clearly better, then draw the rest to match.
- Characters that can act. Customers 44–52 px tall, about 2.5–3 heads, with a 16–18 px head: eyes with a highlight, separate brows, at least 3 mouth shapes, and at least four expressions (happy, wow, impatient, disgusted). Named staff up to 64 px. Build everyone as paper dolls from layered parts in code (body, head, hair, outfit, accessory) with palette swaps, and animate in code (walk, sit, eat, blink, breathing bob, reactions). Never use an image model for frames that must match each other.
- Food is the hero. Nigiri on the counter 12–16 px, plates and bowls 24–32 px, a 48–64 px close-up when a dish is invented, served for the first time or levels up. Each fish keeps one recognisable feature (tuna's deep red and white lines, salmon's fat stripes, ikura's shine). Glisten, a highlight pixel on rice, a little steam.
- Code draws structure and motion; the image model draws still source art. In code: room shells, tiles, counters, conveyor belts, UI, light and shadow overlays and all animation. With the local image model (ComfyUI at 127.0.0.1:8188, FLUX): food, landmark props, signs and window views, generated as source images, many variants, the best picked. Every generated image goes through the same pixelize step: exact target size, the shop's locked palette, background removed, stray pixels cleaned in code, and a colour-count check. Reject anything with gradients or a drifting pixel grid. See references/pipeline.md.
- Every location is a different place. Six shops must differ in at least five ways, not in colour alone: floor plan and seats, 1–2 landmark props, a window view of that city that changes with the time of day, a signature light colour and weather, and local dishes and customers. See references/places.md.
- Light, time of day, life. 4–6 colour grades for morning, noon, dusk, night (and rain), crossfaded over 10 seconds or more; lanterns and signs as additive glows that switch on at dusk; at least three small idle loops per scene (steam, a swaying curtain, a cat, a blinking sign), out of step. Detail goes into characters, food and props; keep floors and walls calm (Kingdom's team: "taking things away" made scenes feel harmonious).
- One palette system. A master palette for people and food (so they read in every shop) plus a sub-palette per shop. Test every character against every shop's background in greyscale: people and food stay the brightest things.
- Split the work. First the resolution switch, the first shop, the characters, the food and the UI in one pass. Then each remaining shop's room can be drawn separately, since rooms are independent files.
- Measure and show. Before/after screenshots of every shop at four times of day, at 1× and 2×, a contact sheet of all customers and their expressions, a sheet of all dishes, frame time in the busiest shop (60 fps), the simulation numbers unchanged, and the share of art made by code versus the image model.
- Report what changed, the palette, the pipeline, what was generated and how it was cleaned, and what still looks weak. If the game goes to Steam, generated art that ships must be disclosed.
Save it as .claude/skills/art-polish/SKILL.md in your project. Put the references folder next to it.
