Chris Woodall posted an update — Jul 23, 2026 12:50 AM EDT

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.