L’étalon-or de l’optimisation : plongée dans les entrailles de RollerCoaster Tycoon

• Sorti en 1999, RollerCoaster Tycoon est un jeu de simulation écrit presque entièrement en assembleur, capable de gérer en temps réel des milliers de visiteurs tout en conservant des performances stables
• Le développeur Chris Sawyer a choisi le contrôle bas niveau plutôt qu’un langage de haut niveau, aboutissant à l’une des dernières grandes générations de jeux en assembleur maximisant l’efficacité des calculs CPU
• Grâce au projet de fans OpenRCT2, les schémas d’optimisation précis et les techniques d’économie mémoire de l’original ont pu être analysés par rétro-ingénierie
• Le jeu exploite les décalages de bits et une granularité fine des types de données pour améliorer la vitesse de calcul et l’efficacité du cache, et rend possible la simulation à grande échelle grâce à une limite de profondeur pour la recherche de chemin et à la suppression des calculs de collision
• Cette architecture est un cas d’école d’optimisation tirant parti de contraintes techniques de façon créative, et montre encore aujourd’hui l’importance d’éliminer les calculs inutiles dès la phase de conception

---

Analyse de l’architecture d’optimisation de RollerCoaster Tycoon

• Sorti en 1999, RollerCoaster Tycoon (RCT) est considéré comme un jeu écrit presque entièrement en assembleur (Assembly), capable de simuler en temps réel des milliers d’agents tout en conservant un framerate stable sur le matériel de l’époque
• En s’appuyant sur un épisode du podcast allemand Stay Forever, l’article analyse en détail comment Chris Sawyer a atteint un niveau d’optimisation extrême
• Le code source original n’a pas été publié, mais le projet de fans OpenRCT2 permet de vérifier par rétro-ingénierie la structure du code et les techniques d’optimisation employées

• Maximisation des performances grâce à l’assembleur

  • RCT a été écrit en assembleur plutôt qu’en C ou en C++, ce qui permettait un contrôle des performances bien plus fin que dans la plupart des autres jeux de l’époque
    • Par exemple, Doom (1993) était majoritairement écrit en C, tandis que RCT a été implémenté presque entièrement en assembleur
    • Cette approche était déjà rare à la fin des années 1990, et RCT est souvent considéré comme l’un des derniers grands jeux en assembleur
  • À l’époque, l’optimisation automatique des compilateurs restait limitée, si bien que l’optimisation manuelle pouvait faire une énorme différence

• Analyse du code via OpenRCT2

  • OpenRCT2 est un projet open source de fans qui a entièrement réimplémenté le jeu original, en réutilisant ses assets tout en conservant une compatibilité à 100 %
    • Les premières versions reproduisaient un comportement presque identique à celui du code original, avant d’intégrer diverses améliorations
  • Ce projet a permis d’observer de près les motifs d’optimisation très fins du code d’origine

• Granularité des types de données — économie de mémoire

  • RCT stocke la taille des données monétaires différemment selon le contexte
    • Exemple : la valeur totale du parc utilise une variable de 4 octets, tandis que le prix d’une boutique tient sur 1 octet
  • Cette granularité visait à économiser la mémoire et à améliorer l’efficacité du cache ; sur les CPU modernes, l’écart de performance est presque nul, si bien qu’OpenRCT2 a unifié cela en une seule variable de 8 octets

• Optimisation des opérations mathématiques avec les décalages de bits

  • Dans le code, des opérations comme NewValue = OldValue >> remplacent les divisions par des puissances de deux
  • Ce type d’optimisation n’est possible que lorsque les multiplications ou divisions portent sur des puissances de deux, ce qui laisse penser que les formules du jeu elles-mêmes ont été conçues pour respecter cette contrainte
  • Autrement dit, la structure mathématique du jeu a été pensée dès la conception pour l’efficacité des calculs CPU

• Un game design pensé pour la performance

  • Comme Chris Sawyer était à la fois programmeur et unique game designer du projet, il a pu bâtir une structure tenant compte des performances dès la phase de conception
  • L’exemple le plus représentatif est le système des visiteurs (pathfinding)
    • Dans la plupart des jeux de simulation, les visiteurs choisissent une destination puis calculent un trajet ; dans RCT, ils marchent de façon aléatoire et découvrent les attractions par hasard
    • Cette approche évite les calculs de pathfinding à grande échelle, ce qui permet de traiter simultanément des milliers de visiteurs
  • Lorsque du pathfinding est nécessaire (par exemple, lorsqu’un mécanicien doit rejoindre une attraction en panne), une limite de profondeur de recherche est appliquée pour éviter les chutes de framerate
    • Les visiteurs ordinaires ne cherchent qu’à travers 5 intersections, les mécaniciens jusqu’à 8
    • Les visiteurs ayant acheté une carte voient cette limite passer à 7
  • Ces limites ne sont pas un simple compromis technique, mais une structure d’optimisation intégrée naturellement au gameplay

• Gestion des foules et suppression de l’évitement des collisions

  • RCT supprime entièrement les collisions et calculs d’évitement entre visiteurs
    • Des milliers de visiteurs peuvent partager la même tuile de chemin
  • À la place, le jeu suit la densité de population locale, et si l’affluence est trop forte, le niveau de bonheur des visiteurs baisse
    • Le joueur doit donc toujours gérer la congestion, mais avec une charge de calcul bien plus faible
  • Cette méthode est considérée comme un excellent exemple de suppression de calculs physiques complexes tout en préservant l’expérience de jeu

• Ce que cela apporte au développement moderne

  • L’optimisation de RCT est souvent citée comme un exemple d’utilisation créative des contraintes techniques
  • Une telle approche reste possible aujourd’hui, mais elle exige une collaboration étroite entre programmeurs et designers
  • Il peut parfois être plus efficace, plutôt que de résoudre un problème technique, de supprimer le problème lui-même dès la conception