AI decompiled games and mashups: preservation, code quality and legal risk
- YT :: https://www.youtube.com/watch?v=s95Q7D0WR40
- Original title :: AI Is Decompiling Every Game | TheStandup
TheStandup episode with Prime, Teej, Trash and guest Casey Muratori on the recent wave of AI-assisted game decompilation and the mashups built on it (Spider-Man in Arkham City, Skate inside Call of Duty, Halo in Animal Crossing). Trash finds it the coolest thing ever but expects the novelty to fade in minutes. Casey says the AI output is bad C++ that is useless for learning or preservation, since the original machine code already preserves the game, but a fair head start if nobody else will do the work. The legal discussion centres on Adobe: cloning a product bite for bite is likely infringement, clean room or not, and the worry is that vendors respond by never shipping binaries again. Casey closes with why free copying does not pay the people who do the real work.
Sponsor: Sentry
- Parody ad about agents gaslighting you ("make CI green, delete the tests"). Sentry gives real production context: spans, session replay, logs next to stack traces.
The decomp and mashup wave
- Before this, decompiling a game and recreating it without a clean room took years and a group of people. The payoffs were modding and running on other hardware (for example Twilight Princess on a PC).
- Trash says that as a kid he wanted to mash universes together, so it is the coolest thing ever. But from the demos it is fun for about five minutes, then the novelty wears off. He compares it to every model release being accompanied by a 3D game demo nobody plays, and expects little impact on the games industry.
- He notes that people used to match code by changing one line and checking whether the compiled output matched, which is now down to a couple of hours.
- Teej separates two kinds of mashup. The first runs two games at once and ships state between physics engines (Spider-Man swinging in Arkham City). Physics, fighting and animation are still hard, so he ends up punching air; least fun to play.
- The second is a full decompile where a chunk of one game's systems is merged into another's loop (Skate inside Call of Duty). Teej thinks this one is more impactful, since you could lift a climbing or combat system almost wholesale into a demo or a game.
Do studios decompile?
- Casey is not sure how many studios study others' work. Gameplay mechanics are rarely complicated enough that you cannot just read them off from playing.
- Rendering is the part that gets analysed, and that needs no AI: capture the GPU commands, step through, see the render passes and buffer contents. There is also a fair amount of information sharing among graphics programmers (someone posted the GPU passes for the 2016 Doom).
- Real decompilation is mostly a retro preservation activity: source bases for Super Mario 64, speedrun analysis and so on.
Retro community, preservation and AI slop
- Casey understands the retro community's anger. Without AI, it would be crazy to decompile with no machine assistance (IDA Pro, Radare), and the task is tedious and repetitive, which suits AI: train on source plus compiled output over and over.
- But the sample he was sent (Banjo-Tooie) was atrocious code, "AI slop". It compiles to the right assembly but looks nothing like the original source, so it does not help humans understand what the programmers actually did.
- On preservation, the original machine code is enough: extract it, write an emulator, done. A decomp only helps if it is close to the real artifact, and this one is not, so it adds no preservation value beyond the machine code (arguably less, since it is not accurate).
- Teej likens it to complaints in mathematics about AI proofs that give a result nobody understands, losing the knowledge gained along the way. Casey disagrees: here the AI produces nothing new, only worse source than the assembly it started from.
- Casey sees real use as a starting point if nobody else is going to decompile and clean up the game; you can start fixing the C++ and guess what the original compiler era used. He compares it to messy AI PRs: the problem is people using AI for something it is not ready for and skipping the human cleanup. That does not mean the AI saved no time.
- Teej asks whether this is a producer versus consumer split: players just want the game to run at a good frame rate, while the mod community is both producer and consumer. A separate point is being free of console vendor decisions: rip your disc and play it on a Steam Deck.
Adobe, clean rooms and legality
- The group discusses a project cloning Adobe tools (Photoshop and others) bite for bite in Rust. Casey thinks decomp matters more for Photoshop than for games.
- Teej asks whether a spec-writing agent plus a code-writing agent would count as clean room. Casey says clean room does not help with copyright. Past look-and-feel lawsuits (Apple, Borland) found infringement for cloning an application's design, so cloning Photoshop, especially when you say "we gave an AI Photoshop and told it to copy it", could lose big judgments or force a takedown.
- Marketing it as a direct copy is itself exhibit A. In Oracle versus Google the implementation had to be different; with a matching decomp it is literally the same.
- Casey says Adobe has the most skin in the game: recurring revenue from a standardised product. Even paying a few thousand dollars in tokens to clone it internally would end seat licences. Nobody knows how courts will rule.
- Games are different: they are pirated on day one anyway, and publishers live on a value proposition ("it only costs $20, please support us"). Adobe is seen as turning the screws on customers.
Information sharing in game development
- Trash asks whether studios would simply share how they built something, versus stealing it via decomp. Casey says in the old days making a game was so hard that nobody guarded secret sauce much, and engines (Unity, Unreal) became standardised platforms that do not compete much.
- Sharing was common: GDC talks showed exactly how entity systems were built. Teej recalls a GDC talk on jump point search (a faster A star) that was freely shared.
- Teej adds that a search algorithm is rarely why players paid $20, so stolen tech is not the key differentiator.
- Trash flips the worry: OpenAI or other big players could watch an up-and-coming product, tell an AI to take everything, and consolidate the best ideas (Unreal's lighting into Unity) into whoever can spend billions.
Will vendors stop shipping binaries?
- Teej fears the Adobe outcome is that everything becomes client server and nobody is ever given a binary again. A small native tool maker (Blick editor) could have its product decompiled and re-released, pushing everyone into browsers and total dependence on vendors.
- Casey agrees these are legitimate concerns and expects legal action. Piracy is illegal yet widespread, but it is hard to run a good, always-on service that ships pirated binaries, so there is no pirate competitor to Steam, only sketchy peer-to-peer sites. That barrier to entry matters.
Consequences of making things free
- Casey rejects "if you can copy it, it should be free": money is how we organise what everyone works on. Free things mean far fewer people work on them, quality drops and it becomes hobbyist work. (Joke thread: "run for office", typing 100 million into every bank account, blowing up the moon or moving it closer.)
- If AI had started with robots making all physical goods, abundance would make digital goods free without a problem. It did not.
- He understands people not wanting Adobe paid (monopoly capture) but has not seen AIs solve those problems; people like the makers of FilePilot and Blick do the work and need to get paid. Until AIs solve everything, how do you pay people doing the important work?
- He is nervous and expects legal challenges. The hosts joke about the courts' understanding of software.