Capcom is open-sourcing its engine so AI can learn it

Capcom is modifying its RE ENGINE to make it easier for AI agents to use.

Share
Capcom is open-sourcing its engine so AI can learn it

Capcom has begun making elements of its in-house game engine open source. One of the stated reasons is so AI models can learn it.

The disclosure came at CAPCOM Open Conference RE:2026 on 2nd October, where programmer Tomofumi Ishida presented REX, a project to evolve RE ENGINE for the next hardware generation.

RE ENGINE development began in 2014 and the engine debuted with Resident Evil 7 in 2017. Every one of the 27-plus titles Capcom has shipped since has been built on it, which makes it, as Ishida put it, the heart of the company's development.

Eight years in, he identified three pressures.

  • Games have grown so large that the routine loop of making a small change and checking the result had become slow enough to drag on development speed.
  • The user base has expanded to more than 2,000 developers — effectively all of Capcom — including a growing number of overseas staff and people arriving from other engines, which demands both approachability and multilingual support.
  • And the pace of AI progress has made integrating AI into the development workflow, in his framing, a necessary condition for future efficiency rather than an optional extra.

REX is the response. Rather than starting a new engine, Capcom is adding a series of individually named subsystems, each prefixed "RE:"and raising it to next-generation level in stages.

RE:Dox replaces per-type data handling with a single common ruleset that any format is translated into, which Capcom says delivers top-class speed for both reading and editing.

RE:UI rebuilds the interface layer for development tools, which had grown heavy enough to freeze, stall on garbage collection, demand large amounts of code for small changes, and run only on Windows. Three changes address it.

  • Appearance is separated from state, so a single checkbox visual is held once and reused across a hundred places on screen while only the checked-or-not state is tracked individually.
  • Notifications from data to view are abolished in favor of one-way flow, removing the congestion that event-driven updates caused at scale.
  • And the view polls the data itself, skipping the redraw entirely when nothing has changed and reducing its own polling frequency when the screen sits idle — which matters because development tools spend long periods simply being looked at. It can be mixed into existing tools gradually rather than requiring a rewrite.

RE:Log overhauls logging and communication together. Instead of writing out text, the system emits a short ID and looks up the corresponding string only when something is displayed. That shrinks the data, lightens the runtime, allows messages to be reworded afterwards without touching code, and makes machine translation into other languages straightforward for overseas staff. Logs are now gathered from individual machines onto a central server, heavily compressed before transmission, and searchable by anyone on the team. Communication and logging have also been unified under a single protocol, so a failed transmission can be traced afterwards in the log.

RE:Flows is visual, block-based authoring for game logic that converts underneath into a widely used standard programming language. Earlier node-based tools suffered from data conflicts when several people worked at once and were awkward to debug; this keeps the accessibility while letting designers rather than only programmers build mechanics.

RE:Runtime reworks the foundation. Code written in a language humans find comfortable is automatically translated into Capcom's own RE:C++ for machine speed, removing the previous mixture of two languages. Memory management no longer handles objects one at a time but batches them into fixed-size containers processed collectively, which Capcom says allows very large numbers of characters and objects to be loaded and displayed quickly.

Ishida tied all of it to a larger target: an AI-generation game engine.

REX standardizes the whole system on the conventions of the world's most widely used programming language, and the stated benefit is explicitly dual; easier for human developers to work with, and easier for an AI to read and understand. Because the base language is now unified, the ambition is that AI will in future be able to comprehend and write engine code automatically, and run test playthroughs to check for bugs on its own.

Several design decisions already point that way. RE:UI's independence from any particular display implementation was singled out as making automated testing, with no human watching the screen, considerably easier. RE:Flows produces standard-language code underneath its visual surface, which is code a model can read. RE:Log's central, compressed, searchable archive of every run is precisely the corpus an automated system would need to diagnose anything.

And then the unusual part. Capcom has published some of these technologies, including RE:Dox and RE:Log, openly on the internet, and says one of the aims is to make them available for AI to learn from.

A studio is releasing its proprietary engine internals as training data, on the expectation that models trained on them will understand its engine.

That approach is worth putting alongside what Unity did a month earlier.

On 9th September Unity shipped an official first-party plugin for Claude Code, installing 29 Unity-authored skills, the Unity command-line interface and an MCP server giving the agent live control of the Editor.

Its director of AI products, Rachel Zhao, explained the reasoning plainly: developers increasingly start by describing a game to a coding agent rather than downloading an engine, and the agent picks the engine for them. The plugin exists so that when an agent reaches for Unity, it uses Unity correctly rather than guessing from third-party sources.

Capcom and Unity have identified the same problem — coding agents do not know your engine and will improvise badly — and chosen opposite solutions. Unity's answer is documentation: tell the agent, authoritatively, at the moment it needs to know. Capcom's answer is training data: publish the engine so the model already knows before anyone asks.

The difference is partly structural. Unity sells its engine to clients and needs them to succeed with it today. Capcom's engine is internal, so there is no customer to support, only a workforce of 2,000 and a future in which some of that workforce is automated. But it is also a genuine disagreement about where engine knowledge comes from — retrieved at the point of use, or baked into the weights.