Forgie: Mobile 2D Game Creator

Build a 2D game on your phone with plain-language guidance. Tell Forgie what you want, preview each change, go back anytime, and export a playable web game.

Comment

I built Forgie because I love what AI makes possible, but I don’t always want it to make everything at once. I want to see what is changing, try it, and change my mind safely.

Try Forgie
Watch the 2:36 demo

Try it in about two minutes

The fastest way to understand Forgie is to open the PWA and choose Start 3-step tutorial.

You’ll help finish a small game called Skybound Spark: Light the Beacon:

  1. Make Forgie the player.
  2. Turn the Spark into a collectible that adds 1 to Score.
  3. Make the Beacon light when Score reaches 1.
  4. Preview the game, collect the Spark, win, and restart.

No account or API key is required. Projects are saved locally in the browser.

A game created through Forgie

As a final creator test, Codex used Forgie’s visible workflow to build and export [Moon Orchard] from a blank project.

Play the exported game

Why I built it

I love making games, and AI has made it possible for me to move from an idea to working software much faster than before.

But I kept running into the same problem: AI could produce a lot, while I was still trying to understand what it changed.

Sometimes too much happened at once. Sometimes I liked most of the result but wanted to adjust one small part. Sometimes an experiment went in the wrong direction and getting back to the version I liked was harder than it should have been.

I wanted a workflow that felt less like:

“Generate the whole thing and hope.”

And more like working with a patient creative partner.

That became Forgie.

What Forgie does

Forgie is a portrait-first 2D game creator that runs on a phone or in a web browser.

You start with a blank scene or the guided tutorial, then build the game one visible change at a time.

A normal Forgie change looks like this:

  1. Add or select something in the scene.
  2. Describe what you want in ordinary language.
  3. Review the plan before anything changes.
  4. Run the result as a draft.
  5. Accept it, adjust it, or throw it away.
  6. Keep building from the version you chose.

Every accepted change is saved. You can return to an earlier point, restore it without deleting later work, or start a new Variation from there.

When you are ready, Forgie can export the project as a playable HTML5 web game.

What makes it different

Forgie is not trying to generate an entire game in one prompt.

It focuses on the next understandable change.

You see the plan first.

Forgie explains what it is about to change and what it will leave alone.

You preview before accepting.

The draft runs in the real game runtime before it becomes part of the project.

Changing your mind is safe.

Accepted history stays available, and exploring an older idea does not destroy the work that came after it.

The output is real.

The editor, preview, and exported game use the same structured game project and shared Phaser runtime.

Who it is for

I designed Forgie for beginner creators, hobbyist game developers, and people who have game ideas but do not want their first step to be learning a large desktop engine.

It is also for creators who already use AI but want a calmer, more understandable way to work with it.

The phone-first design matters to me. Game ideas do not only happen when you are sitting at a development desk. I wanted someone to be able to open Forgie, try an idea, and see it working wherever they are.

Built with Codex and GPT-5.6

I used ChatGPT and Codex for different parts of this project.

ChatGPT was where I worked through the product idea, user experience, priorities, and milestone prompts.

Codex with GPT-5.6 was where the repository was actually researched, architected, implemented, tested, reviewed, and hardened.

I did not use Codex once to scaffold an app and then finish everything manually. It was part of the whole development process.

The workflow looked like this:

  1. I defined the product direction and the experience I wanted.
  2. I gave Codex one detailed greenfield goal.
  3. Codex implemented the first functional alpha.
  4. I manually tested it and recorded what felt wrong.
  5. I opened a fresh Codex session and asked it to independently review the repository.
  6. That review found real problems the first implementation had missed.
  7. I turned those findings into a focused hardening milestone.
  8. Later sessions added the guided game loop, deployment, mobile UI polish, testing, and submission materials.

One of the most useful moments happened when the independent review disagreed with the earlier “everything passed” report. It found that a warmed development folder was hiding clean-checkout problems.

Instead of hiding that, I made it part of the workflow.

The review became a repair plan, the repairs were tested in a clean environment, and the result was reviewed again.

I directed the product, UX, scope, priorities, and acceptance decisions. Codex performed the repository-grounded implementation and verification work, but I decided what belonged in Forgie and what did not.

Forgie Mobile is a new greenfield Build Week repository. It does not copy from or depend on the earlier desktop Forge experiment I had explored before the event.

How it works

Forgie is built with React, TypeScript, Vite, Phaser, IndexedDB, and a small server-side API boundary.

A game is stored as structured, versioned data instead of generated source code.

Planning produces structured changes. Those changes are validated, checked against the current project, and then applied by deterministic application code.

No planner is allowed to write arbitrary JavaScript, directly rewrite project history, or mutate browser storage on its own.

The public demo uses verified on-device planning, which is why it works without an account or API key.

Projects, assets, drafts, accepted versions, Variations, backups, and export records remain local to the browser.

What is real in this alpha

The current build includes:

  • blank game creation;
  • a guided three-step playable tutorial;
  • visual scene and object editing;
  • player movement and simple physics;
  • collectibles, Score, a win condition, and Restart;
  • plain-language supported changes;
  • plan review and draft preview;
  • accept, adjust, and discard;
  • recoverable history and Variations;
  • image importing;
  • project backup;
  • playable web-game export;
  • an installable PWA.

It is still an alpha. It does not pretend to support every game genre or mechanic.

The goal of this week was to prove one complete, trustworthy path from an idea to a working, playable result.

What I learned

The hardest part was not getting Codex to produce code.

It was deciding how to build a product that a creator could trust.

I had to think about things that are mostly invisible when everything works: recoverable history, failed drafts, asset ownership, safe target selection, clean setup, browser persistence, exported-game validation, and keeping secrets out of the client.

I also learned that a strong AI-development workflow is not one giant prompt.

It is a series of focused goals, real testing, written project memory, human decisions, and independent reviews that are allowed to say the earlier work was wrong.

What is next

Next, I want to:

  • make the first-time experience even easier;
  • support more game behaviors without turning Forgie into a complicated engine;
  • test more physical devices and installed-PWA behavior;
  • improve accessibility and offline support;
  • finish protected end-to-end browser verification for the optional server-side planner while keeping the public demo key-free

The main promise will stay the same:

Build your game, one idea at a time.

Built With

Share this project:

Updates

posted an update —

Forgie early-alpha sprint overview

In short, we have been turning Forgie from a mostly literal command interpreter into a safer, AI-assisted text-to-game-change engine built from reusable 2D game-development pieces.

1. We established safer development rules

The public Build Week submission remains frozen. New work is happening locally on codex/early-alpha-interpreter, with no pushes, deployments, or changes to the judge-facing version.

We also tightened the central product rule:

AI may interpret what the creator means, but only Forgie’s deterministic change engine may modify the game.

The AI cannot write arbitrary Phaser code, patch the game document, invent IDs, or bypass history. Creators always receive a bounded plan they can review before accepting.

2. We substantially expanded the interpreter

The original local interpreter was useful mainly for exact commands. We expanded it to recognize more complete, direct creator requests while refusing partially understood or unsafe compounds.

The current architecture has two lanes:

  • Local deterministic lane: Handles exact, complete requests without an API call.
  • Semantic-provider lane: A small AI request interprets ambiguous human wording, but returns only a narrow intent and supporting evidence. Forgie reconstructs and validates the real change locally.

This means a provider can help understand that “make the door swing open” probably means animated rotation, but it does not receive authority to create the door behavior directly.

We also added narrowly bounded multi-change support for a few compatible requests, such as two or three exact transformations on the same selected object. This is not unrestricted batch generation.

3. We added hosted-provider support and measured it

Forgie’s private provider route now supports allowlisted OpenAI, Groq, and Together configurations behind explicit server-only controls. API keys remain on the server and are never exposed to the browser.

The Groq GPT-OSS 20B path has been especially promising:

  • One inspected request used 815 input tokens and 99 output tokens.
  • Total usage was 914 tokens.
  • Response time was approximately 440 ms.
  • The resulting plan compiled, reviewed, applied, and ran correctly.

The app now shows an AI request usage receipt under an AI-assisted plan. It explains input, output, reasoning-token subsets when reported, total tokens, provider, model, and latency.

We also added safe failure diagnostics. If planning fails, Forgie can now show:

  • which route it attempted;
  • how far planning reached;
  • a plain-language failure category;
  • total latency; and
  • a safe diagnostic ID.

It deliberately does not expose prompts, project context, raw provider responses, credentials, headers, or internal server errors.

4. We tested a tiny local model

We used Ollama to evaluate a roughly 0.5B-class model as a possible free on-device interpreter.

The result was a clear NO-GO:

  • It always returned valid JSON.
  • Its best narrow-lane accuracy was only 41%.
  • It produced 10 unsafe false positives across 42 safety cases.
  • It safely stopped only 24 of 36 uncertain cases.
  • Warm latency was approximately 440–616 ms.
  • Peak memory allocation was about 661 MiB.
  • Cold startup took almost four seconds.

The important lesson was that being small and schema-compliant does not make a model trustworthy. It also showed no meaningful latency advantage over the stored Groq results. We did not connect it to Forgie or promote on-device AI as a feature.

A future tiny model could still help with very low-risk classification, but it cannot currently decide what game changes Forgie should make.

5. We built reusable game-mechanic foundations

Rather than adding genre-specific commands, we started building small engine-like bricks that can combine into many games.

Work now includes:

  • Named counters and visible Score/Health labels.
  • Contact events that change a counter once when contact begins.
  • Counter-based win and loss conditions.
  • Conditions on existing tap/contact rules.
  • Contact actions that move, show, or hide another object.
  • Triggered animations to an exact position, rotation, scale, or opacity.
  • Finite Scene-start back-and-forth motion.
  • Collider-shape editing.
  • Exact starting velocity.
  • Bounce/restitution controls.
  • Pause, Restart, reduced-motion, Preview, and export behavior for the relevant slices.

These pieces support small loops such as collectibles, switches, gates, moving targets, warning lights, simple hazards, score goals, and finite visual movement.

They do not yet provide arbitrary scripting, general timelines, callbacks, combat systems, inventory, pathfinding, or unrestricted behavior generation.

6. We completed the first headless Forgie interface

Forgie now has an early local command-line interface for Codex and automated testing.

It can:

  • create a new .forgie game;
  • inspect a game safely;
  • plan a change through the local text interpreter;
  • plan explicit allowlisted operations;
  • inspect the resulting proposal;
  • accept it; or
  • reject it.

Planning creates a private receipt and leaves the accepted game unchanged. Acceptance checks that the game and history have not changed underneath the proposal before replacing the archive safely.

The CLI cannot bypass validation, submit internal restore operations, hand-edit project data, or generate arbitrary Phaser code. It also does not yet import assets, launch Preview, or export a playable game; those still require the visible creator.

We updated the reusable Forgie skill so future agents clearly label their work as:

  • visible black-box;
  • visible informed creator;
  • headless text interpreter evidence; or
  • headless structured engine evidence.

7. We created a capability-driven roadmap

Several design agents brainstormed 26 small games and roughly 207 representative creator requests. We used those ideas to identify reusable missing pieces instead of building isolated one-off features.

This produced a roadmap covering:

  • counters, contacts, conditions, and outcomes;
  • triggered and finite motion;
  • stateful switches and toggles;
  • moving solids and motion completion;
  • camera framing, following, pan, and zoom;
  • reusable pools and schedules;
  • physics constraints, wheels, and motors; and
  • later logic visibility through a Mechanic Map.

We also added docs/INDEX.md and strengthened the capability inventory, status document, work log, and model-routing guide. This should help future agents find the correct system instead of rebuilding or orphaning code.

8. We planned—but have not built—the Mechanic Map

We documented a future read-only visual map of a game’s mechanics.

It would show relationships such as:

  • Lever affects Door.
  • Coin changes Score.
  • Score reaching 10 produces Win.
  • Player follows Camera.
  • Zone triggers Warning Light.

The map would be derived from the accepted game document, not become a second source of truth. Selecting cards could provide Forgie with precise context for a text request.

This is not yet visual scripting, and it has not been implemented. It is a path toward making increasingly complex games understandable without immediately recreating a giant pin-and-wire system.

9. We have a separate physics roadmap

We completed a design review for eventually using Matter-style bodies, constraints, wheels, and motors. That foundation is still planned, not implemented.

Requests such as:

“Add a wheel sprite to this car using a motor constraint and add button controls.”

will require several later bricks:

  • bodies whose visual and collision rotations agree;
  • constraints and anchor points;
  • motor speed and torque;
  • input-driven motor control;
  • reliable Restart;
  • export parity; and
  • editor visualization.

Rotating colliders, moving physical platforms, Player carriage, wheels, and motors should not be claimed as available yet.

10. We dogfooded the motion system with real games

An informed creator built Firefly Sweep, which proved finite movement, moving/stopped taps, counters, a win condition, Pause/Resume, Restart, reduced motion, and unchanged served-export behavior at both phone sizes.

A separate black-box creator then built Signal Shuttle without implementation guidance. It successfully created a three-trip shuttle and proved:

  • three complete round trips;
  • final stop at the saved position;
  • Pause/Resume;
  • reduced motion; and
  • a downloadable export that began the same movement.

That run was classified Partial because Preview Restart appeared to reset the object without replaying its motion, and the export inspection was interrupted.

We later determined that the core motion engine was rebuilding correctly. The confusing behavior came from Preview tools leaving the game paused behind an open panel.

We fixed Restart so it now:

  • closes Preview tools;
  • clears Pause;
  • starts playing immediately;
  • restores keyboard focus; and
  • visibly announces that Preview restarted.

The repaired behavior passed focused tests at both 390×844 and 430×932. A later informed check also proved that the preserved Signal Shuttle export completed all three trips and stopped correctly at both sizes without overflow or runtime errors.

The original black-box result remains Partial rather than being rewritten after the fact.

What we are doing next

The immediate next task is still the fresh M2a black-box promotion test.

A new uninformed creator must test the repaired version without seeing source code, internal documentation, schemas, prior game recipes, or test fixtures. It should create a different finite-motion microgame, test completed-track Restart, and serve its export at both phone sizes.

We attempted this once, but the task had no compliant browser connection. It never opened Forgie, so the result was NOT RUN, not a Forgie failure. This test remains pending until a new task has access to the in-app Browser or Chrome extension.

After that passes, the next implementation slice is M2b: stateful triggered motion toggles.

Examples include:

  • tapping a lever alternates a door between closed and 90 degrees;
  • tapping a switch moves a bridge out and back;
  • entering a zone alternates a warning light between bright and dim.

M2b first needs a Sol/Ultra design-contract session. Once the design receives a GO, Sol/High can implement it with focused tests. A separate provider-efficiency pass will keep direct wording local and measure whether semantic provider requests can stay near roughly 1,000 input tokens and 150 output tokens.

After M2b, the likely sequence is:

  1. One translating physical solid with matching visual and collider movement.
  2. Safe Player carriage on moving platforms.
  3. Motion-completion sequencing.
  4. Camera framing and follow capabilities.
  5. Matter constraints, wheels, and motors.
  6. Continued provider compression and corpus testing.
  7. A blind creator game after every one or two promoted capability bricks.

So, we have built a much stronger foundation, but we are still in early alpha. Forgie can now perform a meaningful collection of small, reviewable game changes; the next phase is about proving those pieces to uninformed creators and gradually composing them into richer game loops without sacrificing safety or predictability.

Log in or sign up for Devpost to join the conversation.

posted an update —

Before the deadline, I gave Codex one final challenge: stop acting like a repository agent and try using Forgie as a creator.

Starting from a blank game, it read Forgie’s public capability guide, designed a small game called Moon Orchard Relay, generated five original sprites, imported them through the normal Assets workflow, and assembled a Player, solid ground, three collect-once pears, Score, a win condition, and Restart.

The first elevated route did not work reliably. Instead of hiding that, the agent changed the level design, moved the required pears onto a reachable ground route, exported the game again, and replayed the exact standalone build at two phone sizes.

This was Document-Assisted creator evidence, not one-shot game generation and not a live GPT request. That distinction matters—but so does the result: Forgie produced a real, playable web game outside its prepared tutorial.

Play Moon Orchard Relay

Try Forgie

Watch the Build Week demo

This is a recap of work completed and linked in the final project before the submission deadline.

Log in or sign up for Devpost to join the conversation.

posted an update —

Really putting Codex through its paces this week. I have tried many different workflows, and I have been needing an excuse to switch to the Pro plan. I was being conservative with the reasoning and very considerate about context window sizes early on. Then I got brave and put the pedal to the medal and have had my first multi-hour sesssions. I have also sweated over the weekly usage cap. The new models and updates to Codex feel like a game changer ;)

In the last few hours I am working on improving Forgie's prompt to game changes feature. Testing different endpoints coupled with beefing up the deterministic regex interpreter. Trying to find a balance of 'this prompt is explicit and can be handled right now without ai' and 'this prompt needs to be sent to low latency endpoint for interpretation'. This is the bread and butter of Forgie. Specific, deliberate, and controlled changes to your game using your words.

I did not set out this week to make a pseudo game engine on mobile, but here we are and I am having a great time! Will post about the current, what I am calling 'pre-alpha interpeter and enpoint supercharged plan, implement, review and refine loop session'.

Log in or sign up for Devpost to join the conversation.