Game engine recreation is a type of video game engine remastering process whereby a new game engine is written from scratch as a clone of the original with the ability to load the original game's data files such as music, textures, scripts, shaders, levels, and more. The new engine should read these data files and, in theory, load and understand them in a way that is indistinguishable from the original. The result of a proper engine clone is often the ability to play a game on modern systems that the old game could no longer run on. It also opens the possibility of community collaboration, as many engine remake projects tend to be open source. Game engine recreation can be beneficial to game publishers because the legal use of a re-creation still requires the original data files. Meaning, a player must still purchase the original game in order to legally play the re-created game.
Motivation
Game engine recreations are made to allow the usage of classical games with newer operating system versions, recent hardware or even completely different operating systems than originally intended. Another motivation is the ability to fix engine bugs which is often hard or impossible with the original engines once a software has become unsupported abandonware, with the sourcecode not available.
Methods
Top down
When game engine recreations are made in a top down development methodology, in the first step the general game's functionality is programmed and the structure is defined. Then, in later steps, the resulting engine is adapted to the specific detail behaviour of the original game, often by reverse engineering, debugging and profiling the original. An example is OpenRA based on specifications contributed by the community by clean-room re-implementations without dis-assembling the original executable, which result in game engines whose behavior differs from the original. Another example is the Total Annihilation engine remake Spring Engine, which resulted in being used for many more games. Typically, this approach results in an approximation of the original behaviour only and not a "clock cycle wise" identical behaviour. On the positive side, running code exists faster, and the finally resulting source code is less specifically tied to a specific, single game and can be reused as a general game engine for other games.
Bottom up
Unlike Top down game engine recreations, bottom up dis-assembled/decompiled versions for a specific game are often able to replicate the behaviour of the original exactly. In these cases, the game core is recreated bottom up with reverse engineering of the original dis-assembledbinary executable, CPU instruction for instruction. In the development phase this has the disadvantage that for a long time no running prototype exists. Also on the negative side, the resulting code is very specifically tied to this single game, often ugly, and can hardly be reused as general game engine. Examples are CSBWin or OpenTTD. Most often, the result is also not called "game engine" but "game recreation" or "game clone". MAME is an example of a video game engine emulation project which also follows this philosophy for accurate representation of the games.
Alternatives
of classical systems or operating systems is an alternative to an engine recreation; for instance DOSBox is a notable emulator of the PC/MS-DOS environment. Static recompilation is another approach based on the original binary executable, potentially leading to better performance than emulation; an example is the 2014 ARM architecture version of StarCraft for the Pandora. Another alternative are source ports for the seldom cases that the source code is available; examples are Jagged Alliance 2 or Homeworld.
