3AGameFactory is driven by a coding agent, and its demos lean on Meshy, Hunyuan3D and Mixamo

The entry point is a document the agent reads, not a command you run

There is no command line in the quick start. The whole setup is three steps, and the first of them is opening a coding agent.

1. Open a coding agent, such as Codex, Claude Code, or another compatible agent.
2. cd GameFactory-3A
3. Give the agent your game requirement and ask it to read agent_skills/setting_overview.md first.

Three named agents are offered as hosts, with Codex, Claude Code and Gemini CLI linked, and the word compatible leaves the list open. What you supply is a game requirement in natural language, and what the framework supplies is the routing.

The routing document is marked as important, in red, and it is described as the entry point for an agent using the framework to generate assets, gameplay, UI and an engine-specific game. Its job is to send the agent onward to whichever asset skill was selected and to the engine API, and the sentence describing that second hop ends partway through the words engine API co, so the exact wording of how the engine layer is introduced is not given there.

This is a design decision with consequences. There is no configuration file to edit and no command to memorise, which means the behaviour of the whole system depends on how well the agent reads that one document. When something goes wrong, the trace you want is the agent's own transcript, not a stack trace from a script you invoked.

Five engines means five adapters, and the same requirement lands differently in each

The supported targets are UE5, Blender, Unity, Godot 4 and three.js, and the top-level tree has an `engine_adapters/` directory beside `agent_skills/`. The pairing is the whole design: an agent reads the skills, the adapters hold the per engine knowledge, and the output is described as engine-ready game code rather than engine-neutral assets.

The demos are organised by that same axis, one group per engine, which makes the differences between targets easy to read off the page.

Unity gets a fighting game, an FPS and a racing game. UE5 gets a fighting game, an RPG and an FPS. Godot 4 gets three demos described as combining generated objects with the engine's own built-in assets. Blender gets four, split between simple downloaded assets and a mix of downloaded scene textures with generated objects. three.js gets a battle game, an RPG exploration game and a racing game.

So the claim is breadth across engines rather than depth in one, and the demo captions are written per engine to say what was used. A practical question that follows is what happens to work when you switch engines, and the visible page does not answer it. The adapter layout implies the pipelines are shared and only the final step differs, but nothing states whether a scene, a rig or a controller written for one engine is reusable in another.

Most of what the demos show was made by other people's services

The asset provenance is stated in each demo group, and it is the most useful paragraph on the page.

In Unity, the fighting characters are fully generated with Meshy and then rigged and animated by the project's own Puppeteer and MoMask chain. The FPS weapon and the racing vehicle come from Hunyuan3D, while their characters and motion come from Mixamo and their scenes from the Unity asset library.

In UE5, the fighting player character and the RPG's character, stone tablet and chest are generated with Meshy, the FPS weapon with Hunyuan3D, and the remaining characters and all motion from Mixamo or other open-source assets, with every scene open-source.

For Godot 4, the objects are generated with Meshy and combined with the engine's own built-in assets. For Blender, the fighting and racing demos use simple downloaded assets, and the exploration and FPS demos combine downloaded scene textures with objects generated by Meshy.

Read across those four lines and a pattern appears. Models come from Meshy or Hunyuan3D, motion comes from Mixamo or an open source equivalent, scenes come from engine asset libraries or downloaded textures. Only the rigging and animation chain for the fighting characters is described as the project's own.

That is not a criticism so much as a calibration. The framework's contribution is the pipeline that orchestrates those services and turns the results into an engine project, and the videos demonstrate that the pipeline holds together across five engines. It does not demonstrate that the assets originate from the framework, and a commercial project would need to clear licensing on every one of those sources separately.

The three.js demo is the only one credited to two agents in sequence

One demo note describes a two pass process rather than a set of ingredients.

The three.js section shows a battle game, an RPG exploration game and a racing game, and the note says that Claude5-Ops first produces a playable generation and that GPT6-Astra then updates it, with what follows being the updated result. So the videos in that group are the second pass, not the first, and the first pass is not shown.

That is a small detail and an honest one. It tells you the iteration model is part of the framework, at least for the web target: an agent produces something playable, a second agent improves it, and the loop is a documented step rather than something a user improvises. It also means the three.js demos are the ones where you can see a different class of output from the engine demos, since those are described purely in terms of which assets went in.

The naming is worth noticing for a different reason. The two agents are referred to by names that do not match the host agents listed in the quick start, which are Codex, Claude Code and Gemini CLI. Whatever they are, they are presented as specific members rather than as general purpose models, and the page does not say what they are or how they are run.

CG video is local 720P, and the cost trade is stated rather than hidden

The CG video section is separated from the game demos, and it comes with a disclosure about how it was made.

Four clips are shown: an F1 racing game opening, a mid-story cutscene from a fantasy exploration RPG, a promotional trailer for a counter-terrorism tactical FPS, and an ultimate-ability cinematic for a two-player fighting game.

The generation note says they were produced locally at 720P with MiniMax H3, linked to its model page on Hugging Face, and that optional higher local resolutions or cloud API models such as Seedance may provide stronger results at higher cost.

That sentence does three useful things. It fixes the resolution the shown results were made at, so nobody reads them as a ceiling. It names the local model actually used, so the results are reproducible on hardware rather than being an API artefact. And it puts a price on the alternative, which is the sentence most generation demos leave out: a stronger model is available and it costs money.

Audio is the one media type in the project's coverage list with no visible example. The stated coverage is image, 3D asset, motion, audio and CG video generation, and the page demonstrates the first, second, third and fifth. Whatever the audio path does, it is not shown here, and the top-level tree gives no directory name that obviously corresponds to it.

No packaging manifest at the root, but tests and test data are both there

The top-level entries describe a working repository rather than a distributed package.

The list is `.gitignore`, `LICENSE`, `README.md`, `README_zh.md`, and then seven directories: `agent_skills/`, `engine_adapters/`, `models/`, `operators/`, `pipeline/`, `scripts/`, `test/`, `test_data/` and `third_party/`.

Three observations follow. There is no packaging manifest among them, so there is nothing at the root declaring an installable distribution, its dependencies or a console entry point. That is consistent with the quick start, which involves no install step at all: you clone, you open an agent, and the agent reads the repository in place.

Second, the directory names map cleanly onto a pipeline. `operators/` is the unit of work, `pipeline/` composes them, `models/` is where the generation backends live, `scripts/` is entry point automation, and `agent_skills/` is the instruction layer the agent reads. A `test/` directory and a `test_data/` directory both exist, which means the pipeline has fixtures to run against rather than being verified by eye.

Third, `third_party/` is a top-level directory. Vendored dependencies sit beside the first-party code, which keeps an agent from having to install anything, at the cost of the repository carrying code that is not the framework's.

There is a Chinese README alongside the English one, linked from the header as the Chinese documentation, and there are no GitHub releases. The licence is Apache-2.0, and the last push to the default branch is recorded as 2026-09-30 with the repository not archived.

Editorial conclusion

Adopt 3AGameFactory if you want the orchestration and the engine adapters rather than the models, because the generation itself is delegated to services like Meshy, Hunyuan3D and Mixamo, and the asset licenses of a shipped game will come from there rather than from this repository. Two things to weigh first. The demos are assembled from downloaded assets and stock libraries as much as they are generated, so the visual result is not a measure of what the framework can produce from nothing. And the entry point is a document the agent reads, so if you are not running one of the named coding agents you will be reimplementing the layer that decides what happens. The Apache-2.0 licence covers the framework itself and says nothing about the third party assets shown in the demos.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. OpenDCAI/GameFactory-3A on GitHub
4. README