2016 में, मैंने रिवर्स इंजीनियरिंग खेल
ड्यूक नुकेम II के लिए एक शौक परियोजना पर काम शुरू किया और इसके इंजन को खरोंच से पुनर्निर्माण किया। परियोजना को रिगेल इंजन कहा जाता है और यह ओपन सोर्स (
गीथहब पर इसका पृष्ठ ) में उपलब्ध है। आज, ढाई साल से अधिक समय बाद, मेरे इंजन पर आप पहले से ही लगभग समान गेमप्ले के साथ मूल खेल के पूरे शेयरवेयर-एपिसोड के माध्यम से जा सकते हैं। यहाँ पहले स्तर के पारित होने के साथ एक वीडियो है:
वह क्या कर सकता है? रिगेल इंजन मूल डॉस बाइनरी (
NUKEM2.EXE ) के पूर्ण प्रतिस्थापन के रूप में काम करता है। आप इसे गेम डायरेक्टरी में कॉपी कर सकते हैं और यह इससे सभी डेटा पर विचार करता है, या कमांड लाइन के तर्क के रूप में गेम डेटा के लिए पथ निर्दिष्ट करता है। इंजन विंडोज, मैक ओएस एक्स और लिनक्स के तहत बनाया और निष्पादित किया गया है। यह
SDL और OpenGL 3 / OpenGL ES 2 पर आधारित है, और C ++ 17 में लिखा गया है।
यह शेयरवेयर एपिसोड से सभी दुश्मनों और गेम मैकेनिक्स के गेम लॉजिक को लागू करता है, साथ ही अधिकांश मेनू सिस्टम को भी। इसके अलावा, आप सहेजे गए गेम और मूल गेम से एक उच्च स्कोर तालिका आयात कर सकते हैं।
इसके अलावा, इंजन के मूल पर फायदे हैं:
- कोई एमुलेटर या पुराने हार्डवेयर की आवश्यकता नहीं, कोई सेटिंग्स की आवश्यकता नहीं
- कोई लोडिंग स्क्रीन नहीं - मेनू में "नया गेम" चुनें, एंटर दबाएं, और तुरंत गेम शुरू करें
- कई ध्वनि प्रभाव एक ही समय में खेले जा सकते हैं, जो मूल में असंभव था
- कणों, विस्फोटों और इतने पर एक साथ प्रभाव की संख्या पर कोई प्रतिबंध नहीं है।
- प्रत्येक खिलाड़ी के लिए फ़ाइलें और हाईस्कोर सूची सहेजें
- बहुत अधिक उत्तरदायी मेनू
अब तक, मैं रिगेल इंजन को पूरी तरह से "तैयार" नहीं मानता हूं। लेकिन यह विकास में एक महान मंच है और इंजन के बारे में फिर से लिखने का एक अच्छा अवसर (
यहां और
यहां प्रकाशित पुरानी पोस्ट)। आइए कोड की वर्तमान स्थिति पर एक नज़र डालते हुए शुरू करें और पता करें कि मुझे यह कैसे मिला।
इंजन में कितना कोड होता है?
लेखन के समय, रिगेलग्विन में 270 स्रोत फाइलें होती हैं, जिसमें कोड की 25 हजार से अधिक लाइनें होती हैं (कोई टिप्पणी / रिक्त लाइनें नहीं)। इनमें से 10 फाइलें और 2.5 हजार लाइनें यूनिट टेस्ट हैं। खाली लाइनों और टिप्पणियों का एक विस्तृत ब्रेकडाउन
यहां उपलब्ध
है ।
इस सभी कोड में क्या है? सामान्य बुनियादी सुविधाओं और सहायक कार्यों का एक सा, इस तरह की बुनियादी चीजें प्रदान करना, और तर्क के छोटे टुकड़ों का एक गुच्छा। इन सब के अलावा, सबसे बड़े हिस्से हैं:
- मूल गेम में उपयोग किए जाने वाले 14 विभिन्न फ़ाइल स्वरूपों के लिए पार्सर / डाउनलोडर - कोड की 2 हजार लाइनें (LOC)
- 24 दुश्मनों / शत्रुतापूर्ण वस्तुओं के लिए व्यवहार तर्क / खेल तर्क - 3.8k LOC
- 14 इंटरैक्टिव तत्वों और खेल यांत्रिकी के लिए खेल तर्क - 2k एलओसी
- खिलाड़ी नियंत्रण तर्क - 1.2k LOC
- 154 कॉन्फ़िगरेशन प्रविष्टियाँ (प्रत्येक दुश्मन का स्वास्थ्य मूल्य, एकत्रित वस्तुओं के लिए प्राप्त अंकों की संख्या, आदि) - 1k LOC
- विनाश के प्रभाव के लिए 31 विनिर्देश (दुश्मन या अन्य विनाशकारी वस्तु के विनाश से उत्पन्न प्रभाव) - 254 LOC
- कैमरा कंट्रोल कोड - 159 LOC
- खेल मेनू विवरण भाषा दुभाषिया / cutscene - 643 LOC
- HUD और अन्य UI कोड 818 LOC है
- मेनू के बाहर 5 स्क्रीन / मोड, उदाहरण के लिए, प्रारंभिक एनीमेशन, बोनस स्क्रीन, आदि। - 789 एलओसी
बेशक, यह सभी कोड लिखे जाने की आवश्यकता है, और यह हमें अगले प्रश्न की ओर ले जाता है।
कितना काम हुआ?
हालाँकि परियोजना के शुरू होने में ढाई साल बीत चुके हैं, लेकिन मैंने इस बार इस पर काम नहीं किया है। कुछ महीनों के लिए मैंने एक परियोजना बिल्कुल नहीं की, कुछ अन्य में मैंने उस पर केवल कुछ घंटे बिताए। लेकिन ऐसे समय थे जब मैंने रिगेल इंजन पर काफी सक्रिय रूप से काम किया। गितुब पर कमिट शेड्यूल को देखते हुए, आप एक मोटा विचार प्राप्त कर सकते हैं कि समय के साथ मेरा काम कैसे वितरित किया गया:
शेड्यूल के अनुसार, हम देखते हैं कि 1081 कमिट मास्टर शाखा में किए गए थे। हालांकि, रिपॉजिटरी बनाने से पहले भी, मैं एक बंद काम कर रहा था, जिसमें 247 और कमिट थे, जो कुल मिलाकर हमें 1328 कमिट देता है। इसके अलावा, कई प्रोटोटाइप शाखाएं थीं जिनका उपयोग मैंने अनुसंधान और प्रयोग के लिए किया था, लेकिन कभी भी मुख्य के साथ संयुक्त नहीं था; इसके अलावा, विलय से पहले, मैंने कभी-कभी बड़ी प्रतिबद्ध कहानियों को छोटे लोगों में संकुचित किया।
मुझे यह भी कहना होगा कि कोड लेखन परियोजना का एकमात्र हिस्सा नहीं था - रिवर्स इंजीनियरिंग एक और महत्वपूर्ण हिस्सा था। मैंने
इडा प्रो (मुक्त संस्करण में) में मूल निष्पादन योग्य फ़ाइल के डिसएम्ड कोड का अध्ययन करने, नोट्स लेने, छद्म लिखने, और मेरे संस्करण के तत्वों के कार्यान्वयन की योजना बनाने में काफी समय बिताया। इसके अलावा, मैंने सक्रिय रूप से मूल गेम का परीक्षण किया, इसे
डॉसबॉक्स में और मूल उपकरण पर (ईबे द्वारा खरीदे गए विभिन्न मशीन 386 और 486)। मैंने विशिष्ट दुश्मनों के अलग-अलग अवलोकन और गेम मैकेनिक्स के अध्ययन के लिए परीक्षण स्तर एकत्र किए, DOSBox का उपयोग करके वीडियो क्लिप रिकॉर्ड किए, और कोडांतरक कोड का अध्ययन करते समय मेरे निष्कर्षों की पुष्टि करने के लिए फ्रेम फ्रेम-बाय-फ्रेम के माध्यम से देखा। दुश्मन या खेल यांत्रिकी का एहसास होने के बाद, मैंने आमतौर पर अपने संस्करण से एक वीडियो क्लिप रिकॉर्ड किया और अपने कार्यान्वयन की सटीकता की पुष्टि करने के लिए मूल के साथ फ्रेम द्वारा इसकी तुलना की।
यहाँ मेरे नोटों की कुछ तस्वीरें हैं:
रिवर्स इंजीनियरिंग कैमरा कंट्रोल कोड। एक बड़ी आयत स्क्रीन को इंगित करती है। धराशायी लाइनें उन क्षेत्रों को दिखाती हैं जो एक खिलाड़ी कैमरे को स्थानांतरित किए बिना स्थानांतरित कर सकते हैं। यदि आप रुचि रखते हैं, तो कैमरा कंट्रोल कोड खुद यहां पाया जा सकता है ।असेंबली कोड को समझने में आपकी मदद करने के लिए सामान्य नोट्स। बाईं ओर एक उच्च स्तर पर मूल गेम को अपडेट करने की प्रक्रिया है। दाईं ओर कुछ गेम ऑब्जेक्ट्स की स्थिति को इंगित करने वाले बिट फ़ील्ड पर नोट्स हैं।कोडांतरक कोड का छद्म कोड में ट्रांसक्रिप्शन। आमतौर पर मैं इसे यंत्रवत् रूप से पर्याप्त करता हूं, इस बारे में सोचे बिना कि कोड क्या कर रहा है, और फिर अंतर्निहित तर्क को समझने के लिए छद्म कोड में संस्करण का उपयोग करें। और इसके आधार पर, मैं पहले से ही अपने कार्यान्वयन के साथ आता हूं। यहां तैयार कोड देखें।दुश्मन तर्क के एक साफ-अप संस्करण का छद्म कोड। हेडर राज्य मशीन की स्थिति को इंगित करते हैं, नीचे दिए गए कोड बताते हैं कि संबंधित राज्यों में क्या होना चाहिए। यह कोडांतरक कोड ट्रांसक्रिप्ट करके प्राप्त कच्चे छद्मकोड के आधार पर बनाया गया था। तैयार कोड यहां पाया जा सकता है ।अंत में, परियोजना पर काम बहुत रोमांचक हो गया, और मैंने इससे बहुत कुछ सीखा: रिवर्स इंजीनियरिंग, 16-बिट x86 असेंबलर, निम्न-स्तरीय वीजीए प्रोग्रामिंग, गंभीर प्रतिबंधों के बारे में जो कि पीसी गेम डेवलपर्स को 90 के दशक की शुरुआत में सामना करना पड़ा था; इसके अलावा, मैंने मूल खेल की आंतरिक विशेषताओं के बारे में कई खोज की और उनमें से कुछ को कैसे अजीब और विचित्र लागू किया गया - यह विषय अपने आप में पदों की एक अलग श्रृंखला का हकदार है।
आगे क्या है
अंतिम शेष कार्यों को जोड़ने और पंजीकृत संस्करण के लिए समर्थन को अंतिम रूप देने के अलावा, मेरे पास रिगेल इंजन की क्षमताओं में सुधार और विस्तार करने के लिए कई विचार हैं, न कि कोड की सफाई और पुन: संचालन करने का उल्लेख करने के लिए - हमेशा की तरह, इस सॉफ्टवेयर के निर्माण के बाद ही एक सॉफ्टवेयर आर्किटेक्चर बनाने का सबसे अच्छा तरीका स्पष्ट है।
भविष्य के सुधारों के लिए, यहाँ कुछ बिंदु दिए गए हैं जिन्हें मैंने लागू करने के बारे में सोचा था:
- प्रक्षेप के साथ चिकनी गति। खेल प्रति सेकंड 15 बार अपने तर्क को अपडेट करता है, और मूल खेल में यह रेंडरिंग के लिए फ्रेम दर भी है। दूसरी ओर, रिगेल इंजन आसानी से 60 एफपीएस और उच्चतर की आवृत्ति के साथ काम कर सकता है। फिलहाल, ये अतिरिक्त फ्रेम कोई लाभ नहीं देते हैं, लेकिन मुझे लगता है कि इनका उपयोग मध्यवर्ती फ्रेम के लिए किया जा सकता है ताकि चिकनी स्क्रॉलिंग और वस्तुओं की गति का एहसास हो सके। खेल का तर्क अभी भी उसी गति से काम करेगा, लेकिन वस्तुएं आसानी से चलेंगी, और 8 पिक्सल की वृद्धि के साथ "कूद" नहीं, जैसा कि वे अब कर रहे हैं। इससे पहले, मैंने ऐसी प्रणाली का एक प्रोटोटाइप बनाया, और यह बहुत अच्छा लग रहा है, हालांकि इसमें सुधार करने की आवश्यकता है।
- गेमपैड सपोर्ट। मूल गेम में, जॉयस्टिक के लिए समर्थन है, और डॉसबॉक्स उन्हें आधुनिक गेमपैड्स पर अनुकरण कर सकते हैं, लेकिन उनका सेटअप मुश्किल हो सकता है - खेल में कॉन्फ़िगरेशन और अंशांकन की तैयारी की आवश्यकता होती है। यह उल्लेख नहीं करने के लिए कि सभी नियंत्रक बटन समर्थित नहीं हैं, लेकिन मेनू का उपयोग करने के लिए आपको अभी भी एक कीबोर्ड लेना होगा। इसलिए, मुझे विश्वास है कि देशी नियंत्रक समर्थन गेमप्ले में काफी सुधार करेगा।
- ध्वनि में वृद्धि। वर्तमान में, सभी ध्वनि प्रभावों का एक ही वॉल्यूम है। ध्वनि-उत्पादक वस्तुएं, उदाहरण के लिए, फ़ील्ड्स को बल देती हैं, जब वे स्क्रीन से टकराती हैं, तो तेज़ी से श्रव्य हो जाती हैं, और तेज़ी से टूट जाती हैं। मुझे उत्सुकता थी कि यदि दूरी में प्रभावों का आयतन फीका हो जाए तो वे कैसे ध्वनि करेंगे। उदाहरण के लिए, हम बल क्षेत्र को बमुश्किल सुन सकते हैं जब यह स्क्रीन पर अभी तक नहीं है, और जब यह आ रहा है तो यह जोर से हो जाएगा।
- अधिकांश स्तर पर दूरस्थ कैमरा / दृश्य। खेल को इसके लिए डिज़ाइन नहीं किया गया था, इसलिए यह संभावना गेमप्ले को नुकसान पहुंचा सकती है - खिलाड़ी उन दुश्मनों को देखना शुरू कर देगा जो स्क्रीन के बाहर सक्रिय नहीं हैं, और जैसे। लेकिन मुझे अभी भी आश्चर्य है कि यह कैसे दिखेगा और खेलेंगे। अंत में, खिलाड़ियों ने इस खेल के बारे में अक्सर शिकायत की कि वे स्तर का एक पर्याप्त हिस्सा देखने में असमर्थता के लिए हैं। एचयूडी को बंद करने या पारदर्शिता का उपयोग करके इसे कम से कम एक के साथ बदलने के विकल्प को जोड़ना दिलचस्प होगा।
- ग्राफिक्स रिज़ॉल्यूशन बढ़ाएँ। यह सुविधा अक्सर कई बंदरगाहों / खेलों के मनोरंजन में पाई जाती है, और इसे यहां जोड़ना बहुत अच्छा होगा। इंजन पहले से ही आपको अपनी खुद की छवियों के साथ स्प्राइट ग्राफिक्स को बदलने की अनुमति देता है, लेकिन अभी तक वे उच्च रिज़ॉल्यूशन के नहीं हो सकते हैं, क्योंकि पैमाने में बाद में वृद्धि के साथ सब कुछ एक छोटे बफर में प्रदान किया जाता है। सबसे पहले, आपको इस दृष्टिकोण को बदलने की आवश्यकता है ताकि व्यक्तिगत वस्तुओं के लिए स्केलिंग का प्रदर्शन किया जा सके।
मेरे पास भविष्य के लिए कोई रोडमैप नहीं है, इसलिए मैं इन बिंदुओं को किसी भी क्रम में लागू कर सकता हूं। लेकिन इस सब से पहले, अगले चरण में विकल्प मेनू को इकट्ठा करने के लिए प्रिय इमगुई का एकीकरण होगा, जो अभी तक खेल में नहीं है; इसके अलावा, यह उपरोक्त सुधारों को सक्षम या अक्षम करेगा। अंत में, मैं कहूंगा कि मैं
GitHub पर काम करने में किसी भी
सहायता के लिए आभारी रहूंगा!