इस सवाल का जवाब जितना ज़्यादातर लोग सोचते हैं, उससे कहीं ज़्यादा कच्चा है।

आज के गेम डेवलपर Unity या Unreal खोलते हैं, और एडिटर मौजूद है, फिजिक्स इंजन मौजूद है, रेंडरिंग पाइपलाइन मौजूद है, लाइटिंग सिस्टम मौजूद है। उनका काम पहले से बने फ्रेमवर्क में कंटेंट भरना है। 1980 के दशक में यह चीज़ मौजूद ही नहीं थी। कोई फ्रेमवर्क नहीं था, कोई इंजन नहीं था, कोई पुन: उपयोग करने योग्य बुनियादी ढांचा नहीं था। अगर आप गेम बनाना चाहते थे, तो पहले आपको एक ऐसी मशीन बनानी होती थी जो उसे चला सके, और फिर उस मशीन पर, असेंबली भाषा में, हर एक पिक्सल को बताना होता था कि उसे किस रंग का होना है।

सब कुछ पिक्सल से शुरू हुआ।

शुरुआती गेम के ग्राफिक्स सीधे मेमोरी में लिखे जाते थे। प्रोग्रामर को स्क्रीन पर हर स्थिति के अनुरूप मेमोरी एड्रेस पता होना चाहिए था। किसी जगह पर एक बिंदु बनाने के लिए, आप उस एड्रेस पर एक मान लिखते थे — मान रंग को दर्शाता था। एक रेखा बनाने के लिए, आप एक लूप लिखते थे, CPU को बताते थे कि इस एड्रेस से उस एड्रेस तक हर N बाइट पर लिखें। एक पात्र बनाने के लिए, आप पिक्सल की हर पंक्ति को हेक्साडेसिमल संख्याओं में बदलते थे, उन्हें पंक्ति दर पंक्ति लिखते थे, स्क्रीन पर सही ऑफसेट ढूंढते थे, और उन संख्याओं को वहाँ रखते थे।

इस प्रक्रिया को आज “सॉफ्टवेयर रेंडरिंग” कहा जाता है। उस समय इसका कोई नाम नहीं था, क्योंकि कोई विकल्प नहीं था — इसे बस “तस्वीर कैसे निकलती है” कहा जाता था।

जब कार्मैक पहले Wolfenstein पर काम कर रहे थे, तो उन्हें एक विशिष्ट समस्या का सामना करना पड़ा: IBM PC का ग्राफिक्स आर्किटेक्चर स्मूथ क्षैतिज स्क्रॉलिंग का समर्थन नहीं करता था। स्क्रीन एक बार में पूरे फ्रेम को रिफ्रेश करके अपडेट होती थी, जिससे इमेज के हिलने पर टियरिंग होती थी — यह ऐसा लगता था जैसे हिल रहा हो। उन्होंने GPU के निम्न-स्तरीय रजिस्टरों का अध्ययन करने में भारी समय बिताया, और हार्डवेयर को धोखा देने का एक तरीका खोजा ताकि वह कुछ ऐसा कर सके जो वह मूल रूप से समर्थित नहीं करता था, इसे सॉफ्टवेयर में अनुकरण करके — और तस्वीर स्मूथी से स्क्रॉल हो सकी।

इसके लिए कोई दस्तावेज़ नहीं थे, कोई पूर्व अनुभव नहीं था। वह बस बैठ गए, हार्डवेयर मैनुअल खंगाले, और परीक्षण और त्रुटि से थोड़ा-थोड़ा करके इसे समझा।

यह उस युग के प्रोग्रामर की बुनियादी कार्य स्थिति थी। आप एक मैनुअल वाले सिस्टम का सामना नहीं कर रहे थे — आप हार्डवेयर का ही सामना कर रहे थे। आपको हार्डवेयर को उससे बेहतर जानना होता था जितना वह खुद को जानता था, और उसकी दरारों में जगह ढूंढनी होती थी।

ध्वनि पूरी तरह से अलग आयाम की समस्या थी।

शुरुआती PC की ध्वनि प्रणाली एक बजर था — PC Speaker। यह केवल एक ध्वनि उत्पन्न कर सकता था: एक बीप। इसके साथ संगीत बजाने के लिए, आपको इस बजर की कंपन आवृत्ति को नियंत्रित करना होता था, अत्यधिक तेज़ गति से विभिन्न आवृत्तियों के बीच स्विच करना होता था, और मानव श्रवण की दृढ़ता का लाभ उठाकर इसे ऐसा सुनाना होता था जैसे कोई धुन बज रही हो। इस तकनीक को PWM, पल्स चौड़ाई मॉड्यूलेशन कहा जाता है। सिद्धांत ध्वनिक भौतिकी है, कार्यान्वयन माइक्रोसेकंड-सटीक समय नियंत्रण है। ज़रा सी भी गलती करें, और आपको केवल शोर मिलता है।

उस समय ऐसे प्रोग्रामर थे जो專門 अध्ययन करते थे कि PC Speaker से ध्वनि की और परतें कैसे निकाली जाएँ। उनकी विधि अत्यंत छोटी समय खिड़कियों में विभिन्न आवृत्तियों के बीच स्विच करके, एक छद्म-स्टीरियो प्रभाव बनाना था। इस तकनीक को उस समय के डेमो दृश्य में काले जादू की तरह माना जाता था। आप एक बजर लेते हैं जो केवल “बीप” कर सकता है, और संगीत जैसा कुछ बनाते हैं। दूसरे प्रोग्रामर जिन्होंने इसे सुना, उन्हें पता नहीं चलता था कि आपने यह कैसे किया — क्योंकि सिद्धांत सहज नहीं था। इसे हासिल करने के लिए समय नियंत्रण की अत्यंत सटीक समझ की आवश्यकता थी।

जब Adlib और Sound Blaster आए, तो वे FM संश्लेषण ध्वनि लेकर आए। यह एक और प्रणाली थी जिसे शून्य से सीखना था। FM संश्लेषण का सिद्धांत एक आवृत्ति की तरंग का उपयोग दूसरी आवृत्ति की तरंग को मॉड्यूलेट करने के लिए करना है, जो जटिल स्वर उत्पन्न करता है। विभिन्न मॉड्यूलेशन पैरामीटर विभिन्न वाद्य ध्वनियाँ उत्पन्न करते थे। प्रोग्रामर को स्वयं पैरामीटर ट्यून करने थे, परीक्षण करना था कि कौन सा संयोजन पियानो जैसा लगता है, कौन सा वायलिन जैसा, कौन सा विस्फोट जैसा। कोई मानक उत्तर नहीं था — सब कुछ कान और अनुभव पर निर्भर था। उस समय, हर कंपनी के ध्वनि प्रोग्रामर के पास अपनी संचित पैरामीटर तालिकाएँ होती थीं। वे सच्चे अर्थों में व्यापारिक रहस्य थे।

गेम लॉजिक स्तर पर डिज़ाइन की भावना एक और रूप थी।

इंजन न होने का मतलब था कोई तैयार टक्कर पहचान नहीं, कोई तैयार भौतिक अनुकरण नहीं, कोई तैयार AI फ्रेमवर्क नहीं। अगर आप चाहते थे कि कोई पात्र दीवार तक पहुँचने पर रुके न कि उसमें से गुज़रे, तो आपको स्वयं टक्कर पहचान लिखनी होती थी, स्वयं परिभाषित करना होता था कि “टक्कर” का क्या अर्थ है, और स्वयं तय करना होता था कि टक्कर के बाद पात्र की गति और स्थिति कैसे बदलेगी।

शुरुआती गेम में टक्कर पहचान सरल और क्रूर थी: पात्र और बाधाओं दोनों को आयत के रूप में मानना, जाँचना कि क्या दो आयत ओवरलैप होते हैं, और यदि हाँ, तो रुक जाना। यह योजना तेज़ थी, लेकिन समस्या यह थी कि वास्तविक गेम पात्र आयत नहीं होते — वे आकार वाले स्प्राइट होते हैं। आयताकार टक्कर बॉक्स और वास्तविक ग्राफिक के बीच हमेशा अंतर होता था। इसीलिए शुरुआती गेम में अक्सर गोलियाँ जो स्पष्ट रूप से चूक गईं फिर भी हिट मानी जाती थीं, या पात्र दीवार को छूने से पहले ही रुक जाते थे।

उस समय के खिलाड़ी इसे बग नहीं कहते थे। वे इसे गेम की विशेषता कहते थे। क्योंकि वे नहीं जानते थे कि यह किसी और तरह से भी हो सकता है।

एक और बात उल्लेखनीय है: शुरुआती PC में अत्यंत सीमित मेमोरी होती थी। 640KB एक पूरे दशक तक हार्डवेयर की ऊपरी सीमा थी। यह संख्या आज एक स्क्रीनशॉट भी स्टोर नहीं कर सकती। प्रोग्रामर को गेम की सभी चीज़ें — ग्राफिक्स, ध्वनि प्रभाव, मानचित्र, लॉजिक कोड — इन 640KB के भीतर ठूंसनी होती थीं, और रनटाइम डेटा के लिए जगह भी छोड़नी होती थी।

कैसे? संपीड़न, खंडित लोडिंग, और पुन: उपयोग।

ग्राफिक्स डेटा संपीड़न एक स्वतंत्र तकनीक थी। प्रोग्रामर को अपने स्वयं के संपीड़न एल्गोरिदम का आविष्कार करना होता था, ग्राफिक्स डेटा को भंडारण में जितना संभव हो उतना छोटा बनाना होता था, और ज़रूरत पड़ने पर तुरंत डीकंप्रेस करना होता था। यदि मानचित्र बहुत बड़ा था, तो आप इसे टुकड़ों में बाँटते थे, जिस टुकड़े में खिलाड़ी खड़ा था उसे लोड करते थे, और जब वह बाहर निकलता था तो अनलोड करते थे। आज इस तकनीक को स्ट्रीमिंग कहा जाता है। उस समय इसे “कोई दूसरा रास्ता नहीं” कहा जाता था।

मेमोरी का हर बाइट संघर्ष से प्राप्त होता था। कोड लिखते समय, प्रोग्रामर को लगातार सोचना पड़ता था: क्या मैं इस वेरिएबल के लिए छोटा डेटा प्रकार उपयोग कर सकता हूँ? क्या मैं इस लॉजिक के लिए कम अस्थायी वेरिएबल का उपयोग कर सकता हूँ? क्या मैं इस लूप में मेमोरी एक्सेस की संख्या कम कर सकता हूँ? सोचने का यह तरीका आज के प्रोग्रामर के लिए अधिकांशतः अनावश्यक है। आधुनिक हार्डवेयर में पर्याप्त मेमोरी मार्जिन है, और कंपाइलर ऑप्टिमाइज़ेशन में पर्याप्त स्मार्ट हैं — आपको हर बाइट गिनने की ज़रूरत नहीं है।

लेकिन उस युग के प्रोग्रामर कंप्यूटर के पूरे आंतरिक कामकाज को अपने दिमाग में रखते थे। CPU निर्देश चक्र से लेकर मेमोरी लेआउट और GPU रजिस्टर तक, उन्हें हर परत को समझना होता था, क्योंकि हर परत एक दरार हो सकती थी जिसका उन्हें दोहन करने की ज़रूरत पड़ सकती थी।

कार्मैक ने एक बार व्युत्क्रम वर्गमूल की गणना करने के लिए कोड लिखा था, जिसके अंदर “what the fuck” नामक एक टिप्पणी थी। इस कोड ने व्युत्क्रम वर्गमूल का तेज़ी से अनुमान लगाने के लिए एक अत्यंत प्रतिरोधात्मक बिट हेरफेर ट्रिक का उपयोग किया, जो मानक गणित लाइब्रेरी से कहीं तेज़ था — सब कुछ 3D रेंडरिंग में गणना समय बचाने के लिए। कोड का यह टुकड़ा बाद में प्रोग्रामर संस्कृति में एक किंवदंती बन गया, बार-बार उद्धृत किया गया, क्योंकि यह सोचने के एक ऐसे तरीके का प्रतिनिधित्व करता है जो गायब हो गया है: हार्डवेयर सीमाओं के भीतर गणित और रचनात्मकता से प्रदर्शन निचोड़ने की विधि।

उस युग के गेम प्रोग्रामर इंजीनियरों और वैज्ञानिकों के मिश्रण के अधिक करीब थे। वे जिस समस्या का समाधान कर रहे थे, वह केवल “फीचर को कैसे लागू करें” नहीं थी — यह थी “क्या इस मशीन की भौतिक सीमाओं के भीतर फीचर को लागू किया जा सकता है।”

ये दो बहुत अलग प्रश्न हैं।

पहले प्रश्न का एक मानक उत्तर है: दस्तावेज़ देखें, API कॉल करें, चरणों का पालन करें। दूसरे प्रश्न का कोई मानक उत्तर नहीं है। आपको स्वयं उत्तर का आविष्कार करना होता है। कभी उत्तर मौजूद होता है, कभी नहीं। आपको पहले यह पता लगाना होता था कि आप किस मामले में हैं, और फिर तय करना होता था कि क्या करना है।

आज का गेम उद्योग एक विशाल सहयोगी प्रणाली है। इंजन कंपनियाँ, मिडलवेयर कंपनियाँ, टूलचेन कंपनियाँ — हर परत पर कोई न कोई काम कर रहा है। डेवलपर इस प्रणाली के शीर्ष पर खड़े होते हैं, स्वयं कंटेंट पर ध्यान केंद्रित करते हैं। यह प्रगति है, यह एक अच्छी बात है — यह अधिक लोगों को गेम बनाने की अनुमति देता है, और गेम के पैमाने और जटिलता को अतीत में जो संभव था उससे कहीं अधिक बढ़ाता है।

लेकिन पिक्सल से गेम बनाने के उस युग में कुछ ऐसा था जो आज मौजूद नहीं है।

आप गेम खोलते हैं, और आप जानते हैं कि स्क्रीन पर हर बिंदु कहाँ से आया, हर ध्वनि कैसे बनी, हर टक्कर कैसे निर्धारित हुई। क्योंकि वे सब आपके द्वारा लिखे गए थे, पंक्ति दर पंक्ति। ऐसा कुछ भी नहीं था जो किसी और ने आपके लिए किया हो।

इस भावना का एक नाम है। इसे पूर्ण नियंत्रण कहा जाता है।

तो, जिन महान लोगों ने उस समय गेम विकसित किए — वे सचमुच महान थे। सचमुच अद्भुत।