Five engines share one agent-directed game framework
GameFactory-3A routes a coding agent across 5 targets: Unreal Engine 5, Unity, Godot 4, Blender, and three.js. The agent starts with agent_skills/setting_overview.md, clarifies a game brief, chooses one engine, plans assets and mechanics, then reads only the instructions for that route. Asset pipelines cover images, 3D objects and scenes, motion, dialogue, sound effects, and CG video. Separate adapters handle engine imports, gameplay, UI, launch, and playtest work.
Our checkout contained 1,275 files and roughly 196,908 lines of source in only 8.7 MB. The high line count makes sense once the engine reference projects and many instruction files are included. This is not a desktop application with a Generate button. Its main interface is a coding agent that reads the repository, chooses model wrappers, runs Python entry points, and manipulates an engine project. The operator must still supply a brief, access, hardware, budget, and acceptance criteria.
The framework separates models, operators, and pipeline runners
The internal boundaries are thoughtfully described. A model wrapper knows how to load and call one backend. An operator turns a task into named artifacts. A pipeline runner reads task data, manages paths, and evaluates existing output. A CPU smoke harness uses fake models to check those contracts without pulling weights. Full game assembly has no single runner; the coding agent coordinates the smaller jobs and stores artifacts by game, run, task type, and task ID.
The 37 MB installed environment does not represent a working generation stack. Implemented wrappers include local models that require GPU runtimes, hosted services that require API keys, and external repositories installed into isolated environments. Unreal, Unity, Godot, Blender, and browser output each have different launch and import rules. The docs say large checkpoints and outside source trees stay outside Git, so reproducing a real game also means recording those versions and licences somewhere the repository does not do automatically.
What happened when we ran it
Our sandbox installed commit 23619e5 in 16 seconds, adding 35 packages and using 37 MB. The build succeeded in 7 seconds. We then ran pytest for 485 seconds in a fresh Python 3.12 Debian container with 3 CPUs and 8 GB of RAM. The result was mixed: 350 tests passed, 6 failed, 6 were skipped, and 28 collection or setup errors were reported out of 384.
The tail names two Godot adapter assertion failures where expected error text was absent, plus 4 mesh-cleanup failures caused by ModuleNotFoundError: No module named 'trimesh'. It also lists an error in test_motion_cloud.py::test_unrecognised_task_type without enough detail to assign a cause. Another 27 collection or setup errors occurred outside that final line. Pip-audit found 0 known vulnerabilities, but a clean dependency audit does not turn the failing test command into a pass.
A 7-second build does not validate a playable game
The project's own agent guide says compilation, launch, or an error-free log is insufficient. It requires playing most intended actions, recording a short gameplay video, watching it, assigning each visible fault to the owning layer, fixing it, and recording again. That is the right standard for generated games. Models can return a valid file while a weapon floats away from a hand, a vehicle drives backward, collision fails, or UI shows state that gameplay never updates.
Our 485-second test run reinforces that caution because 28 cases never reached normal assertion completion. Issue 66 gives a concrete engine example: on Windows, an automated UE5 tap action can reportedly emit only a key-up event, so an attack does nothing while the playtest report still marks the session passed. Teams should retain input traces and video evidence, then confirm that each promised action visibly occurred. A green agent summary cannot replace that observation.
Local models, cloud keys, and asset licences all remain operator work
The model catalog mixes several deployment styles. Tripo and Meshy need their own keys for 3D work. Seedance and Seedream use an ARK key, MiniMax can be cloud or local, and Seed Audio has another credential. Local motion uses external Puppeteer and MoMask sources, while other local image, scene, audio, and 3D routes need weights plus suitable hardware. The framework gives these tools similar Python interfaces, but cost, privacy, output rights, and availability still differ by provider.
The 8.7 MB repository deliberately excludes most of that runtime material. Its README warns that engines, models, checkpoints, and fetched assets keep their own licences. The models guide names Woosh-DFlow weights as CC-BY-NC, which alone can rule out a commercial audio path. Generated objects and downloaded fallback assets need provenance records as they move into a game. An Apache-2.0 licence on the orchestration code does not relicense any model output or marketplace asset.
September 9 activity is fresh, but there is no release line
GitHub showed 589 stars, 8 combined issues and pull requests, and a last push on September 9, 2026. No latest release exists. The open queue is small and active, though several entries are demo storage or internal discussion rather than user support reports. Issue 3, written in Chinese, lists features the maintainers would like to add or reconsider, including game feel, multiplayer design, packaging tests, and longer playtest scenarios. Those are aspirations in an issue, not promised release work.
The repository has a test directory but 0 CI workflow files and no Dockerfile in our scan. That leaves adopters to decide which of the 384 collected cases should gate their own checkout and how to supply missing optional components. GameFactory-3A is most credible as a map of agent workflows, adapter examples, and interchangeable asset backends. Before using it for delivery, pin every external engine and model, make the full test command pass in your environment, and keep the final gameplay recording with the build.