Standar Emas Optimisasi: Mengintip Bagian Dalam RollerCoaster Tycoon

• RollerCoaster Tycoon karya tahun 1999 adalah game simulasi yang hampir seluruhnya ditulis dalam assembly, dan tetap mampu mempertahankan performa stabil sambil memproses ribuan pengunjung secara real-time
• Pengembang Chris Sawyer memilih kontrol tingkat rendah alih-alih bahasa tingkat tinggi, dan menyelesaikan generasi terakhir game assembly yang memaksimalkan efisiensi komputasi CPU
• Melalui proyek penggemar OpenRCT2, pola optimisasi yang presisi dan teknik penghematan memori dari versi asli dianalisis lewat rekayasa balik
• Game ini memanfaatkan operasi bit shift dan perincian tipe data untuk meningkatkan kecepatan komputasi dan efisiensi cache, serta memungkinkan simulasi skala besar dengan pembatasan kedalaman pathfinding dan penghapusan perhitungan tabrakan
• Struktur ini merupakan contoh klasik optimisasi yang memanfaatkan keterbatasan teknis secara kreatif, dan masih menunjukkan pentingnya pendekatan menghapus perhitungan yang tidak perlu sejak tahap desain hingga hari ini

---

Analisis Struktur Optimisasi RollerCoaster Tycoon

• RollerCoaster Tycoon (RCT) yang dirilis pada 1999 dinilai sebagai game yang hampir seluruhnya ditulis dalam assembly, mampu mensimulasikan ribuan agen secara real-time sambil mempertahankan frame rate yang stabil pada perangkat keras saat itu
• Berdasarkan pembahasan di podcast game Jerman Stay Forever, artikel ini menganalisis secara konkret bagaimana Chris Sawyer mencapai tingkat optimisasi yang ekstrem
• Kode sumber aslinya tidak dipublikasikan, tetapi melalui proyek OpenRCT2 buatan penggemar, struktur kode dan teknik optimisasinya dapat diperiksa lewat rekayasa balik

• Memaksimalkan performa dengan assembly

  • RCT ditulis dengan assembly, bukan C atau C++, sehingga memungkinkan kontrol performa yang jauh lebih rinci dibanding game lain pada masa itu
    • Sebagai contoh, Doom (1993) sebagian besar ditulis dalam C, sedangkan RCT diimplementasikan hampir sepenuhnya dalam assembly
    • Pendekatan ini sudah tergolong langka pada akhir 1990-an, dan RCT dinilai sebagai salah satu game assembly besar terakhir
  • Pada masa itu, optimisasi otomatis oleh compiler masih terbatas, sehingga optimisasi manual memberi perbedaan performa yang besar

• Analisis kode melalui OpenRCT2

  • OpenRCT2 adalah proyek open source yang sepenuhnya mengimplementasikan ulang game aslinya, tetap menggunakan aset asli sambil mempertahankan kompatibilitas 100%
    • Versi awalnya mereproduksi perilaku yang hampir identik dengan kode asli, lalu berbagai peningkatan ditambahkan setelahnya
  • Melalui proyek ini, pola optimisasi yang sangat rinci dalam kode asli dapat diamati

• Perincian tipe data — penghematan memori

  • RCT menyimpan ukuran data uang secara berbeda tergantung konteks
    • Contoh: nilai total taman memakai variabel 4 byte, harga toko memakai variabel 1 byte
  • Perincian ini ditujukan untuk menghemat memori dan meningkatkan efisiensi cache, tetapi karena pada CPU modern hampir tidak ada perbedaan performa, OpenRCT2 menyatukannya menjadi satu variabel 8 byte

• Optimisasi operasi matematika dengan bit shift

  • Di dalam kode, operasi NewValue = OldValue >> digunakan untuk menggantikan pembagian dengan pangkat dua
  • Optimisasi semacam ini hanya mungkin ketika perkalian atau pembagian melibatkan pangkat dua, sehingga tampaknya rumus di dalam game sendiri dirancang agar memenuhi kondisi tersebut
  • Dengan kata lain, struktur matematika yang mempertimbangkan efisiensi komputasi CPU sudah dipakai sejak tahap desain game

• Desain game yang mempertimbangkan performa

  • Karena Chris Sawyer berperan sebagai programmer sekaligus satu-satunya game designer, ia dapat membangun struktur yang mempertimbangkan performa sejak tahap perancangan
  • Contoh paling representatif adalah sistem pengunjung (pathfinding)
    • Di sebagian besar game simulasi, pengunjung menentukan tujuan lalu mencari rute ke sana, tetapi di RCT pengunjung berjalan secara acak lalu menemukan wahana secara kebetulan
    • Pendekatan ini adalah struktur yang menghindari perhitungan pathfinding berskala besar, sehingga ribuan pengunjung dapat diproses secara bersamaan
  • Saat pathfinding memang diperlukan, misalnya ketika mekanik bergerak menuju wahana yang rusak, diterapkan batas kedalaman pencarian untuk mencegah frame drop
    • Pengunjung biasa hanya mencari hingga 5 persimpangan, mekanik hingga 8
    • Pengunjung yang membeli peta mendapat batas pencarian meningkat menjadi 7
  • Batasan ini bukan sekadar kompromi teknis, melainkan struktur optimisasi yang terintegrasi secara alami ke dalam elemen gameplay

• Penanganan kerumunan dan penghilangan penghindaran tabrakan

  • RCT sepenuhnya menghapus perhitungan tabrakan atau penghindaran antar pengunjung
    • Ribuan pengunjung dapat berbagi tile jalur yang sama
  • Sebagai gantinya, kepadatan populasi sekitar dilacak sehingga jika tingkat keramaian tinggi, kebahagiaan pengunjung menurun
    • Pemain tetap harus mengelola kepadatan, tetapi jumlah komputasinya jauh lebih kecil
  • Pendekatan ini dinilai sebagai contoh representatif yang menghapus perhitungan fisika kompleks sambil tetap mempertahankan pengalaman bermain

• Implikasi bagi pengembangan modern

  • Optimisasi RCT dinilai sebagai contoh pemanfaatan keterbatasan teknis secara kreatif
  • Pendekatan seperti ini masih mungkin dilakukan saat ini, tetapi membutuhkan kolaborasi erat antara programmer dan designer
  • Kadang, alih-alih menyelesaikan masalah teknis, menghilangkan masalah itu sendiri sejak tahap desain dapat memberikan peningkatan performa yang lebih besar

[cadenzah]

Tolong banyak cintai RollerCoaster Tycoon.

[GN⁺]

Komentar Hacker News

• Warcraft 1, 2, dan StarCraft semuanya menggunakan ukuran peta dalam satuan pangkat dua
  Berkat itu, performa bisa ditingkatkan dengan operasi shift alih-alih pembagian dan perkalian, bahkan di CPU 386/486 yang lambat
  Rendering peta, sprite, font, efek kabut, dan sebagainya ditangani dengan ribuan baris assembly, sementara sisanya adalah kode portabel yang ditulis dalam C
  Untuk Blackthorne, versi SNES, Genesis, dan DOS masing-masing di-porting secara manual dengan assembly yang berbeda, dan versi PC menghasilkan 100 ribu baris kode rendering dengan makro untuk VGA Mode X
  Dari pengalaman ini, Blizzard mendapat pelajaran bahwa “assembly memakan terlalu banyak waktu pengembangan”
  Comanche: Maximum Overkill adalah simulator helikopter berbasis voxel yang seluruhnya ditulis dalam assembly, tetapi karena porting ke protected mode terlalu sulit, mulai versi berikutnya beralih ke rendering poligon

  • Seorang pengguna Reddit menemukan source code gold master StarCraft, tetapi sayang malah mengembalikannya dengan imbalan merchandise Blizzard
    EA memang merilis source code seri Command & Conquer, tetapi Tiberian Sun dan Red Alert 2 tidak termasuk
    Akan bagus jika StarCraft juga dirilis demi pelestarian sejarah
  • Saat kecil, ketika pertama kali melihat Comanche dan Settlers 1, grafis yang muncul di mode teks DOS terasa seperti sihir
    Sejak saat itu saya benar-benar tenggelam dalam game
  • Kalau ikut terlibat di Lost Vikings juga, saya ingin menyampaikan terima kasih karena sudah memberi kegembiraan di masa kecil
    Saya juga penasaran apakah pernah aktif di demoscene
  • Saat berada di Blizzard, pernah ada insiden server source code hilang dan tidak ada backup, saya penasaran apakah Anda ada di sana saat itu
    Saya sempat menjadi konsultan sebentar sekitar masa rilis WC3
  • Maximum Overkill benar-benar game luar biasa sampai saya memainkannya ratusan jam

• Seperti yang disebut dalam tulisan, hasilnya tampak jauh lebih mengesankan ketika desainer dan programmer adalah orang yang sama
  Dalam struktur hierarkis perusahaan besar pun, sesuatu tetap bisa jadi kalau didorong dengan banyak orang, tetapi hasil yang benar-benar kreatif sering kali berawal dan selesai di kepala satu orang
  Saya jadi merasa masa depan alat pengembangan AI mungkin juga akan membawa kita kembali ke era ‘pengembangan satu orang’

• Desainer game tetap perlu mempertimbangkan karakteristik numerik
  Semakin baik desainernya, semakin ia paham bahwa hal-hal seperti efisiensi komputasi atau presisi bisa memengaruhi balance game
  Sekarang ada banyak developer yang mengabaikan hal ini, padahal itu kadang menjadi penyebab tersembunyi turunnya kualitas game

  • Dulu saya juga menganggap mikro-optimisasi seperti ini penting, tetapi setelah mempelajari struktur pipeline CPU modern, pandangan saya berubah
    Sekarang penjumlahan sekitar 1 siklus, perkalian 3 siklus, pembagian 12 siklus, dan beberapa operasi bisa diproses paralel sekaligus
    Di era Pentium lama, pembagian bisa memakan 46 siklus dan clock-nya pun hanya 100MHz
    Sekarang layout memori jauh lebih penting — satu cache miss saja bisa menghabiskan 100~1000 siklus
    Operasi pada int[] jauh lebih cepat daripada Monster[]
  • Saya sedang mengembangkan kernel CAD csgrs, dan merasa bahwa perhitungan numerik masih merupakan masalah yang belum terselesaikan
    Ada trade-off antara kecepatan, akurasi, ukuran penyimpanan, dan kompleksitas
    Makalah seperti Toward an API for the Real Numbers menawarkan pendekatan untuk menyelesaikan masalah ini secara bertahap
    Ada berbagai metode seperti error floating-point, interval arithmetic, dan symbolic computation, tetapi pada akhirnya kalau tidak memahami trade-off, masalahnya akan berbalik menggigit
  • Game komersial adalah produk yang diproduksi massal, jadi desainer yang memahami batasan teknis punya keunggulan besar dalam hal sense desain industri
    Misalnya, Fumito Ueda dengan cermat mempertimbangkan kelayakan teknis di 『Shadow of the Colossus』, dan Doom juga merupakan gabungan kreativitas dan teknologi
    Lihat wawancara terkait
  • Kualitas game bukan sekadar soal performa runtime yang efisien, tetapi soal kesenangan dan tingkat penyelesaian
    Bug, konsistensi cerita, dan rasa imersi lebih penting
    Tentu saja frame drop parah menurunkan kualitas, tetapi kalau sudah berjalan mulus di hardware target, perbaikannya sebaiknya difokuskan ke area lain
  • Saat mengembangkan produk berbasis ARM Cortex-M4, saya pernah membuat generator angka acak kustom
    Saya menyesuaikannya agar konstanta bisa dimuat secara langsung dengan instruksi Thumb-2 sehingga menghindari memory stall
    Hasilnya angka acak bisa digunakan dengan cepat dan efisien, dan semua pengujian juga lolos
    Namun kemudian produk berganti ke Cortex-M0 dan kode ini pun dibuang

• Menarik melihat bagaimana batasan teknis diubah menjadi elemen gameplay
  Ini mengingatkan saya pada sistem Blood Moon di 『The Legend of Zelda』

• Penjelasan bahwa “menggunakan >>3 alih-alih /8 bisa menghemat pembagian” itu tidak benar di compiler modern
  Jika tipenya sesuai, compiler akan otomatis mengoptimalkannya menjadi operasi shift

  • Namun untuk integer bertanda (signed), operasi tambahan bisa masuk demi menyesuaikan aturan pembulatan standar C

• Saya terkejut melihat penjelasan bahwa “shift kiri pada bilangan biner berarti dikali dua”
  Menarik bahwa pada 2026 konsep dasar seperti ini bisa terasa asing dan baru lagi

  • Ini mengingatkan saya pada xkcd 2501

• Ucapan bahwa “compiler tidak mengubah perkalian pangkat dua menjadi shift” adalah lelucon lama
  Bahkan sejak era 2000-an, compiler sudah menganggap optimisasi seperti itu terlalu sepele sampai-sampai menguap saat melihatnya

• Seru dibaca. Untuk RCT, saya juga merekomendasikan bahan-bahan berikut

  • Wawancara Chris Sawyer (2024)
  • Percikan terakhir MicroProse
  • Wawancara 25 tahun RCT
  • Video “RollerCoaster Tycoon was the last of its kind”
  • The Story of RollerCoaster Tycoon (YouTube)

• Saya penasaran apakah di studio besar juga mungkin mengangkat batasan teknis menjadi ciri khas game
  Seperti dalam storytelling, hambatan justru bisa membuat cerita lebih menarik; developer solo bisa mengubah keterbatasan teknis menjadi elemen kreatif
  Misalnya, bug atau glitch ditafsirkan ulang sebagai minigame

• Saat melihat bagian pathfinding di RCT, saya teringat video YouTube Marcel Vos
  Ia banyak mengunggah video yang membedah cara kerja internal RCT secara mendalam