One File to Rule Them All

The Weird Part

Most Unity games are built by dragging things around in the Editor. You place enemies in a scene. You wire up references by hand. You tweak values on Inspector panels. If you want to change the player's speed, you click through a hierarchy, find the right component, change the number, save the scene.

I don't do any of that anymore.

My entire game — every enemy, every level, every projectile, every cutscene, every UI screen — is defined in a single text file. An AI reads that file, understands the entire game, makes changes to it, and then I press one button in the Unity menu bar. That button generates every prefab, every animation controller, every scene, every Addressable group. From scratch. Every time.

The file is GameDefinition.asset. It's 1,200 lines of YAML. It is the game.

What a Session Actually Looks Like

Here's how I work now. I open VS Code. I open a chat with an AI. The AI has instructions that say: read the architecture docs first, then look at GameDefinition.asset.

The AI reads one file and knows:

• The player's speed, jump force, health, sprite sheet, and full animation state machine
• Every enemy type — their AI behavior, stats, attack patterns, sprites, and sound effects
• Every level — which enemies spawn where, at what time, with what health overrides
• Every cutscene — the sprite frame data, audio, and experience events
• Every projectile — damage, speed, lifetime, pool size
• Every UI screen — the main menu, level selection, upgrade shop

Then I say something like "make the enemies smaller" or "add a new level with 5 Shooters" or "change the Chaser's chase range to 8." The AI edits the YAML. I press SickOfIt → Generate Project. Done.

No scene editing. No prefab dragging. No Inspector clicking. The AI never needs to understand Unity's GUI. It just needs to understand a text file.

Why This Works for AI

AI is really good at editing text files. It's terrible at operating GUIs.

Think about what an AI agent would need to do to place an enemy in a traditional Unity project: open a scene, find the hierarchy, instantiate a prefab, set the position in the Transform component, wire up health references, configure the AI settings on the right MonoBehaviour, save the scene, mark it dirty. Every step is a potential failure point. Every step requires understanding Unity's serialization model.

Now think about what it needs to do in this project:

  - type: Chaser
    position: {x: 5, y: -2.33}
    spawnTime: 4
    healthOverride: 0

That's it. Four lines of text. The AI appends them to the enemies list in a level config. The generator handles the rest — instantiating the prefab, setting the position, wiring the health component, configuring the AI, connecting the object pool, attaching rewind components, registering with the timeline.

The gap between "what the AI writes" and "what exists in the running game" is closed entirely by the generator. The AI never touches a Unity scene. It never touches a prefab. It edits data and the generator turns data into a game.

Teaching the AI the Rules

There's a file in the repo called .github/copilot-instructions.md. Every AI session starts by reading it. It contains the rules of the project — not suggestions, rules. Things the AI must know to avoid breaking the build:

These rules exist because an AI will take the path of least resistance. If there's a shortcut that technically works but violates the architecture, it'll use it. The instructions file eliminates those shortcuts before the session begins. The AI doesn't have to figure out the right approach — it's told the right approach upfront.

One Button: Generate Project

This is the part that's genuinely unusual. In the Unity menu bar there's a single menu item: SickOfIt → Generate Project. When you click it, the following happens in order:

1. Cleanup — Every generated asset is deleted. Prefabs, animations, scenes. All of it.
2. Projectile prefabs — Generated from ProjectileConfig[]. Sprite, collider, damage, pool size, sounds.
3. Pickup prefabs — Diamond prefab from PickupConfig.
4. Platform prefabs — Generated from platform config.
5. Player prefab — Character.prefab from PlayerConfig. Sprite sheet, animation state machine, physics, combat components.
6. Enemy prefabs — Enemy_Chaser.prefab, Enemy_Fighter.prefab, etc. Each from its EnemyTypeConfig — sprite, animation, AI, health, drops.
7. Gameplay scenes — Video.unity, Level.unity, Death.unity. Camera, UI, runtime scripts, all wired up via SerializedObject.
8. UI scenes — MainMenu.unity, LevelSelection.unity, VideoSelection.unity, UpgradeShop.unity.
9. Addressable groups — Every generated asset is tagged and bundled for WebGL loading.

The whole thing takes a few seconds. And it's idempotent — run it twice, get identical output. There's no accumulated state, no "well this scene has a slightly different setup because someone tweaked it three weeks ago." The config is the truth. The generated output is disposable.

This means the AI can make changes fearlessly. It can't corrupt a scene. It can't leave a prefab in a half-configured state. It can't break a reference that was manually wired. Because none of those things exist. The only thing that persists is the config file, and the config file is plain text that's trivial to validate, diff, and roll back.

What's In the File

One file. 1,200 lines of YAML. This is the entire game:

GameDefinition.asset
├── PlayerConfig
│   ├── spriteSheet, animationFps, spriteScale
│   ├── animationConfig (states, transitions, parameters)
│   └── walkSpeed, jumpForce, health, doubleJumpCost
├── EnemyTypeConfig[] (Chaser, Fighter, Sentinel, Shooter)
│   ├── spriteSheet, animationFps, spriteScale
│   ├── animationConfig (per-type states and transitions)
│   ├── moveSpeed, health, damage, knockback
│   ├── AI settings (chaseRange, stopDistance, attackCooldown)
│   └── drop config (diamonds, XP)
├── LevelConfig[] (4 levels)
│   ├── enemies[] (type, position, spawnTime, healthOverride)
│   ├── platforms[] (position, scale)
│   ├── barriers[] (position, scale)
│   ├── music, duration, cameraFollowSpeed
│   └── playerSpawnPosition
├── VideoConfig[] (cutscenes)
│   ├── spriteFramesData, audioClip
│   └── experience timeline events
├── DeathConfig[] (death animations)
├── ProjectileConfig[] (Player, Enemy, Laser)
│   ├── spriteSheet, scale, damage, speed, lifetime
│   └── poolSize, sounds
├── PickupConfig (Diamond)
│   ├── sprite, spriteScale, colliderRadius
│   └── popForce, gravity, lifetime
└── UI Scene Configs
    ├── MainMenuConfig
    ├── SelectionSceneConfig (level/video selection)
    └── UpgradeShopConfig

Everything the game needs to know about itself is here. The generators read it and produce Unity assets. The runtime reads it and configures gameplay. There is no other source of truth.

What This Actually Enables

Today, in a single session, an AI agent did all of this by editing one file:

• Moved four enemy types from separate ScriptableObject assets into the config — collapsing a dozen files into one
• Replaced the win condition from "reach coordinates" to "kill all enemies" — config change plus a few lines of runtime code
• Added staggered enemy spawn timing across all four levels — pure data, 23 spawn entries with specific times
• Rebalanced the scale of every entity in the game — player, enemies, projectiles, pickups — by editing YAML values

None of that required opening the Unity Editor. None of it required understanding Unity's scene hierarchy, or prefab overrides, or asset references. The AI edited text. I pressed a button. The game changed.

That's the point. The entire complexity of Unity — its serialization, its prefab system, its scene management, its Addressables pipeline — is hidden behind the generator. The surface area that anyone needs to interact with, human or AI, is a text file and a menu item.

The Full Pipeline

To put it all together, here's the full content pipeline from idea to running game:

From text prompt to playable game content. The AI never opens Unity. It never drags a prefab. It never wires a reference. It writes text and the system does the rest.

Why a Single Config Matters

I could have kept things "normal." ScriptableObjects for enemies. Hand-built scenes for levels. Manually wired prefabs. That's how most Unity projects work and it works fine — for humans, working alone, at human speed.

But I'm not working alone. I'm working with an AI. And an AI's biggest limitation isn't intelligence — it's context. The more files it needs to understand, the more likely it is to miss something. The more places a value can live, the more likely it is to change one place and forget another. The more manual steps between "edit" and "result," the more opportunities for things to silently break.

A single config file eliminates all of that:

• One file to read — The AI understands the entire game by reading 1,200 lines of YAML
• One file to edit — Every change happens in one place. No cross-file reference tracking
• One button to validate — Generate Project either succeeds or fails. There's no "it generated half the assets correctly"
• One file to diff — Want to see what changed between sessions? git diff GameDefinition.asset
• One file to roll back — Something went wrong? git checkout GameDefinition.asset and regenerate

This isn't how Unity games are typically built. Most tutorials, most open-source projects, most professional studios use Inspector-driven workflows with dozens or hundreds of ScriptableObject assets and hand-built scenes. That works great for teams of humans using the Unity Editor.

But if your collaborator is an AI that reads and writes text? You want your entire game to be text.

The best game architecture for human-AI collaboration is one where the game is a text file and everything else is generated from it.

What's Next

The config can grow. More enemy types, more levels, boss encounters, new mechanics — they're all just new entries or new config sections. The generators can grow to handle them. The runtime can grow to interpret them.

But the workflow doesn't change. AI edits the config. I press the button. The game rebuilds. That's it. That's the whole process. And it's fast enough that iteration feels instant — change a number, regenerate, play, decide if it's better. Repeat.

I don't think this is how everyone should build games. But if you're building with AI as your primary collaborator? This is the architecture you want. Make your game a text file. Make everything else disposable. Let the AI do what it's good at — editing text — and let the generator do the rest.