Why Game Developers Need AI Coding Rules
You are a game developer. You work in Unity, Unreal Engine, Godot, or a custom engine. Your constraint: every frame must complete in 16.67ms (60fps) or 8.33ms (120fps). A web developer can afford a 200ms API call. You cannot afford a 2ms garbage collection pause. Memory allocation patterns that are fine in business applications (create objects freely, let the GC handle it): cause frame hitches in games. Without AI rules: the AI generates code that works in a simple test scene but stutters in a production level with 500 entities and 10,000 draw calls.
With AI rules: the AI generates game-optimized code by default. AI rule: 'No heap allocations in Update() or FixedUpdate(). Use object pools for all frequently created/destroyed objects (projectiles, particles, UI elements). Pre-allocate collections with known capacity. Cache component references in Awake(), never call GetComponent() per frame.' Every AI-generated system: respects the frame budget. Every update loop: allocation-free. The code: runs at 60fps with 500 entities, not just with 5.
The gamedev-specific benefit: game codebases mix multiple disciplines — gameplay programmers, graphics programmers, audio programmers, UI programmers, tools programmers. Each discipline has different conventions. AI rules: standardize the patterns across disciplines so a gameplay programmer can read graphics code and vice versa. The team: collaborates efficiently across disciplines because the code follows shared conventions.
How AI Rules Enforce Consistent Engine Patterns
Entity-Component-System (ECS) conventions: AI rule: 'Components are data-only structs (no methods, no inheritance). Systems are stateless processors that operate on component queries. Entity creation uses the EntityFactory pattern — never instantiate entities with inline component setup. Component naming: <Noun>Component (HealthComponent, VelocityComponent, RenderComponent).' The AI: generates ECS-compliant code. The gameplay programmer: creates entities using factories. The systems: process components without coupling to specific entity types. The architecture: clean and extensible.
Scene organization: game scenes become chaotic without conventions. AI rule: 'Scene hierarchy: root → Managers (singletons), Environment (static geometry), Entities (dynamic objects), UI (canvases). Prefab naming: PFB_<Category>_<Name> (PFB_Enemy_Goblin, PFB_UI_HealthBar). No nested prefabs deeper than 2 levels.' The AI: generates scene-compatible code that creates objects in the correct hierarchy. The level designer: navigates any scene instantly because the structure is consistent. The build system: processes scenes predictably.
Event systems: game systems communicate through events (player died, level completed, item collected). AI rule: 'Use the typed event bus for inter-system communication. Event naming: On<Subject><Action> (OnPlayerDied, OnLevelCompleted). Events are structs, not classes (avoid GC allocation). Subscribe in OnEnable, unsubscribe in OnDisable — never leave dangling subscriptions.' The AI: generates event-driven code with proper lifecycle management. The gameplay programmer: never debugs a ghost event handler that fires after its owner is destroyed. AI rule: 'Game engines provide freedom that business frameworks do not — no enforced architecture, no mandatory patterns. This freedom is also the risk: without conventions, game codebases become unmaintainable faster than any other software. AI rules: provide the structure that engines deliberately leave open.'
The ghost handler: a common game bug. Object A subscribes to OnPlayerDied. Object A is destroyed. Player dies. The event fires. The handler runs on a destroyed object — crash, or worse, silent corruption. AI rule: 'Subscribe in OnEnable, unsubscribe in OnDisable.' With this lifecycle rule: every handler is removed before the object is destroyed. Zero ghost handlers. Zero dangling references. The rule: eliminates an entire category of hard-to-debug game crashes with one lifecycle convention.
AI Rules for Frame Budget Compliance
Update loop performance: AI rule: 'No Instantiate() or Destroy() in Update loops — use object pools. No string operations in Update (string concatenation allocates on heap). No LINQ queries in hot paths (ToList() allocates). No Debug.Log in production builds (wrap in #if UNITY_EDITOR). Profile any system that runs per-frame — maximum 2ms per system in a 16ms frame budget.' The AI: generates allocation-free update code. The frame budget: predictable and measurable.
Rendering optimization: AI rule: 'Batch static geometry with static batching flags. Use GPU instancing for repeated objects (trees, rocks, enemies of the same type). LOD groups required for all 3D models visible beyond 50 meters. Maximum draw calls per frame: 2000 (target: under 1000). Shader complexity: no more than 100 ALU operations in fragment shaders for mobile.' The AI: generates rendering-aware code that respects draw call and shader budgets. The artist: gets consistent performance guidance from AI-generated setup code.
Physics optimization: AI rule: 'Use layers for collision filtering — never rely on tag-based filtering in OnCollisionEnter. Rigidbody queries (raycast, overlap): use NonAlloc variants (RaycastNonAlloc, OverlapSphereNonAlloc). Maximum active rigidbodies: 200 per scene. Use simplified collision meshes — never use mesh colliders on moving objects.' The AI: generates physics code that scales. The game: maintains 60fps during combat scenes with dozens of active physics objects. AI rule: 'Frame budget compliance is not optimization — it is the minimum viable product for games. A game that runs at 45fps is not a slow game — it is a broken game. AI rules: encode performance requirements as constraints, not suggestions. The AI: generates code that fits within the budget by default.'
string concatenation in Update(): creates a new string object every frame. At 60fps: 60 allocations per second. After 10 seconds: 600 garbage objects. The GC triggers: 5ms pause. The frame: misses its 16ms budget. The player: perceives a hitch. Multiply by every system that allocates in Update: dozens of hitches per minute. AI rule: 'No heap allocations in Update().' The AI: generates allocation-free update code. The GC: never triggers during gameplay. The player: experiences smooth, uninterrupted gameplay.
AI Rules for Game Asset Management
Asset loading patterns: AI rule: 'Use Addressables for all runtime asset loading. Never use Resources.Load (deprecated pattern, not scalable). Preload assets during loading screens — never load synchronously during gameplay. Asset groups: by scene (load/unload with scene transitions). Maximum memory per asset group: 256MB.' The AI: generates async asset loading that prevents hitches. The player: never experiences a freeze when entering a new area.
Memory budgets by platform: AI rule: 'Total memory budget: PC 4GB, console 3GB, mobile 1GB. Texture memory: maximum 50% of total budget. Audio memory: maximum 10% of total budget. Mesh memory: maximum 20% of total budget. Remaining 20%: code, runtime data, system overhead. All assets: compressed (textures use BC7/ASTC, audio uses Vorbis, meshes use Draco).' The AI: generates platform-appropriate asset references. The build: stays within memory budgets for each target platform.
Asset naming and organization: AI rule: 'Asset path pattern: Assets/<Category>/<SubCategory>/<Asset>. Textures: T_<Name>_<Type> (T_Goblin_Diffuse, T_Goblin_Normal). Materials: M_<Name> (M_Goblin). Meshes: SM_<Name> (SM_Goblin). Animations: A_<Name>_<Action> (A_Goblin_Walk). Never use spaces in asset names. Never exceed 3 directory levels.' The AI: generates code that references assets with consistent naming. The artist: finds any asset instantly. The build pipeline: processes assets predictably. AI rule: 'Game asset management is where performance meets organization. A misnamed texture: hard to find. An uncompressed texture: hard to fit in memory. An improperly loaded texture: hard to play at 60fps. AI rules: solve all three simultaneously through consistent naming, compression standards, and async loading patterns.'
Resources.Load('EnemyPrefab') — loads the asset from disk, blocks the main thread until complete. Load time: 50-200ms depending on asset size and platform. During that time: the game freezes. The player: sees a micro-stutter every time a new enemy type appears. AI rule: 'Use Addressables for all runtime asset loading. Preload during loading screens.' With async Addressables: assets load in the background. The player: never sees a loading hitch. The transition from Resources.Load to Addressables: one rule that eliminates an entire category of gameplay freezes.
Game Developer Quick Reference for AI Coding
Quick reference for game developers using AI coding tools.
- Core benefit: AI rules enforce frame budget compliance so AI-generated code runs at 60fps with production entity counts
- ECS: data-only components, stateless systems, EntityFactory for creation — clean architecture by default
- Scene hierarchy: Managers, Environment, Entities, UI — consistent structure across all game scenes
- Events: typed event bus, struct events (no GC), subscribe in OnEnable, unsubscribe in OnDisable
- Update loops: no allocations, no Instantiate/Destroy, no string ops, no LINQ — allocation-free by rule
- Rendering: static batching, GPU instancing, LOD groups, draw call budget — performance-aware code
- Asset loading: Addressables only, async loading, scene-based groups, platform memory budgets
- Naming: consistent prefixes (T_, M_, SM_, A_) for all asset types — findable and pipeline-compatible