- RollerCoaster Tycoon, lanzado en 1999, es un juego de simulación escrito casi por completo en ensamblador, y aun así mantenía un rendimiento estable mientras procesaba a miles de visitantes en tiempo real
- El desarrollador Chris Sawyer eligió el control de bajo nivel en lugar de lenguajes de alto nivel, y completó uno de los últimos juegos en ensamblador de gran escala que llevó al máximo la eficiencia de cómputo de la CPU
- A través del proyecto de fans OpenRCT2, se analizaron mediante ingeniería inversa los patrones de optimización precisos y las técnicas de ahorro de memoria del original
- El juego aprovechó operaciones de desplazamiento de bits y una granularidad fina en los tipos de datos para mejorar la velocidad de cómputo y la eficiencia de caché, y hizo posible una simulación a gran escala mediante límites en la profundidad de búsqueda de rutas y la eliminación de cálculos de colisión
- Esta estructura es un ejemplo clásico de optimización que aprovecha creativamente las limitaciones técnicas, y todavía hoy muestra la importancia de eliminar operaciones innecesarias desde la etapa de diseño
Análisis de la estructura de optimización de RollerCoaster Tycoon
- RollerCoaster Tycoon (RCT), lanzado en 1999, fue escrito casi por completo en ensamblador (Assembly), y es considerado un juego capaz de simular en tiempo real a miles de agentes manteniendo cuadros estables en el hardware de la época
- Basado en lo tratado por el pódcast alemán sobre videojuegos Stay Forever, aquí se analiza en detalle cómo Chris Sawyer logró un nivel extremo de optimización
- Aunque el código fuente original no se ha publicado, el proyecto hecho por fans OpenRCT2 permite confirmar mediante ingeniería inversa la estructura del código y sus técnicas de optimización
-
Maximización del rendimiento con ensamblador
- RCT fue escrito en ensamblador en lugar de C o C++, lo que permitió un control de rendimiento mucho más detallado que en otros juegos de la época
- Por ejemplo, Doom (1993) fue escrito mayormente en C, mientras que RCT fue implementado casi por completo en ensamblador
- Este enfoque ya era poco común a finales de los años 90, y RCT es considerado uno de los últimos grandes juegos en ensamblador
- En ese momento, la optimización automática de los compiladores era limitada, así que la optimización manual marcaba una gran diferencia en el rendimiento
-
Análisis del código a través de OpenRCT2
- OpenRCT2 es un proyecto de código abierto en el que fans reimplementaron por completo el juego original, manteniendo compatibilidad del 100% mientras usa los recursos originales
- Las primeras versiones reproducían un comportamiento casi idéntico al del código original, y después se añadieron varias mejoras
- Gracias a este proyecto fue posible verificar los patrones detallados de optimización del código original
-
Granularidad fina en los tipos de datos — ahorro de memoria
- RCT almacena los datos monetarios con tamaños distintos según el contexto
- Ejemplo: el valor total del parque usa una variable de 4 bytes, mientras que el precio de una tienda usa una variable de 1 byte
- Esta granularidad se usó para ahorrar memoria y mejorar la eficiencia de caché, aunque en las CPU modernas casi no hay diferencia de rendimiento, por lo que en OpenRCT2 se unificó todo en una sola variable de 8 bytes
-
Optimización de operaciones matemáticas usando desplazamiento de bits
- En el código aparecen operaciones como
NewValue = OldValue >> que sustituyen divisiones por potencias de 2
- Como esta optimización solo es posible cuando la multiplicación o la división involucran potencias de 2, parece que las propias fórmulas del juego fueron diseñadas para ajustarse a esa condición
- Es decir, desde la etapa de diseño del juego se usó una estructura matemática pensada para la eficiencia de cómputo de la CPU
-
Diseño del juego con el rendimiento en mente
- Como Chris Sawyer participó en RCT como programador y único diseñador del juego, pudo construir una estructura que ya consideraba el rendimiento desde la fase de diseño
- Un caso representativo es el sistema de visitantes (pathfinding)
- En la mayoría de los juegos de simulación, los visitantes eligen un destino y buscan una ruta, pero en RCT los visitantes caminan al azar y descubren atracciones por casualidad
- Este enfoque evita operaciones de búsqueda de rutas a gran escala, lo que permite procesar miles de visitantes al mismo tiempo
- Cuando sí se necesita búsqueda de rutas, por ejemplo cuando un mecánico se dirige a una atracción averiada, se establece un límite de profundidad de búsqueda para evitar caídas de frames
- Los visitantes normales solo buscan hasta 5 cruces, y los mecánicos hasta 8
- Los visitantes que compran un mapa aumentan su límite de búsqueda a 7
- Estas limitaciones no son solo una concesión técnica, sino una estructura de optimización integrada de forma natural en la jugabilidad
-
Manejo de multitudes y omisión de evasión de colisiones
- RCT elimina por completo los cálculos de colisión o evasión entre visitantes
- Miles de visitantes pueden compartir la misma casilla de camino
- En su lugar, rastrea la densidad de población cercana y está diseñado para que si la congestión es alta, disminuya la felicidad de los visitantes
- El jugador sigue teniendo que gestionar la congestión, pero con una carga computacional mucho menor
- Este enfoque es considerado un ejemplo representativo de cómo mantener la experiencia de juego mientras se eliminan cálculos físicos complejos
-
Lo que sugiere para el desarrollo moderno
- La optimización de RCT es considerada un caso de uso creativo de las limitaciones técnicas
- Incluso hoy este enfoque sigue siendo posible, pero requiere una colaboración estrecha entre programadores y diseñadores
- A veces, en lugar de resolver un problema técnico, eliminar el problema mismo desde la etapa de diseño puede traer una mejora de rendimiento mucho mayor
2 comentarios
Por favor, denle mucho amor a RollerCoaster Tycoon.
Comentarios de Hacker News
Warcraft 1, 2 y StarCraft usaban mapas con tamaños en potencias de 2
Gracias a eso, podían ganar velocidad en CPUs 386/486 lentos usando operaciones de desplazamiento en lugar de divisiones y multiplicaciones
El renderizado del mapa, sprites, tipografías, efectos de niebla y demás se resolvía con miles de líneas de ensamblador, y el resto era código altamente portable escrito en C
En el caso de Blackthorne, las versiones de SNES, Genesis y DOS se portaron a mano con ensamblador distinto para cada una, y en PC generaron por macros 100 mil líneas de código de renderizado para VGA Mode X
Esa experiencia llevó a Blizzard a sacar la lección de que “el ensamblador consume demasiado tiempo de desarrollo”
Comanche: Maximum Overkill era un simulador de helicópteros basado en vóxeles escrito por completo en ensamblador, pero como portarlo a modo protegido era demasiado difícil, desde versiones posteriores cambiaron a renderizado poligonal
EA sí publicó el código fuente de la serie Command & Conquer, aunque faltaban Tiberian Sun y Red Alert 2
Habría estado bien que StarCraft también se liberara por preservación histórica
Desde entonces me enganché por completo a los videojuegos
También me da curiosidad si estuvo activo en la demoscene
Yo estuve un tiempo corto como consultor cerca del lanzamiento de WC3
Como se menciona en el artículo, parece que los resultados son mucho más impresionantes cuando el diseñador y el programador son la misma persona
Incluso con la estructura jerárquica de una gran empresa, al final algo sale si le echas suficiente gente, pero los resultados realmente creativos muchas veces nacen completos en la cabeza de una sola persona
También me hace pensar que el futuro de las herramientas de desarrollo con IA podría ser un regreso a esta era del “desarrollador de una sola persona”
Los diseñadores de juegos todavía tienen que considerar las características numéricas
Cuanto mejor es un diseñador, más entiende que factores como la eficiencia computacional o la precisión pueden afectar el balance del juego
Hoy muchos desarrolladores ignoran esto, pero a veces termina siendo una causa oculta de la baja calidad de un juego
Hoy hablamos de algo como 1 ciclo para suma, 3 para multiplicación y 12 para división, además de que varias operaciones pueden ejecutarse en paralelo
En la época del Pentium eran 46 ciclos y además corría a 100 MHz
Ahora el layout de memoria importa mucho más: un solo cache miss puede costarte entre 100 y 1000 ciclos
Operar sobre
int[]es muchísimo más rápido que sobreMonster[]Hay trade-offs entre velocidad, precisión, tamaño de almacenamiento y complejidad
Artículos como Toward an API for the Real Numbers proponen enfoques para resolver este tipo de problema de forma gradual
Hay muchas técnicas —error de punto flotante, aritmética de intervalos, operaciones simbólicas—, pero al final si no entiendes los trade-offs, el problema te termina mordiendo
Por ejemplo, Fumito Ueda consideró con mucho cuidado la viabilidad técnica en Shadow of the Colossus, y Doom también fue una combinación de creatividad y tecnología
Véase esta entrevista relacionada
Los bugs, la coherencia de la historia y la inmersión son más importantes
Claro, si hay caídas fuertes de frames, la calidad baja, pero si corre fluido en el hardware objetivo, las mejoras deberían concentrarse en otras áreas
Lo ajusté para poder cargar constantes de inmediato con instrucciones Thumb-2 y así evitar memory stalls
Gracias a eso, pude usar números aleatorios de forma rápida y eficiente, y todas las pruebas pasaron
Pero después cambiaron a Cortex-M0 y ese código terminó desechándose
Me pareció interesante la parte de convertir las limitaciones técnicas en elementos de gameplay
Me recordó al sistema de Blood Moon de The Legend of Zelda
La explicación de que “si usas
>>3en vez de/8, te ahorras la división” ya no es cierta con compiladores modernosSi el tipo es correcto, el compilador lo optimiza automáticamente a una operación de desplazamiento
signed), sí pueden añadirse operaciones extra para respetar las reglas de redondeo del estándar de CMe sorprendió ver la explicación de que “en binario, un desplazamiento a la izquierda equivale a multiplicar por dos”
Qué curioso que en 2026 una idea tan básica pueda sentirse tan ajena o novedosa otra vez
Decir que “el compilador no cambia una multiplicación por potencia de 2 a un shift” es un chiste muy viejo
Incluso en los 2000, los compiladores ya bostezaban al ver ese tipo de código porque lo optimizaban por defecto
Lo leí con gusto. Sobre RCT, también recomiendo estos materiales
Me pregunto si en un estudio grande también es posible elevar las limitaciones técnicas hasta convertirlas en rasgos distintivos del juego
Así como en la narrativa los obstáculos vuelven más interesante una historia, un desarrollador en solitario puede transformar las limitaciones técnicas en elementos creativos
Se me ocurre, por ejemplo, reinterpretar bugs o glitches como minijuegos
Al ver la parte del pathfinding de RCT, pensé en el video de YouTube de Marcel Vos
Tiene muchos videos donde examina a fondo el funcionamiento interno de RCT