The old prototyping pipeline was measured in weeks. Concept art, placeholder models, level blockouts, basic gameplay code, integration, testing. Two weeks minimum for a bare-bones vertical slice, and that's if you know the engine well and don't hit any surprises.

The new pipeline is measured in hours. Describe what you want. AI generates it. You iterate on what it produces. Playtest the same day.

This isn't science fiction. It's also not magic. It's a specific workflow using specific tools, and it has specific limitations. This post walks through the entire pipeline from "I have a game idea" to "I can hand a controller to someone and watch them play" — honestly, including the parts where AI falls short and you have to step in.

The Prototyping Mindset Shift

Before we get into tools and workflows, let's reset expectations. A prototype is not a game. A prototype answers a question: "Is this fun?" "Does this mechanic work?" "Does this concept have legs?"

The goal of rapid AI prototyping isn't to skip development. It's to fail faster. The faster you discover that your tower defense/dating sim hybrid doesn't work, the less time you waste building it. The faster you discover that your core loop is genuinely addictive, the sooner you can commit to doing it right.

Traditional prototype timeline:

AI-assisted prototype timeline:

The required skill shifts from "can you build it?" to "can you describe what you want and evaluate what you get?" That's a different skill. It's not easier — it's different.

The Full Pipeline

Here's the full pipeline, step by step. We'll reference real tools at each stage, then walk through a complete example.

Step 1: Describe Your Game Concept

This is the part most people rush past, and it's the part that matters most. AI tools are only as good as the prompt. Vague concepts produce vague results.

Bad prompt: "Make a dungeon game."

Good prompt: "Top-down dungeon crawler. Grid-based movement on 1-meter tiles. Single floor, 30x30 room with corridors connecting 5-7 rooms of varying sizes. Rooms contain either enemies, treasure, or traps. Player has melee attack with 1-tile range. 3 enemy types: skeleton (melee), archer (ranged 5-tile), boss (large, slow, high damage). Health pickups spawn in treasure rooms. Win condition: defeat the boss in the final room. Camera: top-down, 45-degree angle, follows player."

The good prompt isn't more creative. It's more specific. Specificity is the key skill in AI-assisted prototyping. You need to know what you want before the AI can help you build it, which means you need to understand game design fundamentals even if you never write a line of code.

Step 2: AI Level Generation via MCP

With your concept described, the next step is generating the level layout inside your engine. This is where MCP (Model Context Protocol) tools transform the workflow.

MCP lets AI assistants like Claude directly control game engines and 3D tools through structured tool calls. Instead of the AI writing code that you copy-paste and run, the AI executes operations in your running editor in real time.

For Unreal Engine, the Unreal MCP Server provides 305 tools across 42+ categories — everything from spawning actors and configuring materials to setting up gameplay systems and running editor utilities. For Godot, the Godot MCP Server offers 131 tools covering scene management, node creation, scripting, and resource handling.

What the AI actually does during level generation:

1. Creates the floor grid (spawns and scales floor tiles or a single floor mesh)
2. Generates room boundaries using wall actors
3. Creates corridors connecting rooms
4. Places door triggers between rooms
5. Sets spawn points for enemies, treasure, and traps per room
6. Positions the player start location
7. Places the camera and configures its settings

This happens through a conversation. You say "Create a 30x30 dungeon with 6 rooms connected by corridors." The AI plans the layout and executes the tool calls to build it in your running editor. You see it appear in real time. You say "Make room 3 bigger" or "Move the boss room to the far corner." The AI adjusts.

The AI is not generating room layouts from a PCG algorithm (though it could trigger one if your project has procedural generation systems). It's placing actors in the editor based on the layout it designed from your description. Think of it as a level designer who works very fast but needs clear direction.

Step 3: AI Asset Creation

A prototype needs visual elements, even if they're rough. The AI pipeline handles this at several fidelity levels.

Geometric primitives (immediate, via MCP). For the fastest possible prototype, the AI places cubes, spheres, and cylinders as stand-ins. A cube is an enemy. A sphere is a health pickup. A tall thin cube is a pillar. This looks terrible and plays fine. Most famous games were prototyped with worse.

AI-generated 3D models (minutes, via Blender MCP). The Blender MCP Server connects Claude to Blender with 212 tools for modeling, materials, modifiers, and export. You can describe assets ("low-poly skeleton warrior, T-pose, game-ready topology") and the AI creates them through Blender's modeling tools — not generative AI image-to-3D, but actual modeling operations: extrude, subdivide, sculpt, rig.

The results are functional, not beautiful. They look like a first-pass blockout from a junior artist. For a prototype, that's exactly what you need. They have correct topology for animation, proper UVs for texturing later, and sensible scale for your game world.

AI-generated textures and materials. Texture generation through AI image tools has matured significantly. For prototypes, even basic colored materials applied through MCP tools (setting base color, roughness, metallic values per material instance) give you enough visual distinction to playtest. Red enemies, blue pickups, gray walls. Readability over beauty.

Step 4: AI Gameplay System Setup

This is where the pipeline gets interesting and where the limitations become most apparent.

Using pre-built systems. The fastest path to gameplay is using existing systems rather than generating them from scratch. The Blueprint Template Library includes 15 gameplay systems with networking support — health, inventory, quest tracking, save/load, ability systems, and more. Through MCP, the AI can configure these systems on your actors: set health values, assign inventory contents, configure damage responses.

This is the difference between "AI writes gameplay code" (unreliable) and "AI configures existing gameplay systems" (reliable). The systems already work. The AI just sets the parameters.

Setting up interactions via MCP. Beyond pre-built systems, MCP tools can:

• Create Blueprint component hierarchies on actors
• Set collision profiles and overlap events
• Configure navigation meshes for AI pathing
• Set up basic AI behavior (patrol points, aggro ranges, attack patterns)
• Create trigger volumes for room transitions, trap activation, pickups
• Wire up UI elements to game state (health bars, inventory displays)

What AI can actually generate for gameplay:

• Simple state machines (patrol/chase/attack)
• Trigger-based events (enter zone, pick up item, kill enemy)
• Spawn and despawn logic
• Basic scoring and win/lose conditions
• Camera configuration and following behavior

What AI struggles with:

• Complex ability interactions
• Nuanced combat feel (hitboxes, timing windows, animation canceling)
• Physics-based mechanics that require careful tuning
• Anything that depends on "feel" rather than logic

The pattern is consistent: AI handles structure well, feel poorly. It can set up the skeleton of gameplay. It can't make combat satisfying without human iteration.

Step 5: Human Iteration

Here's the honest truth about AI prototyping: the AI gets you to roughly 60% of a playable prototype, fast. The remaining 40% is human work, and it's the 40% that determines whether the prototype actually answers your design question.

What the AI typically gets wrong that you'll need to fix:

• Room sizes that look right in the editor but feel wrong when you move through them at player speed
• Enemy placement that's technically valid but creates unfun encounters (three archers in a narrow corridor)
• Movement speed that's either too sluggish or too twitchy
• Camera distance that's either too close (can't see threats) or too far (no intimacy)
• Timing on traps, respawns, and cooldowns that needs feel-based adjustment

This iteration phase is where your game design sense matters more than any tool. The AI built the stage. You're directing the play.

Complete Walkthrough: Dungeon Crawler in One Session

Let's build the prototype we described earlier. This is a real workflow using real tools, not a theoretical exercise.

Hour 0-0.5: Setup and Concept

Prerequisites: You need Claude with MCP tool access, a running instance of Unreal Engine (or Godot) with the appropriate MCP server plugin installed, and optionally Blender with the Blender MCP Server for asset creation.

The concept document (you write this, the AI doesn't):

Game: "Crypt Descent" - Top-down dungeon crawler prototype
Purpose: Test whether grid-based movement with real-time combat is fun
Core loop: Enter room → fight/loot → proceed → boss fight

Level: Single floor, ~30x30 unit grid
Rooms: 6 rooms connected by corridors
- 2 combat rooms (skeletons + archers)
- 1 trap room (floor spikes on timer)
- 1 treasure room (health potion + weapon upgrade)
- 1 empty room (rest/exploration)
- 1 boss room (single large enemy)

Player: Capsule mesh, 1 unit/sec movement, melee attack (1 tile range, 0.5s cooldown)
Camera: Top-down, 60 degrees, 15 units above player, follows with slight lag

Enemies:
- Skeleton: Melee, 1 tile range, patrols, 30 HP, 10 damage
- Archer: Ranged, 5 tile range, stationary, 20 HP, 15 damage
- Boss: Melee, 2 tile range, slow, 100 HP, 25 damage

Items: Health potion (+50 HP), Damage boost (+10 damage, permanent)

Win: Kill boss
Lose: Player HP reaches 0

This concept document is your specification. The AI will reference it throughout the session.

Hour 0.5-1.5: Level Construction

You open Claude and start the conversation with your concept document. Then you begin instructing the level build.

Conversation flow (simplified):

You: "Using the Unreal MCP tools, create the dungeon floor. Start with a 30x30 plane at world origin for the floor, then create 6 rooms with walls. Rooms should be: Room 1 (spawn, 5x5) in the southwest corner, Room 2 (combat, 8x6) connected by corridor to the east, Room 3 (trap, 6x6) north of Room 2, Room 4 (treasure, 4x4) east of Room 3, Room 5 (combat, 7x7) north of Room 4, Room 6 (boss, 10x10) at the northeast corner connected to Room 5."

The AI then executes a sequence of MCP tool calls:

• Creates the floor plane, scales it to 30x30
• Creates wall segments for each room boundary
• Creates corridor connections (removing wall segments at connection points)
• Organizes everything into folders in the outliner

You can watch this happen in the editor. It takes 5-10 minutes of AI execution time.

You: "The corridor between Room 2 and Room 3 is too narrow. Make it 3 tiles wide instead of 1."

The AI adjusts the wall positions. This kind of iterative adjustment is where MCP-based workflows shine — you're art-directing in real time, not waiting for re-exports or rebuilds.

You: "Add a PlayerStart in Room 1. Add point lights in each room — warm orange, intensity 3000, one per room centered on the ceiling."

More MCP tool calls. The level takes shape.

Hour 1.5-2.5: Asset Creation

For the fastest path, you skip Blender entirely and use primitives:

You: "Place placeholder enemies in the combat rooms. In Room 2, put 3 skeleton placeholders (red capsules, 0.8 scale) and 1 archer placeholder (yellow capsule, 0.7 scale) near the far wall. In Room 5, put 4 skeletons and 2 archers."

You: "In Room 6, place a boss placeholder — a large red cube, 2x2x2 units, in the center of the room."

You: "In Room 4, place two pickup placeholders — a green sphere for health potion and a blue sphere for the damage boost."

You: "In Room 3, create 6 trap trigger volumes (box collision, 1x1 unit) in a pattern across the floor. Alternate rows."

If you have time and want slightly better visuals, you can use the Blender MCP workflow:

You (to Blender MCP): "Create a simple skeleton warrior. Humanoid proportions, low-poly (under 500 triangles), no textures needed. T-pose for later rigging. Export as FBX to my project's content folder."

The Blender MCP Server executes this through Blender's modeling tools. The result is rough but recognizable — a blocky humanoid form. Good enough for a prototype.

For textures, MCP tools can create and assign material instances directly in Unreal:

You: "Create material instances for the prototype: DungeonFloor (dark gray, roughness 0.8), DungeonWall (medium gray, roughness 0.9), EnemySkeleton (dark red, roughness 0.5), EnemyArcher (dark yellow, roughness 0.5), EnemyBoss (bright red, metallic 0.3), PickupHealth (green, emissive 2.0), PickupDamage (blue, emissive 2.0). Apply them to the corresponding actors."

Hour 2.5-4: Gameplay Systems

This is the most complex phase. The approach depends on your engine and available systems.

With the Blueprint Template Library:

If you have the Blueprint Template Library installed, the AI configures existing systems rather than building from scratch:

You: "Set up the health system on the player character. Starting health: 100, max health: 100. Set up health on skeletons (30 HP), archers (20 HP), and the boss (100 HP)."

You: "Configure the inventory system on the player. Two item types: HealthPotion (consumable, restores 50 HP) and DamageBoost (passive, +10 melee damage)."

The AI uses MCP tools to add components, set property values, and configure the pre-built systems. This is configuration, not code generation, so the reliability is much higher.

Without pre-built systems:

The AI creates Blueprint logic through MCP tools. This works but is slower and less reliable:

You: "Create a health component Blueprint. It should have CurrentHealth and MaxHealth float variables. Add a TakeDamage function that reduces CurrentHealth. Add an OnDeath event dispatcher that fires when health reaches 0."

The AI creates the Blueprint, adds variables, creates the function graph, and wires up the logic through MCP tool calls. This works for simple systems. For complex logic (ability interactions, combo systems, dynamic difficulty), it becomes unreliable and you're better off writing the code yourself.

Player movement:

You: "Set up the player character with top-down movement. WASD input, 5 units/second movement speed, no jumping. Add a melee attack on left click — sphere trace 1.5 units forward, apply 20 damage to anything with a health component. 0.5 second cooldown between attacks."

Enemy AI (basic):

You: "Set up skeleton AI: patrol between two points in their room. When the player enters within 8 units, chase the player. When within 1.5 units, attack (10 damage, 1 second cooldown). When the player leaves 15 units, return to patrol."

You: "Archer AI: Stationary. When player is within 10 units and line of sight is clear, fire a projectile every 2 seconds. Projectile speed: 10 units/sec, damage: 15."

You: "Boss AI: Same as skeleton but slower movement (3 units/sec), 2 unit attack range, 25 damage, 1.5 second attack cooldown."

Camera:

You: "Set up a spring arm camera on the player. Arm length 15 units, rotation -60 degrees pitch, no roll/yaw. Enable camera lag, lag speed 5. Set the game to use this camera on play."

Traps:

You: "Configure the trap triggers in Room 3. Each trigger activates on a 3-second cycle: 1 second active (red, deals 15 damage to overlapping actors), 2 seconds inactive (gray). Stagger the cycles so alternating traps are active."

Win/Lose:

You: "When the boss enemy's health reaches 0, display 'You Win' text on screen and pause the game. When the player's health reaches 0, display 'Game Over' and pause."

Hour 4-5: Playtesting and Iteration

Now you hit Play and discover everything that's wrong. This is the most important phase.

Common issues you'll find and fix:

Movement feels bad. 5 units/sec is too slow — you spend too long walking through corridors. Bump it to 8. The AI adjusts the movement speed through MCP. Takes 30 seconds.

Room 2 is too hard. Three skeletons and an archer swarm you immediately. Move two skeletons to the back of the room so you encounter them sequentially. The AI repositions them.

The boss is trivial. 100 HP with 20 damage per hit means 5 hits to kill. With a 0.5s cooldown, the boss dies in 2.5 seconds. Increase boss HP to 250 and add a second attack pattern: ground slam that creates a 3-unit radius damage zone. This is where AI starts needing help — it can increase the HP instantly but the ground slam ability might need manual Blueprint work.

Traps aren't readable. The player can't tell which traps are active. Add a particle effect or at minimum a color change (red = dangerous, gray = safe). The AI creates material instances and sets up the material swap through MCP.

The camera clips through walls in corridors. Add a collision check to the spring arm. The AI configures the spring arm's collision test channel.

Pickups don't feel rewarding. Add a simple scale-up animation when the player picks up an item. The AI can set up a timeline-based scale animation through Blueprint.

Each of these fixes takes 2-10 minutes with AI assistance. In a traditional workflow, each would take 15-60 minutes of manual implementation. The cumulative time savings over a full iteration session are significant.

What AI Prototyping Can't Do

Being honest about limitations is more useful than being enthusiastic about capabilities. Here's what doesn't work.

AI Can't Design Fun

AI can build what you describe. It can't tell you what to describe. The creative vision — what makes your game interesting, what distinguishes it, what emotional response it targets — is entirely on you.

If you ask AI to "make a fun combat system," you'll get a generic system that technically functions. It won't be fun because fun emerges from specific design choices that AI doesn't have the judgment to make: the exact duration of hitstun, the precise arc of a dodge roll, the ratio of risk to reward in aggressive play.

AI is a builder, not a designer. You're the designer.

AI Can't Evaluate Its Own Output

When the AI places enemies in a room, it doesn't know whether the resulting encounter is balanced. When it sets movement speed, it doesn't know whether traversal feels good. When it creates a level layout, it doesn't know whether the pacing works.

You have to playtest. There is no shortcut. The AI builds, you evaluate, you instruct adjustments, the AI rebuilds. The loop is fast, but the human evaluation step is irreplaceable.

Complex Systems Degrade in Quality

Simple systems (health, pickups, triggers, movement) work reliably through AI generation. As system complexity increases, AI reliability decreases:

This degradation is predictable and consistent. Plan for it. Use AI for the simple stuff, handle the complex stuff yourself.

The 60/40 Rule

Here's the most useful mental model for AI prototyping: AI gets you to 60% of a playable prototype, fast. The remaining 40% is human craft, and it takes disproportionately longer.

The first 60% — level geometry, actor placement, basic movement, simple systems, material setup, camera configuration — takes 2-3 hours with AI assistance.

The last 40% — feel tuning, encounter balancing, edge case handling, polish passes, making the prototype actually answer your design question — takes another 2-4 hours of human work.

Total: 4-7 hours for a playable prototype. That's still dramatically faster than the traditional 2-3 weeks, but it's not the "concept to playable in 30 minutes" that some AI marketing suggests.

The 60/40 split is also a good guide for when to stop prototyping and start building for real. Once the prototype has answered your design question ("Is this fun? Does this mechanic work?"), stop polishing the prototype and start the real project. The prototype is disposable. Don't get attached.

The AI Prototype as Communication Tool

Beyond validating design ideas, AI prototypes serve another purpose: communication.

Pitching to team members. "Here's a playable prototype of what I'm thinking" is infinitely more persuasive than "Here's a design document." Prototypes resolve disagreements about how things should feel because everyone can play them.

Pitching to publishers or investors. A playable prototype — even a rough one — demonstrates that you can execute. It shows the core loop, the genre, the vibe. It takes your pitch from abstract to concrete.

Testing with players. You can put a prototype in front of playtesters within days of having the idea. The feedback you get from watching someone play a rough prototype is more valuable than any amount of design discussion.

The speed of AI prototyping isn't just about saving development time. It's about collapsing the feedback loop between idea and validation.

Tool Integration Map

Here's how the various StraySpark tools fit into different phases of the prototyping pipeline:

You don't need all of these for a prototype. The MCP server for your engine is the core tool. The others accelerate specific phases if you need more than the bare minimum.

Workflow Tips from Practice

After running this workflow across many prototypes, here are the practical lessons:

Describe Constraints, Not Just Goals

"Create a combat room" is vague. "Create an 8x6 room with two pillars for cover, 3 melee enemies on the far side, and 1 ranged enemy on an elevated platform" gives the AI actionable constraints. The more constraints you provide, the closer the first result is to what you want.

Work Top-Down, Then Detail

Build the full level layout before placing any enemies. Place all enemies before configuring their AI. Configure all AI before tuning values. Working top-down lets you see the whole picture before investing time in details that might change.

Save Checkpoints

After each major phase (level built, enemies placed, systems configured), save your project. AI occasionally makes destructive mistakes — moving an actor into a wall, deleting a component, setting a value that crashes the game. Having checkpoints lets you revert quickly.

Name Everything

Tell the AI to name actors descriptively: "Room2_Skeleton_01", "BossRoom_Pillar_Left", "TrapRoom_Trigger_A3". Default names ("StaticMeshActor_47") make iteration painful because neither you nor the AI can refer to specific objects easily.

Keep a Prompt Log

Copy your key prompts into a text file as you go. When you want to rebuild the prototype with changes (different room layout, different enemy types), you can replay your prompts with modifications rather than starting from scratch.

Know When to Drop to Code

If you spend more than 15 minutes trying to get the AI to create a specific gameplay behavior through natural language, it's faster to write it yourself. The AI excels at volume and configuration. It struggles with precision logic. Recognize the crossover point and switch tools.

Beyond the First Prototype

The prototyping workflow described here is for the first playable — the roughest, fastest version. Once you've validated the concept, subsequent iterations can use the same tools for higher-fidelity work:

Second prototype: Replace primitives with actual meshes (Blender MCP workflow), add sound effects, improve lighting, add a simple UI. Still disposable, but closer to the real game's look. 1-2 days.

Vertical slice: Build one complete level with final-quality assets, full gameplay systems, and polished feel. This is where you transition from AI-configured systems to hand-tuned code. The prototype's architecture is a reference, not a foundation. 2-4 weeks.

Production: The prototype workflow continues to be useful for testing new features and levels before committing development time. Need to test whether a new enemy type works? Prototype it in an afternoon. Need to evaluate a level layout? Block it out with MCP tools, playtest, iterate, then hand it off to a level designer for the real version.

The prototype is never the product. But the faster you can prototype, the more ideas you can test, and the better your final product will be.

Getting Started

If you want to try this workflow:

1. Install your engine's MCP server. Unreal MCP Server for UE5, Godot MCP Server for Godot. Follow the setup guide — it takes 10-15 minutes.
2. Write your concept document. Be specific. Include dimensions, quantities, behaviors. The clearer your concept, the faster the AI builds it.
3. Start simple. Your first AI-assisted prototype should be something small — a single room with a single mechanic. Get comfortable with the tool interaction before attempting a full game prototype.
4. Expect iteration. The first output from the AI will not be what you want. The third or fourth iteration will be close. Plan for the conversation, not the single prompt.
5. Playtest early and often. Hit play after every major change. Don't build the entire prototype before testing any of it.

The shift from "I need to build everything" to "I need to direct the building" is the fundamental change in the prototyping workflow. It's not easier. It requires a different skill set — clarity of vision, specificity of description, evaluative judgment. But it's dramatically faster, and in game development, speed of iteration is the closest thing to a cheat code.