Game Dev Field Notes: 12 AI Prompts That Speed Up Prototyping, Balancing and Build Pipelines in Unity, Unreal and Godot

Game Dev Field Notes: 12 AI Prompts That Speed Up Prototyping, Balancing and Build Pipelines in Unity, Unreal and Godot

Every indie team knows the drill: the idea is ready, the deadline is not. You spend three evenings wiring a prototype, two more tuning weapon damage so a boss does not die in four seconds, and another night fighting a Godot export preset that refuses to produce a working build. None of that is game design — it is plumbing. And plumbing is exactly where a well-written prompt saves you hours.

This is not a list of "10 magical AI tricks." It is a working notebook: prompts that map to real tasks in Unity (C#), Unreal Engine (C++ and Blueprints) and Godot (GDScript), with the reasoning behind each one. The examples below assume you already have an LLM of choice — GPT-class, Claude-class, or a local model — and that you treat its output as a first draft, not a final commit.

A quick note on trust: AI writes plausible code, not correct code. Unity's official docs (docs.unity3d.com), Unreal's API reference (dev.epicgames.com/documentation) and Godot's class reference (docs.godotengine.org) remain the source of truth. Use these prompts to move faster, then verify against the engine's own documentation and your profiler.

Why prompts work differently in game dev

Game development prompts differ from generic coding prompts in three ways. First, engines have their own idioms: Unity wants MonoBehaviour lifecycles, Unreal wants UCLASS/UPROPERTY macros, Godot wants node-based composition. A prompt that ignores these idioms produces code that compiles but fights the engine. Second, game logic is stateful and frame-dependent — you must specify tick rates, physics steps and interpolation. Third, balance and feel are subjective: the model can propose numbers, but only playtesting confirms them.

So the structure of a good game dev prompt is: engine + version + context + constraint + output format. Skip any of these and you get generic filler.

Category 1 — Basic: unblocking the daily grind

1. The mechanic prototype skeleton

Task: turn a one-line mechanic idea into a runnable script scaffold.

Prompt:

Act as a Unity 6 gameplay programmer. I need a minimal prototype of a grappling-hook mechanic.
Constraints:
- Unity 6, built-in CharacterController (no Rigidbody)
- C#, single MonoBehaviour named GrappleHook
- Raycast from camera, max distance 20 units, LayerMask "Grappleable"
- On hit: pull player toward point with configurable speed, stop at 2 units
- Include [SerializeField] tuning fields and a public bool IsGrappling for animator
Return only the script plus a 5-line usage note. No explanations of Unity basics.

Example result: the model returns a GrappleHook.cs with Update() handling input, a Physics.Raycast call, and a coroutine or Vector3.MoveTowards pull loop. You attach it to the player, tag a few surfaces, and you have a testable mechanic in under ten minutes. The value is not the code quality — it is that you skipped the blank-file paralysis.

2. GDScript node wiring for Godot

Task: generate idiomatic Godot 4 GDScript, not Python-flavored guesses.

Prompt:

Write Godot 4.3 GDScript for a 2D enemy that patrols between two Marker2D nodes and chases the player when within detection_radius.
Use CharacterBody2D, @export vars, @onready node references, and move_and_slide().
Use signals for "player_detected" and "player_lost".
Show the scene tree I need to build. Keep it under 80 lines.

Example result: a script using @export var speed: float = 120.0, @onready var point_a = $PointA, and a simple state enum. Godot's signal system is a common stumbling block for newcomers, so asking the model to wire signals explicitly is where it earns its keep.

3. Unreal Blueprint-to-C++ translation

Task: move a prototype from Blueprints to C++ without losing behavior.

Prompt:

Here is a description of my Blueprint: [paste node logic].
Convert it to Unreal Engine 5.4 C++ inside an AActor subclass.
Use UPROPERTY(EditAnywhere) for tunables, UFUNCTION(BlueprintCallable) for methods I want to keep calling from Blueprints.
Add comments mapping each C++ block back to the original Blueprint node.

Example result: you get a .h/.cpp pair with proper GENERATED_BODY(), and a mapping table so you can verify nothing was dropped. Epic's own docs recommend keeping Blueprint-callable UFUNCTIONs for designer-facing logic — the prompt encodes that convention.

Category 2 — Advanced: balance, AI behavior, shaders

4. Weapon balance spreadsheet from a design intent

Task: turn a feel-based design goal into starting numbers.

Prompt:

I have 5 weapons in a top-down shooter. Design intent: SMG = high fire rate, low per-shot damage, close range; Sniper = low rate, high damage, long range.
Produce a Markdown table with: name, RPM, damage, DPS, effective range, TTK vs 100 HP target.
Keep DPS roughly equal across weapons (within 15%), vary TTK by role.
Flag any row where the numbers contradict the design intent.

Example result: a table where DPS clusters around a common band but TTK and range differentiate roles. This is a starting point for playtesting, not a final answer — but it prevents the classic mistake of a weapon that is strictly better than every other.

5. State machine for enemy AI

Task: generate a maintainable FSM instead of nested if-statements.

Prompt:

Write a finite state machine for a stealth enemy in Unity 6 C#.
States: Patrol, Investigate, Chase, Search, Return.
Transitions described as: Patrol->Investigate when noise heard; Investigate->Chase when player visible; Chase->Search when line of sight lost for 3s; Search->Return after 8s; Return->Patrol on arrival.
Use an enum + switch, no external libraries. Include a debug gizmo that colors the enemy by state.

Example result: a clean switch-based FSM with a Debug.DrawRay or OnDrawGizmos color indicator. Debugging AI is far easier when state is visible in the scene view.

6. Shader optimization review

Task: find expensive operations in an existing shader.

Prompt:

Review this HLSL/ShaderLab fragment shader for a mobile target (Vulkan, mid-range Android).
List, in a table: operation, why it is expensive, suggested cheaper alternative.
Focus on: texture samples, pow(), branching, derivatives (ddx/ddy), and precision qualifiers.
Do not rewrite the shader; only produce the review table.

Example result: a table flagging things like unnecessary pow(x, 2.0) (replace with x*x), dynamic branching, and missing half precision on mobile. Always confirm findings against Unity's shader performance docs and your target device profiler.

7. Dialogue tree for an NPC

Task: generate branching dialogue that respects character voice.

Prompt:

Write a dialogue tree for a blacksmith NPC in a fantasy RPG.
Voice: gruff, short sentences, no modern slang.
Nodes: greeting, quest offer, quest in-progress, quest complete, idle chat.
Each node: id, speaker line, up to 3 player choices, next node ids.
Output as JSON ready to import into a dialogue system.

Example result: a JSON structure with node ids and transitions — directly importable into tools like Ink-compatible pipelines or custom systems. The voice constraint is what separates usable output from generic fantasy filler.

Category 3 — Expert: builds, pipelines, profiling

8. CI build script for Unity

Task: automate headless builds.

Prompt:

Write a Unity 6 batchmode build script (C#) callable via -executeMethod.
Support targets: Windows64, Android.
Read output path from a command-line argument -buildPath.
Exit with code 1 on failure and log the error.
Also show the exact command-line invocation for Windows.

Example result: a static BuildScript.PerformBuild() method plus a command like Unity.exe -quit -batchmode -projectPath . -executeMethod BuildScript.PerformBuild -buildPath ./builds/win. This is the foundation of any CI pipeline on GitHub Actions or Jenkins.

9. Unreal Automation Tool wrapper

Task: script packaging and cooking.

Prompt:

Show an Unreal Engine 5.4 command line using RunUAT to package a Shipping build for Windows.
Include flags for cooking content, a custom output directory, and a clean build.
Explain each flag in one line.

Example result: a RunUAT BuildCookRun invocation with -build -cook -stage -package -clientconfig=Shipping. Unreal's build tooling is notoriously flag-heavy; a prompt that demands per-flag explanation doubles as documentation.

10. Godot export preset automation

Task: produce consistent exports without manual clicking.

Prompt:

Write a Godot 4.3 export workflow using the headless CLI.
Export a Windows and a Linux build from an existing export_presets.cfg.
Provide the exact terminal commands and note where export templates must be installed.

Example result: commands of the form godot --headless --export-release "Windows Desktop" ./build/game.exe. Godot's export templates are a frequent gotcha — the prompt should remind you they must be downloaded for the matching engine version.

11. Profiler triage prompt

Task: interpret profiler output instead of staring at it.

Prompt:

Here is a Unity Profiler capture summary: [paste top 15 samples with ms].
Identify the 3 most likely bottlenecks, classify each as CPU-bound, GPU-bound or GC-driven, and propose one concrete fix per item.
Rank by expected impact.

Example result: a ranked list, e.g. "1) GC spikes from string concatenation in Update — cache strings; 2) Overdraw from transparent UI — batch; 3) Physics queries every frame — throttle." Always cross-check with the actual profiler before acting.

12. Playtest feedback synthesis

Task: turn raw tester notes into actionable tasks.

Prompt:

Here are 40 lines of raw playtester notes: [paste].
Cluster them into themes, label each theme with frequency (high/medium/low), and output a prioritized backlog of 5-8 concrete tasks.
Separate bugs from design feedback from subjective preference.

Example result: a table with themes like "camera disorientation (high)," "enemy telegraphing unclear (medium)," and a backlog where the top item is a specific, testable change rather than "improve camera."

How to keep AI output honest

Treat every prompt result as a junior developer's first draft: useful, fast, and in need of review. The three engine docs linked at the top are your review checklist.

Final thoughts

Prompts do not replace game design — they remove the friction between an idea and something you can actually play. The twelve above cover the three phases where indie teams lose the most time: prototyping the first mechanic, balancing systems that pretend to be fun, and shipping builds without a manual checklist. Start with one prompt from the category that hurts most this week, adapt it to your project, and keep the ones that survive contact with your compiler. If you want a structured path through AI-assisted development beyond game dev, explore the practical, text-based courses on asibiont.com — and bring your profiler.