ForgeAX is an AI-native personal game studio. We believe the barrier to making games is being redefined by AI.
Our vision is direct: let smaller teams, with AI, make games that used to require much larger ones. Not to replace creators, but to hand the heavy engineering and production between "idea" and "playable game" to AI.
Where we are
The current stage is turning ideas into playable games with AI: we can already make playable FPS, ARPG, survival and shooter demos in the studio, with an engine covering PBR rendering, physics and skeletal animation. We'll keep polishing this stage toward shippable quality.
Open source
The ForgeAX tool layer is licensed under Apache License 2.0 — anyone can freely fork, use, build commercially, and redistribute. We want it to be an open project the community can build together. See the license page.
Let smaller teams make bigger games.
In the studio you describe the game you want to an AI lead called Forge — through chat, by working directly in a visual editor, and (later) with inputs like images and video. It plans, brings in specialized sub-Agents when needed (gameplay, design, art…), then writes the engine code itself, hot-reloading the result into a live browser preview.
Underneath are two in-house foundations: an engine redesigned for the AI's point of view (so AI can read it, write it, and understand its errors), and a development loop that holds AI to a correct, verifiable result (requirements in, playable output out, every step observable and traceable).
A seven-step loop
Inside the engine, every feature goes through the same pipeline — requirements in, a working result out, with a readable record at each step:
- Requirements — state what to build, with acceptance criteria.
- Research — survey history, constraints and options.
- Plan — set a strategy and break it into tasks.
- Implement — write code and tests.
- Verify — independent checks; any red blocks the merge.
- Judgment — a human makes the final call.
- Finalize — merge once it passes.
An orchestrator and sub-Agents
An "orchestrator" drives the state machine, deciding which sub-Agent to dispatch at each step and checking its output; sub-Agents are role-specialized with their own context. Humans inject judgment at just two points: stating requirements and reviewing results.
No "looks fine" slipping through
Verification has two AI gates: one statically scans docs and APIs from an AI user's perspective, catching "promised but not implemented"; the other actually runs the demo in an isolated sandbox, captures screenshots, and re-checks them — guarding against "tests green, screen black."
It gets steadier over time
After each feature, the friction encountered along the way is captured as feedback that upgrades the pipeline itself. The next feature automatically uses the improved version — the pipeline feeds on its own output and gets smarter.
The result: AI produces not "demo-grade" code, but verified, replayable features a human can take over.
Most game-engine APIs are written for humans. When AI becomes the one writing the code, the engine should look different.
ForgeAX's core idea is simple: the user describes a game, and AI writes the engine code. That sounds like "just a different author," but in practice existing engines aren't friendly to AI — they assume a reader who reads docs, guesses, and fills in context like a human does.
Our stance is blunt: AI is the engine's first user. When "friendly to AI" conflicts with "friendly to humans," AI wins. Here are a few concrete consequences.
1 · One source of truth, derive the rest
A fact is defined in exactly one place; everything else derives from it. Component fields, for instance, live inline in a schema — inspectors, debuggers and tooling read the schema instead of grepping source and guessing. AI doesn't need to "remember" conventions scattered everywhere, because there's only one place to look.
2 · Errors AI can understand and recover from
An error isn't just a human sentence you throw. We use a closed set of error codes, each carrying structured "what / why / how to recover" info. When AI hits an error, it knows what to change next — instead of treating the exception text as mysticism.
3 · Structured data instead of "look at the screen"
The hardest part of a rendering bug is that "it looks wrong on screen." A human can stare at the monitor; AI can't. So the engine can capture a frame of render calls — draw calls, bindings, render targets, pipeline state — to read offline, replay, and inspect the full state at the Nth draw. A visual problem becomes data AI can Read.
4 · Two implementations that check each other
The render layer has two backend implementations (WebGPU and a wasm one) behind a single interface. They render side by side: the moment AI misuses an engine API, the other backend immediately diverges, surfacing the problem — far faster than waiting for a human review.
These designs share one yardstick: the fewer concepts a reader (human or AI) must hold in their head, the better. The more self-consistent and locally-indexable the API, the more often AI gets it right — and the easier it is for a human to take over.
"AI-native" isn't a slogan — it's a long series of "redo it for the AI's point of view" decisions. We'll unpack more of them in the docs and future posts.