Games — AI One-Shot Build Comparisons

This repo is a testbed for comparing how different AI models perform when given the exact same detailed build prompt for a non-trivial game, in as close to "one shot" as possible (a single agentic pass from blueprint to a working, runnable project).

Each game concept was written up as a thorough spec (see each folder's OriginalPrompt.txt), then handed unmodified to two different AI models. Every folder is a separate, independent implementation — nothing is shared between them — so you can diff the actual engineering decisions (architecture, file layout, physics/math choices, polish, bugs) each model made from identical instructions.

📺 Watch a video comparing the builds

Layout

Folders are named <game>_<model>:

Prefix	Game	Prompt
cc_	Cats v. Dogs — a browser-only, sprite-based RTS (Command & Conquer–style: harvesting, base building, unit control, minimap)	cc_k3/OriginalPrompt.txt
rl_	Rocket Arena — a local, web-based Rocket League–style game (car, ball, boost, flight, goals, instant replay)	rl_k3/OriginalPrompt.txt

Suffix	Model
_fable	Build produced by the "Fable" model
_k3	Build produced by the "K3" model

So the four project folders are:

• cc_fable/ — Cats v. Dogs, built by Fable (single-file index.html, no build step)
• cc_k3/ — Cats v. Dogs, built by K3 (modular ES modules, static-server dev workflow)
• rl_fable/ — Rocket Arena, built by Fable (Three.js + Rapier3D + Vite)
• rl_k3/ — Rocket Arena, built by K3 (Three.js + Rapier3D + Vite)

Each project folder is fully self-contained with its own README.md (setup/run/controls) and OriginalPrompt.txt (the exact spec given to the model). Start there for how to run a specific build.

Why compare these

Same requirements, same constraints, different models — the interesting part is where the implementations diverge:

• Architecture: single-file vs. modular; how cleanly each model split engine/data/UI.
• Fidelity to the spec: which requirements got implemented, skipped, or reinterpreted.
• Code quality: naming, comments, testability (e.g. cc_k3 includes a headless test harness and Python lint tools under tools/).
• Bugs and rough edges introduced by each model, and how each documented known limitations.
• Polish beyond the minimum spec (extra features, effects, UX touches).

Quick start

Each project has its own run instructions; in general:

• cc_fable — just open index.html in a browser (no server needed).
• cc_k3 — serve the folder with any static file server (ES modules need http://, not file://), e.g. py -m http.server 8123.
• rl_fable / rl_k3 — Node project: npm install && npm run dev (or build/run via the included Dockerfile).

See each folder's README for full details, controls, and architecture notes.