Game projects trip AI up more than almost anything else. Engines change their APIs between major versions, much of the project is scenes and assets edited visually rather than in code, and the AI can't actually play your game. A good rules file deals with all three.

1. Pin the exact engine version

This is the single most important line in a game project's brain file. AI models have seen years of tutorials for older engine versions and will happily mix them with newer ones.

Godot is the classic example. Godot 4 changed a lot of GDScript compared with Godot 3, and old syntax still shows up in AI answers:

Godot 3 (old)	Godot 4
`export var speed = 200`	`@export var speed := 200`
`onready var sprite = $Sprite`	`@onready var sprite := $Sprite2D`
`yield(get_tree().create_timer(1), "timeout")`	`await get_tree().create_timer(1).timeout`
`KinematicBody2D`	`CharacterBody2D`
`move_and_slide(velocity)`	set `velocity`, then call `move_and_slide()`
`connect("pressed", self, "_on_pressed")`	`pressed.connect(_on_pressed)`

Unity has its own forks in the road: the old Input Manager versus the Input System package, and the Built-in render pipeline versus URP or HDRP. Code written for one often doesn't work with the other. Name yours.

## Engine
- Godot 4.3, GDScript only (no C#)
- Never use Godot 3 syntax or class names. If you're unsure whether
  an API exists in 4.3, say so and I'll check the docs.

## Engine
- Unity 6 (6000.0 LTS), C#
- Render pipeline: URP. Input: the Input System package (not the old
  Input Manager).

2. Protect scenes and assets

Godot .tscn/.tres files and Unity scenes and prefabs (when serialized as text) look editable, but they're full of IDs and references the editor manages. An AI "fixing" one by hand can silently break a scene. Moving or renaming assets outside the editor breaks references too: Unity tracks assets through their .meta files, and Godot updates paths when you move things inside its FileSystem dock.

## Scenes and assets
- Don't hand-edit .tscn/.tres (or .unity/.prefab) files unless I ask.
  Instead, tell me the editor steps: which node, which property.
- Don't move or rename assets from the command line. Tell me what to
  move and I'll do it in the editor.
- When a script needs to be attached or a signal connected, tell me
  exactly where in the editor.

3. A tiny game design section

The AI writes better gameplay code when it knows what the game is. Five lines is enough:

## Game
- 2D top-down roguelite, runs last 10-15 minutes
- Core loop: clear room, pick 1 of 3 upgrades, next room
- Controls: WASD + mouse aim; gamepad support later
- Target: PC (Steam Deck friendly), 1280x720 base resolution
- Art: 16x16 pixel art, nearest-neighbour filtering

4. Conventions and a performance budget

## Code conventions
- Folders: scenes/, scripts/, assets/sprites/, assets/audio/, ui/
- One script per responsibility; scripts named after their scene
- Use signals for communication between nodes; avoid get_node()
  paths that reach across the scene tree
- Typed GDScript everywhere (var hp: int = 10)
- Game-wide state lives in autoloads: GameState, Audio

## Performance
- Hold 60 FPS on a Steam Deck
- Don't create nodes every frame; pool bullets and particles
- No per-frame work in _process when a signal or timer will do

For Unity, the same ideas apply in C#: cache GetComponent results instead of calling them in Update, avoid Find calls at runtime, and pool frequently spawned objects.

5. Git that won't fight the engine

Back up the project with git, but tell git (and the AI) what not to track:

Godot 4: ignore the .godot/ folder (it's a regenerated cache). Commit your *.import files next to assets; they hold import settings.
Unity: commit Assets/, Packages/, and ProjectSettings/, including every .meta file. Ignore Library/, Temp/, Obj/, Logs/, UserSettings/, and build folders. GitHub's github/gitignore repository has well-maintained templates for both engines.
Big binaries (audio, large textures, models): consider Git LFS so the repo stays fast.

## Git
- Commit after each working feature with a clear message
- Never commit .godot/ (or Library/ and Temp/ in Unity)
- Ask before running git commands that rewrite history

6. Close the feedback loop

The AI can't see your game running, so you're its eyes. Make that easy:

Paste the exact error from the Godot Output/Debugger panel or the Unity Console, including the file and line.
Describe what you expected and what happened: "the player slides after releasing the key, expected an instant stop."
Ask the AI to add temporary print() / Debug.Log() lines when a bug is hard to see, and to remove them afterwards.
If your tool accepts images, a screenshot of the scene tree or Inspector helps a lot.

Add a rule so the AI asks for this itself:

## Debugging
- You can't run the game. When a fix depends on runtime behavior, tell
  me exactly what to test and what output to send back.

Put it together

Combine the blocks above into your brain file, or use the generator's "Game" preset as a starting point and edit the engine line. As the project grows, keep a short design doc and decision log next to it; the memory guide shows the layout.