Space Quest II मास्टर डिस्क की गलती

 (lanceewing.github.io)
1 पॉइंट द्वारा GN⁺ 2024-05-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Sierra On-Line की Space Quest II 2.0D/2.0F 720KB Disk 1 में AGI interpreter का source code बचा रह गया था, जो file list में दिखाई नहीं देता था; यह master disk तैयार करते समय हुई गलती का मामला था जो commercial disks में जस-का-तस copy हो गया
  • DOS FAT में file delete करने पर data मिटाया नहीं जाता, केवल sectors को unused mark किया जाता है, इसलिए अगर बिना format की हुई disk को master के रूप में इस्तेमाल किया जाए तो पुराना data सभी copies में साथ जा सकता है
  • Disk 1 के 402,432-byte “free” area में format fill value 0xF6 के बजाय C/assembly source बचा हुआ था; extraction से 93 files, 15,000 से ज्यादा lines, और AGI interpreter source का करीब 70% मिला
  • FormMaster duplication equipment ने files के स्तर पर नहीं, बल्कि disk के सभी sectors को byte-by-byte copy किया, जिससे वास्तविक file list में मौजूद न होने वाला deleted data भी customers और retail stores के लिए बनी disks में फैल गया हो सकता है
  • March 1988 में AGI era के अंतिम दौर में हुई यह गलती October 2016 में NewRisingSun द्वारा पहली ज्ञात खोज किए जाने तक दबी रही, और 36 साल बाद Sierra के AGI implementation में झांकने वाला digital archaeology material बन गई

File list से न दिखने वाले निशान

  • Space Quest II version 2.0D और 2.0F की 720KB floppy disks बाहर से खास नहीं दिखतीं, और file list भी सामान्य Sierra game disk जैसी लगती है
  • 2.0D directory में कोई संदिग्ध extra file नहीं है, और PICDIR, LOGDIR, VIEWDIR, SNDDIR, VOL.0, VOL.1 जैसी मुख्य data files 14 March 1988 को बनाई गई थीं
  • .OVL files का timestamp 15 March 1988 है, और AGI interpreter code का timestamp 18 March 1988 है, जिससे Sierra office में Space Quest II 2.0D की तैयारी एक हफ्ते तक चली होने के निशान मिलते हैं
  • Disk का used space 302,918 bytes और “free” space 402,432 bytes दिखाया गया, यानी खाली space इस्तेमाल हुए space से ज्यादा था

Hex editor में दिखा unused area

  • DOS में newly formatted floppy disk के unused sectors आम तौर पर format fill value 0xF6 से भरे होते हैं
  • Space Quest II 2.0D की Disk 2 में unused sectors 0xF6 से भरे थे, लेकिन Disk 1 में 0xF6 से भरा एक भी unused sector नहीं था
  • Disk 1 में लगातार 0xF6 bytes की सबसे लंबी sequence सिर्फ 2 bytes की थी, और आधे से ज्यादा space “free” होने के बावजूद वास्तव में पुराना data बचा हुआ था
  • unused mark किए गए area में C source code जैसा दिखने वाला text था, जो मजबूती से संकेत देता है कि Space Quest II Disk 1 master के रूप में इस्तेमाल होने से पहले यह disk किसी और काम में इस्तेमाल हुई थी
  • DOS FAT file system में file delete करने पर actual data हटता नहीं है, बल्कि sectors को दोबारा इस्तेमाल योग्य mark किया जाता है; इसलिए अगर नई files उन्हें overwrite न करें तो पुरानी सामग्री जस-की-तस रहती है

बचा हुआ AGI interpreter source code

  • unused area से ASCII text extract करने पर DisplayStatusLine और StatusLineOn जैसे C functions मिले
  • DisplayStatusLine current score और sound on/off status वाली text line दिखाने वाला code है, और Space Quest II screen के ऊपर की सफेद status bar से जुड़ा है
  • यह code game data नहीं, बल्कि Sierra के AGI interpreter itself का source code है
  • unused sectors में बड़ी मात्रा में source code था, और code consecutive sectors में stored था, इसलिए उसे extract करना और files में अलग-अलग बांटना तुलनात्मक रूप से आसान था
  • हर file के top पर source file name बताने वाला comment था, जिससे split points ढूंढना आसान रहा; अलग करने पर कुल 93 files मिलीं
    • 75 C source files
    • 16 assembly source files
    • 2 DOS BAT files
  • पूरा code 15,000 lines से ज्यादा है, और ज्यादातर files complete form में थीं
  • इस disk में Sierra On-Line के AGI interpreter source code का लगभग 70% comments और change history सहित मौजूद था

Change history और developer traces

  • कुछ source files के top header comments में Change History शामिल है
  • ANIMATE.C header में source file name, “adventure game में animation का एक cycle process करता है” जैसा छोटा description, और compile: MWC जैसी information है
  • MWC उस समय widely used Mark Williams का C compiler प्रतीत होता है
  • change history में date, time, changer के initials, और change description शामिल हैं
  • initials में JAS AGI interpreter code पर मुख्य रूप से काम करने वाले Jeff Stephenson को, और DCI Chris Iden को दर्शाते हैं
  • Robert Heitman भी दिखाई देते हैं, लेकिन उनका मुख्य focus Picture Editor और View Editor जैसे graphics tools पर था, जबकि Jeff Stephenson और Chris Iden मुख्य रूप से interpreter code संभालते थे

AGI.EXE memory map और 70% calculation

  • Space Quest II 2.0D 720KB Disk 1 में 93 source files के अलावा AGI.EXE executable file का memory map भी 2,000 से ज्यादा lines में था
  • release वाले AGI games में interpreter executable file का नाम सिर्फ AGI होता है और उसे directly run नहीं किया जा सकता, लेकिन development के दौरान .EXE extension वाला directly executable interpreter इस्तेमाल होता था
  • Sierra में किसी ने 7 October 1987 को AGI.EXE, यानी AGI interpreter का memory map generate किया
  • यह date source code change history में सबसे नए comments September 1987 के होने से मेल खाती है
  • memory map AGI interpreter बनाने वाले modules और source files की list अपेक्षाकृत complete रूप में देता है
  • memory map में दिखाई देने वाली अलग-अलग source files 98 हैं, जिनमें से SQ2 disk पर complete form में मौजूद files 71 हैं
  • इसी ratio के आधार पर calculate किया गया कि Space Quest II disk में AGI interpreter source code का लगभग 70% था
  • कुछ modules में केवल C header files शामिल थीं, इसलिए उन्हें इस calculation में शामिल नहीं किया गया

Sierra की intellectual property के रूप में AGI

  • Sierra On-Line ने 1984 में King’s Quest release के आसपास business-wise कठिन दौर देखा, और Ken Williams को लगभग 100 employees निकालकर staff करीब 130 से घटाकर करीब 30 करना पड़ा
  • इसके बाद AGI adventure game system और उस पर बने games की success ने company की स्थिति बदलने में योगदान दिया
  • 1984 के अंत में King’s Quest computer game software sales chart के top 20 में पहुंचा, और King’s Quest II release होने तक लगभग आधे साल तक chart में बना रहा
  • Tandy Radio Shack के साथ contract के तहत Radio Shack stores में Tandy version games बेचना भी मददगार रहा
  • 1985 से 1988 तक AGI games लगातार bestsellers रहे, और AGI interpreter Sierra On-Line की प्रमुख revenue source और core intellectual property था
  • AGI interpreter source code का 70% mass-copy होकर दसियों हजार या लाखों customers तक पहुंचना Sierra के लिए बड़ी गलती थी

Format छोड़ी गई master disk का असर

  • Sierra जब new game release तैयार करता था, तो FormMaster disk duplication equipment में इस्तेमाल के लिए production copy master disk बनाता था
  • FormMaster master disk से सिर्फ files copy नहीं करता था, बल्कि usage status की परवाह किए बिना disk के सभी sectors को byte-by-byte copy करता था
  • Space Quest II 2.0D और 2.0F Disk 1 में इसी तरीके के कारण actual files के रूप में इस्तेमाल न हो रहे 402,432 bytes भी साथ copy हो गए
  • master disk preparation process में game files copy करने से पहले disk को पूरी तरह format करना जरूरी था, और Sierra ने ज्यादातर original game disks में यह step ठीक से किया था
  • Space Quest II 2.0D Disk 1 में लगता है कि किसी ने यह format step छोड़ दिया, और वही disk 2.0F में भी इस्तेमाल हुई
  • नतीजतन customers और retail stores तक गईं SQ2 disks की लाखों copies में AGI interpreter source code का 70% hidden form में शामिल रहा हो सकता है

2016 में ही सामने आया digital archaeology case

  • यह घटना लगभग निश्चित रूप से अनजाने में हुई गलती थी, और लगता है कि Sierra, competitors या customers—किसी ने भी उस समय इसे notice नहीं किया
  • पहली ज्ञात discovery online user NewRisingSun ने October 2016 में की
  • यह बात भी महत्वपूर्ण है कि यह AGI era के अंतिम दौर में हुआ
    • March 1988 में Sierra पहले ही SCI adventure game system develop कर चुका था
    • SCI इस्तेमाल करने वाले पहले game King’s Quest IV के release की तैयारी चल रही थी
  • अगर AGI interpreter source code गलती से public होने का समय 1–2 साल पहले होता, तो यह ज्यादा बड़ा problem बन सकता था
  • extracted AGI interpreter source code GitHub repository पर upload किया गया है
  • web-based AGI interpreter AGILE implementation को original AGI source code से कुछ मदद मिली थी

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-24
Hacker News की रायें

  • 1989 के DOS वर्ज़न Double Dragon II: The Revenge को 2 floppy disks पर वितरित किया गया था, जिनमें से एक में पूरा source code deleted compressed file के रूप में मौजूद था
    DIR command में वह दिखाई नहीं देता था, लेकिन आसानी से recover किया जा सकता था: https://tcrf.net/Double_Dragon_II:The_Revenge(DOS)

    • ROM खोलकर देखने पर compile process के दौरान directories और file names के सीधे silicon में छप जाने के उदाहरण हमेशा मज़ेदार लगते हैं
      सचमुच वह दौर था जब हर byte पैसे के बराबर था, फिर भी लोगों के FAT entries cartridges में bake हो गए—ऐसे मामले काफी हैं, यह सोचकर हंसी आती है
      https://forums.nesdev.org/viewtopic.php?t=17324
    • यह थोड़ा बेवकूफाना सवाल हो सकता है, लेकिन उत्सुकता है कि ऐसी चीज़ होती कैसे है
      गेम final करके किसी तरह की master disk बनाई गई होगी और फिर mass production facility को भेजी गई होगी; ऐसे में deleted compressed file master में कैसे आ गई होगी, यही सोचता हूं। शायद गलती से copy कर दी और release से पहले delete कर दी?
    • दोस्त के घर गया था तब उसके पिता के computer पर खेला गया मेरा दूसरा multiplayer game यही था
      पहला भी उसी computer पर DOS वर्ज़न Spacewar! था। अगर याद सही है, तो boss तक पहुंचने पर game freeze हो जाता था, इसलिए Double Dragon II पूरा खत्म नहीं कर पाया, लेकिन अच्छी याद है

  • हाल में synthesizer ROM reverse engineering काफी कर रहा हूं
    Yamaha DX9 ROM में binary में बचे खाली space के अंदर firmware symbol table के टुकड़े थे[0], और संभवतः development system से आया 6303 code block भी काफी बड़ा था। ऐसी चीज़ें संयोग से मिलें तो सच में कमाल का एहसास होता है। मैं इसमें इतना डूब गया कि खुद को अतीत में हल्की झलक पाने वाला software archaeologist जैसा महसूस हुआ, और Yamaha ने कौन-से development tools इस्तेमाल किए होंगे यह जानने के लिए गहरे rabbit hole में चला गया। पक्के तौर पर कुछ नहीं मिला, लेकिन उस दौर के development tool docs पढ़ते हुए modern workflows के लिए कृतज्ञता बढ़ गई
    0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...

    • मुझे भी synthesizer reverse engineering पसंद है, इसलिए पहले Yamaha A-sampler का analysis किया था और Yamaha A-sampler disk users के लिए basic tasks तेज़ी से करने वाला management tool बनाया था
      BeBox पर raw I/O और raw disk sector analysis खूब किया, और BeOS में file system hacking के लिए अच्छे tools थे। उसी के जरिए Windows के लिए file system driver बनाया, जो इतना अच्छा चला कि Yamaha का support भी मिला। कभी A-sampler के लिए Yamaha ROM reverse engineer करने की इच्छा हो तो संपर्क करना। इस क्षेत्र में मेरी काफी रुचि है। DX9/DX7 पर काम भी शानदार है, और दोनों synthesizers को launch के समय से इस्तेमाल करने वाले user के तौर पर यह सच में बहुत मज़ेदार है

  • इस game ने मेरे बचपन में इतना ज़बरदस्त स्थान लिया कि बहुत समय बाद आज सोचता हूं तो उल्टा यह सपने जैसा लगता है
    आज की ज़िंदगी में किसी game के साथ उसी तरह की connection की कल्पना करना असंभव लगता है। आसपास की हर चीज़ बस game, show या कोई वस्तु जैसी लगती है, लेकिन Space Quest 2, 3, 4 मेरे DNA के बुनियादी हिस्से की तरह गुंथे हुए हैं

    • Space Quest III मेरा पहला Sierra game था, और उसमें वाकई ऐसी ताकत है
      उस दौर के Sierra games सच में खास थे। खासकर Police Quest II, LSL III, Hero's Quest मैंने लगभग उसी समय खूब खेले। text-based EGA Sierra games में कुछ जादुई था, और मेरे लिए वे Infocom और बाद के point-and-click VGA versions के बीच emotional और creative connection का बिल्कुल सही मध्य-बिंदु थे
    • मैंने 6वें भाग से शुरुआत की, लेकिन बाद में 1–5 फिर खेले, और वे निश्चित ही मेरी core personality का हिस्सा बन गए
      Space Quest मेरी पसंदीदा early internet stories में से एक से भी जुड़ा है। जब websites ज़्यादातर Geocities और ऊबे हुए college students द्वारा host की जाती थीं, उस समय एक Space Quest fan site था, और मैंने बड़े SQ sites में से एक के operator को email करके लिखा कि मुझे games और site पसंद हैं। तब मेरी उम्र करीब 14 साल रही होगी, और उसने जवाब दिया कि वह original games लगभग 40 डॉलर में भेज सकता है। वे सभी original releases थे, original boxes और floppies के साथ। लगभग 1997 की बात है, इसलिए देश के दूसरे छोर पर किसी अनजान व्यक्ति को 40 डॉलर भेजना और सच में सामान मिलने की उम्मीद करना थोड़ा चिंता भरा था, लेकिन उसने सच में भेज दिया। कुछ हफ्तों बाद सारे games बिल्कुल बताए गए अनुसार पहुंच गए, और मैं बेहद खुश था। एक रात में ही सच्चा believer बन गया, और यह आज भी मेरे भीतर बची optimism का सूरज-सा core memory है। Jess, अगर तुम कहीं हो, तो तुम असली थे। उम्मीद है कभी फिर मिलेंगे
    • मुझे भी बहुत मिलता-जुलता एहसास है
      मेरे पिता steel mill में काम करते थे, और वहां के computer guy से उनकी दोस्ती थी; उसने घर पर खेलने के लिए SQ2 की copy दी थी। मैंने वह game दीवानों की तरह खेला, लेकिन काफी छोटा था इसलिए बहुत-सी चीज़ें समझ नहीं आती थीं। सच में अटक जाता तो पिता से कहता कि वे उस computer guy से पूछें कि किसी खास जगह से कैसे निकलना है, और लगता है वह सीधे जवाब देने के बजाय दयालुता से hints देता था। करीब 35 साल बीत गए, लेकिन उस game से जुड़े सपने भी काफी detail में याद हैं। उसने सच में बड़ा असर डाला
    • मुझे भी वही एहसास है, लेकिन खासकर Space Quest II के बारे में
      SQ I बहुत बाद में खेला, और SQ III उतना गहराई से नहीं छू पाया। बाकी तो फिर EGA text-input games भी नहीं रहे। SQ II बहुत-सी यादें वापस ला देता है, और English भी कुछ हद तक उसी से सीखी। Roger Wilco से “rub berries” करवा सकते हैं, यह पता चलने पर जो संतोष मिला था, वह याद है
    • game की शुरुआत में creature को बचाते समय free little dude काम कर गया था, इससे मुझे बहुत खुशी हुई
      इस तरह का game पहली बार यही खेला था, और करीब दस साल की उम्र में कई हफ्तों तक इसमें अटका रहा

  • मुझे नहीं लगता कि AGI इंजन में ऐसा कोई खास secret sauce था जिससे competitors को leak से फायदा मिल जाता
    और उदाहरण हो सकते हैं, लेकिन Hugo's House of Horrors कुछ साल बाद एक व्यक्ति द्वारा बनाया गया AGI-style गेम था। शुरुआती novelty के तौर पर graphics adventure से आगे, Sierra games इसलिए सफल रहे क्योंकि graphics बनाने और असल game लिखने में बहुत भारी मेहनत लगी थी। इसका मतलब यह नहीं कि technology कुछ भी नहीं थी, लेकिन final product में उसका हिस्सा अपेक्षाकृत छोटा था

    • उस दौर में जानकारी और उपयोगी example code हासिल करना कहीं ज्यादा मुश्किल था
      काम करने वाला software सीखना और बनाना आज की तुलना में बहुत कठिन था, और आधार बनाने के लिए लगभग कुछ नहीं था। MS-DOS पर meaningful open source बहुत कम था, और open-source game engines तो और भी कम। ऐसे माहौल में अगर AGI source व्यापक रूप से leak हो गया होता, तो कम-से-कम उस समय के सबसे popular PC games ठीक-ठीक कैसे बनाए गए थे, यह दिखाने वाले blueprint के रूप में उसका काफी महत्व हो सकता था
    • कभी-कभी सोचता हूं कि leaked source code सच में कितना valuable होता है
      खासकर अगर उसमें keys या backdoors जैसे ऐसे secrets न हों जिनका hackers दुरुपयोग कर सकें। leaked code के पास जाहिर है कोई license नहीं होता, इसलिए अगर lawsuit से बचना हो तो उसे अपने product में जस-का-तस reuse नहीं कर सकते। आखिरकार आपको वह code पढ़ना, techniques समझना, और copyright infringement जैसी गंध न आए इस तरह उसे अपने काम में लागू करना पड़ता है, जो अक्सर scratch से बनाने से भी ज्यादा कठिन होता है। मान लें कुछ मामलों में advantage हो भी, तो वह वास्तविक competitive edge में कितनी बार बदलता होगा, यह भी सवाल है। Developers तो अच्छी documentation और permissive license वाले open source के बावजूद नया code लिखते रहते हैं। Code पढ़ना अक्सर लिखने से कठिन होता है, और सिर्फ उसे फिर से build करना भी मुश्किल हो सकता है। इससे cloning थोड़ी आसान हो सकती है, लेकिन games आम तौर पर कुछ ही दिनों में crack होकर distribute हो जाते थे, और संभव है copy-protection code source में शामिल ही न रहा हो
    • यह किसी ऐसे व्यक्ति की बात लगती है जो “ASM या C लिखे बिना भी कुछ बनाया जा सकता है” वाले दौर में बड़ा हुआ हो
      उन भाषाओं को बोल पाने वाले लोग शायद कई orders of magnitude कम थे, और उनसे कोई coherent चीज बना पाने वाले उससे भी कम
    • उस समय internal neural network का learning rate लगभग maximum तक चढ़ा हुआ था
      आज यह तेजी से घट रहा है, इसलिए आज जिन चीजों से हम रूबरू होते हैं, वे internal weights बनाने में उतनी ताकतवर नहीं हैं जितनी तब थीं

  • change history comments वाकई बहुत अच्छे हैं
    Source-control tools के ऐसे चीजों को साफ-साफ दिखाने से बहुत पहले के दौर में, ये उच्च स्तर की सावधानी और craftsmanship दिखाते हैं। सच कहूं तो CVS/SVN/Git के बाद भी कई लोगों के लिए यह अब भी स्पष्ट नहीं था। यह लेख 1986 के मशहूर ‘No Silver Bullet’ लेख[1] की भी याद दिलाता है, जिसमें अनुमान लगाया गया था कि software आगे भी मोटे तौर पर उसी तरह रहेगा, जहां programmer एक-एक command मेहनत से लिखते जाते हैं। मूल पोस्ट के game engine code और comments आज मेरे लिखे हुए जैसे लगते हैं—यह बात करीब 40 साल बाद भी उस prediction को support करती है
    [1] https://en.wikipedia.org/wiki/No_Silver_Bullet

    • आज भी git commit messages में “fix” या “stuff” बहुत ज्यादा दिखता है

  • Famicom version Air Fortress में ROM में अनजाने में शामिल चीजें हास्यास्पद रूप से बहुत ज्यादा हैं
    Uncompiled ASM code, MS-DOS directory listing, game build में इस्तेमाल किए गए EXE में से एक की strings, और भी बहुत कुछ शामिल है। Japanese cartridge 128+128KB था। बाद में US NES version बनाते समय पता चला कि 128KB graphics data का अधिकांश हिस्सा duplicate graphics या unused था, और असली unique graphics लगभग 36KB थे। Ending में एक planet image हटाकर graphics को 32KB किया गया, और 128+128KB cartridge की जगह 128+32KB cartridge के रूप में release किया गया
    Source: https://tcrf.net/Air_Fortress

  • ऐसी स्थिति असल में बहुत अक्सर होती थी
    The Cutting Room Floor में accidental included code के छोटे हिस्सों से लेकर ज्यादातर हिस्से तक वाले लगभग 500 entries listed हैं
    https://tcrf.net/Category:Games_with_uncompiled_source_code

    • जल्दी से देखने पर लगता है कि इस खास Space Quest II disk के AGI interpreter uncompiled code वाला मामला अभी वहां नहीं है
      जानना चाहूंगा कि क्या मेरा भी यही आकलन है। King's Quest III disk में भी यही हुआ था, और सच में यह Space Quest II वाले मामले के लगभग उसी समय हुआ दिखता है

  • मेरा पसंदीदा हिस्सा यह है कि ऐसा लगता है कि पूरी एक पीढ़ी बीत जाने तक disk पर पड़े source code को किसी ने नहीं खोजा
    “हैरानी की बात है कि Sierra, competitors या customers—किसी ने भी शायद ध्यान नहीं दिया कि ऐसा हुआ है, और यह दशकों बाद ही खोजा गया। ज्ञात पहली खोज अक्टूबर 2016 में online user NewRisingSun ने की थी।” हाल के Tetris और Super Mario Bros. breakthroughs भी याद आते हैं। बचपन में जब ये games खेले थे, तो लगता था कि दशकों बाद ये भुला दिए गए relics रह जाएंगे जिन्हें सबसे dedicated hobbyists के अलावा कोई चला भी नहीं पाएगा। लेकिन internet और emulators ने उन शुरुआती games और computing में नई जान डाल दी

    • आखिरी वाक्य ही शायद जवाब देता है
      deleted files खोजने वाले लोग जरूर रहे होंगे, लेकिन internet common होने से पहले वे व्यापक रूप से known या recorded नहीं हुए होंगे
    • कुछ लोग पुराने software को preserve करने और perfect disk copies संभव बनाने के लिए आधुनिक tool flux imaging का इस्तेमाल करते हैं
      ऐसी disks image करते समय खाली जगह में बचा हुआ data किसी ने खोज लिया होगा

  • 1987 से 1993 के बीच दो Mac ऐप्स के लिए करीब नौ master disks तैयार किए थे
    हमेशा नई floppy इस्तेमाल की, और यह जांचने के लिए एक लंबी checklist होती थी कि disk सही है। सौभाग्य से सब ठीक निकले, और उनमें से कुछ तो खास तौर पर 100,000 disks बनाने में इस्तेमाल हुए। अच्छा है कि अब किसी को यह काम नहीं करना पड़ता

    • आज भी कुछ ऐसा ही किया जाता है, बस इसका नाम Docker layer है
      मैंने ऐसे layers देखे हैं: base, tools जोड़ना, source code जोड़ना, compile करना, source code हटाना, अतिरिक्त tools हटाना, release। “Docker image इतनी बड़ी क्यों है? खैर, storage तो सस्ता है...” जैसी स्थिति। multi-stage build जैसा आसान समाधान भी है( https://docs.docker.com/build/building/multi-stage/ ). लेकिन अगर यह पता न हो कि मौजूदा Docker image view में पिछले सभी layers शामिल होते हैं, तो कभी-कभी गलती हो जाती है

  • जब release artifacts हाथ से बनाए जाते थे, तो उनमें अक्सर ऐसी बची-खुची चीजें शामिल हो जाती थीं जिन्हें release करने का इरादा नहीं था
    जैसे cut content[1] या debug symbols[2]। जिस video game की मैं reverse engineering कर रहा था, उसके demo version data archive के अंदर छिपे हुए debug symbols अचानक मिले, तो यह अप्रत्याशित था लेकिन बहुत मददगार साबित हुआ। आजकल CI/CD, automated builds और अन्य आधुनिक development practices की वजह से ऐसी चीजें कम होने की संभावना है
    [1] https://tcrf.net
    [2] https://www.retroreversing.com/games/symbols

    • मुझे शक है कि CI/CD जैसी अच्छी practices game development में उतनी आम नहीं होंगी जितना हम सोचते हैं
    • CI/CD pipeline उल्टा असर भी कर सकती है
      अगर कोई error न हो, तो console output की हजारों lines कोई नहीं देखता। अंतिम release package में जरूरत से ज्यादा अनावश्यक चीजें शामिल हों, तब भी tests pass होने की संभावना रहती है। इसलिए मेरा gut feeling तो उलटा है। यह ज्यादा बार हो सकता है, या कम से कम manual build की तुलना में CI/CD इस तरह की चीजों को ज्यादा संभव बना सकती है। दूसरे factors भी हो सकते हैं