Entrevista con los creadores de ScummVM

Dentro de ScummVM: Motor para Aventuras Gráficas Clásicas

por Howard Wen

08/21/2003

ScummVM es un emulador de motores de videojuegos, que permite jugar a las aventuras clásicas de LucasArts como son The Secret of Monkey Island, Day of the Tentacle, y Sam and Max Hit the Road, en Linux, Mac OS, PocketPC, Windows, Amiga, MorphOS y otras tantas plataformas. Existe incluso una versión para la antigua consola de Sega Dreamcast, y está en desarrollo una versión para la consola Playstation 2. ScummVM emula y mejora el motor SCUMM ("Script Creation Utility for Maniac Mansion") que LucasArts empleaba en estos juegos.

Iniciado en Septiembre de 2001, el proyecto ScummVM provocó la ira de LucasArts en lo concerniente a la publicación de ScummVM bajo el formato GPL. Mientras escribo esto, ambas partes se hayan bloqueadas en este asunto. Los programadores de ScummVM instan a los usuarios a que obtengan copias legales de los juegos SCUMM de LucasArts. ScummVM accede a los datos de los disquetes o CD-ROMs originales a la hora de ejecutar los juegos; pero como sucede con la mayoría de emuladores para otros motores, los datos de las copias piratas sirven igualmente.

Tras realizarse esta entrevista, pero antes de ser difundida, se han publicado las versiones 0.50 y 0.51 de ScummVM. Dichas versiones añaden soporte para los juegos de AdventureSoft, Simon the Sorcercer 1 y 2, así como para el juego Beneath a Steel Sky de Revolution Software.

Como respuesta al soporte ofrecido por ScummVM, Revolution ha permitido al proyecto la distribución del juego de forma totalmente gratuita.

¿Quiénes son sus autores?

Ludvig Strigeus es en la actualidad un estudiante de informática de 22 años. Vive en Gotemburgo, Suecia. Ludvig programó la primera versión de ScummVM.

James Brown tiene 20 años y es programador. Reside en Perth, Western Australia. Es actualmente es líder del proyecto ScummVM. Según él, "Supongo que lo soy, porque nadie más quiso que le despertase el departamento jurídico de LucasArts a las 3 de la mañana."

Max Horn tiene 23 años y es estudiante de matemáticas y ciencias informáticas en Darmstadt, Alemania. Contribuyó al soporte inicial para el juego Curse of Monkey Island, y ayudó a corregir muchos errores y a rematar la interfaz de usuario.

Torbjörn Andersson, 32, programador que vive en Säffle, Sweden. Se centra en “corregir pequeñas cosas, solucionar errores o añadir características no demasiado esenciales, pero que ayudan a pulir el aspecto gráfico y sonoro."

Turno de la palabra para los Programadores

O'Reilly Network: ¿Cuál fue vuestra motivación a la hora de tomar parte en el proyecto ScummVM?

Ludvig Strigeus: Mi primer acercamiento fue cuando tuve la idea de desarrollar mi propio motor para videojuegos de aventuras hace unos años. Para poder llevarlo a la práctica, me era necesario conocer el funcionamiento interno de SCUMM, y así poder tomar ideas del mismo. Tenía en mente crear un intérprete [para ScummVM] capaz de ejecutar Monkey Island 2, por eso cargué mi antiguo desensamblador y comencé a trabajar.

James Brown: Aunque el concepto ya estaba ideado cuando me uní al proyecto, ScummVM siempre ha supuesto una experiencia de aprendizaje, y es por momentos fascinante. No sólo estoy aprendiendo técnicas y métodos novedosos tanto de programación como de ingeniería inversa, sino además es una oportunidad única para estudiar las técnicas de los programadores que estamos tratando de emular, buscando nuevas mejoras partiendo de la metodología y técnicas originales.

ORN: ¿Qué lenguajes han empleado para desarrollar ScummVM?

JB: ScummVM comenzó siendo casi todo C plano, con algunas clases C++ incrustadas. Al poco tiempo de unirme al proyecto, nos pasamos a C++.

Personalmente, no soy muy partidario de C++. Creo que tiende a generar "código enredado" cuando los programadores abusan de herencias y orientación a objetos. Siempre prefiero ANSI C directamente. Aunque, al querer añadir soporte para más juegos y plataformas, las propiedades de herencia para objetos de C++ resultan en un código fuente más legible.

Por ejemplo, recientemente hemos trabajado en la emulación de Curse of Monkey Island, que hace uso del sistema SCUMM Versión 8. Pensamos que esta versión era lo suficientemente diferente para permitir implementar "version classes". De modo que se pueden heredar los opcodes de guión y las funciones de administración de recursos desde nuestra clase versión 6, y únicamente reemplazar aquellas que son sustancialmente diferentes.

En ocasiones hemos utilizado Perl, para crear prototipos y probar diferentes funcionalidades. Hemos utilizado también información obtenida de otros programas creados por otros programadores de la comunidad, en especial de alguien llamado Serge, que fueron creados en Delphi. Y naturalmente, ensamblador x86 para nuestra ingeniería inversa.

ORN: ¿Qué parte de código incorpora ScummVM que no fuese programado originalmente por el equipo?

LS: ScummVM utiliza SDL, una librería que facilita enormemente la tarea de compilar a través de plataformas código de imagen y audio.

Torbjrn Andersson: El controlador ALSA MIDI está en su mayor parte copiado y pegado del vkeybd de Takashi Iwai, y esa parte del código de audio es una versión LGPL del fmopl de MAME creado por Tatsuyuki Satoh.

JB: Hemos utilizado los escaladores gráficos de la familia 2xSal de Kreed. También Ogg Vorbis y la librería MAD MP3 para poder ofrecer compresión de audio, sobre todo por facilitar la tarea de guardar los juegos en dispositivos móviles como el iPAQ.

Podría sonar algo hipócrita, siendo ScummVM un emulador, pero no tiene sentido reinventar la rueda. Es mucho más sencillo aprovechar código ya existente y concentrarse en las entrañas del motor.

ORN: ¿Cuáles han sido los retos técnicos más importantes durante el desarrollo de ScummVM?

Max Horn: Crear un único motor capaz de emular las diferentes versiones del motor SCUMM, cada una con sus numerosas rarezas, modificaciones y peculiaridades.

Una solución a un problema suele provocar otros cinco errores, y a veces sólo te das cuenta un mes más tarde, siendo complicado encontrar la causa. Luego toca mejorar la solución original de modo que corrija los problemas anteriores sin provocar otros nuevos.

JB: Una de nuestras ideas primordiales es mantenerlo tan portable como nos sea posible. Todavía queda mucho por hacer, puesto que la utilización de memoria está muy poco optimizada por el momento; algunos han intentado utilizar ScummVM en una Gameboy Advance, que sólo cuenta con 288K de memoria.

Dado que a menudo tenemos que manejar codecs de compresión extraños—que aunque son sencillos de reimplementar, son complicados de comprender—los ajustes específicos para cada plataforma pueden suponer un serio obstáculo.

ORN: ¿Cuál ha sido el principal desafío en cuanto a la ingeniería inversa del motor SCUMM?

LS: El reto técnico de analizar un fichero .exe, y partiendo de ahí reconstruir la lógica del programa. Cuando se compila un programa, todos los nombres de las variables y las funciones se pierden. Para reconstruirlos, es necesario analizar las funciones y observar los patrones para intentar comprender lo que el el desensamblador hace, y cómo funciona.

Otro desafío técnico es ofrecer soporte para diferentes versiones del intérprete partiendo de un único árbol de código. Cada juego SCUMM utiliza su propia versión de intérprete y espera que ciertas cosas sucedan de un modo determinado. Se hace necesario encontrar un común denominador de funcionalidades que sean utilizadas por todas las versiones del intérprete, y que lo amplíen con funcionalidad más específica de cada uno de ellos.

No puedo afirmar que esté completamente satisfecho de cómo ha funcionado esto en ScummVM durante el tiempo que he estado involucrado en el proyecto. A menudo al añadir una funcionalidad para soportar un juego más generaba problema con juegos más antiguos. En relación a la compatibilidad de los juegos, sería ideal que cada versión del intérprete dentro del árbol del código, fuera independiente del resto. Pero eso conllevaría mucho mantenimiento, en parte debido al hecho de que por cada versión del intérprete, habría que duplicar las funciones y en ese caso el árbol del código crecería extremadamente.

JB: Implementar tantas pequeñas versiones es tremendamente laborioso, porque suele haber cambios estructurales, si no funcionales. Eso dificulta encontrar puntos en común en el código para establecer comparaciones.

La mayoría de motores para juegos presentan estos problemas, unidos al hecho de que, al trabajar con motores interpretados, nunca se está del todo seguro de qué trucos han empleado en el código los guionistas que pudieran trabar tu motor. Programar un decompilador de guiones debería ser el primer paso, asegurándonos de que sea lo suficientemente flexible para corregir opcodes en tiempo real, e integrar fácilmente los cambios de argumentos y parámetros en el intérprete del motor.

ORN: ¿Qué mejoras añadidas al motor ScummVM no estaban presentes en el motor original SCUMM?

MH: La portabilidad a sistemas que no fueron soportados por los juegos originales.

LS: Los filtros de escalado, como 2xSaI, que suaviza la imagen cuando se observa en resoluciones superiores a 320x200, que es la resolución efectiva real que utilizan los juegos. ScummVM también es capaz de ejecutar los juegos Simon the Sorcerer de AdventureSoft.

TA: La gran mayoría de ficheros de audio se pueden comprimir, y la pistas de CD audio se pueden sustituir por ficheros MP3 y Ogg Vorbis. Supone poder jugar a estos juegos desde disco duro, algo muy útil puesto que mi CD-ROM a veces suena como un secador. Hay al menos una escena la versión CD de LOOM, que resultaba tremendamente complicada cuando la probé con el intérprete original. Cada pocos segundos el juego se paralizaba unos instantes porque se creaba un bucle con un sonido de fondo leído desde el CD.

El intérprete original de Sam & Max presentaba ciertos errores gráficos que el motor ScummVM no presenta.

JB: La mayoría de mejoras y añadidos no son apreciables por dos motivos: El primero puramente técnico. El motor SCUMM de LucasArts SCUMM—así como el motor Simon the Sorcerer de AdventureSoft, que también emula—es sólo un intérprete, gran parte de su gracia está en los guiones. Se podría comparar con Quake, donde el motor es el único responsable de la funcionalidad central. Y en un entorno 2D, al menos gráficamente, hay muy poco margen de mejora a diferencia de los entornos 3D.

El segundo motivo es más simplista. Aunque estemos abiertos a realizar mejoras, todo lo que afecte a la jugabilidad podría ser considerado “blasfemia”.

ORN: ¿Qué novedades se planean para versiones futuras de ScummVM?

MH: En este momento, trabajamos en estabilizar el soporte de Curse of Monkey Island. Luego volveremos a corregir los retrocesos introducidos al añadir soporte para Curse. Pero hay planeadas algunas otras cosas:

* Interfaz mejorada, p.ej., opciones configurables cómodamente desde el GUI.

* Soporte para juegos SCUMM muy antiguos (Maniac Mansion, Zak McKracken, LOOM).

JB: Lo primero y principal, nuestro objetivo principal es lograr la compatibilidad total con los juegos SCUMM tanto como sea posible. Barajamos la posibilidad de poder sustituir guiones del juego. Permitiría, entre otras cosas, la posibilidad de actualizar las interfaces de los juegos; por ejemplo, sustituir “verb interface” de Day of the Tentacle con un “cursor interface” de Sam & Max. Permite reducir el tamaño de pantalla ocupado por el juego, facilitando la conversión a otras plataformas inferiores.

Una vez alcanzada la plena, o casi completa compatibilidad con todos los juegos, podríamos considerar la expansión hacia sistemas de videojuegos de aventuras similares. Revolution Software, siendo tan fantásticos como son, nos enviaron el código fuente de Beneath a Steel Sky, preguntándonos si estaríamos interesados en programar un motor de juegos compatible que permitiera a la gente poder jugar en las plataformas más nuevas. Es algo sorprendente, comprobar cómo los desarrolladores de un juego clásico, están interesados en un grupo que está programando un clon.

ORN: ¿Qué consejos le darían a todo aquel que quisiera modificar juegos SCUMM antiguos, o crear juegos nuevos para ScummVM?

MH: No se si es una buena opción. Si alguien me preguntase esto, es probable que le dijera que utilizase uno de los motores de juegos de aventura gráfica de código libre existente, en lugar de emplear ScummVM como punto de partida. ScummVM contiene gran cantidad de particularidades motivadas por la necesidad de emular el SCUMM original. Si fuera a programar un motor para juegos de aventura, muchas cosas las haría de un modo diferente del que están implementadas en ScummVM. ScummVM es fabuloso haciendo aquello para lo que fue concebido; esto es, poder utilizar juegos SCUMM. Exactamente eso es lo que lo hace menos idóneo para la creación de nuevas aventuras gráficas.

TA: Nunca he pensado demasiado en modificar juegos originales. Hay pocos juegos que contengan pantallas de protección anti-copia como parte del guión. Los intérpretes de LucasArts fueron creados para saltarlas cuando estos juegos eran publicados nuevamente como parte de una colección, y por ello nosotros tuvimos que hacer lo mismo, aunque no siempre de la misma manera. Pero siempre se efectúa desde ScummVM. Nunca modificando los ficheros de datos.

Si desea crear un juego, sería mucho mejor tomar un sistema de desarrollo que cuente con una máquina virtual plenamente documentada que no incorpore tantos arreglos específicos para cada juego. Contar con herramientas actuales para el desarrollo del juego sería también de gran ayuda.

Intentar crear un juego nuevo para ScummVM sería como intentar desarrollar un programa extenso empleando únicamente un desensamblador. Seguramente, podría hacerse. Cualquier mortal necesitaría un compilador y librerías estándar, las cuales seguramente se tardarían años en programar.

El compilador Inform de Graham Nelson para Z-Machine de Infocom ofrece una visión muy interesante de la evolución de un proyecto capaz de generar ficheros para una máquina virtual en modo de ingeniería inversa. Inform llegó a ser realmente popular. Se han escrito gran cantidad de juegos con él; Z-Machine está perfectamente documentado; y se han desarrollado intérpretes en diferentes lenguajes como Java, Perl y Emacs Lisp. Pero sería bueno recordar que se invirtieron uno o dos años antes de que el compilador evolucionase a un estado, en el que Graham no fuera el único capaz de crear un juego completo.

Conclusión: Se puede hacer pero requiere mucho tiempo, y quizá no sea el mejor modo de comenzar.

JB: No. Mientras sea posible, existen gran cantidad de sistemas de desarrollo de juegos tremendamente más sencillos de utilizar. A menos que le interese el reto técnico de desarrollar la docena o más de herramientas necesarias para crear un juego que emplee el sistema SCUMM, es una idea nada aconsejable. ScummVM se diseñó para emplear los juegos existentes, no como una plataforma para los nuevos programadores de juegos. Sería alucinante, pero no es factible.

ORN: ¿Algún consejo para aquellos interesados en hacer ingeniería inversa con un motor de juegos, tanto de tipo técnico como jurídico?

MH: Técnicamente, se necesita mucha paciencia para recabar todos los pequeños detalles. Quizá se pueda uno iniciar rápidamente en la tarea, pero para solventar todas las pequeñas trabas, se debe emplear una gran cantidad de esfuerzo.

Jurídicamente, se debería saber que para la DMCA desmontar motores de videojuegos puede resultar ilegal. Pero, si echamos un vistazo a Exult, otro motor de juegos de código libre en el que estoy inmerso, no tuvimos que desensamblar ningún elemento.

JB: Tengo dos consejos legales. El primero es sencillo: Preguntar. No espere quizá respuesta, pero no sabe hasta qué punto se sorprendería de cuantas complicaciones pueden evitarse al poder afirmar, "Pero yo le dije que iba a hacer esto..." Aunque AdventureSoft nunca nos dio una respuesta acerca de nuestra implementación de Simon, y la respuesta de LucasArts fue una nota de advertencia de DMCA, puede que otras compañías, como Revolution, que muestren un interés activo en que sus juegos estén disponibles para otras plataformas.

El segundo consejo es también parte del primer aviso técnico: Utilice la ingeniería inversa tan poco como sea posible. La mayor complicación jurídica de la ingeniería inversa sucede cuando desensamblamos, puede resultar tentador traducir la salida del compilador en código directamente en nuestro programa. Aquí les diría que jurídicamente no, no y no. Es casi con seguridad una violación de los derechos de autor. Y puede suceder por accidente.

Por último, escoja las herramientas adecuadas para el trabajo. La ingeniería inversa es una labor complicada. Aunque existen gran cantidad de programas gratuitos para ello—BIEW por ejemplo, ninguno es tan fácil y gratificante en su uso como los extensos programas comerciales del tipo, IDA Pro y SoftICE.

ORN: ¿Qué juego SCUMM de LucasArts es vuestro favorito, y qué trucos podríais compartir con quienes jueguen desde ScummVM?

LS:Mi juego favorito es Monkey Island 2; después de todo, creé ScummVM con el propósito de jugar a Monkey 2.

MH: No es fácil destacar uno sólo como favorito, puesto que me gustan un montón. Pero si insiste en una elección, diría Monkey Island 2. Por fortuna, el soporte en ScummVM roza casi la perfección. Tiene gran cantidad de humor, referencias a otros juegos de LucasArts, e ideas realmente graciosas. Una de las escenas que más me gusta es cuando Guybrush se golpea en la cabeza, y sueña con sus padres, que surge en forma de esqueleto interpretando una famosa canción.

JB:Personalmente, me encanta Sam and Max Hit the Road. Cuenta con algunos de los mejores gags que haya podido ver, eso sin mencionar sus puzzles con gran sentido que se pueden resolver sin rodeos. Como es mi favorito, funciona perfectamente con ScummVM. Mi único consejo es no jugar al mini juego "highway". Va demasiado rápido en ScummVM, y, como la única forma de salir implica perder, es fácil quedarse atascado.

TA: Para mi sería Day of the Tentacle. Es el único que fui capaz de completar sin ningún tipo de ayuda externa.

La ejecución de los juegos me pareció sumamente sencilla, una vez leída la documentación y el listado de compatibilidad. El mayor problema fue encontrar un lugar donde comprar los juegos. Todo me funciona correctamente ahora mismo. Dudo de que algún día tenga la posibilidad de jugar a la versión en 256 colores de Zak McKracken. Supongo que mi único consejo es poder comprar los juegos en cuanto se tenga esa opción.

Howard Wen, el autor de la entrevista, es redactor freelance y ha colaborado asiduamente con O'Reilly y ha escrito también para Salon.com, Playboy.com, y Wired, entre otros.