La picardía era un requisito para publicar juegos hace varias décadas, cuando no existían las actualizaciones y correcciones online de hoy
Los bugs en los videojuegos son, por desgracia generalmente, un mal del que muy pocos juegos se libran. Lo normal es que perjudiquen el juego de formas notables si son graves o que no nos permiten continuar nuestra partida con normalidad, aunque también hay casos en los que han dado lugar a historias o hazañas que habrían sido imposibles de conseguir en condiciones normales o si se hubieran corregido.
Pero por desgracia, la mayoría de los casos pertenecen al primer grupo, los conocidos como los "show stopers" o que hacen que la experiencia se vea seriamente perjudicada. En los juegos de mundo abierto o altamente complejos como pueden ser CyberPunk 2077 o Skyrim encontramos notables ejemplos. Son títulos que tuvieron un lanzamiento bastante accidentado y que, por fortuna, posteriores revisiones y actualizaciones han permitido corregir hasta dejarlos en un estado -mayormente- aclamado. Pero ¿y qué hacían los desarrolladores en el siglo pasado? Cuando Internet era un lujo y no existía la posibilidad de descargar parches o arreglos.
Pues muchas veces no se podía arreglar, y tratar de recolocar versiones revisadas del juego era muy caro, aparte que nadie quiere pagar dos veces por lo mismo, pero es lo que se solía hacer. Por suerte, estos fallos se localizaban previos al lanzamiento y era posible "camuflarlos" con un poquito de picardía. Un ejemplo perfecto lo encontramos en uno de los primeros juegos de Chris Roberts: Wing Commander.
Los problemas de programar un juego para MS-DOS
Antes de la llegada y masificación de Windows como sistema operativo para jugar, o del advenimiento de Steam y otras plataformas cuyo propósito era albergar los juegos que instalábamos para gestionarlos y mantenerlos, la práctica totalidad de los juegos en PC se programaban en base a Microsoft DOS, el sistema operativo que Microsoft ofrecía como gestor del ordenador antes de la llegada de sus "ventanas", y para el que los juegos se diseñaban.
En los casos de juegos sencillos como las aventuras gráficas o determinados RPG algo primitivos no suponía un gran problema, ya que sus requisitos eran proporcionalmente discretos comparados con los de hoy en día. Pero en el caso de juegos que ya eran algo más avanzados -como los que comenzaron a introducir a los jugadores en género más “tridimensionales” como los Space SIM o simuladores de vuelo espacial- pues la cosa ya se complicaba.
En general, los ordenadores de los 90 venían con alguna de las primeras versiones Windows preinstaladas (NT o 3.1 por lo habitual), y arrancar esos sistemas operativos consumía una considerable cantidad de memoria EMS; memoria que estos juegos necesitaban para ejecutarse. En términos llanos, era una extensión de la memoria RAM del sistema operativo gestionada por la aplicación EMM386, el gestor de memoria virtual de Microsoft integrado en MS-DOS. Como ya sabéis, si se necesita disponer de toda la memoria del sistema debemos reiniciar el ordenador.
Pero como Windows se cargaba "sí o sí" -por defecto, aunque había formas de detener su carga como ahora veremos-, aunque luego pudiéramos cerrarlo para ser llevados a MS-DOS, pues ya había consumido buena parte de la memoria en el arranque y no era posible ejecutar programas complejos. Esto hacía que muchos juegos no pudieran ejecutarse por falta de memoria EMS. La alternativa era crear un disco de arranque que "detuviese" la ejecución de Windows si lo introducíamos en la disquetera durante el arranque; lo mismo que hoy en día con los USB si le pedimos a la BIOS de la placa base que arranque el PC tomando la unidad extraíble como la principal.
Pero no todos los videojuegos o empresas disponían de esta aplicación que venía de serie con la instalación de sus juegos. La mayoría, de hecho, debían comprimirse para usar la mínima cantidad posible de memoria. El problema es que dejaban seco al ordenador de este recurso y no era posible arrancar nada más una vez habíamos terminado de jugar.
Esto era muy mala publicidad para un juego en la época ya que, aunque siempre se podía reiniciar el PC, era bastante latazo. Y había un juego que provocaba eso, con un preocupante mensaje de que se había producido un error en el EMM386; el space sim Wing Commander. Al final de cada sesión de juego durante las pruebas de lanzamiento, al volver a MS-DOS, este nos comunicaba que “Se ha producido un error de excepción en el módulo EMM386”.
La solución de Wing Commander: esconderlo bajo la alfombra
Puesto que a veces era imposible implementar una solución a tiempo sin retrasar el juego -ya sea por fechas límite o por imposibilidades técnicas del momento- los desarrolladores muchas veces debían recurrir a la “picaresca”. Precisamente Wing Commander es un excelente ejemplo, ya que durante toda su vida útil (y en todas sus copias hasta descatalogarse) arrastró ese “bug” que se traduce en el mensaje de error. Ken Demarest, uno de los desarrolladores de Origin Systems convirtió el error en algo menos alarmista.
Gracias a una publicación en el Blog The Wiert Corner, el mismo desarrollador explica cómo convirtió el error en una “característica”. En este caso, un mensaje de agradecimiento a los usuarios que jugaban al juego. Lo que hizo Demarest fue editar hexadecimalmente el mensaje de error provocado por el juego para que DOS lo tradujera como “¡Gracias por jugar a Wing Commander!”.
Naturalmente, esto no anulaba el error en sí, y seguía siendo necesario reiniciar el PC para volver a disponer de la memoria RAM sin fragmentar. Pero es uno de los ejemplos más antiguos de cómo los desarrolladores “solucionaban” o camuflaban ciertos errores de juegos que no podrían recibir arreglos a menos que se relanzaran. Hoy en día, ese error ya no existe porque las versiones disponibles de Wing Commander se ejecutan con emulación, y apenas consumen un 1% de la memoria del sistema para ejecutarse.
Vía | Jeuxvideo
Imagen de portada: Boitumelo (vía Unsplash)
Ver todos los comentarios en https://www.3djuegos.com
VER 1 Comentario