12 Prompts That Build Your Game's Vertical Slice Before Your Coffee Gets Cold: A Unity & Godot Pipeline for Solo Devs

12 Prompts That Build Your Game's Vertical Slice Before Your Coffee Gets Cold: A Unity & Godot Pipeline for Solo Devs

Every solo developer knows the trap. You spend three months polishing one level, then realize the core loop isn't fun. According to a widely cited 2023 report from the Game Developers Conference (GDC) State of the Industry survey, a significant share of indie studios operate with teams of five or fewer people — and many solo devs report that scope creep is their single biggest risk. The vertical slice exists precisely to kill that risk: a short, polished, playable fragment that proves the game works before you commit months to it.

The problem is that a vertical slice demands skills most solo devs don't have in equal measure: game design, level design, economy balancing, dialogue writing, technical writing, and build optimization. You can't hire all those people on a ramen budget. But in 2026, you can prompt for them.

This article is a working pipeline of 12 prompts, tested against Unity 6 (LTS) and Godot 4.4. Each prompt targets a specific bottleneck in the vertical slice pipeline — from a one-page GDD to a Steam page draft. I'll show you the actual input, the expected output, and — critically — the moment in development when you should fire that prompt. No theory, just the workflow.

Why Prompts Beat Hiring (and Where They Don't)

Let's be honest about the limits. A language model will not produce a shippable, bug-free level. It will not replace your taste. What it does extremely well is compress the drafting phase: the first 80% of any document, spreadsheet, or script. You still own the final 20% — the part that makes it yours.

Think of these prompts as a junior team that works at 3 a.m., never argues, and costs nothing per revision. Your job shifts from producing to editing, which is a fundamentally faster mode of work.

A note on tools: These prompts work in any capable LLM chat interface. I've used them in ASI Biont's AI agent and in standard chat assistants. The prompts are model-agnostic; the code is engine-specific.

The Pipeline at a Glance

Phase 1: Concept & Design

1. The One-Page GDD Generator

Task: Turn a vague idea ("a roguelike about a lighthouse keeper") into a structured one-page Game Design Document with pillars, core loop, and scope boundaries.

When to use it: Day one. Before you open the engine.

Prompt:

You are a senior game designer who has shipped three commercial roguelikes.
I have a one-sentence concept: "[YOUR CONCEPT]".

Write a one-page GDD with these exact sections:
1. Elevator pitch (max 30 words)
2. Three design pillars (each one sentence, each falsifiable)
3. Core loop (list the 4-6 verbs the player repeats)
4. Session length target (minutes) and why
5. Explicit NON-goals (what this game is NOT — list 4)
6. Vertical slice definition: what must be true for a slice to be "done"

Keep it under 400 words. Be opinionated. Do not hedge with "could" or "might".

Example result (excerpt for "lighthouse keeper roguelike"):

• Pillars: (1) Darkness is a resource you spend. (2) Every death changes the map permanently. (3) No combat — tension comes from resource routing.
• Core loop: Scout → Route light → Trade → Reinforce → Survive night.
• Non-goals: No crafting trees, no NPC romance, no multiplayer, no skill trees.
• Slice done when: Player can survive three nights, die once, and see the map mutate on respawn.

Why it works: The "falsifiable pillars" constraint forces specificity. A pillar like "fun combat" is useless; "darkness is a resource you spend" is testable.

2. The Lore Bible in 500 Words

Task: Generate a compact world bible that gives your game consistency without a 40-page document nobody reads.

When to use it: After the GDD, before writing any dialogue. It prevents lore contradictions later.

Prompt:

Based on this GDD: [PASTE GDD]

Write a 500-word world bible with:
- The central conflict (one paragraph)
- Three factions, each with: name, one-line belief, what they want from the player
- The rules of the world's magic/technology (3 hard rules, no exceptions)
- A timeline of 4 historical events that explain the current state

Tone: [e.g., melancholic maritime gothic].
Do not invent proper nouns that sound like existing franchises.

Example result: Factions emerge as "The Keepers" (light is a debt), "The Wreckers" (light is a lie), and "The Tideborn" (light must be sold). The three hard rules become constraints you can enforce in code later — e.g., "Light cannot be created, only moved."

Pro tip: Paste this bible back into every subsequent prompt. It becomes your system context and keeps generation consistent.

Phase 2: Systems & Balance

3. Economy Balance Spreadsheet

Task: Produce a starting economy table you can paste directly into a Google Sheet or ScriptableObject.

When to use it: Once you know your resources. Before you tune anything by hand.

Prompt:

I'm balancing an economy for a game with these resources: [LIST, e.g., Oil, Coin, Hull].
Session length: [X] minutes. Target difficulty curve: [e.g., ramp then plateau].

Produce a Markdown table with columns:

| Item | Cost (Coin) | Value (Oil) | Unlock Day | Rationale |

Rules:
- Row count: exactly 12 items.
- The cheapest item must be affordable in the first 60 seconds.
- The most expensive must require roughly 3 full sessions of saving.
- Every rationale must cite a specific player behavior, not a feeling.

Example result:

Why it works: The "rationale must cite behavior" rule turns a generic price list into a design document.

4. Progression Curve Calculator

Task: Generate the math for XP, difficulty, or loot tables so you don't discover a broken curve at week six.

When to use it: As soon as you have a leveling or difficulty system.

Prompt:

Design an XP curve for a game with a 6-hour campaign and 20 levels.
Requirements:
- Level 2 reached in under 5 minutes.
- Level cap reached at ~5.5 hours for an average player.
- Each level should feel 10-15% longer than the previous.

Output:
1. A formula (explain the exponent).
2. A table of XP-to-next for levels 1-20.
3. A C# method `int XpForLevel(int level)` implementing it.
4. A GDScript method `func xp_for_level(level: int) -> int` implementing it.

Example result (C#):

public static int XpForLevel(int level)
{
    // Base 100, exponent 1.35 tuned so level 20 ~= 5.5h at 60 XP/min
    return (int)(100 * Mathf.Pow(level, 1.35f));
}

Example result (GDScript):

func xp_for_level(level: int) -> int:
    return int(100 * pow(level, 1.35))

Why it works: Asking for the formula and the implementation forces the model to check its own math against the time constraints.

Phase 3: Content & Levels

5. Procedural Level Layout (Grid Blueprint)

Task: Get a text-based grid blueprint for a level before you touch the editor.

When to use it: When you're stuck on layout. Faster than dragging tiles.

Prompt:

Design a level for a top-down stealth roguelike. Grid: 16x12 tiles.
Symbols: # wall, . floor, S spawn, E exit, G guard, L loot, D door.
Constraints:
- Exit must be at least 12 tiles (Manhattan) from spawn.
- At least 2 alternate routes.
- At least 3 loot rooms, one of which is a dead end.
- No guard line-of-sight covers a loot room's only entrance.

Output the grid as a code block, then list every constraint and whether it's satisfied.

Example result: The model returns a 16x12 ASCII grid and a checklist verifying each constraint. You paste it into a script that instantiates tiles at runtime.

Why it works: Text-first layout lets you iterate 20 designs in the time it takes to open the tile palette once.

6. Unity Tilemap → JSON Converter

Task: Turn the grid blueprint into data your Unity Tilemap can consume.

When to use it: Immediately after prompt #5.

Prompt:

Convert this ASCII grid into a JSON array of tile objects for Unity.
Schema: [{"x": int, "y": int, "type": "wall"

|"floor"|"spawn"|"exit"|"guard"|"loot"|"door"}]
Then write a C# MonoBehaviour `LevelLoader` that reads the JSON (via TextAsset)
and instantiates a prefab from an array indexed by type.
Use Tilemap.SetTile with a TileBase array. Include bounds checking.

Example result (C#):

using UnityEngine;
using UnityEngine.Tilemaps;
using System;

[Serializable] public class TileData { public int x; public int y; public string type; }
[Serializable] public class LevelData { public TileData[] tiles; }

public class LevelLoader : MonoBehaviour
{
    public TextAsset levelJson;
    public Tilemap tilemap;
    public TileBase[] tilesByType; // 0=wall,1=floor...
    static readonly string[] Order = {"wall","floor","spawn","exit","guard","loot","door"};

    void Start()
    {
        var data = JsonUtility.FromJson<LevelData>(levelJson.text);
        foreach (var t in data.tiles)
        {
            int idx = Array.IndexOf(Order, t.type);
            if (idx < 0) continue;
            tilemap.SetTile(new Vector3Int(t.x, t.y, 0), tilesByType[idx]);
        }
    }
}

Why it works: JsonUtility requires a wrapper object (LevelData) — a common gotcha the model handles correctly if you name the schema.

7. Godot TileMapLayer from the Same Grid

Task: The Godot 4.4 equivalent, using TileMapLayer (introduced to replace the deprecated TileMap node).

When to use it: If you're building in Godot instead of Unity.

Prompt:

Write a GDScript script for Godot 4.4 that loads a JSON level file
and populates a TileMapLayer node.
Use FileAccess and JSON.parse_string.
Map type strings to tile atlas coordinates via a Dictionary.
Handle missing files gracefully with push_error.

Example result (GDScript):

extends TileMapLayer

const TYPE_TO_ATLAS := {
    "wall": Vector2i(0, 0),
    "floor": Vector2i(1, 0),
    "spawn": Vector2i(2, 0),
    "exit": Vector2i(3, 0),
}

func load_level(path: String) -> void:
    if not FileAccess.file_exists(path):
        push_error("Level not found: " + path)
        return
    var f := FileAccess.open(path, FileAccess.READ)
    var data = JSON.parse_string(f.get_as_text())
    if data == null:
        push_error("Invalid JSON")
        return
    for tile in data["tiles"]:
        var atlas = TYPE_TO_ATLAS.get(tile["type"], null)
        if atlas == null: continue
        set_cell(Vector2i(tile["x"], tile["y"]), 0, atlas)

Why it works: TileMapLayer.set_cell has a specific signature (coords, source_id, atlas_coords). The prompt names the node type so the model uses the current API, not the deprecated one.

8. Branching Dialogue & Quests

Task: Generate a branching dialogue tree with a quest hook, in a format you can parse.

When to use it: When your slice needs to prove the narrative system works.

Prompt:

Write a branching dialogue for an NPC named [NAME] in this world: [PASTE LORE BIBLE].

Output as JSON nodes:
{"nodes": [{"id": "n1", "text": "...", "choices": [{"text": "...", "next": "n2", "effect": "quest_start"}]}]}

Requirements:
- 8-12 nodes total.
- At least 3 endings: one starts a quest, one refuses, one reveals a secret.
- Every choice must have a distinct consequence tag.
- Match the tone: [TONE].

Example result: A JSON tree where the "reveal a secret" ending sets effect: "flag_lighthouse_truth" — a flag your quest system can read later.

Why it works: JSON output means you can load it into a dialogue graph tool (e.g., Ink-compatible or a custom node system) without retyping.

Phase 4: Code & Debugging

9. The C# / GDScript Debugger

Task: Paste an error and get a fix with an explanation, not a guess.

When to use it: Every time the console turns red.

Prompt:

I'm getting this error in [Unity 6 / Godot 4.4]:
[PASTE FULL ERROR + STACK TRACE]

Here is the relevant script:
[PASTE SCRIPT]

Diagnose the root cause. Then give me:
1. The minimal fix (diff-style if possible).
2. Why the error happened (one paragraph, for learning).
3. One related pitfall to avoid next time.
Do not rewrite the whole script unless necessary.

Example result: For a NullReferenceException on a GetComponent<Tilemap>() call, the model identifies that the component is on a child object and suggests GetComponentInChildren<Tilemap>(), plus warns about Awake vs Start ordering.

Why it works: The "minimal fix" constraint stops the model from dumping a 200-line refactor you didn't ask for.

10. Build Optimization for Mobile

Task: Get a concrete checklist and code changes to hit a mobile framerate target.

When to use it: Before your first mobile test build, not after.

Prompt:

My Unity 6 project targets Android, minimum spec: [e.g., Snapdragon 660, 4GB RAM].
Current issues: [e.g., frame drops to 25fps, 300MB build].

Give me:
1. A prioritized checklist of the 8 highest-impact optimizations for this spec.
2. A C# example of object pooling for my [PROJECTILE/PARTICLE] prefab.
3. Which Unity Profiler modules to check first and what number is "bad".
Be specific to mobile — no desktop advice.

Example result: The model recommends Application.targetFrameRate = 60, QualitySettings texture downscaling, and provides a ObjectPool<T> implementation. It correctly points to the Memory Profiler for GC allocations.

Why it works: Naming the GPU spec and the exact symptom prevents generic advice.

Phase 5: Shipping

11. Steam Page Copy (Store Description)

Task: Draft your Steam store page: short description, long description, and tags.

When to use it: Two weeks before your slice demo, so you can collect wishlists early.

Prompt:

Write Steam store copy for this game: [PASTE GDD + LORE].

Output:
1. Short description (max 300 characters, no marketing fluff, lead with the hook).
2. Long description in Steam BBCode (use [h2], [b], [list]).
3. 15 Steam tags, ordered by relevance.
4. Five capsule art descriptions (text only) for an artist.

Tone: [TONE]. Avoid the words "epic", "revolutionary", "immersive".

Example result: Short description becomes: "A lighthouse roguelike where light is a currency and the map remembers your failures. Route, trade, survive the dark." Tags include Roguelike, Resource Management, Atmospheric, Singleplayer.

Why it works: Banning buzzwords is the fastest way to force specific, honest copy.

12. The Vertical Slice Playtest Script

Task: A structured playtest questionnaire that tells you whether your slice actually works.

When to use it: The day your slice is playable. Run it on 5+ strangers.

Prompt:

Create a playtest script for a [GENRE] vertical slice lasting [X] minutes.

Output:
1. A 5-question pre-test survey (player background).
2. A 10-question post-test survey focused on the core loop verbs.
3. Three "think-aloud" prompts to say during play.
4. A scoring rubric: what score means "slice is validated" vs "loop is broken".
5. Two metrics to log automatically (not survey-based).

Avoid leading questions. Every question must be answerable on a 1-5 scale or with one sentence.

Example result: The rubric defines "validated" as: 4/5 players can describe the core loop unprompted, and 3/5 replay voluntarily. Metrics: time-to-first-death, session length.

Why it works: The "no leading questions" constraint is the difference between real data and flattery.

Putting It Together: A One-Week Slice Sprint

Here's how the 12 prompts map to a realistic seven-day schedule for one person:

This isn't a promise that your game will be fun — no prompt can do that. It's a promise that the scaffolding stops being the bottleneck. The three months you used to spend rewriting one level now go into the part only you can do: making it feel good.

The prompts above are starting points, not gospel. Tune them, break them, paste your lore bible into every one. If you want to go deeper into AI-assisted development workflows — from prompt engineering to agent-based pipelines — the ASI Biont course catalog has structured, text-based tracks that go beyond copy-paste prompts. But honestly? Start with prompt #1 today. Your coffee is getting cold, and your slice isn't going to build itself.

Engines referenced: Unity 6 LTS (Unity Technologies official documentation), Godot 4.4 (Godot Engine official docs, TileMapLayer class reference). Industry context: GDC State of the Industry surveys (annual). All code examples are illustrative and should be tested in your own project.