粉丝制作的移植、克隆及发行商嫌冷门时由粉丝接手的其他作品 [更新：Oblivion Remastered 的 AI 辅助 FPS 改进 Mod]

This is a topic for discussing developments within the scene of fan-made ports and clones that are created using any method (decomps, recomps, clones, re-implementations, source ports, and the whole shebang).

Useful websites listing projects of these types:

• https://osgameclones.com - This is an exhaustive list of fan-made remakes that are developed using a variety of methods. Every single project listed here is open-source.
• https://decomp.dev/projects - A list of decomps and their progress.
• https://thegamingemporium.com/categories/decompilations-recompilations/ - A huge list of recomps (and some decomps).
• https://www.pcgamingwiki.com/wiki/List_of_unofficial_ports - Not as exhaustive as the above links, but has a bunch of fan-made ports and remakes.
• https://en.wikipedia.org/wiki/List_of_game_engine_recreations - Another list of fan-made ports. This one has a lot overlap with the projects on the osgameclones and pcgamingwiki lists.
• https://www.agdinteractive.com/games/games.html - Several fan remakes of classic Sierra adventure games.
• https://infamousadventures.itch.io - Fan remakes of two Sierra classics.
• https://www.adventuregamestudio.co.uk/play/game/401/ - Fan remake of Maniac Mansion.

Disclaimer: These are not links to piracy, but rather links to fan-made recreations that almost always require the original game files.

List of terminologies that you'll see in relation to these projects:

Source code: The blueprint of a game. This is human-readable code that compiles into an executable that lets you run the game. It's almost always written in a higher-level language like C++ and will contain names for variables and functions, with plenty of comments explaining what some of the code does.

Machine code / Assembly code: When a game is compiled, it is stored as machine code in the executable that the CPU will load and run. During the compilation process, all names and comments in the source code are stripped away. Assembly code is machine code that's shown in a readable form to humans. Disassemblers like Ghidra and IDA are popular for this task. Ghidra and IDA also feature decompilers that can automatically decompile assembly code into high-level pseudocode, which is of great help when it comes to reverse-engineering.

Reverse-engineer: The task of understanding the inner workings of a game. For instance, reverse-engineering assembly code to understand what it does, or studying game formats to understand how game data is stored.

Debug symbols: When a game is compiled, you can tell the compiler to include a database of debug symbols to assist with debugging the game. If this is somehow kept in the game files (which almost always is the result of a mistake by the developer) then it's a huge boon to fans as it makes it much faster to reverse-engineer the game's assembly code.

Decompilation: A project that aims to fully re-create a game's source code from scratch by studying the game's assembly code and manually re-writing it in an higher-level language. Usually this is done with the goal of creating a source code that compiles into an executable that's byte-for-byte identical to the original. This process is extremely time-consuming and will likely take tens of thousands of hours over multiple years. When done, you will not end up with a port -- you'll end up with a source code. One such example is Devilution, which is Diablo 1 decompiled with the help of debug symbols from the Playstation port. It took 3 years to accomplish.

Port / Source port: A game ported from one system to another. This is usually done by working from a game's source code. Doom is a good example of a game that's been ported by fans countless times after the source code was released back in 1997. A more recent example is SDL-PoP: a port of Prince of Persia based on the assembly code of the DOS version. It's worth mentioning that writing a port is much faster than the process of writing a decompilation from scratch.

Recompilation: A static recompiler takes an executable, extracts the machine code, and automatically converts it to a higher-level language so it can be compiled for other platforms. Some recompilers even include a runtime library that mimics the original hardware's behaviour for sound, input, and graphics, making the process of porting a game fast to accomplish (you could have a game up and running in mere days), but it has the downside that the generated source code is as hard to read as assembly code. The Blue Dragon recomp is a good example of this kind of project. It also looks like this is the method Microsoft used for running Xbox 360 games on Xbox One/Series.

Clone / Remake / Re-implementation / Game engine recreation: Projects that intend to recreate a game which share the similarity that they don't have the goal of writing a source code that mimics the exact same structure as the original codebase. With how most people define reimplementation and game engine recreations, I think you can expect those to be as faithful as possible, potentially by using the original assembly or source code as reference and definitely requiring the original game data to run. Examples include freeserf, OpenRA, OpenXcom and OpenLara. These are fairly faithful to The Settlers, Command & Conquer, X-Com and Tomb Raider, and reverse-engineering was used during the process, but the new codebases are extremely different from the originals and a few of these have some rather big gameplay differences.

Interpreter: Some games are fully driven by a scripting language, this means a new version can be created by writing a interpreter for that scripting language. ScummVM is a good example of this. The LucasArts and Sierra games it supports are mostly driven by a interpreter for the scripting languages those companies created.

Translation layer: This acts as a middleman between the game executable and your system. This usually implies you can run the machine code in the executable as-is because the CPU architecture is the same (ie, a Windows PC can run the machine code from a PS5 executable since both systems use x86 CPUs), and the translation layer is responsible for catching calls to various APIs (graphics API, OS API, etc) and changes those calls with new code that returns the values the game expects or diverts the calls to appropriate APIs on the Windows PC.

Emulator: An emulator mimics every single part of a platform's hardware, including its CPU. That way you don't even need to port a game, as you instead emulate the CPU so you can run the original game executable as-is. That said, the focus of this thread are native ports, as those are the ones that usually come with major enhancements. Just wanted to include emulation in this list it to note the differences between it and other methods for running a game on a different platform.

Last edited: Oct 11, 2026