ऑप्टिमाइज़ेशन का गोल्ड स्टैंडर्ड: RollerCoaster Tycoon के अंदरूनी ढांचे पर एक नज़र

• 1999 में आया RollerCoaster Tycoon लगभग पूरी तरह Assembly में लिखा गया simulation game था, जो हज़ारों guests को real time में प्रोसेस करते हुए भी स्थिर performance बनाए रखता था
• डेवलपर Chris Sawyer ने high-level language के बजाय low-level control चुना और CPU computation efficiency को अधिकतम करने वाली आख़िरी पीढ़ी के Assembly games में से एक तैयार किया
• फैन प्रोजेक्ट OpenRCT2 के ज़रिए मूल गेम के सटीक optimization patterns और memory-saving techniques का reverse engineering के माध्यम से विश्लेषण किया गया
• गेम ने bit shift operations और data type granularity का उपयोग करके computation speed और cache efficiency बढ़ाई, और pathfinding depth limits व collision calculations को हटाकर बड़े पैमाने की simulation संभव बनाई
• यह संरचना तकनीकी सीमाओं का रचनात्मक उपयोग करने वाले optimization का एक क्लासिक उदाहरण है, और आज भी दिखाती है कि design phase में अनावश्यक computations हटाने का दृष्टिकोण कितना महत्वपूर्ण है

---

RollerCoaster Tycoon की optimization संरचना का विश्लेषण

• 1999 में रिलीज़ हुआ RollerCoaster Tycoon(RCT) लगभग पूरी तरह Assembly में लिखा गया था, और इसे ऐसा गेम माना जाता है जो हज़ारों agents को real time में simulate करते हुए भी उस समय के hardware पर स्थिर frame rate बनाए रखता था
• जर्मन गेम podcast Stay Forever में की गई चर्चा के आधार पर, यह विस्तार से विश्लेषण किया गया है कि Chris Sawyer ने इतनी चरम स्तर की optimization कैसे हासिल की
• मूल source code सार्वजनिक नहीं है, लेकिन फैंस द्वारा बनाए गए OpenRCT2 प्रोजेक्ट के माध्यम से code structure और optimization techniques को reverse engineering से देखा जा सकता है

• Assembly आधारित performance maximization

  • RCT को C या C++ के बजाय Assembly में लिखा गया था, जिससे उस समय के दूसरे games की तुलना में कहीं अधिक सूक्ष्म performance control संभव हुआ
    • उदाहरण के लिए, Doom (1993) का अधिकांश हिस्सा C में लिखा गया था, जबकि RCT लगभग पूरी तरह Assembly में implement किया गया था
    • 1990 के दशक के उत्तरार्ध तक यह तरीका पहले ही दुर्लभ हो चुका था, और RCT को आख़िरी बड़े Assembly games में से एक माना जाता है
  • उस समय compiler की automatic optimization सीमित थी, इसलिए manual optimization performance में बड़ा अंतर पैदा कर सकती थी

• OpenRCT2 के माध्यम से code analysis

  • OpenRCT2 फैंस द्वारा बनाया गया एक open source प्रोजेक्ट है, जिसने मूल गेम को पूरी तरह reimplement किया है और मूल assets का उपयोग करते हुए भी 100% compatibility बनाए रखता है
    • शुरुआती versions ने मूल code के लगभग समान behavior को reproduce किया, और बाद में कई तरह के improvements जोड़े गए
  • इस प्रोजेक्ट के माध्यम से मूल code के सूक्ष्म optimization patterns को देखा जा सका

• Data types का सूक्ष्म विभाजन — memory savings

  • RCT में राशि से जुड़े data का size स्थिति के अनुसार अलग-अलग रखा जाता है
    • उदाहरण: पूरे पार्क की value के लिए 4-byte variable, जबकि दुकान की कीमत के लिए 1-byte variable
  • यह विभाजन memory बचाने और cache efficiency बढ़ाने के लिए था, लेकिन आधुनिक CPU पर performance का अंतर लगभग नहीं के बराबर है, इसलिए OpenRCT2 में इसे एक ही 8-byte variable में एकीकृत किया गया

• Bit shift से mathematical operations की optimization

  • code में NewValue = OldValue >> जैसे operations का उपयोग 2 की power से division को replace करने के लिए किया गया
  • इस तरह की optimization केवल तब संभव है जब multiplication या division 2 की power हो, इसलिए लगता है कि गेम के formulas को भी इसी शर्त के अनुरूप design किया गया था
  • यानी, game design phase से ही CPU computation efficiency को ध्यान में रखकर mathematical structure बनाई गई थी

• Performance को ध्यान में रखकर game design

  • RCT में Chris Sawyer programmer और एकमात्र game designer दोनों थे, इसलिए वे design phase से ही performance-aware structure बना सके
  • इसका प्रमुख उदाहरण guest pathfinding system है
    • अधिकांश simulation games में guests किसी destination को चुनकर उसका path खोजते हैं, लेकिन RCT में guests यूं ही random चलते रहते हैं और संयोग से rides खोज लेते हैं
    • यह तरीका बड़े पैमाने की pathfinding calculations से बचने वाली संरचना है, जिससे हज़ारों guests को एक साथ संभालना संभव हुआ
  • जहाँ pathfinding आवश्यक होती है (जैसे कोई mechanic खराब ride तक जाए), वहाँ search depth limit रखी गई ताकि frame drops रोके जा सकें
    • सामान्य guests केवल 5 intersections तक खोजते हैं, mechanic 8 तक
    • map खरीदने वाले guests के लिए search limit 7 तक बढ़ जाती है
  • ये सीमाएँ सिर्फ तकनीकी समझौता नहीं थीं, बल्कि optimization को gameplay element के रूप में स्वाभाविक रूप से integrate करने वाली संरचना थीं

• Crowd handling और collision avoidance को छोड़ना

  • RCT में guests के बीच collision या avoidance calculations को पूरी तरह हटा दिया गया
    • हज़ारों guests एक ही path tile को share कर सकते हैं
  • इसके बजाय आसपास की population density को track किया जाता है, ताकि भीड़ बढ़ने पर guests की happiness कम हो
    • इससे player को अब भी भीड़ को manage करना पड़ता है, लेकिन computation बहुत कम हो जाती है
  • यह तरीका जटिल physics calculations हटाकर भी game experience बनाए रखने का एक प्रतिनिधि उदाहरण माना जाता है

• आधुनिक development के लिए संकेत

  • RCT की optimization को तकनीकी सीमाओं का रचनात्मक उपयोग करने वाले उदाहरण के रूप में देखा जाता है
  • आज भी ऐसा दृष्टिकोण संभव है, लेकिन इसके लिए programmers और designers के बीच घनिष्ठ सहयोग ज़रूरी है
  • कई बार तकनीकी समस्या को हल करने से बेहतर, समस्या को ही design phase में हटा देना कहीं बड़ा performance improvement दे सकता है

[cadenzah]

कृपया RollerCoaster Tycoon को बहुत प्यार दें

[GN⁺]

Hacker News की राय

• Warcraft 1, 2, StarCraft — इन सभी में 2 की घात वाली map size units इस्तेमाल की गई थीं
  इसकी वजह से धीमे 386/486 CPU पर division·multiplication की जगह shift operations से speed हासिल की जा सकती थी
  map rendering, sprite, font, fog effects आदि हज़ारों lines की assembly में संभाले गए थे, और बाकी हिस्सा C में लिखा गया highly portable code था
  Blackthorne के मामले में SNES, Genesis, DOS versions को अलग-अलग assembly में हाथ से port किया गया था, और PC version के लिए VGA Mode X हेतु 100,000 lines का rendering code macros से generate किया गया था
  ऐसे अनुभवों से Blizzard ने यह सबक सीखा कि “assembly बहुत ज़्यादा development time खा जाती है”
  Comanche: Maximum Overkill पूरी तरह assembly में लिखा गया voxel-based helicopter simulator था, लेकिन protected mode में port करना बहुत कठिन था, इसलिए बाद के versions में polygon rendering पर स्विच किया गया

  • Reddit के एक user को StarCraft gold master source code मिला था, लेकिन उसने उसे Blizzard merchandise के बदले लौटाया — यह थोड़ा अफसोसजनक लगा
    EA ने Command & Conquer series source code जारी किया था, लेकिन Tiberian Sun और Red Alert 2 उसमें शामिल नहीं थे
    अच्छा होता अगर StarCraft भी इतिहास के संरक्षण के लिए सार्वजनिक किया जाता
  • बचपन में जब मैंने पहली बार Comanche और Settlers 1 देखे, तो DOS text mode में graphics निकलना जादू जैसा लगा था
    उसी समय से मैं games में पूरी तरह डूब गया
  • अगर उन्होंने Lost Vikings पर भी काम किया था, तो बचपन की खुशी देने के लिए धन्यवाद कहना चाहूँगा
    यह भी जानने की जिज्ञासा है कि क्या वे demoscene में भी सक्रिय थे
  • Blizzard में रहते समय source code server खो जाने और backup न होने वाली घटना हुई थी — क्या वे उस समय वहाँ थे, यह जानना चाहूँगा
    मैं WC3 release के आसपास थोड़े समय के लिए consultant था
  • Maximum Overkill सचमुच ऐसा शानदार game था कि मैंने उसे सैकड़ों घंटे खेला

• जैसा लेख में कहा गया है, जब designer और programmer एक ही व्यक्ति होते हैं, तो नतीजा कहीं ज़्यादा प्रभावशाली लगता है
  बड़ी कंपनियों की hierarchical structure में भी आखिरकार manpower झोंककर कुछ न कुछ बना लिया जाता है, लेकिन सचमुच रचनात्मक परिणाम अक्सर एक ही व्यक्ति के दिमाग से पूरा रूप लेते हैं
  यह भी लगता है कि AI development tools का भविष्य शायद ऐसे ‘one-person development era’ की वापसी हो सकता है

• game designers को आज भी numerical characteristics का ध्यान रखना चाहिए
  जितना अच्छा designer होगा, उतना ही वह समझेगा कि computational efficiency या precision जैसी चीज़ें game balance को प्रभावित करती हैं
  आजकल कई developers इसे नज़रअंदाज़ करते हैं, लेकिन यही कभी-कभी game quality गिरने का छिपा हुआ कारण बनता है

  • पहले मैं भी मानता था कि ऐसी micro-optimizations बहुत महत्वपूर्ण हैं, लेकिन modern CPU pipeline architecture पढ़ने के बाद मेरी सोच बदल गई
    आज addition लगभग 1 cycle, multiplication 3 cycles, division 12 cycles के स्तर पर है, और कई operations एक साथ parallel में चलते हैं
    पुराने Pentium दौर में यह 46 cycles लेता था और clock भी 100MHz थी
    अब memory layout कहीं ज़्यादा महत्वपूर्ण है — एक cache miss में 100~1000 cycles निकल सकते हैं
    int[] पर काम करना Monster[] से काफ़ी तेज़ होता है
  • मैं csgrs CAD kernel विकसित कर रहा हूँ, और महसूस करता हूँ कि numeric computation अभी भी अनसुलझी समस्या है
    speed, accuracy, storage size और complexity के बीच trade-off मौजूद है
    Toward an API for the Real Numbers जैसे papers इन समस्याओं को चरणबद्ध ढंग से हल करने की approach पेश करते हैं
    floating-point error, interval arithmetic, symbolic computation जैसी कई विधियाँ हैं, लेकिन अंत में trade-off को न समझो तो वही समस्या काट खाती है
  • commercial games बड़े पैमाने पर बनने वाले products हैं, इसलिए designers का technical constraints समझना industrial design sense के रूप में बड़ा फ़ायदा है
    उदाहरण के लिए Fumito Ueda ने 『Shadow of the Colossus』 में technical feasibility पर बहुत बारीकी से विचार किया था, और Doom भी creativity और technology का संगम था
    संबंधित interview देखें
  • game quality सिर्फ़ efficient runtime performance का सवाल नहीं है, बल्कि मज़ा और polish का मुद्दा भी है
    bug, story consistency, immersion ज़्यादा महत्वपूर्ण हैं
    बेशक frame drops बहुत हों तो quality घटती है, लेकिन अगर target hardware पर game smoothly चल रहा है, तो सुधार किसी और हिस्से पर केंद्रित होना चाहिए
  • ARM Cortex-M4 आधारित product बनाते समय मैंने custom random number generator बनाया था
    Thumb-2 instructions में constants को immediate load किया जा सके, इसके लिए adjustment किया ताकि memory stalls से बचा जा सके
    इसकी वजह से random numbers तेज़ और efficiently इस्तेमाल हो सके, और सारे tests भी pass हुए
    लेकिन बाद में Cortex-M0 पर बदलाव होने से यह code हटा दिया गया

• technical constraints को gameplay elements में बदलने वाला हिस्सा दिलचस्प लगा
  इससे 『The Legend of Zelda』 के Blood Moon system की याद आई

• “/8 की जगह >>3 लिखो तो division बच जाएगा” — यह बात modern compilers में सही नहीं है
  अगर type सही हो, तो compiler अपने-आप उसे shift operation में optimize कर देता है

  • हाँ, signed integers के मामले में C standard की rounding rules मिलाने के लिए कुछ extra operations जुड़ सकते हैं

• “binary में left shift करने से value दोगुनी हो जाती है” — यह पढ़कर हैरानी हुई
  2026 में इस तरह की बुनियादी अवधारणा भी फिर से नई और अजनबी लग सकती है, यह दिलचस्प है

  • xkcd 2501 याद आ गया

• “compiler 2 की घात वाले multiplication को shift में नहीं बदलता” — यह बहुत पुराना मज़ाक है
  2000s में भी compiler ऐसे code को देखकर जम्हाई लेते हुए आराम से optimize कर देता था

• पढ़ने में मज़ा आया। RCT के बारे में ये सामग्रियाँ भी सुझाऊँगा

  • Chris Sawyer interview (2024)
  • MicroProse की आख़िरी चमक
  • RCT 25वीं वर्षगाँठ interview
  • “RollerCoaster Tycoon was the last of its kind” वीडियो
  • The Story of RollerCoaster Tycoon (YouTube)

• यह जानने की जिज्ञासा है कि क्या बड़े studios में भी technical constraints को game features में sublimation करना संभव है
  जैसे storytelling में बाधाएँ कहानी को दिलचस्प बनाती हैं, वैसे ही solo developers technical limits को creative elements में बदल सकते हैं
  उदाहरण के लिए bugs या glitches को mini-game की तरह reinterpret करने वाला approach दिमाग में आता है

• RCT के pathfinding हिस्से को देखकर Marcel Vos का YouTube वीडियो याद आया
  वे RCT के internal workings को गहराई से खोलकर दिखाने वाले कई वीडियो डालते हैं