qvib.pro
RU

Playable game prototype in an engine

What for: get a runnable code skeleton for your game in the engine you picked — scene, input, core mechanic, win and lose loop.

бесплатно профи

Updated: 02.07.2026

$ You are a gameplay programmer working in <ENGINE: Phaser 3 / Godot 4 (GDScrip…
Playable game prototype in an engine

When to use it

You have a GDD and you want to feel the core mechanic in an engine as fast as possible — no art, no menus, but it has to actually run and be playable. The AI's role is a gameplay programmer on a specific engine. Output: a minimal playable build that tells you whether it's fun or not.

The prompt (copy and paste)

You are a gameplay programmer working in <ENGINE: Phaser 3 / Godot 4 (GDScript) / Unity (C#)>.
Build a MINIMAL playable prototype that actually runs.
GAME: "<PASTE THE CORE MECHANIC IN ONE SENTENCE>"
CONTROLS: <e.g. WASD + mouse / tap / arrow keys>
GOAL AND LOSS CONDITION: <when the player wins, when they lose>

Requirements:
1. Core loop only: input → action → world reaction → win/lose condition. No menus, art or sound.
2. Graphics — primitives/colored rectangles as placeholders; structure the code so they're easy to swap for sprites later.
3. Give the FULL code file by file with paths + exact run instructions (commands/steps in the engine editor).
4. Pull the gameplay parameters (speed, spawn rate, damage) into a single block of constants at the top — so I can tune balance without digging through the code.
5. No external assets or paid dependencies. If something has to be installed — give the install command.
6. At the end: the first 3 steps to grow the prototype, and where in the code to make them.
If a choice is ambiguous (version, how to run it) — pick the most common option and mark it [assumption].

The technique: a hard "core loop only, must run, parameters in one place" keeps the model from drifting into a pretty but unplayable skeleton.

Filled-in example

Engine: Phaser 3. Game: "dodge falling meteors, collect stars". Controls: arrow keys. Goal: survive 30 seconds; you lose on touching a meteor.

What the AI should come back with: index.html + game.js with a single scene; a rectangle player on the arrow keys; meteors spawned on a timer; a "meteor → game over" collider; a star counter and a survival timer; a const CONFIG = { playerSpeed, meteorRate, ... } block at the top; run instructions "open index.html through a local server with npx serve".

Variations

  • For Godot/Unity. Swap the engine — ask for the scene and node/prefab structure, not just the scripts.
  • With live balance tuning. "Expose the parameters in a simple on-screen panel so I can change them on the fly" — fast tuning without restarting.
  • Iteration. After it runs: "the mechanic works but it's boring — suggest one twist and show me the code diff."

Pro tips

  • Ask for the minimum runnable thing and test the build immediately — half of all "finished" code trips over small version differences; fix from the real error, not from a guess.
  • For an engine you don't know, pin the version (Godot 4 ≠ 3, Phaser 3 ≠ 2) — the APIs differ, otherwise you get code that won't build.
  • The constants block at the top isn't cosmetic: it turns the prototype into a tool for hunting the numbers that feel fun.

Читать по-русски →