The fan effort to bring older console games to modern PCs has a new and unusually pointed fault line: not whether a game can be made to run, but how the work gets done and whether the result remains useful to the community after its first upload.
A project called Banjo-Tooie Recompiled recently drew criticism from people involved in established human-led recompilation projects. Their objections are not limited to a general dislike of generative AI. They center on authorship and disclosure, the technical durability of the resulting code, and the risk that rushed, poorly understood ports will confuse players and modders looking for reliable fan work.
At the heart of the dispute is a term that has rapidly become shorthand for the community’s concern: “slopcomp.” It is a disparaging label for an AI-generated or AI-heavy decompilation/recompilation project that critics believe has been produced without the careful research, testing and architecture expected from a long-term preservation or modding effort.
What recompilation means in this context
Recompilation is not simply copying an old game onto a new machine. In broad terms, a recompilation project works to understand game code created for its original hardware and transform it so it can run on a modern platform. The fan-made N64: Recompiled tool has enabled enthusiasts to pursue unofficial PC versions of Nintendo 64 games by helping reverse-engineer code for contemporary hardware.
That process can involve a substantial amount of human investigation. Developers must account for a game’s original behavior, the renderer that produces its graphics, memory behavior, and the framework that lets the game operate outside its native console environment. A working build is therefore only one measure of success. The organization of the code and the ability to maintain, study or modify it matter too.
This is why the current argument is bigger than a dispute over one Banjo-Kazooie sequel. The people objecting to AI-generated recompilations say these projects can borrow the appearance and labels of painstaking community work without offering the same underlying value.
Banjo and Zelda recompilation developers draw a bright line
Darío, known online as DarioSamo and previously involved with a human-led unofficial PC port of the first Banjo-Kazooie, publicly distanced that work from Banjo-Tooie Recompiled. In an October 1 post, he said the newer project was entirely AI-generated and was not associated with the Banjo or Zelda recompilation teams.
“Both Zelda: Recompiled and Banjo: Recompiled have very clear No AI stances. We have not, do not and will not use AI to ever work on these projects.”
Related coverage includes Recompilation Developers Push Back as AI-Made N64 Fan Ports Spark "Slopcomp" Debate.
He also said his group had already expressed an intention to tackle Banjo-Tooie itself at a later point without generative AI. The concern, then, is not that no one should attempt the game. It is that the similarly named AI project could be mistaken for, or trade on the reputation of, the established efforts.
That distinction matters to enthusiasts trying to decide what they are downloading, discussing or contributing to. A familiar project name can imply a shared team, process or standard of maintenance even when none exists. The backlash intensified because the project’s AI involvement was not initially made clear in the video presentation that helped spread it online.
For a scene built around voluntary technical labor, transparent labels are practical information rather than cosmetic branding. Players may want to know whether a build comes from a team that can explain its changes. Modders may need to know whether the code structure is stable enough to support further work. Contributors need to know whether their own research is being represented accurately.
The technical issue: patches and maintainability
The sharpest criticism is not merely that AI can produce bugs. DarioSamo argued that this particular project bypasses an existing patching system and instead patches recompiled code and memory “from the wrong side.” In his view, that approach makes conventional modding unmaintainable over the long term and offers nothing back to broader decompilation work.
That language deserves unpacking. A patching system is the method through which targeted changes are applied to a game or project. In a healthy long-running project, patches can give developers and modders a predictable, understandable place to make alterations. The details matter because future contributors need to identify what has changed, why it changed, and how their own changes will interact with it.
Maintainability means that software can be understood, repaired and extended over time. It is especially important in volunteer projects, where the people doing the work may change and documentation can be as valuable as the code itself. If a port technically runs but its modifications are difficult to trace or safely build upon, it can become a dead end for the community.
The phrase “wrong side” is an assessment from the project’s critics, not an independently established technical verdict on every AI-assisted port. But it identifies the practical standard they want people to consider: does the work preserve a usable pathway for mods, fixes, research and future contributors, or does it just generate a short-term result?
Why “it runs” is not enough for a fan project
Fan recompilation communities often serve several overlapping audiences. Some people only want a playable version of an old favorite on a modern computer. Others are interested in high-quality preservation, reverse-engineering knowledge, visual improvements, fixes or creative mods. A project that meets the first need may still fail the others.
Critics of the AI-generated work argue that a wave of projects made by people with little programming experience could make this distinction harder to see. FunkyLion, who assembled a list intended to identify human-made decomps and recomps, warned that untested AI ports could be buggy or broken while overshadowing work done by people who have deeply researched the games.
The concern is partly about discoverability. A flashy video or a fast-moving social post can bring attention to a release before players know its technical limits, its maintenance prospects or even the process behind it. A more careful project may take longer and be less visible, despite offering a better foundation for the people who follow.
That does not establish that every project using AI is broken, nor does it resolve wider debates about tools in software development. The developers speaking out are making a narrower community argument: for these recompilation efforts, human understanding and accountable, maintainable work are central to the point of the exercise.
Preservation values are colliding with speed
One contributor to a new MediEvil recompilation project, Jay Gunn, also backed the pushback. He said he did not know more than what had been posted about the situation, but agreed with the calls to keep generative AI away from MediEvil work. His reasoning was rooted in the appeal of an earlier development era: games were made by hand with far fewer premade tools and shortcuts.
That sentiment is not a technical rule, and it is not an argument that every modern tool is inherently unwelcome. It does, however, reflect a preservation-minded view of fan development. When volunteers reverse-engineer an older game, the research itself can be part of what the community values. The work documents how a game functions and creates an intelligible base that others can inspect and improve.
Generative code can complicate that value proposition if the output is difficult to verify or explain. In an ordinary commercial software setting, a team may have internal testing, ownership and formal processes for reviewing code. In a distributed fan scene, public trust can depend much more directly on recognizable contributors, open technical discussion and a visible chain from research to result.
The dispute also lands amid a broader games-industry conversation about AI as a tool rather than a substitute for expertise. One recent industry example frames AI around bug-finding rather than replacing developers; the recompilation controversy demonstrates why that distinction can be even more sensitive in volunteer preservation projects.
What players and modders can take from the dispute
No one evaluating an unofficial recompilation needs to become a reverse engineer. But the debate points to a few useful questions before treating any fan PC port as a dependable project:
- Is the project clear about who made it and how? Explicit disclosure helps separate independent projects with similar names.
- Is there a credible maintenance path? A project’s value can depend on whether fixes and updates can be made later, not solely on an initial build.
- Does it support the kind of modding users expect? A technically working port may not be a practical base for modifications.
- Are claims of testing and quality supported by the project itself? Fast availability should not be mistaken for reliable compatibility or polish.
- Does it contribute understandable work back to the community? Research, documentation and maintainable structures can outlast any one release.
These questions also avoid collapsing a complicated issue into a binary choice between old games and new technology. The immediate fight is about standards: disclosure instead of ambiguity, stewardship instead of a rush for attention, and code that can be worked on by people after the original upload has faded from view.
For now, the human-led Banjo and Zelda recompilation developers have stated their position plainly: their projects reject AI-generated development. The appearance of an AI-based Banjo-Tooie project has made that boundary more visible, while the reaction from other recompilation contributors suggests the debate is likely to extend well beyond one Nintendo 64 game.
