I've been absolutely loving the decomp projects that have been coming out lately. Huge props to the writer for this, Snowboard Kids is a real gem.
I'd also encourage people to check out the Legend of Dragoon recomp [1]. It's a real labor of love that has breathed new life into a largely abandoned game. You can play it fully vanilla, or with improved graphics, fixes to cumbersome design choices, bugfixes, etc.
It inspired me to use AI to decompile my favorite games as well, mostly Mega Man Battle Network games from my childhood. I'm not going to make it in 84 days though. I insist on understanding the game and documenting it myself instead of just having the AI do it all for me on autopilot.
As slow as that is, it's already led to some awesome moments. AI built a literal synthesizer that played back music straight out of the ROM. Mapped out all of the music that way. It was incredible.
Have neen reverse engineering my laptop's BIOS as well. AI is fully in charge of that one, and it's nearly done. Hopefully soon I'll have drivers and perhaps even coreboot.
I love this trend as well. More than any other project or trend, it makes me feel optimistic about a future with AI and little or no slop.
I had hoped to someday make retro games for all major 80s and 90s consoles. I started with the Atari 2600 12 years ago[0], and planned to move to other 6502 family systems when I had time. I realized last year that AI could essentially do all of what I considered the hard parts and craft of retro game assembly, which felt like having the rug pulled out from me. Projects like this have really turned that around for me.
New tools just mean old things become easier and new things become the difficult (where I think the fun is), but solvable, frontier. This category of projects inspired me to pick back up an Ultima V decompilation project I started more than 10 years ago[1,2]. I'm looking forward to a world where all of my childhood games are cracked wide open for mods, ports, etc.
It's pretty amazing what you can do when you embrace LLMs, figure out how to build one high-quality rigorous project with them, and then start working on more projects.
You become a machine with your workflow, once again limited only by your time/energy, tokens, and your discretion on how to spend it.
> It's pretty amazing what you can do when you embrace LLMs, figure out how to build one high-quality rigorous project with them, and then start working on more projects.
Indeed. But I think it's fair to say that just embracing LLMs is not enough.
Mildly related, but I have been waiting for goldeneye to be decompiled for a while but before that process has finished there is has been a spiritual successor(?) made that has scratched the single-player itch for me: https://store.steampowered.com/app/1574480/Agent_64_Spies_Ne...
I saw some news last week saying the project had reached 100%. Looking at the git repo (https://gitlab.com/kholdfuzion/goldeneye_src) that claim is a bit harder to verify, but maybe look again?
Even if you're the owner of the game, the contracts for the voice actors, motion capture, models, etc. frequently define very narrow terms of usage. Defining the exact release platforms is common. Not to mention profit sharing if the actors or studios you're hiring are popular.
It's even worse for retro games. Many times the original rights holder went out of business, sold their rights, died, or something else that muddies the ownership chain.
Including the one my username is inspired by. It's why you see a lot of fan remakes. Another sad side effect of corporate owned IP is also a lot of times the individuals who did the bulk of the work on something can't be the ones to do a remake. They don't own their own work. A company owns it. That's what most of us sign up for to get a paycheck. But when it's something like film or games, the effect on artists or designers can be pretty depressing.
So yes, games are not unique in this way. I am hopeful in the optimistic future case where LLMs lead to lower barriers to entry, UBI, and so forth that copyright essentially disappears, or at the very least is severely reformed.
Many things should simply enter the public domain at a far more accelerated rate.
Would you still allow transfer of copyrights? Otherwise 1) would really make things more difficult in this case, because you're gonna need to deal with far more people (and potentially far more complicated contracts to try to work around this problem). A shorter expiration period would definitely help, at the very least a 'use it or lose it' provision that would remove the protection from works that are no longer being sold.
I would not. I'm far less concerned about the rights and profits of copyright holders and far more concerned with society and civilization having access to the art that's produced within it.
Since I'm just pitching wild ideas on the Internet of course I have the freedom to make any suggestion I want, but I would like to live in a world where (a) no companies or rights owners are able to play bullshit games with gating access to art that can be reproduced at trivial cost and (b) we can consume all the art we want that's past its sell-by date. It's insane to me that we don't have free, legal databases of every work of art created before, say, 2006.
> Rights can't be held by corporations, only individuals. So the rights to a piece of art or IP would always trace down to a list of names.
Isn't the current system setup around the idea that the company gets the rights, and in return the workers get a basically risk-free salary? Wouldn’t your proposal undo that, so then workers took on the risk of whether they got paid, based on whether the game ends up being profitable?
In theory, the financier or team of financiers would be added onto the list of creating individuals. I suppose some sort of fractional representation might be worked out.
That would be a tough change... An easier one, which is how things used to be, that everything enters public domain IF not renewed after X years (let's say 20). Abandoned or complex IP would just become public domain unless the owners themselves figure things out and demonstrate interest with the renewal process. Even a modest fee would lead to a huge gain without much friction for the true rights holders.
I don't know how they made it, but there was a GoldenEye made for Xbox 360 that seems to only update the UI. The controls are maybe a little different, but you can swap between original and updated renderer in game. Anyway, they couldn't ship in the end due to legal stuff.
Historically there was a notion of "clean room" reimplementation.
These days it seems people translate the actual game code into a different representation of that same code and that makes it open source? Github is full of these.
> Historically there was a notion of "clean room" reimplementation
These projects start off with the original assembly code and use it actively throughout all stages. This is about as far away from clean room as you get.
These projects do not start with assembly. They start with machine code interleaved with data. Even getting to assembly through a disassembled requires some input and understanding. Usually these are raw binaries with no (or limited) metadata.
When run through a disassembler, in most cases, it’s probably the first time anyone has ever looked at the assembly (assuming PlayStation or newer). There are no comments or labels or symbols. Not what most people would consider “the original assembly”.
It seems like it could go either way to me in the US (not a lawyer, but someone who has a fair amount of experience in reverse engineering / fair use issues).
On the one hand, it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.
On the other hand, these projects are mostly free, intended for owners of the game to play the original game on a different platform or in a modified format, and not likely to have a negative effect on the original work's desirability or value. And, the reproductions aren't complete and alone usually produce limited to no value to a consumer (usually, they won't start without the original game files). These are the other important factors considered in fair use determinations and generally go the way of these being OK.
So, it's hard to say. With reverse engineering and copyright in the US in general, context is crucially important; something that would be completely illegal for one purpose (ie - decompiling and recompiling a competitor's software to distribute it without a license or use it internally without purchasing it would be obviously illegal) could be OK for another one.
In a sane world, if brought before a court, the binary itself wouldn't have any protection unless hand authored. The actual creative work/human expression was the source code. The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.
Then a freshly written project would be completely different with no derivative elements at all; the only commonality between the two codebases is their functional elements. You can compile a decomp into the same binary, but that's only to prove functional equivalence. The intended mode would be with a modern compiler that completely rewrites the logic (it might even have to if it writes it for a completely different computer architecture, which describes every retro console game). Then neither the source nor the compiled artifact would match.
> The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.
I strongly disagree with this notion from even a conceptual (much less legal) level; the point of compilation is not to erase the algorithms the programmer implemented, just to optimize and implement them.
> You can compile a decomp into the same binary, but that's only to prove functional equivalence.
This is like saying that a translated book is only "functionally" identical to the original; there's a lot of precedent in copyright law for this not being the case, and I don't think any argument revolving around the transformativeness of the compilation process would fly at all.
A huge portion of the actual thing I write when writing a program does not exist at all in the compiled binary. Names, types, type parameters, etc. being big ones, but many types are also aliases for the empty struct, so their value doesn't exist at runtime either. Conversely, I can write _.map(_.map(_.map(f))) and have that turn into all sorts of looping and branching logic that I didn't write, and the meaning of which is basically "do whatever must be done to make the types work".
Programs as written are nothing like programs as compiled, certainly not as an expressive endeavor. Books don't have an analog. There's no point where we strip all conceptual meaning from the book and leave only the procedural algorithms the semantics demand. There's no point where we replace all the individual words with autovectorized versions, or where we automatically delete impossible sentences, or remove every layer of abstraction that the programmer put in there exactly for the ability to convey ideas.
> it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.
Absolutely false. There are an infinite number of programs that will compile to the same machine code. Especially when an optimizer is involved. Discovering one of those is a creative process, transformative, and protected.
Using an LLM to do it for you? I wouldn’t touch that with a 10 foot pole. Seems too close to mechanical transformation to me.
Most of these projects carefully distribute only the source code representation of the binaries, for this reason, relying on the consumer to acquire / own the art assets and copyrighted material (logos, trademarks, etc.).
None of the original source code exists in these projects. It’s all created from scratch.
Copyright for this new code is owned by the person doing decompilation. No one knows how similar to the original it is or not, just that it compiles to the same output.
Edit to clarify: by not exist, I mean it is not publicly available.
It's not an obvious legal argument that it is not a derivative work of the compiled code or the original source code that produced that. Clean room reverse engineering is meant to give you a strong argument for that, and while it's not necessarily required to prevail against a copyright case (or actually sufficient) it's gonna make things harder if you don't. (All of this is made more murky because copyright is meant to only cover expressions of human creativity, and code is kind of a mix of creativity and mechanical details: the clean room approach is meant to separate out the mechanical details)
Also, If it is an unauthorized derivative work, as I understand it then it might not even qualify for copyright protection itself.
A decompilation is not clean room, nor is it "created from scratch". If that was the case, you could just compile a program to remove the copyright, because the machine code doesn't resemble the source code at all either.
A reimplementation or a behavior-based clone is an entirely different legal world from decompilation.
The compiled binary is protected and the property of the original company. The source code written by people doing decompilation is owned by the people doing the decompilation. That source code can compile to a lot of different binary representations, just like a lot of code representations (infinitely many) could compile to the original binary.
In fact, the goal of most decomp not to produce the same binary, that’s just used as a validation.
There was a decompilation project of GTA 3 and Vice City. It got DMCAed by Rockstar Games, despite requiring the user to provide their own game assets.
Historically these projects have gone to match byte for byte recreations which ensures that they are derivative works making them infringing copyright.
> One small but useful improvement was to give every task an explicit deadline and expose that deadline to the agent.
I’m really curious about trying this myself. Recently I’ve been handing off tasks for agents to complete on their own more and more. While their work is acceptable I’ve found them to not only take a long time to complete it, but they often add too much complexity and tests.
I just did one last weekend, but it is a game that was clearly written in assembler in the first place (Elite 8088 CGA).
Trying to reconstruct the original build environment that Andy Onions (where are you?) used took some time. It was assembled with 16-bit MASM, but you can't easily run 16-bit exes under 64-bit Windows, so a bit of a kludge to set up DOSbox where the LLMs can push/pull in-and-out of it while being able to drive it enough to execute MASM and read the stderr and output files etc to get a feedback loop going.
Making up plausible function names and branch labels was pretty quick for LLMs.
I think Marx is rolling in his grave over the tirelessly expended human to recreate what almost definitely already exists on a floppy sitting in some “IP - Do Not Touch” lock box. But maybe endless puzzles for ever cleverer people is the point of it all.
I dunno. I was a gamedev. I'm pretty sure everything got thrown out. I don't remember ever taking any source home. It was all managed through Visual Source Safe (!) on a local server.
The 80s games were mostly coded in bedrooms, but after that it all moved to teams in offices and a lot of studios went boom-to-bust pretty quickly.
Its really great how we can breathe new life into older games like this. I'm currently working solo on a Tales of Symphonia gamecube decomp. My aim is to let AI do everything of substance. currently about 3400 functions are exact out of about 4800. So still a way to go. But I haven't written a single line yet.
How did you get started? I have a project in mind and would love to try, but getting a foothold on it feels really hard when you are starting with an ISO image and an empty folder.
But in essence it's not so complex. You only need the original compiler that was used to compile the game and tools like ghidra. Binutils for the architecture can help. From there you ask the agent to start building the project. Prepare to spend a ton of tokens though if you go the full AI route.
LLMs are truly amazing and I hope those decomp will keep coming! I am currently watching the Test Drive Unlimited decompilation project, which seems to use a mix of LLM decomp and actual engine improvement (porting the game to Vulkan and a new physics engine instead of Havok):
https://github.com/opentestdriveunlimited/OpenTestDriveUnlim...
It and the sequel were among two of the best multiplayer games on the system. It was so sad to see the series die when it went portable instead of continuing to be a ton of fun.
https://github.com/n64decomp/perfect_dark claims to be “a complete decompilation of Perfect Dark for the Nintendo 64”. And: “When a matching decompilation is compiled with the same compiler that the original developers used, the output will be exactly the same as the retail game, byte for byte.”
Relatedly, https://github.com/perfect-dark-pc-port/perfect_dark forked from the above describes itself as “a work-in-progress port of the Perfect Dark decompilation to modern platforms”. Further: “The game is in a mostly functional state, with both singleplayer and split-screen multiplayer modes fully working.
There are minor graphics- and gameplay-related issues, and possibly occasional crashes.”
Does decompiling a game made by a certain development team help decompile others made by the same people? Because you might know what patterns to look for?
No, not at all. I know where I worked there was zero code reuse across teams and games.
Games of this generation had code that wasn't intended to be supported or managed after release (no patches for those consoles) and so the code tended to be fairly horrible.
I love the game Monster Hunter2 so much that I once practiced decompiling it. I worked on it for about two months and got maybe 5% done. Sometimes I really admire people who do this kind of decompilation work.
It's especially annoying that LLMs/agents are a logical starting point for decompiling old games but there is a significant backlash against it as the gaming community is very anti-AI and consumers of the benefits decompiling offers tend to be noncoders who don't believe that AI can do more than slop. I've seen takes such as "they're too lazy to learn C++" and accepting a PR from someone using Claude taints the project irrevocably.
I think the backlash isn’t necessarily against the decomp itself, but rather the sloppy/buggy PC ports that often come from it.
In my mind using an LLM to assist with decompiling is fine, as the output is provably correct. It either compiles to the original binary or it doesn’t.
Turning that into a playable PC game with controls that feel good, etc, is a different story. That requires human taste & judgement.
Yeah the problem isn't people using AI, it's the flood of lazy "native ports" that have no meaningful improvement over playing the game in an emulator and often crash or glitch out a level or two in because unsurprisingly a lot of the people who leave all the work to Claude don't feel like testing the game themselves. LLMs are a godsend for RE work when they're used properly, but a lot of these projects just waste everybody's time.
to be fair much of the fun in decompiling/RE is the puzzle solving, it's like a giant crossword puzzle that you fill in bit by bit, slowly figuring out how things work.
Having an LLM do large parts of that for you is probably kinda boring for many.
The problem isn't that people consider it boring, it's that the use of LLMs is considered essentially sacrilegious, and whatever end-result that's created is considered tainted, often regardless of the extent of LLM usage.
Which does kind of suck. Yeah, it's not nearly as cool to say "I prompted a probabilistic pile of tensors and it did the hard work for me", and I think it majorly adjusts how "impressive" projects are. There's no point pretending like decompiling a game by hand and using GPT-6.7 to do it are remotely comparable.
The suck-y part is that if you do the decomp with GPT-6.7 and produce, say, a PC port of an early 2000s console game, a large number of people will refuse to touch it and treat it as if you have committed a cardinal sin. Maybe that's justified? I dunno. It definitely goes beyond people just saying it isn't as fun.
Its curious the cultural differences you see in some places too, a not too uncommon Japanese one I've seen is where the cardinal sin is "stealing" other people's creative works, rather than anything specifically involving LLMs.
Meanwhile so many westerners see LLMs as "stealing IP", it becomes a bit paradoxical where the lines get drawn.
Even Japanese attitudes towards IP are not that clear cut. One of the reasons the MiniDisc format was so popular in Japan vs the rest of the world was that physical media in Japan is expensive, so there are stores which rent out CDs. Those CDs would often be copied to MD (or later to PCs.)
The backlash has only been growing as the result of a significant number of incredibly sloppy decomps, either creating unreadable codebases or outright being so buggy/inaccurate as to be useless. Every day I see another decomp pop up that exists solely for the cred of being the first to do so, which is then promptly abandoned by the developer because it doesn't fucking work.
on the flip side retro games are almost completely and entirely an aesthetic experience. like if something totally subjective and personal like nostalgia is not just a valid reason, but the #1 reason, to be engaged with retro gaming, why isn't some random condition about the process of resurrecting the games also valid?
i think you agree that there is. but it should change your language about this idea of "consumers" and "benefits" - like this is the difference between making code and making a product. nobody NEEDS retro games. in my opinion, they aren't even that good! they are completely and utterly an aesthetic experience. the process IS the product.
If the process is the product, then anyone who is not involved with the process has no right to say anything about the product.
Not to mention, there's a lot of stuff beyond an "aesthetic experience". Videogames have historical value, and they have relevancy at the very least as a testament of the state of the industry at any given point.
Legend of Dragoon, for example, integrated QTE-like controls in its attacks, even as a turn-based game. FFVIII, released the same year, implemented interaction in a somewhat similar way. These two are very early predecessors to mechanics Clair Obscur: Expedition 33 much more recently used. That has value.
If anyone wants to establish random conditions as to why they consider a work to be worthy or not, they may have those. But then they should keep them to themselves, rather than pretending people shouldn't care about something because of the way it was done. It's like the classic situation of someone complaining about how some open source project doesn't do something exactly in the way they like. I have nothing but contempt and despise for that sort of people, and it's a whole order of magnitude worse here, where the "problem" stems from their political stance, which nobody with a pulse should give a crap about.
I'm still baffled by RE community aiming for "100% asm match", needing to reproduce specific compiler version, instead of aiming for functional equivalence and cleaner code
is there really no tools whatsoever that produce proof certificates for "these two functions do the same thing"?
Game behavior can be tied so closely to quirky hardware behavior that I doubt such a tool would be simple to create. You’d have to verify that your code produces the same hardware state. And different (ie more efficient) code almost by definition produces a different hardware state than the original code. Thus changing the game.
Who said games were well written? Older games are often very sloppy and buggy, and abuse the specific hardware they're designed for to get extra performance, unique graphical effects, etc.
Emulators constantly run into games that don't run because of specific hardware nuances that may or may not have been intentionally used (Ex. relying on exact cycle counts, reading uninitialized memory, changing values while they're used, etc.).
I wouldn't characterize that as sloppy or buggy in any way (though certainly that is also true for some games). Exploiting hardware in new and novel ways was an essential part of developing for older consoles.
This is something someone only familiar with writing code for general purpose devices or higher level languages can't imagine. But when you're building for one very specific hardware platform you can tailor your code to that platform in ways that simply aren't possible when building for portability.
I've been absolutely loving the decomp projects that have been coming out lately. Huge props to the writer for this, Snowboard Kids is a real gem.
I'd also encourage people to check out the Legend of Dragoon recomp [1]. It's a real labor of love that has breathed new life into a largely abandoned game. You can play it fully vanilla, or with improved graphics, fixes to cumbersome design choices, bugfixes, etc.
[1] https://legendofdragoon.org/projects/severed-chains/
Loving this trend too.
It inspired me to use AI to decompile my favorite games as well, mostly Mega Man Battle Network games from my childhood. I'm not going to make it in 84 days though. I insist on understanding the game and documenting it myself instead of just having the AI do it all for me on autopilot.
As slow as that is, it's already led to some awesome moments. AI built a literal synthesizer that played back music straight out of the ROM. Mapped out all of the music that way. It was incredible.
Have neen reverse engineering my laptop's BIOS as well. AI is fully in charge of that one, and it's nearly done. Hopefully soon I'll have drivers and perhaps even coreboot.
I love this trend as well. More than any other project or trend, it makes me feel optimistic about a future with AI and little or no slop.
I had hoped to someday make retro games for all major 80s and 90s consoles. I started with the Atari 2600 12 years ago[0], and planned to move to other 6502 family systems when I had time. I realized last year that AI could essentially do all of what I considered the hard parts and craft of retro game assembly, which felt like having the rug pulled out from me. Projects like this have really turned that around for me.
New tools just mean old things become easier and new things become the difficult (where I think the fun is), but solvable, frontier. This category of projects inspired me to pick back up an Ultima V decompilation project I started more than 10 years ago[1,2]. I'm looking forward to a world where all of my childhood games are cracked wide open for mods, ports, etc.
[0]: https://github.com/cleak/FlappyBoot [1]: https://github.com/cleak/u5-spec (spec for Ultima V binary) [2]: https://github.com/cleak/u5-engine (Rust port of Ultima V made from the spec; still lots of prose slop)
Any advances in emulators recently? I would love to see Nintendo get into a legal tussle with Big AI. Giant douche can fight turd sandwiches.
It's pretty amazing what you can do when you embrace LLMs, figure out how to build one high-quality rigorous project with them, and then start working on more projects.
You become a machine with your workflow, once again limited only by your time/energy, tokens, and your discretion on how to spend it.
matching decompilation is a verifiable target. Its hard to create slop that still matches. The same does not hold up for coding with llms normally.
> It's pretty amazing what you can do when you embrace LLMs, figure out how to build one high-quality rigorous project with them, and then start working on more projects.
Indeed. But I think it's fair to say that just embracing LLMs is not enough.
I'd consider embracing to include developing expertise in the tool.
Mildly related, but I have been waiting for goldeneye to be decompiled for a while but before that process has finished there is has been a spiritual successor(?) made that has scratched the single-player itch for me: https://store.steampowered.com/app/1574480/Agent_64_Spies_Ne...
Worth a look if you want a bit of nostalgia.
I saw some news last week saying the project had reached 100%. Looking at the git repo (https://gitlab.com/kholdfuzion/goldeneye_src) that claim is a bit harder to verify, but maybe look again?
I’m surprised the game companies themselves aren’t interested in these projects.
Seems like easy money to just decompile a retro game, add some quality of life improvements and stick it on steam.
Are their hands tied by legal or what other factors are preventing this?
> Are their hands tied by legal
Yes.
Even if you're the owner of the game, the contracts for the voice actors, motion capture, models, etc. frequently define very narrow terms of usage. Defining the exact release platforms is common. Not to mention profit sharing if the actors or studios you're hiring are popular.
It's even worse for retro games. Many times the original rights holder went out of business, sold their rights, died, or something else that muddies the ownership chain.
Yes many games are caught up in IP hell.
Including the one my username is inspired by. It's why you see a lot of fan remakes. Another sad side effect of corporate owned IP is also a lot of times the individuals who did the bulk of the work on something can't be the ones to do a remake. They don't own their own work. A company owns it. That's what most of us sign up for to get a paycheck. But when it's something like film or games, the effect on artists or designers can be pretty depressing.
So yes, games are not unique in this way. I am hopeful in the optimistic future case where LLMs lead to lower barriers to entry, UBI, and so forth that copyright essentially disappears, or at the very least is severely reformed.
Many things should simply enter the public domain at a far more accelerated rate.
I think that we should change copyright law such that
1) Rights can't be held by corporations, only individuals. So the rights to a piece of art or IP would always trace down to a list of names.
2) Everything enters the public domain after 20 years or the death of the entire list of ownership.
Would you still allow transfer of copyrights? Otherwise 1) would really make things more difficult in this case, because you're gonna need to deal with far more people (and potentially far more complicated contracts to try to work around this problem). A shorter expiration period would definitely help, at the very least a 'use it or lose it' provision that would remove the protection from works that are no longer being sold.
I would not. I'm far less concerned about the rights and profits of copyright holders and far more concerned with society and civilization having access to the art that's produced within it.
Since I'm just pitching wild ideas on the Internet of course I have the freedom to make any suggestion I want, but I would like to live in a world where (a) no companies or rights owners are able to play bullshit games with gating access to art that can be reproduced at trivial cost and (b) we can consume all the art we want that's past its sell-by date. It's insane to me that we don't have free, legal databases of every work of art created before, say, 2006.
> Rights can't be held by corporations, only individuals. So the rights to a piece of art or IP would always trace down to a list of names.
Isn't the current system setup around the idea that the company gets the rights, and in return the workers get a basically risk-free salary? Wouldn’t your proposal undo that, so then workers took on the risk of whether they got paid, based on whether the game ends up being profitable?
In theory, the financier or team of financiers would be added onto the list of creating individuals. I suppose some sort of fractional representation might be worked out.
That would be a tough change... An easier one, which is how things used to be, that everything enters public domain IF not renewed after X years (let's say 20). Abandoned or complex IP would just become public domain unless the owners themselves figure things out and demonstrate interest with the renewal process. Even a modest fee would lead to a huge gain without much friction for the true rights holders.
I don't know how they made it, but there was a GoldenEye made for Xbox 360 that seems to only update the UI. The controls are maybe a little different, but you can swap between original and updated renderer in game. Anyway, they couldn't ship in the end due to legal stuff.
>Are their hands tied by legal or what other factors are preventing this?
Nightdive studios has a few blog posts regarding this.
The problem apparently is that a lot of retro game IP changed hands when records were physical.
So Nightdive goes to Company A and says "Hey do you have the rights to <Game> or did you sell them"?
Company A says "You can pay us 50,000 dollars to check our records we are not sure."
Nightdive says "Ok, seeing as you dont know if you own the game, could you give us permission just in case you do"
Company A: "No, we would need to review the records. However if you released the game to market, we would check just to see if we can sue"
Nightdive has an identical conversation with Company B, who may have bought the rights from Company A but only have archival records.
Nightdive walks away from the project.
What's the legal status of these?
Historically there was a notion of "clean room" reimplementation.
These days it seems people translate the actual game code into a different representation of that same code and that makes it open source? Github is full of these.
> Historically there was a notion of "clean room" reimplementation
These projects start off with the original assembly code and use it actively throughout all stages. This is about as far away from clean room as you get.
These projects do not start with assembly. They start with machine code interleaved with data. Even getting to assembly through a disassembled requires some input and understanding. Usually these are raw binaries with no (or limited) metadata.
When run through a disassembler, in most cases, it’s probably the first time anyone has ever looked at the assembly (assuming PlayStation or newer). There are no comments or labels or symbols. Not what most people would consider “the original assembly”.
Ghidra is able to figure out the functions in around 99%++ of cases though
It seems like it could go either way to me in the US (not a lawyer, but someone who has a fair amount of experience in reverse engineering / fair use issues).
On the one hand, it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.
On the other hand, these projects are mostly free, intended for owners of the game to play the original game on a different platform or in a modified format, and not likely to have a negative effect on the original work's desirability or value. And, the reproductions aren't complete and alone usually produce limited to no value to a consumer (usually, they won't start without the original game files). These are the other important factors considered in fair use determinations and generally go the way of these being OK.
So, it's hard to say. With reverse engineering and copyright in the US in general, context is crucially important; something that would be completely illegal for one purpose (ie - decompiling and recompiling a competitor's software to distribute it without a license or use it internally without purchasing it would be obviously illegal) could be OK for another one.
In a sane world, if brought before a court, the binary itself wouldn't have any protection unless hand authored. The actual creative work/human expression was the source code. The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.
Then a freshly written project would be completely different with no derivative elements at all; the only commonality between the two codebases is their functional elements. You can compile a decomp into the same binary, but that's only to prove functional equivalence. The intended mode would be with a modern compiler that completely rewrites the logic (it might even have to if it writes it for a completely different computer architecture, which describes every retro console game). Then neither the source nor the compiled artifact would match.
> The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.
I strongly disagree with this notion from even a conceptual (much less legal) level; the point of compilation is not to erase the algorithms the programmer implemented, just to optimize and implement them.
> You can compile a decomp into the same binary, but that's only to prove functional equivalence.
This is like saying that a translated book is only "functionally" identical to the original; there's a lot of precedent in copyright law for this not being the case, and I don't think any argument revolving around the transformativeness of the compilation process would fly at all.
A huge portion of the actual thing I write when writing a program does not exist at all in the compiled binary. Names, types, type parameters, etc. being big ones, but many types are also aliases for the empty struct, so their value doesn't exist at runtime either. Conversely, I can write _.map(_.map(_.map(f))) and have that turn into all sorts of looping and branching logic that I didn't write, and the meaning of which is basically "do whatever must be done to make the types work".
Programs as written are nothing like programs as compiled, certainly not as an expressive endeavor. Books don't have an analog. There's no point where we strip all conceptual meaning from the book and leave only the procedural algorithms the semantics demand. There's no point where we replace all the individual words with autovectorized versions, or where we automatically delete impossible sentences, or remove every layer of abstraction that the programmer put in there exactly for the ability to convey ideas.
> it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.
Absolutely false. There are an infinite number of programs that will compile to the same machine code. Especially when an optimizer is involved. Discovering one of those is a creative process, transformative, and protected.
Using an LLM to do it for you? I wouldn’t touch that with a 10 foot pole. Seems too close to mechanical transformation to me.
Clean room might get you past copyrighted code, but surely it won't get you past trademarks or copyrighted artistic work?
Most of these projects carefully distribute only the source code representation of the binaries, for this reason, relying on the consumer to acquire / own the art assets and copyrighted material (logos, trademarks, etc.).
The code assets are just as copyright encumbered as the art assets.
None of the original source code exists in these projects. It’s all created from scratch.
Copyright for this new code is owned by the person doing decompilation. No one knows how similar to the original it is or not, just that it compiles to the same output.
Edit to clarify: by not exist, I mean it is not publicly available.
It's not an obvious legal argument that it is not a derivative work of the compiled code or the original source code that produced that. Clean room reverse engineering is meant to give you a strong argument for that, and while it's not necessarily required to prevail against a copyright case (or actually sufficient) it's gonna make things harder if you don't. (All of this is made more murky because copyright is meant to only cover expressions of human creativity, and code is kind of a mix of creativity and mechanical details: the clean room approach is meant to separate out the mechanical details)
Also, If it is an unauthorized derivative work, as I understand it then it might not even qualify for copyright protection itself.
A decompilation is not clean room, nor is it "created from scratch". If that was the case, you could just compile a program to remove the copyright, because the machine code doesn't resemble the source code at all either.
A reimplementation or a behavior-based clone is an entirely different legal world from decompilation.
The compiled binary is protected and the property of the original company. The source code written by people doing decompilation is owned by the people doing the decompilation. That source code can compile to a lot of different binary representations, just like a lot of code representations (infinitely many) could compile to the original binary.
In fact, the goal of most decomp not to produce the same binary, that’s just used as a validation.
>is owned by the people doing the decompilation
True, but as a derivative work of the original source code they don't have rights to do anything with that code without infringing copyright.
Yes, I agree with you (see my sibling post), but it's not what the post I replied to was saying.
There was a decompilation project of GTA 3 and Vice City. It got DMCAed by Rockstar Games, despite requiring the user to provide their own game assets.
Historically these projects have gone to match byte for byte recreations which ensures that they are derivative works making them infringing copyright.
> One small but useful improvement was to give every task an explicit deadline and expose that deadline to the agent.
I’m really curious about trying this myself. Recently I’ve been handing off tasks for agents to complete on their own more and more. While their work is acceptable I’ve found them to not only take a long time to complete it, but they often add too much complexity and tests.
For people who've done matching decomps: what burned the most calendar time for you, toolchain freeze or the last 5% of non-matching functions?
I just did one last weekend, but it is a game that was clearly written in assembler in the first place (Elite 8088 CGA).
Trying to reconstruct the original build environment that Andy Onions (where are you?) used took some time. It was assembled with 16-bit MASM, but you can't easily run 16-bit exes under 64-bit Windows, so a bit of a kludge to set up DOSbox where the LLMs can push/pull in-and-out of it while being able to drive it enough to execute MASM and read the stderr and output files etc to get a feedback loop going.
Making up plausible function names and branch labels was pretty quick for LLMs.
>Making up plausible function names and branch labels was pretty quick for LLMs.
there was official source code release for 6502 port, why not match names from that one?
I think Marx is rolling in his grave over the tirelessly expended human to recreate what almost definitely already exists on a floppy sitting in some “IP - Do Not Touch” lock box. But maybe endless puzzles for ever cleverer people is the point of it all.
I dunno. I was a gamedev. I'm pretty sure everything got thrown out. I don't remember ever taking any source home. It was all managed through Visual Source Safe (!) on a local server.
The 80s games were mostly coded in bedrooms, but after that it all moved to teams in offices and a lot of studios went boom-to-bust pretty quickly.
Yeah I am decompiling a PS2 game. It's not easy but I think I finally have the right setup.
Sounds cool, please document your steps and pitfalls. I would live to try this one day.
Its really great how we can breathe new life into older games like this. I'm currently working solo on a Tales of Symphonia gamecube decomp. My aim is to let AI do everything of substance. currently about 3400 functions are exact out of about 4800. So still a way to go. But I haven't written a single line yet.
How did you get started? I have a project in mind and would love to try, but getting a foothold on it feels really hard when you are starting with an ISO image and an empty folder.
For gamecube games you are in luck because there is a template: https://github.com/encounter/dtk-template
But in essence it's not so complex. You only need the original compiler that was used to compile the game and tools like ghidra. Binutils for the architecture can help. From there you ask the agent to start building the project. Prepare to spend a ton of tokens though if you go the full AI route.
LLMs are truly amazing and I hope those decomp will keep coming! I am currently watching the Test Drive Unlimited decompilation project, which seems to use a mix of LLM decomp and actual engine improvement (porting the game to Vulkan and a new physics engine instead of Havok): https://github.com/opentestdriveunlimited/OpenTestDriveUnlim...
I don’t remember this game at all - and there weren’t many N64 games, especially in the first couple of years.
Watching bits of videos from this guy's series on beating every N64 game (including JP-only releases) is a fun way to find out about interesting games I missed from back then. https://www.youtube.com/playlist?list=PLrwJXOVKrLbIDAiT9b4Lk...
It and the sequel were among two of the best multiplayer games on the system. It was so sad to see the series die when it went portable instead of continuing to be a ton of fun.
Interesting.
For me it was Goldeneye (of course) and Diddy Kong Racing.
Awesome. Hopefully AI will allow more games to be decompiled in the future. Anyone working on a decomp of Perfect Dark?
https://github.com/n64decomp/perfect_dark claims to be “a complete decompilation of Perfect Dark for the Nintendo 64”. And: “When a matching decompilation is compiled with the same compiler that the original developers used, the output will be exactly the same as the retail game, byte for byte.”
Relatedly, https://github.com/perfect-dark-pc-port/perfect_dark forked from the above describes itself as “a work-in-progress port of the Perfect Dark decompilation to modern platforms”. Further: “The game is in a mostly functional state, with both singleplayer and split-screen multiplayer modes fully working. There are minor graphics- and gameplay-related issues, and possibly occasional crashes.”
- super smash bros
- LoZelda Ocarina of time& majora’s mask
- starfox 64
- Mario party
- extreme G racing
- jet force Gemini
- golden eye
- conkers bad fur day
- Mario 64
- Tony hawk
Man… so much nostalgia
Does decompiling a game made by a certain development team help decompile others made by the same people? Because you might know what patterns to look for?
No, not at all. I know where I worked there was zero code reuse across teams and games.
Games of this generation had code that wasn't intended to be supported or managed after release (no patches for those consoles) and so the code tended to be fairly horrible.
It varies. Nintendo for example has plenty of different teams and internal frameworks, but not every game uses them.
I love the game Monster Hunter2 so much that I once practiced decompiling it. I worked on it for about two months and got maybe 5% done. Sometimes I really admire people who do this kind of decompilation work.
It's especially annoying that LLMs/agents are a logical starting point for decompiling old games but there is a significant backlash against it as the gaming community is very anti-AI and consumers of the benefits decompiling offers tend to be noncoders who don't believe that AI can do more than slop. I've seen takes such as "they're too lazy to learn C++" and accepting a PR from someone using Claude taints the project irrevocably.
I think the backlash isn’t necessarily against the decomp itself, but rather the sloppy/buggy PC ports that often come from it.
In my mind using an LLM to assist with decompiling is fine, as the output is provably correct. It either compiles to the original binary or it doesn’t.
Turning that into a playable PC game with controls that feel good, etc, is a different story. That requires human taste & judgement.
Yeah the problem isn't people using AI, it's the flood of lazy "native ports" that have no meaningful improvement over playing the game in an emulator and often crash or glitch out a level or two in because unsurprisingly a lot of the people who leave all the work to Claude don't feel like testing the game themselves. LLMs are a godsend for RE work when they're used properly, but a lot of these projects just waste everybody's time.
The backlash will soon die out once the majority see the results.
(Of course there will always be the annoying "never AI" virtue-signalers, but the same can be said about anything.)
to be fair much of the fun in decompiling/RE is the puzzle solving, it's like a giant crossword puzzle that you fill in bit by bit, slowly figuring out how things work. Having an LLM do large parts of that for you is probably kinda boring for many.
The problem isn't that people consider it boring, it's that the use of LLMs is considered essentially sacrilegious, and whatever end-result that's created is considered tainted, often regardless of the extent of LLM usage.
Which does kind of suck. Yeah, it's not nearly as cool to say "I prompted a probabilistic pile of tensors and it did the hard work for me", and I think it majorly adjusts how "impressive" projects are. There's no point pretending like decompiling a game by hand and using GPT-6.7 to do it are remotely comparable.
The suck-y part is that if you do the decomp with GPT-6.7 and produce, say, a PC port of an early 2000s console game, a large number of people will refuse to touch it and treat it as if you have committed a cardinal sin. Maybe that's justified? I dunno. It definitely goes beyond people just saying it isn't as fun.
Its curious the cultural differences you see in some places too, a not too uncommon Japanese one I've seen is where the cardinal sin is "stealing" other people's creative works, rather than anything specifically involving LLMs.
Meanwhile so many westerners see LLMs as "stealing IP", it becomes a bit paradoxical where the lines get drawn.
Even Japanese attitudes towards IP are not that clear cut. One of the reasons the MiniDisc format was so popular in Japan vs the rest of the world was that physical media in Japan is expensive, so there are stores which rent out CDs. Those CDs would often be copied to MD (or later to PCs.)
The backlash has only been growing as the result of a significant number of incredibly sloppy decomps, either creating unreadable codebases or outright being so buggy/inaccurate as to be useless. Every day I see another decomp pop up that exists solely for the cred of being the first to do so, which is then promptly abandoned by the developer because it doesn't fucking work.
on the flip side retro games are almost completely and entirely an aesthetic experience. like if something totally subjective and personal like nostalgia is not just a valid reason, but the #1 reason, to be engaged with retro gaming, why isn't some random condition about the process of resurrecting the games also valid?
i think you agree that there is. but it should change your language about this idea of "consumers" and "benefits" - like this is the difference between making code and making a product. nobody NEEDS retro games. in my opinion, they aren't even that good! they are completely and utterly an aesthetic experience. the process IS the product.
If the process is the product, then anyone who is not involved with the process has no right to say anything about the product.
Not to mention, there's a lot of stuff beyond an "aesthetic experience". Videogames have historical value, and they have relevancy at the very least as a testament of the state of the industry at any given point.
Legend of Dragoon, for example, integrated QTE-like controls in its attacks, even as a turn-based game. FFVIII, released the same year, implemented interaction in a somewhat similar way. These two are very early predecessors to mechanics Clair Obscur: Expedition 33 much more recently used. That has value.
If anyone wants to establish random conditions as to why they consider a work to be worthy or not, they may have those. But then they should keep them to themselves, rather than pretending people shouldn't care about something because of the way it was done. It's like the classic situation of someone complaining about how some open source project doesn't do something exactly in the way they like. I have nothing but contempt and despise for that sort of people, and it's a whole order of magnitude worse here, where the "problem" stems from their political stance, which nobody with a pulse should give a crap about.
[left hand emoji] you have very strong feelings about something, you're sharing it with others on a public forum
[right hand emoji] "their political stance"... "they should keep them to themselves"
Unfortunately, the community will not accept an AI-assisted decomp. Gotta do it for real.
I'm still baffled by RE community aiming for "100% asm match", needing to reproduce specific compiler version, instead of aiming for functional equivalence and cleaner code
is there really no tools whatsoever that produce proof certificates for "these two functions do the same thing"?
Game behavior can be tied so closely to quirky hardware behavior that I doubt such a tool would be simple to create. You’d have to verify that your code produces the same hardware state. And different (ie more efficient) code almost by definition produces a different hardware state than the original code. Thus changing the game.
Really though? You have to try really hard to make your code that unstable - and well written code isn't that.
Seems more like voodoo.
Who said games were well written? Older games are often very sloppy and buggy, and abuse the specific hardware they're designed for to get extra performance, unique graphical effects, etc.
Emulators constantly run into games that don't run because of specific hardware nuances that may or may not have been intentionally used (Ex. relying on exact cycle counts, reading uninitialized memory, changing values while they're used, etc.).
I wouldn't characterize that as sloppy or buggy in any way (though certainly that is also true for some games). Exploiting hardware in new and novel ways was an essential part of developing for older consoles.
This is something someone only familiar with writing code for general purpose devices or higher level languages can't imagine. But when you're building for one very specific hardware platform you can tailor your code to that platform in ways that simply aren't possible when building for portability.
Because byte-for-byte identical output is far easier to measure than trying to test for functional equivalence.
This is also partly a preservation activity so (as best we can create it) identical code generating identical output is a big part of the point.
It's usually just the first sweep to make sure everything is understood and documented before you start to make mods.
No. Halting problem.