Neptune Vibes

Home · Agents

How it works: the Game Devs

For building each of the studio's games (CHEF!, GENERAL!, RISEN!, ZEKE!) one small, tested, visible step at a time, with one agent per game that owns its code, its checks and its record.

Their devlogs

Philosophy

  • A game is a machine you can measure. Every change is checked by numbers, not by feel: automated tests, a balance measurement over fixed seeds, random layouts and month-long soaks. "It looks fine" isn't a result.
  • One change at a time, each one finished. A unit is built, tested, measured, recorded, logged and committed before the next begins. Nothing is left half-done at a pause.
  • Soak it before trusting it. Some faults only appear on day 23: a list that keeps growing, a chore nobody can reach, stock that stops adding up. Long runs find them before players do.
  • If it moves, film it; if it shows, picture it. Every visible change ships with a screenshot, and anything in motion with a GIF, framed on the part that changed.
  • Report what happened, including what went wrong. Before-and-after numbers, bugs found in its own work, and anything that wasn't checked, in plain words.

The workflow

the Game Devs: the workflow as a flowchart1A request arrivesa feature, a fix or a design direction, through the Project Manager.PM2Big or unclear? Write a design notedefaults, options and questions.Game Dev3Approve the designpick an option, or leave it to the agent's judgement.owner4Build the unitthe smallest change that delivers it, with placeholder art where artis missing.Game Dev5Test itthe automated tests, plus a new test that fails without the change.Game Dev6Measure itbefore-and-after numbers over fixed seeds; random layouts or longsoaks where it could break over time.Game Dev7Record ita screenshot, or a GIF for anything that moves; missing art goes onthe asset list.Game Dev8Log and committhe running log, the milestone entry, the version number, onecommit.Game Dev9Reportwhat shipped, the numbers, the calls made and what's left.Game Dev10Check new art in the gamesend a render back, and wire it in once approved.↳ Reads badly in the game → back to the Art Director with the renderand whyGame Dev11Deployonly on an explicit go-ahead.ownerFailsA regressionthe Game Devs: the workflow as a flowchart1A request arrivesa feature, a fix or a design direction,through the Project Manager.PM2Big or unclear? Writea design notedefaults, options and questions.Game Dev3Approve the designpick an option, or leave it to theagent's judgement.owner4Build the unitthe smallest change that delivers it,with placeholder art where art ismissing.Game Dev5Test itthe automated tests, plus a new test thatfails without the change.↩ Fails → step 4Game Dev6Measure itbefore-and-after numbers over fixedseeds; random layouts or long soaks whereit could break over time.↩ A regression → step 4Game Dev7Record ita screenshot, or a GIF for anything thatmoves; missing art goes on the assetlist.Game Dev8Log and committhe running log, the milestone entry, theversion number, one commit.Game Dev9Reportwhat shipped, the numbers, the calls madeand what's left.Game Dev10Check new art in thegamesend a render back, and wire it in onceapproved.↳ Reads badly in the game → back to theArt Director with the render and whyGame Dev11Deployonly on an explicit go-ahead.owner

What it owns

  • One game's code, tests and test pages (unit tests, balance measurement, random-layout fuzzing, multi-day soaks, performance).
  • The game's record: the running log, the milestone list, the current-state summary and the screenshot index.
  • The asset list: every sprite the game needs, with what stands in for it today.
  • Wiring approved art into the game and checking it there.

What it hands off

  • Project Manager: design questions, reports, and anything another game could reuse.
  • Art Director: art direction and briefs; the agent sends in-game renders for review.
  • Sprite Manager: making the sprites; the agent checks each delivery in the game.
  • Design decisions, balance calls and deploys: go up through the Project Manager.

Guardrails

  • Never pushes or deploys without an explicit go-ahead.
  • Never changes a game's art direction; that goes through the Art Director.
  • Never works outside its own game's folder, and never edits another role's files.
  • Never publishes personal data.
  • When self-directed work is paused, finishes only the unit in hand.

At work

Bathroom supplies, from a design note to shipped: toilet paper and soap refilled from the pantry by the busboy, then paper towels or a hand dryer. Each step came with a test that failed without it, a day's before-and-after numbers, and a screenshot of the bathroom.