01
The engine is part of the context
For supported workflows, the answer may depend on how code is connected inside the editor—not just what exists in a file.
About EngineForge
Game development is more than writing code.
AI for game developers should work with more than source code.
EngineForge is built around that belief: bring relevant project, engine, and runtime context into the workflow while keeping the developer in control.
Why we built EngineForge
Games do not live in source code alone.
Repository-aware AI can already help developers inspect code, reason about systems, and propose useful changes. But a game also lives in its engine: in scenes, nodes or objects, signals and references, project configuration, editor state, and the behavior that appears when the game runs.
Those layers answer different questions. Code can show that logic exists. Engine context can show how that logic is connected. Runtime evidence can show whether a specific behavior occurred in a controlled run.
We built EngineForge to help game developers work across those layers without losing the ability to inspect the changes, evaluate the evidence, and make the final call.
What we believe
Better assistance starts with better grounding.
02
Evidence is better than assumptions
A plausible change is only a starting point. Bounded runtime observations can provide evidence for the specific behavior being worked on.
03
The developer remains in control
EngineForge keeps changes and relevant evidence available for review. The Crew can help carry the work forward, but developer judgment and approval remain part of the workflow.
What we're building
A platform built around the work of making games.
EngineForge combines project understanding, an extensible Crew, supported engine actions, and bounded runtime verification in one development environment. The goal is not to hide the work. It is to help move a task forward while keeping the result available for developer review.
Platform
A focused workspace for understanding a game project, making changes, and reviewing the result.
Engine connections
Supported Unity and Godot workflows can include selected editor actions and runtime context.
Extensible Crew
Specialists can own or receive bounded work when their role is useful, without turning every task into a fixed pipeline.
Reviewable evidence
Changes, supported engine feedback, and targeted runtime observations help developers evaluate what happened.
Built to grow
The launch roster is a starting point, not a ceiling.
The five launch roles establish the first Crew in an extensible system. Its architecture can support additional specialists and capabilities over time, without requiring every role to participate in every task.
Unity and Godot are the supported engines at launch. The same architecture is designed to accommodate additional engine workflows over time.
See how EngineForge works
Follow a game-development task beyond the code change.
Explore the product or learn how the Crew delegates bounded work while keeping leadership and review visible.