Prompting for Game Development

TL;DR: AI does not build games. It helps with bounded pieces — dialogue and item text, level-design brainstorming, shader or math explanations, boilerplate for a named engine and version, and debugging one system at a time. Generated code compiles more often than it's correct, and generated art is never automatically cleared for commercial use.

What Can AI Actually Do for Game Development?

Start with what it cannot do, because that's where most wasted prompts come from. A model has never played your game. It cannot feel whether a jump arc is satisfying, whether a difficulty curve is fair, or whether a boss fight is fun. It has no access to your build, your frame rate, or your save file. Every claim that an AI tool can "build your game" from a single prompt is describing a demo, not a shippable product.

What it does well is narrower and genuinely useful: producing a first draft of something you'll edit, explaining an unfamiliar system, or writing boilerplate for a pattern you already understand well enough to check. Treat it the way you'd treat a fast, occasionally wrong junior collaborator who has read a huge amount of documentation but has never once opened your project. If terms like structure and specificity are new to you, our beginner's guide to prompt engineering covers the fundamentals this post assumes.

There's a scale problem underneath all of this that's easy to miss. A short script or a single dialogue tree fits comfortably inside whatever a model can hold in context at once, so the model reasons about it the way you do: as a whole, all at once. A real game project doesn't fit that way. Your player controller, your save system, your inventory, and your UI all reference each other, and a model that hasn't seen all of them will confidently invent a method name that doesn't exist in your codebase, or assume a class shape that matches a tutorial project instead of yours. That's not a bug in the model. It's what happens when you ask something to reason about a system it can only see a slice of. The fix isn't a bigger prompt. It's picking a slice small enough that pasting in the relevant files is actually feasible, which is most of why every example in this post is scoped to one script, one system, or one error at a time.

It's also worth being blunt about what "AI built this game" demos actually are. Almost every viral clip of a model "building a game from one prompt" is a tiny genre skeleton: a paddle and a ball, a grid of tiles, a character that walks and jumps, built in an engine or framework chosen specifically because that skeleton is common enough to be well-represented in training data. That's a real, if narrow, capability, and it's a fine way to scaffold a game jam prototype over a weekend. It is not evidence that the same process scales to a game with your specific mechanics, your specific art direction, or more than a few hundred lines of interconnected state.

Dialogue, Item Text, and Lore

This is the safest category, because the failure mode is cheap. A bad line of NPC dialogue costs you a rewrite, not a crash.

The prompt that works is specific about voice, constraint, and context, not just topic:

Write 6 lines of barks (short combat reactions) for a grizzled mercenary
captain NPC. Tone: dry, unimpressed, never panicked. Each line under
12 words, no exclamation points, no modern slang. Context: the player
just landed a critical hit on a much larger enemy.

Vague prompts like "write some cool dialogue for my fantasy game" produce generic fantasy filler that reads the same in every project that asks for it. Constraint is what makes generated dialogue sound like your game instead of a template.

Level-Design Brainstorming: Options, Not Decisions

AI is a fast way to generate a wide spread of layout ideas, encounter pacing options, or puzzle mechanics you then filter with your own judgment. It is a bad way to have the level actually designed for you, because it has no sense of your game's difficulty curve or your engine's specific constraints.

A useful prompt asks for variety and reasoning, not a final answer:

Suggest 8 different pacing structures for a 5-minute stealth level in a
top-down game. For each, name the core tension (time pressure, resource
scarcity, patrol density, etc.) in one line. I'll pick two to prototype.

Then you build two of the eight and see which one actually plays well. The model's job stopped at generating options. If you're not sure how to even phrase a request for a system you don't fully understand yet, this guide to prompting for a task you don't understand yet walks through that specific problem.

The same "options, not decisions" discipline applies to enemy encounter design and economy balancing, which are the two other places solo and small-team developers most often reach for a brainstorming assist. Asking for eight enemy archetypes with one distinguishing mechanic each is a good use of a prompt. Asking a model to balance your entire in-game economy — drop rates, currency sinks, progression curves — from a text description is asking it to guess at numbers it has no way to playtest, which is exactly the kind of decision this whole post argues you should keep for yourself.

Boilerplate for a Known Engine: Name the Version, Every Time

This is where naming the engine and version stops being a formality and starts being the difference between code that compiles against your project and code that doesn't. Unity, Godot, and Unreal Engine differ sharply from each other, and each one changes meaningfully between major versions. Current releases as of September 2026: Unity 6 (the 6000.x series, currently at 6.6, per unity.com), Godot 4.8 (per godotengine.org), and Unreal Engine 5.8 (per Epic's own documentation site).

Unity 6, C# — a simple patrol script. Ask for exactly this pattern and you'll get code that compiles against any recent Unity project, because MonoBehaviour, Transform, and Vector3.MoveTowards are stable, long-standing parts of the API:

using UnityEngine;

public class EnemyPatrol : MonoBehaviour
{
    [SerializeField] private float speed = 2f;
    [SerializeField] private Transform[] waypoints;
    private int currentWaypoint = 0;

    void Update()
    {
        if (waypoints.Length == 0) return;
        Transform target = waypoints[currentWaypoint];
        transform.position = Vector3.MoveTowards(
            transform.position, target.position, speed * Time.deltaTime);

        if (Vector3.Distance(transform.position, target.position) < 0.1f)
        {
            currentWaypoint = (currentWaypoint + 1) % waypoints.Length;
        }
    }
}

Godot 4.8, GDScript — a platformer movement skeleton. This is the exact case where version matters most. Godot 4 renamed KinematicBody2D to CharacterBody2D and changed move_and_slide() from a method that took a velocity argument to one that reads a velocity property and takes none — confirmed against Godot's own CharacterBody2D class reference. A prompt that doesn't say "Godot 4" risks getting Godot 3 code back:

extends CharacterBody2D

@export var speed := 300.0
@export var jump_velocity := -400.0
var gravity: float = ProjectSettings.get_setting("physics/2d/default_gravity")

func _physics_process(delta: float) -> void:
    if not is_on_floor():
        velocity.y += gravity * delta
    if Input.is_action_just_pressed("jump") and is_on_floor():
        velocity.y = jump_velocity

    var direction := Input.get_axis("move_left", "move_right")
    velocity.x = direction * speed
    move_and_slide()

Unreal Engine 5.8, C++ — a pickup actor header. UCLASS, GENERATED_BODY, and UPROPERTY are part of Unreal's reflection system and have been stable across UE4 and UE5, so this shape holds even as the engine's feature set moves forward:

UCLASS()
class MYGAME_API APickupItem : public AActor
{
    GENERATED_BODY()

public:
    APickupItem();

    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Pickup")
    int32 ScoreValue = 10;

protected:
    virtual void BeginPlay() override;
};

None of these three snippets is a system. Each is a starting point you drop into a project you already understand, then test. Notice, too, that all three are deliberately small — a single class, a single node script, a single header. That's the actual skill in prompting for boilerplate: not phrasing, but scoping the request down to something you can read in full and verify against the engine's real API in under a minute. A prompt that asks for "the whole inventory system" produces five hundred lines you can't realistically audit before you paste them in; a prompt that asks for "the function that removes one stack of an item and updates the UI" produces something you can.

The version-naming habit pays off hardest with Godot specifically, because so much AI training data and so many older tutorials online are still written against Godot 3, which had a genuinely different node hierarchy and a different physics API. Unity's changes between versions are usually additive: new APIs arrive, and old ones get deprecated with warnings rather than removed outright, so a script written for an older Unity version is more likely to still compile, just with a deprecation notice. Unreal's C++ reflection macros are the most stable of the three across major versions, but its Blueprint visual scripting has no text representation at all, so a model can describe a Blueprint graph in prose but cannot hand you paste-able Blueprint code the way it can for C++ or GDScript. If you're working in Blueprint, treat AI output as a description of nodes to wire up yourself, not a file to import.

Shader and Math Explanations

Asking an LLM to explain an unfamiliar shader function, a quaternion rotation, or why your interpolation looks wrong is one of the highest-value, lowest-risk uses in this whole list, because the output is a mental model you verify against your own engine's documentation, not code you paste in unread.

Explain what this HLSL line is doing and why, step by step, assuming I
understand basic vector math but not shader-specific conventions:

float fresnel = pow(1.0 - saturate(dot(normalize(viewDir), normal)), power);

The engine and version still matter here, because shading languages and built-in functions differ between Unity's HLSL variant, Godot's shader language, and Unreal's material graph. Say which one you're in.

Debugging One System at a Time

The single most useful debugging prompt is boring: paste the actual error or console output verbatim, name the engine and version, and describe only the one system involved.

Godot 4.8, GDScript. This script throws
"Invalid get index 'velocity' (on base: 'null instance')" on line 12.
Here is the full script: [paste script]. What's the most likely cause,
and what would you check first?

A vague "why is my game broken" prompt gets a vague, generic answer. A specific error message plus the relevant script gets a specific, checkable hypothesis. For debugging prompts outside game code specifically, see 30 AI prompts for debugging, error to root cause; if the code in question is a pull request rather than a live bug, our guide to prompting for a genuinely useful code review covers the review side of the same discipline.

Generated Assets: Don't Assume Commercial Rights

If you use an AI image, audio, or 3D generator for game assets, the commercial-use question is answered by that specific tool's terms of service and your specific plan, not by any general rule about AI-generated content. Some tools license commercial use on paid tiers only; some restrict it by revenue or by asset type; a few restrict it outright regardless of plan. Read the terms page for the exact tool and tier you're using before you ship a game containing what it generated — this is not a detail to assume your way past.

Visual Style Without Imitating a Named Artist

When prompting an image tool for concept art, don't reach for "in the style of [a specific living artist or studio]." Describe the visual qualities you actually want instead: a limited, desaturated palette; heavy black outlines; soft ambient occlusion; a particular silhouette shape language. It's a real grey area to reproduce a specific person's or studio's recognizable style by name, and a qualities-based prompt is usually more specific and more useful anyway, because it forces you to articulate what you want rather than pointing at a name and hoping the model interprets it the way you do.

A Reusable Prompt Template for Game Dev Tasks

Engine + version: [e.g. Godot 4.8]
Task type: [dialogue / level brainstorm / boilerplate / shader explanation / debug]
Scope: [the ONE system or file this touches — not "my game"]
Context: [relevant existing code, error message, or design constraint]
Constraint: [tone, length, performance, or style limits that matter]

Filling in all five lines before you send a prompt does most of the work of getting a usable answer back. The version line prevents the Unity-pre-6, Godot-3-vs-4, and Blueprint-vs-C++ mismatches covered above. The scope line is what keeps a request bounded enough that you can actually review what comes back, which is the whole discipline this post is arguing for: AI drafts one piece, you decide whether it's right, and the game only ships once you've played it.