# Game Studio Crew > A game studio that runs itself - 13 AI specialists building real games in Unity, Unreal and Godot, on a 3D studio floor you can watch. Rust daemon, no API keys. - **Type:** MCP server - **Install:** `agentstack add mcp-tugcantopaloglu-game-studio-crew` - **Verified:** Pending review - **Seller:** [tugcantopaloglu](https://agentstack.voostack.com/s/tugcantopaloglu) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [tugcantopaloglu](https://github.com/tugcantopaloglu) - **Source:** https://github.com/tugcantopaloglu/game-studio-crew ## Install ```sh agentstack add mcp-tugcantopaloglu-game-studio-crew ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Game Studio Crew **A game studio that runs itself.** Thirteen AI specialists, a producer and a director, working a real project in a real engine, on a studio floor you can watch in 3D while it happens. Rust daemon · Unity · Unreal Engine 5 · Godot 4 · No API keys **Windows · macOS · Linux** --- ## What this is You describe a game. A director decomposes it into tasks, hands each one to the specialist who should do it, and runs them in parallel. Engineers write code, artists draw and rig the assets, QA verifies against the real engine, and the whole thing commits itself to git as it goes. You watch all of it happen on a top-down 3D studio floor in your browser: desks lighting up, characters walking to meetings, a timeline you can scrub. There are **no API keys anywhere in this**. Everything runs through the coding CLI subscription you already pay for. --- ## Meet the crew Thirteen roles across six departments. An engine is a *prompt layer*, not a separate cast, so the same crew works Unity, Unreal and Godot. ### Leadership Studio DirectorTier 1 · FableOwns the plan. Answers to you. ProducerTier 2 · OpusScope, sprints, release gates. Systems & Tools EngineerTier 2 · OpusArchitecture and the build. Game DesignerTier 2 · OpusMechanics and the feel of them. ### Engineering & QA Gameplay EngineerTier 3 · OpusSystems that ship in the game. Build & Infra EngineerTier 3 · OpusPipelines, CI, packaging. QA EngineerTier 3 · OpusReproduces, verifies, refuses. Technical ArtistTier 3 · OpusRigs, shaders, the art pipeline. ### Design, Art & Audio Level DesignerTier 3 · OpusSpaces, pacing, encounters. Narrative DesignerTier 3 · OpusStory, dialogue, tone. UX/UI DesignerTier 3 · OpusMenus, HUD, readability. ArtistTier 3 · OpusSprites, textures, characters. Audio DesignerTier 3 · OpusMusic, SFX, mix. Every role has a **frozen charter**: a byte-identical system prompt that never changes between invocations, so the model provider's prompt cache pays for it once. Each role also carries only the tools its job needs: coordination roles get none at all, designers and engineers get read and write, art and QA additionally get a shell. --- ## Quick start Runs on **Windows, macOS and Linux**. One line each: **Windows** (PowerShell) ```powershell irm https://raw.githubusercontent.com/tugcantopaloglu/game-studio-crew/main/scripts/install.ps1 | iex ``` **macOS and Linux** ```bash curl -fsSL https://raw.githubusercontent.com/tugcantopaloglu/game-studio-crew/main/scripts/install.sh | sh ``` Each script picks the right build for your platform, downloads it from the latest release and installs it, with no admin or root needed. Add `-Portable` on Windows to unpack without running the installer, or set `PREFIX=/usr/local` on Linux to install system-wide. ### Or install by hand Every release ships an installer as well as an archive: a `-setup.exe` for Windows, a `.dmg` for macOS, and a tarball with its own `install.sh` for Linux. See [Releases](../../releases). | Platform | Installer | Archive | |---|---|---| | Windows | `game-studio-crew-1.0.1-setup.exe` | `...-windows-x86_64.zip` | | macOS | `...-macos-aarch64.dmg` / `...-macos-x86_64.dmg` | `...tar.gz` | | Linux | `install.sh` inside the tarball | `...-linux-x86_64.tar.gz` | The Windows installer needs **no admin rights** and touches neither `PATH` nor any service; on uninstall it asks before removing the studio's own data. Your project folders live where you put them and are never touched. The macOS build is unsigned, so the first launch needs right-click → **Open**. The Linux desktop shell needs `libwebkit2gtk-4.1`; the daemon alone has no such dependency. ### From source ```bash cargo build --release ./target/release/studiod doctor # what's installed, and what can actually run the crew ./target/release/studiod studio # serve the floor at http://127.0.0.1:7878 cd desktop && cargo build --release # the native window, optional ``` On Linux, install the webview headers first: `libwebkit2gtk-4.1-dev libgtk-3-dev`. ### The desktop window The window is a thin native frame around the same floor the daemon serves on `127.0.0.1:7878`. It starts the daemon for you, waits for the port rather than guessing, and takes the daemon and every worker down with it when you close it, on every platform. If a daemon is already running it attaches to that one instead of starting a second. ### What you need `studiod doctor` deliberately tells you two different things: **which CLIs you have**, and **which ones can actually spawn a worker**. | | Status | |---|---| | **A coding CLI** | `claude`, `codex`, `gemini`, `copilot` and `kimi` are all detected. Any one is enough to install, but only a CLI that accepts a frozen charter can run the crew, which today means **`claude`**. | | **git** | Optional. Reported present or absent; its absence is never an error. | | **An engine** | Optional. Godot, Unity or Unreal, whichever you're building in. | | **Art pipeline** | Optional. `node`, a `python` that can import `pillow`, and the `codex` imagegen skill. | An install that finds only Gemini succeeds, and then says plainly that nothing installed can start a worker yet, and exactly what to install, instead of showing a tick you'd learn the truth about at your first task. `studiod doctor --fix` runs the installs it can after showing you the list and asking. The one step it can't do for you is `codex login`, and it says so. --- ## The studio floor The floor is a top-down 3D office rendered in the browser. It is not a log viewer; it is the studio. - **Desks light up** when a worker spawns, and settle when it exits. - **Characters walk** to the meeting room when a room is convened, and back to their desks after. - **Shape encodes identity**: outfit, hair and the prop in hand are per-role, so you can tell the QA engineer from the audio designer at floor distance. - **A second storey** holds management, reached by a working lift. - **Click anyone** to inspect what they're doing, what they were briefed with, and what they cost. - **A timeline scrubber** replays the run; a minimap keeps you oriented. - **A workflow track** shows the DAG executing, node by node. - Live **token and cost readouts**, cache hit rates, and a frame-time counter where you'd actually look for it. Everything on the floor is driven by a real event feed over WebSocket: the same events that go into the state store, replayed on reconnect from the last sequence number you saw. --- ## What you can do ### Projects Work is scoped to a project: a directory you name, at a path you choose, with its own git repo. Create one from the floor (name, absolute path, engine, and whether to `git init`), and every task, workflow and build afterwards runs with that directory as the working directory. **Nothing runs without a project selected.** There is no fallback to the daemon's own directory. You can also **adopt an existing game**: point the studio at a folder, and it surveys the tree, detects the engine, indexes the code and writes a summary the crew plans against, so tasks extend what's there instead of rebuilding it. ### Tasks Send a single role a single brief. It spawns, works in the project, and commits. ### Builds Describe what you want. The director returns a plan, a DAG of tasks with roles, briefs and dependencies, which you can **edit before anything runs**: change a brief, drop a step, reorder. Then the crew executes it, up to four workers in parallel. Turn on **guided mode** and the run holds after every step for your approval, with an option to send a step back with a note ("make the pipes green") up to three times. ### Meetings Convene a room and the daemon runs a real deliberation, not a transcript. Each participant after the first is handed the previous positions **verbatim** and asked to answer them. The chair, the nearest common ancestor in the escalation tree, receives the whole room and is held to a schema, so it returns a rule the studio will follow, the reason it beat the alternative, and the positions it overrules. The ruling lands in two places: the decision store, so it can be handed to a worker weeks later, and `docs/decisions/` in the project repo as an ADR recording the claim, the reasoning, the dissent and the whole room. A chair that returns nothing usable adjourns the meeting; the studio never records a decision nobody made. ### Workflows Four DAG workflows ship built in, defined in TOML with nodes, edges and gates: | Workflow | What it does | |---|---| | `feature` | design → implement → verify → polish | | `bugfix` | triage → reproduce → fix → regression-test | | `release` | freeze → verify → export → package | | `sprint_planning` | scope → break down → estimate → schedule | ### Verification and repair When a gate fires, the daemon runs the engine's own build and test commands, parses the structured report, and hands any failures back to a repair worker with the exact list, up to three rounds. The verify contract is **inconclusive-first**: a missing report, an empty suite, a truncated report, a crash exit code or a silent CI helper are all *inconclusive*, never a pass. Absence of evidence is never treated as evidence. Infrastructure problems (a licence server, a missing GPU) are routed away from the crew rather than handed to an engineer to "fix". The gate also **re-verifies its own tooling before every run**: the studio's CI helper lives inside the project, so if anything rewrote it, the gate restores it from the shipped copy and fails by name rather than trusting a check the work under test could have written. ### Art the crew draws itself The crew can make its own assets: it asks `codex` for a sprite or texture, keys the flat background out of it, and turns a character into a **rigged, animated model the engine loads**, including retargeting Mixamo clips onto the generated skeleton. A character nothing can pose is failed, not shipped. ```bash studiod asset character --name hero --describe "a small knight in dented brass armour" studiod asset sprite --name coin --describe "a spinning gold coin" studiod asset rig --slug hero studiod asset animate --slug hero --fbx anims/run.fbx ``` This path is optional in the honest sense: with any of it missing, every other path behaves exactly as before and the crew builds art by hand. ### Version control The daemon commits for you. After each worker completes it stages the project and writes a commit subject of `: `, so history reads as ordinary studio work and you can diff or revert any single worker's output. **Committing is daemon work, not worker work.** No worker ever runs git or receives git tools, and no commit message is model-generated, so version control costs **zero tokens**. From the floor you get a commit tree, per-node revert, rollback with a preview of exactly what's about to be destroyed, and push. ### Budget governance You set a ceiling in tokens, in dollars, or both. The daemon projects every spawn before it happens and admits, degrades or refuses it. As pressure rises the crew degrades gracefully rather than stopping dead: leaning on reasoning effort first, routing summarization to a cheaper model, trimming context, with the rung following actual budget pressure rather than the number of spawns. You can also ask to be prompted above a spend threshold, and stop a run at any point from the floor. Every worker's real usage is recorded per turn, including workers that were killed or timed out, which are exactly the runs that cost the most. ### Code index A tree-sitter index parses GDScript, C# and C++ into a separate database, gated on content hashes so an unchanged file is never re-parsed. Workers ask it for **symbols, not files**. A worker learns that `Enemy.attack` calls `Player.take_damage`, and that it runs on the `CharacterBody2D` at `Player` in `scenes/main.tscn`, without any of those files entering its context. Measured against a worker with `Read`, `Grep`, `Glob` and no index on the same question: **2.3–3.4× fewer input tokens**, same correct answer. ### Settings Per-tier and per-role model and effort overrides, engine binary paths, budgets, parallelism, and music, all from the floor and all live. --- ## How it works The daemon owns everything. Workers are cheap, disposable, and told only what they need for one task. ```mermaid graph LR subgraph Daemon["Rust daemon"] ORCH[orchestratorsupervisor + budget] CTX[context enginefrozen charters] STATE[(state storeSQLite/WAL)] IDX[(code indexSQLite/WAL)] EVT[event bus] MCP[MCP server] end subgraph Workers["CLI workers (stateless)"] W1[worker] W2[worker] end ENG[engine driversUnity / UE5 / Godot] UI[studio floor] CTX --> ORCH STATE ORCH IDX --> CTX ORCH --> W1 & W2 W1 & W2 -. tool calls .-> MCP MCP --> ORCH ORCH --> ENG ENG -. structured failures .-> ORCH ORCH --> EVT --> UI ``` A worker reads a frozen system prompt, receives one volatile task brief, does the work, and exits. It never talks to another worker and never holds durable state. The daemon reduces its output into events, ledger rows and state transitions. ### The crates | Crate | Owns | |---|---| | `studio-core` | worker supervision, process trees, watchdogs, stream parsing, git | | `studio-context` | layered prompts, charter freezing and hashing, capsules, summarization | | `studio-store` | runtime state, event log, token ledger; single-writer SQLite | | `studio-index` | engine detection, tree-sitter extractors, the code/asset index | | `studio-agents` | the 13-role registry, delegation and escalation | | `studio-events` | event envelope and enum, coalescing, resume | | `studio-budget` | budgets, enforcement points, the degradation ladder | | `studio-engine` | engine profiles, charter fragments, helper bootstrap | | `studio-verify` | the `verify()` contract, report parsers, the repair loop | | `studio-workflow` | TOML DAG workflows, the parallel executor, gates | | `studio-standards` | rule modes and the R0–R4 trust model | | `studio-mcp` | the studio's MCP tools over stdio | | `studio-settings` | settings, providers, model and effort resolution | | `studio-server` | HTTP + WebSocket server and the studio floor | | `studiod` | the binary that ties it together | Two **separate** SQLite databases: runtime state and the code index. They are never the same file and never share a connection. --- ## Why it's cheap > **Feed the model minimum viable context, and never pay twice for the same tokens.** - **The tool list is the primary lever.** Built-in tool schemas, not project files, are the bulk of a default invocation: the same call costs **22,572** tokens with the default tool set and **184** with an empty one. - **Charters are byte-frozen and content-hashed**, so prompt caching (1-hour TTL, keyed on exact prompt bytes plus tool set plus model) pays for them once, and every same-role worker in the window reads from cache. - **13 roles, not 50.** Fewer distinct prefixes means fewer cold starts, and a cold start costs a **2.0× write premium**. - **Cold starts are staggered.** When a wave holds several workers sharing a prefix, one goes first and warms it; the rest follow warm instead of each paying the write premium. - **The daemon summarizes**, at zero token cost, so briefs stay small. - **Symbols, not files**, from the index. Measured: a warm prefix costs **$0.0025 against $0.0374 cold, a 14.8× reduction** across separate subprocesses, against **$0.2258 undefended**. These are probe measurements, not estimates. See [`probes/`](probes/README.md). --- ## Engines | Engine | Status | |---|---| | **Godot 4** | Proven end to end: build, verify, repair, export | | **Unity** | Profile written, commands bound, **not yet run against a real editor** | | **Unreal Engine 5** | Profile written, commands bound, **not yet run against a real editor** | | **Web / Python** | Supported for prototypes and probe … ## Source & license This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [tugcantopaloglu](https://github.com/tugcantopaloglu) - **Source:** [tugcantopaloglu/game-studio-crew](https://github.com/tugcantopaloglu/game-studio-crew) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** yes - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: flagged — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/mcp-tugcantopaloglu-game-studio-crew - Seller: https://agentstack.voostack.com/s/tugcantopaloglu - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.