A New Direction for Game Development
OpenCaw 5.0.0 is available, and it establishes a clear direction for the project: video game development is now the center of OpenCaw.
When I first wrote about why I built OpenCaw, the problem was consistency. Different AI sessions could approach the same repository differently. Planning, testing, documentation, memory, and review needed a shared foundation that could survive beyond a single conversation.
That foundation still matters. With 5.0.0, I am applying it across more of the work involved in making a game: designing systems, implementing gameplay, producing assets, animating them, building interfaces, and checking the result inside the selected engine.
The catalog now contains 166 skills, with dedicated workflows for Three.js, Babylon.js, Phaser, Unity, Unreal, and Godot. The release also introduces connected production workflows for turning approved visual references into models, models into animations, and animations into composed actions.
Upgrade note: Version 5.0.0 requires a fresh installation. The upgrade section below covers the layout and tooling changes.
Why focus on games?
Game development makes the relationships between disciplines especially visible.
A movement system affects animation. Animation affects how clearly a player can read an attack. The camera affects that readability too. UI, audio, and effects need to communicate what the gameplay system actually decided. A detailed environment asset still has to fit the scene's performance budget.
An AI workflow needs to carry those relationships through the work.
Consider a simple enemy encounter. There is a design question about what the player should learn, an implementation question about the enemy's behavior, an art question about its silhouette, and an animation question about how its attack is telegraphed. Testing has to examine the encounter as something a person can play.
That is the direction I want OpenCaw to support: a coherent process that connects the intended player experience to implementation, assets, and observable results.
OpenCaw continues to provide a shared baseline for agents such as Codex, Claude, and Cursor. You bring the project, engine, tools, and creative direction. OpenCaw supplies the instructions, specialist workflows, commands, memory, and review structure that help the agent work within those decisions.
Six engines, with explicit boundaries
One of the largest changes in 5.0.0 is making engine selection an explicit project decision.
The engine catalog registers six engines, and the expanded skill catalog addresses their particular workflows:
| Engine | Examples of covered work |
|---|---|
| Three.js | Scenes, controls, materials, UI, actor animation, and code-authored models |
| Babylon.js | Scenes, materials, controls, audio, UI, animation, and physics integration |
| Phaser | Scenes, sprites, tilemaps, controls, physics, audio, and game UI |
| Unity | Scenes, rendering, 2D content, editor tools, animation, UI, netcode, and services |
| Unreal | Gameplay framework, abilities, AI, worlds, multiplayer, animation, and effects |
| Godot | Scenes, controls, physics, shaders, animation, audio, UI, and multiplayer |
The project selects its engine in ENGINE.md. Architecture and art pipeline choices remain separate decisions.
That separation gives the agent a clearer answer to several different questions: which runtime owns the game, how the software is organized, and how its assets should be produced.
Skills declare engine compatibility, and role capabilities are filtered accordingly. If a requested skill conflicts with the selected engine, OpenCaw reports the conflict. Changing the engine requires an explicit decision.
The practical benefit is continuity. A project using Godot should keep receiving work that fits its Godot setup. A Unity project should keep its Editor and package constraints. A Three.js project still needs explicit choices for systems such as physics and networking.
Each engine also needs its actual tools and runtime verification. The shared animation and action workflows currently include executable Three.js presentation adapters; other engines require their own compatible integrations. Phaser requires an explicit sprite or pre-rendered handoff when the source material is 3D.
From visual references to a reviewed game asset
The default art pipeline is now PROOF_TO_MODEL.
The proof-to-model workflow establishes a sequence from original sources through reconstruction, finishing, and acceptance:
- Understand the source material. Record what is visible, what is inferred, and what remains uncertain.
- Review six consistent views. Approve the front, right, back, left, top, and bottom together.
- Prepare and reconstruct. Process the approved images and camera information for the pinned Pixal3D multi-view reconstruction workflow.
- Finish the asset in Blender 4.5 LTS. Apply the required topology, UV, material, texture, level-of-detail, and collision work within the asset's budgets.
- Review the exported result. Inspect the model, preserve its source history, obtain independent review, and complete separate human acceptance in the game runtime.
The six-view stage matters because a reference image only establishes what it actually shows. The back of a character, the underside of a vehicle, or a hidden mechanical connection may still require a design decision. The workflow keeps those inferred details visible during approval.
The resulting package includes editable sources and runtime exports, with the applicable textures, levels of detail, and collision data. Keeping the editable source makes later corrections possible without starting the entire asset again.
The release also expands the existing Blender production guidance around subjects such as hard-surface assemblies, sculpting, retopology, vegetation, hair, cloth preparation, articulation, and engine handoffs.
OpenCaw's six-view reconstruction path requires live validation; upstream multi-view validation covers four views. Visual quality and runtime suitability still have to be judged on the actual asset.
From a model to motion, then to an action
A model becomes much more useful when it can participate in the game.
5.0.0 adds two downstream workflows that handle different parts of that work.
Model to animation
MODEL_TO_ANIMATION starts with a reviewed model and checks whether it is ready for the requested motion.
That can involve a skinned character, an articulated mechanism, or a rigid object. A character needs appropriate topology, a skeleton, and weights. A vehicle may need independent wheels and steering pivots. A ship can use a rigid hull with defined effect anchors.
Those distinctions matter. The workflow checks the actual structure before proceeding into rigging, motion authoring or explicitly mapped retargeting, baking, export, and review.
It also carries the work into the selected engine, where complete clips and transitions need inspection. The exported file, the motion, and the runtime behavior each need evidence.
Model to action
MODEL_TO_ACTION composes reviewed clips into larger sequences.
A dance can contain several steps. A combat combination can join distinct attacks. A casting sequence can charge an effect, release a visual projectile, and recover.
The workflow supports trims, playback rates, bounded repetitions, blends, markers, and effect cues. It preserves an editable timeline and exports actual composite animation.
It also addresses what happens during playback: pausing, cancellation, replacement, stale callbacks, and resource cleanup. Those details become visible as soon as a player interrupts an action or starts another one.
The initial shared compositor uses in-place clips with supported interpolation. Root-motion sequences and other inputs need an appropriate preparation step or an explicit engine-specific implementation.
Gameplay keeps authority
One design boundary is especially important to me: gameplay retains authority over the rules.
An animation marker can coordinate presentation. A visual projectile can travel toward a target. Gameplay still decides whether the target is valid, whether an attack hits, how much damage it causes, and whether costs or cooldowns apply.
That boundary lets animation and effects communicate the game state while keeping the rules in the systems responsible for them. It also gives interrupted actions and multiplayer behavior a clearer foundation.
Game design, interfaces, and feedback belong in the same process
The release expands the work around the assets too.
Game design guidance now addresses player decisions, progression, economies, and balance hypotheses. A balance hypothesis gives a playtest something concrete to investigate: what choice should the player face, what behavior do we expect, and what evidence would make us change the design?
Game UI work covers HUD synchronization, screen and input ownership, controller focus, accessibility, and the coordination of camera, audio, and visual feedback.
These are everyday game problems. A menu has to return focus to the right place. A HUD needs to reflect current gameplay state. Feedback needs to arrive at the right time and clean up correctly when the action ends.
The game production overview connects each area to evidence: observed playtests, representative scenarios, actual engine results, and supported-device testing.
For haptics, for example, that includes testing on a real supported device. A mocked API call can establish that code executed; evaluating the feedback requires feeling it.
A more focused project
This direction also means narrowing parts of OpenCaw.
5.0.0 retires selected general web-experience workflows, specialist roles, and architecture and style templates outside the new game production focus. Backend services, databases, security, CI/CD, .NET, UI, and accessibility support remain relevant parts of the catalog.
Games need those systems too. Multiplayer services, persistence, account systems, and delivery infrastructure still require careful engineering.
The existing planning and delivery foundations also continue: Brainstorm, Task, Goal, Gauntlet, repository memory, and coordinated agent work. This release updates their storage and evidence paths for the new layout.
I want the result to be easier to reason about as a game development workflow, with the surrounding engineering support available where the project needs it.
Upgrading to 5.0.0
This release requires a fresh installation. Existing users should read the 5.0.0 installation instructions before updating a project.
The main changes are:
- Install at
<project-root>/.opencaw/. The same directory is used across supported agents. Earlier tool-specific installation paths are no longer supported. - Preserve your project state. Memory, tasks, reports, and workflow evidence now live under
.opencaw/.cache/. Despite the name, this is durable project state and should be backed up. Legacy.ai/state is not imported automatically. - Review the art pipeline choice.
PROOF_TO_MODELreplacesCSS3as the default. Ordinary CSS and SVG remain supported for game interfaces. - Check native tooling requirements. The new native production workflows require .NET 10, Blender 4.5 LTS, and the applicable reconstruction tools and licenses. Their native process execution currently supports Windows and Linux; macOS execution is blocked.
The .NET 10 requirement belongs to OpenCaw's standalone native tooling. Engine projects retain their own language and runtime requirements.
Start with something playable
You can begin with a normal conversation. For example:
Help me plan a small Three.js combat arena with player movement,
one enemy, one attack, and a readable health HUD.
Inspect the repository first. Agree on the player experience,
scope, asset requirements, and a frame-time budget.
Plan a playable slice with clear review points for gameplay,
models, animation, and feedback. Show me how we will verify
the result before editing.
That gives the agent a concrete outcome and a manageable set of connected problems.
A small playable slice also gives you somewhere to examine the whole workflow. You can see how the mechanic feels, whether the animation communicates it, whether the HUD stays synchronized, and whether the scene fits its budget.
That is what I want to build toward with OpenCaw: AI-assisted game development where the design, implementation, assets, and review remain connected as the project grows.