AI Game Mashups: Can AI Really Turn Two Games Into One?

Mario shooting some baddies in Halo. Minecraft inside GTA V ( see Appendix: a real-world example ). A social media trend has people sharing videos of what’s being branded as “AI game mashups.” The claim is that people have used AI to reverse engineer different games and mash them together into one in unexpected or cool ways... but is that the whole story?

As usual, hype has a tendency to exaggerate things to create, well, more hype. So let's separate reality from fiction and explore what’s actually happening behind these demos.

The good news is that there is plenty on the reality side to be mind-blown about! However, there are also some disappointing truths. At least for the time being.

Let's walk through a ridiculous combination as a practical example. Let's imagine that we want to combine Candy Crush and Call of Duty!

However, simply naming two games does not constitute a plan. Like anything else, first we need to work out our requirements and architectural concerns.

Here's my take: every time you reload your weapon, Candy Crush loads inside the Call of Duty gameplay and you have to complete a match-three puzzle before the reload can finish.

Hypothetical mashup: solve a match-three puzzle to finish reloading. AI-generated concept illustration, not a screenshot of a working mod.

I have no idea whether that would be fun. I suspect my teammates would have opinions. But at least we now have something concrete enough to discuss.

There are still decisions to make though. Does the shooter pause while you solve the puzzle? What happens if you fail? Can you cancel? Does a harder puzzle earn you more ammunition?

Neither original game contains the answers so it's up to us to introduce new rules.

And that is our first lesson: Connecting two game engines does not automatically create coherent new gameplay. Somebody, potentially with AI assistance, still has to decide what the connection means and implement it.

When I watch these demos, I find it useful to separate four things.

These can overlap. A project might combine graphics and translate a few events without sharing every part of either simulation.

For example, an explosion in one game could trigger an explosion in another. That is a meaningful integration, but it doesn’t, by itself, establish that every object in both worlds can collide, that both physics engines agree, or that every mission works across the boundary.

A clip can still demonstrate a specific interaction beautifully while leaving those broader questions unanswered.

Ok, so how can we go about implementing our Call of Duty and Candy Crush mash-up? Well, to begin with we need to discover each game's available integration points. Then we need to find a way to connect those before finally figuring out how to coordinate the result.

A game with a supported modding API might already expose the events and controls we need. Otherwise, investigating its internal behaviour may be necessary.

For our shooter, we would need to identify a reload request and find a reliable way to defer it. For the puzzle, we need to start a challenge and detect its completion. Observing an animation on screen is different from having a dependable signal that the underlying action succeeded.

This is where reverse engineering can contribute: working out how software behaves when its original source code or a suitable interface isn’t available.

REA, or Reverse Engineer Anything, is one project in this area and the one behind the viral game mashups trend. Its documentation describes connecting agents to analysis tools, including Ghidra, Hopper and IDA, and returning findings that an agent can investigate further.

It is indeed a pretty cool tool that gives an agent ways to inspect software. However, it is NOT a magical command that enables agents to recover an entire game’s original source project or to understand every subsystem.

Moreover, it's important to remember that runtime modification of games predates AI tools.

Mod Engine 2, for example, documents runtime patching and injection for Souls games, including Elden Ring. Existing tools and community knowledge are part of the foundation here.

Once we understand the relevant behaviour, we can build adapters: code that translates between what our mashup needs and what each game can actually do.

From the coordinating code’s perspective, the shooter adapter might offer operations such as “defer reload” or “resume gameplay.” The puzzle adapter might offer “start challenge” and a completion event.

Those are interfaces that we have to build unless the game itself provides out-of-the-box integration points, or in simpler language, hooks. This could be, for example, official support for mods. That means creating and maintaining your own adapter code, which, yes, you can also use AI to help you generate.

There is an added complication: If components run in separate processes, they need a way to exchange messages, such as sockets or named pipes. This is referred to as inter-process communication, often shortened to IPC.

A hook and a communication channel have different jobs. A hook can intercept behaviour inside a game whereas IPC lets separate processes exchange information. Having one doesn’t automatically give us the other.

Either way, we arrive at our second lesson: AI doesn't somehow make two incompatible executables magically understand each other. The real magic is that AI can help us build the missing interfaces between them.

Now we need the coordinator, or orchestrator, that implements our reload rule so we can load Candy Crush every time you need to reload your weapon on Call of Duty.

Here's the plan: it receives a reload request, defers the action, puts the shooter into an appropriate paused state, and opens the puzzle. On success, it allows the reload to proceed and returns control to the shooter.

The orchestrator coordinates the reload and puzzle, with a recovery path for failure, cancellation or timeout. This conceptual flow assumes the required integration points exist.

What if the puzzle crashes though? The player shouldn’t remain trapped forever with a frozen gun. And how about if a completion message arrives twice? We need to be careful not to grant ammunition twice. Like any piece of software we need to design for our error conditions.

This is why “pause the game” deserves scrutiny. Preventing player input is different from pausing the simulation. In a networked game, the server and other players may continue regardless. Our example depends on capabilities that may be unavailable or prohibited in a protected online title.

If you work with microservices, there’s a familiar architectural idea here. Connecting two services doesn’t automatically create an e-commerce application. You still need rules that define what placing an order means, what happens next, and how failure is handled.

Games add another difficulty, one that becomes our third lesson: we still need to design and build gameplay rules for the mashup much like building any other game.

In one possible implementation of our example, the shooter and puzzle remain separate processes while our own coordinator manages their behaviour and presentation.

The simplest implementation may be, for example, switching back and forth between the Candy Crush puzzle’s window and the Call of Duty window. A more integrated version could display the puzzle within the shooter’s view as ensioned in our concept above. We'll have to work harder for it because it then adds rendering and input-routing work but it does look super cool. Either way, the objective is to have the player experience a single set of rules while multiple programs do the work.

Another consideration is whether we need to create our own launcher app. This could gives even more control over the runtime and coordination between the two processes running either game, however it does not automatically give control over either game's internals.

So lesson four is: the desired user experience dictates how much control you need to have over either game and determines the architectural choices as well as the amount of code that you need to write and maintain.

This is perhaps the most intriguing question.

A newly written game might use original artwork, generated assets, placeholders or reused material. A mod might leave the original game’s engine and assets in place. A mashup might combine output from two running engines, each rendering its own content.

Those are different workflows. A familiar character on screen doesn’t tell you which one happened.

In our hypothetical example, if both original games were running, neither would need its graphics recreated merely to appear in the experience. Each game already knows how to render its own world. The integration challenge would concern control, communication, presentation and the new rules.

Conversely, reproducing familiar graphics in a newly written program doesn’t establish that the original physics, enemy behaviour, timing or levels have been reproduced.

But hang on. If we put Mario inside Halo, how does he know where the floor is? Doesn’t he come with his own bounding box? The important distinction is that a character’s appearance and its collision behaviour are separate things. A visible model doesn’t automatically bring a working physics system with it.

For a hypothetical model replacement, we could give an existing Halo character Mario’s appearance while keeping the host character’s movement and collision setup. Or, if we were adding a new character, we would need to create or convert the collision data into a form the host engine understands and configure its behaviour. Halo wouldn’t need to recognise “Mario”; it would need a correctly configured character in its own simulation. That could stop him falling through the floor without reproducing how he moves in a Mario game.

So lesson number five is: Looking like two worlds have merged does not mean that their physics have merged too. There's work to be done to make that happen.

Asset provenance and permission are also separate questions from whether an integration works. A clip alone cannot answer them. Before making claims about how a creator obtained the assets, we need their documentation.

We should distinguish AI helping build the mashup from AI running it.

During development, an agent can use tools to investigate behaviour, propose integration code and help iterate on failures. REA’s documented workflow, for example, lets an agent inspect findings, ask follow-up questions, and write and test an implementation.

But once our reload rule works, it can run as ordinary deterministic code. Receive the event, start the puzzle, wait for a result, update the state. There is no inherent need to ask a language model what should happen every time the player reloads.

AI can be the engineer that builds the bridge without being the driver that crosses it.

That distinction also helps us evaluate claims about speed. A successful demo shows that someone achieved a result. Understanding how much AI accelerated it requires more evidence: the starting tools, existing mods, development history, human interventions and failed attempts. The finished clip doesn’t contain that history.

I find this trend exciting because it opens up questions about what people might build when investigating and connecting unfamiliar software becomes more accessible. Not to mention that level of creativity which makes me smile or even laugh out loud every time I see one out there.

But, if we're gonna get down to the nitty and gritty and talk technical, I scrutinize them about what they're trying to prove. What is running? How much of it is custom integration and coordination code? Which information crosses the boundary? Which interactions actually work? Where does the AI contribute?

An overlay, an event bridge and a hybrid game can all be worthwhile achievements. Describing them accurately gives the people building them credit for the work they actually did, and gives everyone else a better understanding of what remains unsolved.

Reverse engineering exposes capabilities. Integration connects them. Orchestration gives them new meaning.

Whatever the path you take, ultimately it comes down to our final lesson number six: AI or no AI, REA or whatever comes next...game mashups are a project like any other and still take a lot of work!

As for whether solving Candy Crush puzzles before reloading a gun in Call of Duty is a good idea...that is up for debate!

The Universal Modder repository documents a Minecraft and GTA V story-mode example. Its description identifies a Minecraft Fabric mod, a ScriptHookV component and a ReShade add-on, with camera, ground and event information exchanged over a local WebSocket connection. It also describes combining Minecraft’s colour and depth output with GTA’s frame, and translating selected Minecraft events into GTA effects.

There are two useful ideas in that description.

First, the games have specific integration components. A communication channel carries information, but code still has to decide what to send and what the receiving game should do with it.

Second, presentation and interaction are separate problems. Depth information helps decide which rendered surfaces should appear in front of others. That can make the combined image convincing. Making an object affect the other game’s simulation requires additional behaviour.

That is a substantial achievement. It is also a much more precise claim than “any two games can now be merged.” The project’s documented approach is evidence about that example, not a universal explanation for every viral mashup.

Project documentation checked on 20 October 2026; collision reference added on 29 October 2026. Named implementations are described from their maintainers’ documentation; I have not independently run or benchmarked them.