En una época en la que los videojuegos son desarrollados por equipos de cientos de personas, con motores gráficos complejos y presupuestos multimillonarios, resulta casi inverosímil pensar que uno de los títulos más innovadores, complejos y queridos de los años 90 fuese obra de una sola persona. Pero así fue.
Pero Chris Sawyer (un programador escocés con una cierta obsesión por el rendimiento de sus creaciones) no sólo creó RollerCoaster Tycoon prácticamente en solitario, no: también lo hizo usando uno de los lenguajes de programación más temidos. Ensamblador.
Una pasión inesperada por las montañas rusas
Como explicaba en una entrevista para Atari-Club, todo comenzó en 1996 o 1997, cuando Sawyer trabajaba en la secuela de su anterior éxito, Transport Tycoon. Frustrado por las limitaciones técnicas de la época y desmotivado con el rumbo del proyecto, encontró inspiración en un hobby inesperado: su creciente fascinación por las montañas rusas y su ingeniería. Así nació una idea que cambiaría su vida y la historia de los videojuegos.
En un principio, no tenía una idea clara de cómo quería que fuese el juego final. De hecho, RollerCoaster Tycoon comenzó como un simple 'conjunto de construcción de montañas rusas' dentro del motor isométrico de Transport Tycoon.
Pero lo que empezó como un experimento personal creció hasta convertirse en uno de los simuladores de parques de atracciones más completos, entretenidos y técnicamente admirables jamás hechos.
Christ Sawyer, en fotograma de vídeo de 'Waldoc' en YouTube
Un simulador profundo disfrazado de juego familiar
A primera vista, RollerCoaster Tycoon es un juego simpático, colorido y accesible. Pero bajo esa estética amigable se esconde una simulación rica en detalles. Cada visitante tiene personalidad propia, gustos específicos, niveles de tolerancia al miedo y al aburrimiento, e incluso diferente poder adquisitivo. La gestión económica del parque —costos, ingresos, campañas de marketing, personal, mantenimiento— también influye en el éxito de cada escenario.
Además, el juego incluye una construcción modular de montañas rusas que, gracias al motor físico personalizado de Sawyer, permite diseñar atracciones realistas (o completamente disparatadas) cuyas características son evaluadas automáticamente por el juego en términos de emoción, intensidad y mareo.
Arte y diseño con restricciones creativas
La elección de una vista isométrica pre-renderizada no fue una decisión estética, sino técnica. Los gráficos 3D en tiempo real eran inviables si se quería mantener un alto rendimiento. En su lugar, el artista Simon Foster creó miles de sprites pre-renderizados con consistencia de iluminación y perspectiva, usando una paleta de 256 colores optimizada para permitir variaciones de color sin impacto en el rendimiento.
La coherencia visual del juego, sus animaciones fluidas y su intuitiva interfaz de usuario fueron claves en su éxito. Muchos aún recuerdan con nostalgia su estética 'pixel-art' tridimensional, que ha envejecido sorprendentemente bien.
¿Por qué ensamblador?
En 1999, muchos juegos ya se desarrollaban en lenguajes de medio/alto nivel como C/C++. Sin embargo, Sawyer optó por el ensamblador x86, un lenguaje de muy bajo nivel (lo más bajo que se puede usar sin recurrir al propio lenguaje binario) que interactúa directamente con el hardware. ¿La razón? Rendimiento.
Sawyer quería un juego fluido, capaz de simular cientos de visitantes interactuando con decenas de atracciones, sin sacrificar la calidad visual ni el nivel de detalle. Para lograr esto en los modestos ordenadores de finales de los 90, necesitaba extraer hasta el último ciclo de CPU disponible.
Cada elemento —desde la 'inteligencia artificial' de los visitantes hasta la física de las montañas rusas— fue cuidadosamente optimizado para ejecutarse a gran velocidad. Esto permitió que el juego funcionara sin problemas incluso en PCs de bajo coste, ofreciendo una experiencia sin ralentizaciones. En una era sin actualizaciones por Internet, el código tenía que ser perfecto desde el primer día.
'Pensamientos recientes: "...aunque puede ser desmoralizante tener que descartar una o dos semanas de trabajo, siempre tenía un lado positivo: el siguiente intento o el nuevo enfoque solían salir mucho mejor"'. (Chris Sawyer)
Pero… ¿qué es exactamente el ensamblador y por qué es tan difícil?
Para quienes no tienen experiencia en programación, es importante entender por qué usar ensamblador para crear RollerCoaster Tycoon no solo fue inusual, sino una auténtica hazaña técnica.
Ya hemos dicho antes que prácticamente supone hablar el 'lenguaje interno' de un PC: olvídate de comandos legibles como "if", "while" o "print" que puedes encontrar en lenguajes como C, Python o JavaScript: en ensamblador las instrucciones controlan directamente la CPU y la memoria, y tiene la forma de un 'MOV AX, 4C00h' o 'INT 21h'.
Y así, amigos, se escribe "Hola, mundo" en ensamblador
Por ejemplo, una simple línea de código en C puede convertirse en 5 o 6 líneas de ensamblador: cada operación debe ser descrita paso a paso. Además, el programador debe llevar todo el contexto del programa en su cabeza: qué registros están ocupados, dónde están los datos en la memoria, cómo evitar que el sistema se congele, etc.
Programar un juego completo en ensamblador implica:
- Tener un conocimiento profundo del hardware, incluyendo cómo funciona la CPU, la memoria RAM y la tarjeta gráfica.
- Hacer malabares con los recursos: usar solo la memoria estrictamente necesaria, minimizar cada operación y garantizar que todo funcione en tiempo real.
- No contar con ayuda: sin autocompletado, sin depuradores visuales, sin motores gráficos… todo, desde el motor de renderizado hasta la física, debe ser escrito desde cero.
Y ahora piensa en las particularidades de RollerCoaster Tycoon, un juego que requiere calcular en tiempo real:
- Trayectorias de montañas rusas.
- Fuerzas físicas sobre los trenes.
- Comportamiento y emociones de cientos de visitantes.
- Animaciones gráficas y sonidos sincronizados.
- Colisiones, economías internas, eventos aleatorios…
Todo eso, escrito línea a línea, como si alguien construyera una ciudad entera ladrillo a ladrillo, sin grúas y sin planos.
Por eso, que una sola persona lograra escribir un juego con la complejidad de RollerCoaster Tycoon en ensamblador, sin errores graves, sin actualizaciones posteriores, y con un rendimiento impecable, es simplemente legendario.
Su impacto cultural
Lanzado en 1999, RollerCoaster Tycoon se convirtió en el juego más vendido del año, superando incluso a títulos de grandes estudios, según relata Tech Stories. En el 2000, fue el segundo juego más vendido, solo por detrás de Los Sims. Y todo esto sin campañas de marketing millonarias.
Sawyer continuó con RollerCoaster Tycoon 2, que expandía las ideas del primero pero sin grandes cambios. Más adelante desarrollaría Locomotion, una especie de sucesor espiritual de Transport Tycoon. Pero con el paso del tiempo y el avance de la tecnología, el ensamblador dejó de ser una ventaja competitiva y Sawyer optó por retirarse del desarrollo activo.
Su legado
Su última gran contribución fue supervisar RollerCoaster Tycoon Classic, una adaptación para móviles que requirió reescribir el juego desde cero en un lenguaje de alto nivel como C++. Irónicamente, este proceso tomó más tiempo que el desarrollo original en ensamblador, y tuvo que ser realizado por un equipo entero.
Aunque Sawyer se retirase de la escena, su obra vive gracias a comunidades como OpenRCT2, que han adaptado y expandido el código original para hacerlo compatible con sistemas modernos y añadir nuevas funcionalidades. En YouTube, creadores como Marcel Vos siguen explorando los límites del juego con diseños de montañas rusas imposibles y experimentos fascinantes.
El propio Sawyer, siempre modesto, ha dicho que no descarta volver a crear otro juego, pero que no siente la misma necesidad de antes. Para él, el objetivo siempre fue simple: "crear algo divertido".
Imagen | RollerCoaster Tycoon
En Genbeta | En 'Star Wars' también se programaba: este es el lenguaje que usaban en la Estrella de la Muerte
Ver 3 comentarios