VberAI End-to-End: AI Studio + Engine MCP for a Playable Mini-Game

For indies and small teams, the bottleneck is rarely “cannot write a single line of code.” It is usually two tracks running in parallel:

1. UI and art structure never land cleanly in the engine—slicing comps, rebuilding Canvas / Control trees, mismatched names and hierarchy
2. Gameplay and scripts are expensive to iterate—reattach components, chase errors, enter Play—hours lost to repetitive editor work

VberAI splits those jobs into two layers. It does not claim “one button, finished game”:

Layer	Product	Job
Canvas → engine UI	AI Studio	Generate game UI from natural language, or import PSD / Figma; split, matte, edit, then sync/export to Unity, Godot, Cocos Creator
Engine ↔ AI IDE	Engine MCP (Unity / Godot / Cocos)	Drive the open editor from Cursor, Claude Code, Codex, and similar clients: logic, scripts, debug, preview

The rest of this guide is a production-shaped path for a playable 0–1 slice and for later revision cycles.

End-to-end pipeline

Gameplay goal / design file / NL UI brief
        │
        ├─→ AI Studio (generate · import · split · matte · componentize · export)
        │         ↓
        │    UI hierarchy / prefabs / scene assets in the engine project
        │
        └─→ AI IDE + Engine MCP (read scene · write scripts · wire · Play/debug)
                  ↓
             Demoable gameplay slice → return to Studio or keep using MCP by change type

Rules of thumb:

• Get UI structure right on the canvas before deep engine wiring
• Keep behavior and numbers in-engine; humans own Play results
• Commit before large edits; keep the MCP bridge on localhost only

AI Studio: engine-ready interface assets

AI Studio is for game UI / interface structure—not a generic chat box, and not a replacement for in-engine combat state machines.

Path 1: Natural-language UI (no design file yet)

Help me design a chibi-style match-3 game

Then verify on canvas: hit targets vs decoration, names that scripts can bind, layout under target resolutions. Demo below:

Path 2: Import PSD / Figma / project assets (design exists)

1. Import layered comps or existing UI
2. AI split into panels, list items, dialogue frames
3. Hard edges (hair, glow, semi-transparent) via AI Super Matting when needed, then back to Studio
4. Componentize and sync / export to Unity, Godot, or Cocos Creator

Demo of PSD / Figma import and split:

What this step produces

Produces	Does not produce
Mountable UI hierarchy, textures, prefab/scene structure	Full combat FSMs, netcode authority, save systems

Deeper handoff example: Figma to Unity UI.

Engine MCP: dialogue-driven logic and editor labor

MCP (Model Context Protocol) lets an AI IDE call local tools. VberAI’s engine plugins expose the open editor to the client: scenes/nodes, scripts, debug and preview aids—not only pasting files into the repo.

Pick and install by engine:

• Unity MCP · install guide
• Godot MCP (open source) · install guide
• Cocos 3.x / 2.x · 3.x install · 2.x install

Comparison: Godot MCP vs Unity MCP vs Cocos MCP.

Demo: after Studio export, Cursor + Godot MCP ships a chibi match-3

Continuing Path 1: the UI is already in Godot from AI Studio. Connect Godot MCP in Cursor and drive the editor in natural language—without writing a single line of code by hand—to implement the chibi match-3 gameplay and debug it to a playable state. Recording below:

Good fits for MCP

• Testable gameplay slices: player control, simple combat, enemy states, quest wiring
• Batch Hierarchy / scene-tree renames, attach components, bind Studio-exported HUD to events
• Within plugin limits: logs, selection context, small reversible edits then Play

Poor fits

• Unreviewed multiplayer authority or full render-pipeline rewrites
• “One prompt, ship a commercial game”
• Replacing art direction and feel decisions—those still need humans in Play mode

Worked examples: 3D RPG with Unity MCP, 2D platformer with Godot MCP.

0–1: a minimal path

Aim for a demoable slice in hours, not a feature checklist.

1. Scope the slice — e.g. “move + one enemy + one HUD” or “one platform level + restart”
2. Install MCP and read-only smoke — list scene roots; confirm the AI IDE is connected
3. Placeholder UI or gameplay first — Labels/Sliders while systems are unfinished; open AI Studio when menus/HUD must look finished
4. Advance logic via MCP — one concern per prompt: control → damage → enemy → fail/quest conditions
5. Polish UI when needed — Studio export → MCP binds buttons and value events
6. Play acceptance — feel, collision, UI refresh; if it fails, narrow the prompt and retry

Fast iteration: choose the loop by change type

Change	Prefer
Feel, numbers, AI, navigation, script bugs, node wiring	AI IDE → engine MCP
Full-screen visuals, reskin, layer split, re-export prefabs	AI Studio (+ matting if needed)
Still stuck on “comps will not enter the engine”	Studio structure first, then MCP

The expected gain is concrete: less rebuilding UI from scratch in the editor, and less repetitive clicking. It does not remove design judgment or testing.

Team checklist

• Licensing: Unity / Cocos MCP follow official activation; Godot MCP can validate habits via open source
• Security: MCP Server on 127.0.0.1 only
• Prompts with acceptance criteria: paths, attach points, what Play should show in ~10 s, out-of-scope refactors
• Review: always Play-test generated scripts and node edits—MCP cuts operation cost, not QA

Takeaway

VberAI’s useful story is a split of high-frequency pain—not “full automation”:

• AI Studio: natural language or PSD/Figma → UI structure for Unity / Godot / Cocos
• Engine MCP: natural language in an AI IDE → in-editor logic, scripts, debug, preview

Use the right loop and 0–1 slices plus revision cycles move faster. Cross the boundary (canvas writing combat FSMs, MCP slicing entire UI packs) and you add rework. Adopt one layer or both by project stage—you do not need every product on day one.