Inicio rápido: tu primer juego
El flujo de trabajo principal de ForgeAX es una frase:Describe el juego que quieres forjar y deja que él se encargue del resto.
The target: a complete tiny loop
Start small enough that the agent can implement and verify the whole experience in one pass. This guide uses a neon collectathon:
- WASD movement
- 8 collectibles
- progress + win state
- browser Play build
1 · Lanzar el estudio
Una vez instaladas las dependencias, un comando abre el estudio. En el navegador verás dos áreas:
BUILD BRIEF · Small scope · complete loop
Build a small 3D neon collectathon in the active ForgeAX game.
- Move with WASD and keep the camera readable.
- Place 8 glowing energy shards in a compact arena.
- Collecting a shard updates an on-screen counter.
- Collecting all shards shows a clear win state.
Use the installed Engine Skills and exact SDK declarations; do not guess APIs.
Run the game, open the Play URL, test movement and collection, and fix any failure you observe.
2 · What the agent does behind the scenes
ForgeAX turns a free-form request into a bounded, evidence-producing loop:
- Inspect — Read the active game, Runtime and Engine SDK identity.
- Learn — Open the relevant Engine Skills, declarations and working templates.
- Implement — Edit the smallest coherent set of files in the active game.
- Run — Build through the verified Runtime and obtain the Play URL.
- Verify — Exercise real behavior, inspect errors and repair until proven.
3 · Engine capabilities used by this tiny game
| Player-facing result | Engine capability | Why it is AI-friendly |
|---|---|---|
| Player, shards and arena exist as game objects | ECS World, components and schedules | State and update order are explicit and queryable. |
| A lit 3D scene appears in the browser | Render projections, materials, lights and camera | Rendering inputs and pass structure can be inspected instead of guessed. |
| Movement and collision feel stable | Input and physics domains | Each domain owns its data and execution contract. |
| Progress and win feedback are visible | State + HTML/CSS or Engine UI | State transitions are explicit and presentation can be tested independently. |
| The project can be rebuilt consistently | Pack, asset GUIDs and versioned Runtime | Sources, published assets and runtime identity stay traceable. |
4 · Iterate by player experience, not by file
Once the core loop works, ask for one experience-level change at a time. The agent can decide which systems and assets need to change.
SECOND PASS · GAME FEEL
Make movement feel more responsive, add a short pickup pulse and sound,
and keep the win feedback readable on both desktop and a narrow browser window.
Re-run and verify the complete loop after the change.
THIRD PASS · VISUAL DIRECTION
Give the arena a coherent cyan-and-amber sci-fi look using Engine materials,
lighting and post effects. Preserve gameplay readability and compare the result
in the real Play build before reporting completion.
5 · Definition of done
- The reported active game is the game you intended to change.
- The launch result shows a matching Runtime and Engine SDK identity.
- The Play URL loads without a fatal browser or runtime error.
- Movement, all collectibles, progress and the win state were exercised in the running game.
Your source of truth is the project directory. You can close the AI client, reopen it later, read status and continue the same game.