927
edits
Changes
Jump to navigation
Jump to search
no edit summary
Sometimes a full system emulator is overkill. This is especially true when a developer only wants to get one game (or a number of games that use the same engine) working. In that case, reimplementing that game alone would save more time than implementing the platform it runs on. These kinds of projects are common when abandonware has large communities; when the original developer has disbanded and can no longer support or update it, an effort is then made to get it running natively on newer versions of-- and/or entirely different-- operating systems and platforms.
* When the developer only has a binary to work with (and not the [[source code]]), they recreate the engine rather than port it, hence the term '''[[wikipedia:Game engine recreation|game engine recreations]]''' (or alternatively '''game engine re-implementations'''). How the developers go about this process depends on their philosophy; they may opt to decompile the original executable and have their own program rely on the original until all of its functions have been remade, at which point the original binary is no longer needed. Alternatively, they can be remade based on a clean room design, in which the project implements the abstract features without having to disassemble the original, going by how components are expected to be used rather than how the game uses them. Some engines come about simply because they were inspired by the original game, and the programmer felt confident enough that no reverse engineering was necessary to make an engine that does the same thing.
* In rare cases, games are released as open-source by the publishers themselves, allowing developers to perform a '''source port''' of the code. This skips the step of figuring out how the game works. The most common example that's often used is id Software's release of Doom in 1997. It led to [[wikipedia:List of Doom source ports|so many ports being released]] that the community began to joke about what devices haven't gotten it running yet.
Some projects are implemented in ways that the original developer did not intend; for example, for a platform other than which publishers marketed it for. And they're not just limited to game engines either; [https://webamp.org/ Webamp] is a JavaScript application that reimplements Winamp in the web browser. These projects are almost always open-source which also allows new programmers to fix bugs that could have been difficult to track down during development (alternatively, the bugs may be emulated to allow old mods to continue to safely exploit them). When most of the effort is on programming, the project will usually require the original game's assets (such as files in the installation directory or ROMs) until those ever get remade. This lets the developers claim they aren't infringing the game's copyrights since the player must obtain the original to use it; if the game is still being sold, this could allow the publisher to even earn revenue from the project.
For a complete list the sake of brevity, most of these projects, see [https://osgameclones.com/ Open Source Game Clones]often refer to themselves under some variety of '''fan remakes'''. See The [[#External Linkslinks|External Linkslinks]] section has lists for links to vast lists a number of known and available open-source game engine recreations and similar softwareprojects.
==Multi game engine==
<references group=N />
==External Linkslinks==
* [https://osgameclones.com/ Open Source Game Clones] (Likely the best and most complete list.)
* [https://github.com/leereilly/games Games on GitHub] by Lee Reilly ([https://github.com/leereilly/games/blob/master/README.md Master list] in wider view. This list from leereilly contains Table of Contents and categories with highlighted links to Git repos.)
