La recreación de un motor de juego es un tipo de proceso de remasterización de un motor de videojuego mediante el cual se reescribe un nuevo motor de juego desde cero como un clon del original con la capacidad de cargar los archivos de datos del juego original, como música , texturas , scripts , sombreadores , niveles y más. El nuevo motor debería leer estos archivos de datos y, en teoría, cargarlos y comprenderlos de una manera que sea indistinguible del original. El resultado de un clon de motor adecuado suele ser la capacidad de jugar un juego en sistemas modernos en los que el juego anterior ya no podía ejecutarse. También abre la posibilidad de colaboración comunitaria, ya que muchos proyectos de remake de motores tienden a ser de código abierto. La recreación de motores de juego puede ser beneficiosa para los editores de juegos porque el uso legal de una recreación aún requiere los archivos de datos originales, ya que un jugador aún debe comprar el juego original para poder jugar legalmente el juego recreado (como se detalla en esta lista de recreaciones de motores de juego ).
Las recreaciones de motores de juegos están diseñadas para permitir el uso de juegos clásicos con versiones más nuevas de sistemas operativos , hardware reciente o incluso sistemas operativos completamente diferentes a los originalmente previstos. Otra motivación es la capacidad de corregir errores de motores , lo que a menudo es difícil o imposible con los motores originales (con notables excepciones, consulte el parche de la comunidad ) una vez que un software deja de tener soporte y el código fuente no está disponible.
Cuando se realizan recreaciones de motores de juegos con una metodología de desarrollo descendente , en el primer paso se programa la funcionalidad general del juego y se define la estructura. Luego, en pasos posteriores, el motor resultante se adapta al comportamiento de detalle específico del juego original, a menudo mediante ingeniería inversa, depuración y creación de perfiles del original. Un ejemplo es OpenRA basado en especificaciones aportadas por la comunidad mediante reimplementaciones en sala limpia [1] sin desensamblar el ejecutable original, lo que da como resultado motores de juegos cuyo comportamiento difiere del original. [2] Otro ejemplo es el remake del motor Total Annihilation Spring Engine , que resultó ser utilizado para muchos más juegos. Por lo general, este enfoque da como resultado una aproximación del comportamiento original solamente y no un comportamiento idéntico " en términos de ciclos de reloj ". En el lado positivo, el código que se ejecuta existe más rápido y el código fuente resultante final está menos vinculado específicamente a un juego único específico y se puede reutilizar como un motor de juego general para otros juegos.
A diferencia de las recreaciones de motores de juego de arriba hacia abajo , las versiones desensambladas/descompiladas de abajo hacia arriba para un juego específico a menudo pueden replicar exactamente el comportamiento del original. En estos casos, el núcleo del juego se recrea de abajo hacia arriba con ingeniería inversa del ejecutable binario desensamblado original , instrucción de CPU por instrucción. En la fase de desarrollo, esto tiene la desventaja de que durante mucho tiempo no existe un prototipo en funcionamiento. También en el lado negativo, el código resultante está muy específicamente vinculado a este único juego, a menudo feo (" código pseudoensamblador " [3] [4] ), y difícilmente se puede reutilizar como motor de juego general. Algunos ejemplos son CSBWin u OpenTTD . La mayoría de las veces, el resultado tampoco se llama "motor de juego", sino "recreación de juego" o "clon de juego". MAME es un ejemplo de un proyecto de emulación de motor de videojuegos que también sigue esta filosofía para la representación precisa de los juegos.
Ocasionalmente, como fue el caso con algunos de los motores/núcleos de juego en ScummVM , los desarrolladores originales ayudaron a los proyectos al proporcionar el código fuente original (a estos se los puede llamar puertos fuente ). Este es el mejor caso, óptimo para la precisión y minimizando el esfuerzo. Un ejemplo es Beneath a Steel Sky . [5] [6]
La emulación de sistemas clásicos o sistemas operativos es una alternativa a una recreación del motor; por ejemplo, DOSBox es un notable emulador del entorno PC / MS-DOS . La recompilación estática es otro enfoque basado en el ejecutable binario original , que potencialmente conduce a un mejor rendimiento que la emulación; un ejemplo es la versión de arquitectura ARM de 2014 de StarCraft para Pandora . [7] [8] [9] Otra alternativa son los source ports para los raros casos en los que el código fuente está disponible; ejemplos son Jagged Alliance 2 [10] o Homeworld [11] [12] [13] (más ejemplos en la Lista de videojuegos comerciales con código fuente disponible ).
¡Soporte para Beneath a Steel Sky, posible gracias a Revolution Software, que nos proporcionó el código fuente original en ensamblador!
La regla "sin código fuente, no hay puerto" no es completamente cierta, puedes obtener algo similar (pero no lo mismo) como puerto a través de una recompilación estática. M-HT hizo cosas similares varias veces para algunos juegos de DOS. El juego también se convirtió para Android con un enfoque bastante similar.
{{cite web}}: CS1 maint: copia archivada como título ( enlace )[...] puerto lanzado de HomeworldSDL. [...] permite que tu Pandora experimente el excelente trabajo realizado por los chicos de HomeworldSDL.