How to Prompt AI for Game Code That Works

Step 1: Specify Your Engine, Version, and Language

Every prompt for game code should include your engine name, version, and programming language. This is not optional guidance, it is the foundation of getting correct output. Engine APIs change significantly between major versions, and AI models are trained on code from many different versions. Without explicit version information, the AI defaults to whichever version it has seen most frequently, which may not be the one you are using.

Compare these two prompts. Bad: "Create a physics body for the player." Good: "Create a Havok physics body for the player mesh in Babylon.js 7 using TypeScript, with a capsule collision shape, mass of 80 units, and locked rotation on the X and Z axes." The second prompt eliminates all ambiguity about which physics engine, which version of the API, and which language to use.

For engines that support multiple physics backends, specifying the exact backend matters. Phaser 3 supports both Arcade Physics and Matter.js. Babylon.js supports Havok, Cannon.js, Oimo, and Ammo.js. The API surface differs completely between backends, and a physics prompt without backend specification will likely generate code for the wrong one.

Include your framework and library versions when relevant. If you are using a state management library, a UI framework, or a networking library alongside your engine, mention those too. "Using Colyseus 0.15 for multiplayer state synchronization" or "UI built with Babylon.js GUI 7.0" prevents the AI from suggesting incompatible approaches.

Step 2: Reference Existing Code by Name

The most effective game code prompts point to specific classes, functions, and patterns that already exist in your project. This anchors the AI's output to your actual architecture rather than a generic structure it would invent on its own.

Instead of "add a health system," write "add a HealthComponent that implements the IComponent interface from src/ecs/Component.ts, with a maxHealth property set at construction, a current health value, a takeDamage(amount) method that fires the EventBus 'entity:damaged' event, and a heal(amount) method capped at maxHealth. Register it in the ComponentRegistry using the existing registerComponent() pattern."

This prompt references four specific elements from your codebase: the IComponent interface, the EventBus with its event naming pattern, the ComponentRegistry, and the registerComponent() function. The AI can read or reason about these references to generate code that matches your architecture precisely.

When working with editor-based tools like Cursor or Copilot, having the referenced files open helps the AI access them as context. With agent-based tools like Claude Code, the agent can read the files by name. Either way, specific references dramatically improve code compatibility with your project.

Name your patterns explicitly when they are conventions rather than specific classes. "Follow the factory function pattern we use for all entity creation (see createPlayer in src/entities/factories.ts)" tells the AI to look at an example and replicate the approach. This is more reliable than describing the pattern in words because the AI copies from a real implementation.

Step 3: Describe Behavior with Exact Parameters

Game code is ultimately about behavior, and behavior is defined by numbers. Vague descriptions like "the player should move smoothly" produce default values that never match your intended game feel. Specific parameters produce code that works on the first try or needs only minor adjustment.

For movement: "Accelerate to a max speed of 8 units per second over 0.25 seconds using linear interpolation. Decelerate in 0.15 seconds when input is released. Apply a 0.05 second direction-change slide by blending the old velocity direction with the new one using a lerp factor of 0.7 per frame at 60fps."

For projectiles: "Spawn the projectile at an offset of (0, 0.8, 1.2) in the player's local space. Initial velocity is 25 units per second in the player's forward direction plus 3 units per second upward. Apply gravity at 9.81 units per second squared. The projectile has a 0.15 unit radius sphere collider and is destroyed on first contact with any physics body or after 4 seconds."

For cameras: "Smooth follow camera with a 5-unit distance behind the target and 2 units above. Lerp position at a rate of 4.0 per second (deltaTime scaled). Add a 1-unit dead zone around the target center where the camera does not move. When the target velocity exceeds 6 units per second, offset the camera 1.5 units in the velocity direction for lookahead."

These specific prompts translate directly into code parameters. The AI does not have to guess what "smooth" or "fast" means in your game's context. When you provide exact numbers, the AI implements exactly those numbers, and you can adjust from a working baseline rather than an arbitrary default.

Step 4: Break Complex Features into Ordered Steps

Large game features involve too many interconnected decisions for a single prompt to handle well. An inventory system, a dialogue tree, a crafting mechanic, or a multiplayer lobby each have data models, logic layers, UI components, and integration points that should be built sequentially.

Start with the data model. "Create an InventoryItem interface with id (string), name (string), stackable (boolean), maxStack (number), icon (string path), and a generic metadata object. Create an Inventory class with a 2D grid of slots (6 columns, 4 rows), methods to addItem(item, count), removeItem(slotIndex, count), moveItem(fromSlot, toSlot), and getSlotContents(index). Use TypeScript with strict typing."

After reviewing and approving the data model, prompt for the next layer. "Using the Inventory and InventoryItem types from the previous step, add a serialize() method that returns a JSON-compatible object and a static deserialize(data) factory method. Items should be referenced by ID rather than serialized inline, with an ItemDatabase class that maps IDs to InventoryItem definitions."

Then build the UI layer. "Create an InventoryUI class that renders the Inventory grid using Babylon.js GUI. Each slot shows the item icon image and stack count text. Empty slots show a dark background. Highlight the slot under the mouse cursor. On click, select the slot (show a bright border). On clicking a second slot, call inventory.moveItem() between the two slots."

Each step works with real, reviewed code from the previous step. The AI does not have to guess how you structured the data model when building the UI because it can read the actual implementation. This sequential approach produces dramatically better results than a single "build an inventory system" prompt.

Step 5: Use Domain-Specific Vocabulary

Game development has a rich vocabulary of standard terms that map directly to specific algorithms and techniques. Using these terms in your prompts helps the AI select the correct implementation rather than inventing something from scratch.

For interpolation, use the precise term: "lerp" for linear interpolation, "slerp" for spherical linear interpolation (quaternion rotation), "ease-in" for quadratic acceleration, "ease-out" for quadratic deceleration, "ease-in-out" for combined. Each of these maps to a specific mathematical function that the AI implements correctly when you name it.

For collision detection, specify the exact type: "AABB" for axis-aligned bounding boxes, "OBB" for oriented bounding boxes, "sphere-sphere" for spherical intersection, "ray cast" for line-of-sight checks, "sweep test" for continuous collision detection. The AI knows the algorithm for each type and produces the correct implementation.

For AI and behavior, use the established terms: "behavior tree" with "selector," "sequence," and "decorator" nodes. "Finite state machine" with explicit state names and transitions. "Utility AI" with scoring functions and action selection. "Steering behaviors" with seek, flee, arrive, wander, and obstacle avoidance. Each term maps to a known pattern.

For rendering, specify: "PBR material" for physically-based rendering, "billboard" for camera-facing quads, "instanced rendering" for many copies of the same mesh, "LOD" for level-of-detail switching, "frustum culling" for visibility optimization. The AI generates the engine-specific implementation of each technique.

Avoid vague terms that mean different things in different contexts. "Smooth" could mean lerp, slerp, bezier curves, or spring physics. "Fast" could mean high velocity, low latency, or optimized performance. "Smart AI" could mean behavior trees, GOAP, neural networks, or simple scripts. Be specific about what you mean.

Step 6: Iterate with Specific Corrections

AI-generated game code almost always needs refinement after playtesting. The key to efficient iteration is providing specific, behavioral corrections rather than starting over or giving vague feedback.

After testing, describe what you observe and what you want instead. "The jump feels too floaty at the peak. Add a gravity multiplier of 2.5 when the player's Y velocity is positive and below 1.0 units per second, so the peak-to-descent transition is sharper. Keep the upward portion of the jump unchanged." This tells the AI exactly what to change and what to preserve.

For visual issues, describe the specific problem. "The particle effect is spawning all particles at once instead of spreading them over the burst duration. Change the emission to distribute particles evenly over 0.15 seconds with random angular offsets between 0 and 360 degrees." The correction focuses on the exact aspect that needs fixing.

When something works partially, acknowledge what is correct. "The pathfinding correctly avoids static obstacles but walks through other moving units. Add dynamic obstacle avoidance by checking a 2-unit radius around the path ahead and recalculating when a collision is predicted within the next 0.5 seconds." This preserves the working pathfinding logic and adds the missing behavior.

Keep your feedback focused on behavior and parameters rather than implementation details. Let the AI decide how to restructure the code to achieve the behavioral change. If you dictate the exact code changes, you lose the AI's ability to see better solutions. If you dictate the behavior, the AI produces code that achieves it, possibly through an approach you would not have considered.