मैजिक डेटा-संचालित डिज़ाइन

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

विचार 1: मूल बातें

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

विचार 2: आवश्यक न्यूनतम

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

सुविचार 3: सीमा कुछ भी नहीं

मान लीजिए कि कुछ भी बदल सकता है (सबसे अधिक संभावना है)। यदि गेम को स्प्लिट स्क्रीन मोड की आवश्यकता होती है, तो आपको दो बिल्कुल सटीक निर्दिष्ट करने की आवश्यकता नहीं है। अपना खुद का गेम लिखें, जो प्रत्येक कैमरे के लिए अपने स्वयं के तर्क के साथ किसी भी संख्या में स्क्रीन का समर्थन कर सकता है। इससे काम की मात्रा, व्यवसाय के लिए सही दृष्टिकोण के साथ, काफी वृद्धि नहीं होगी। पाठ फ़ाइलों के जादू का उपयोग करके, आप यह निर्धारित करते हैं कि खेल में कितनी स्क्रीन होनी चाहिए - एक, दो, चार या अधिक। फाइलें कैमरों के लिए प्रारंभिक डेटा भी देंगी: स्थिति, दिशा, कवरेज का कोण और झुकाव। सबसे अच्छी बात यह है कि इन सेटिंग्स को बदलने के लिए आपके गेम डिज़ाइनरों की भी सीधी पहुँच होती है।
लचीला कोड डिजाइन के साथ खेल पूरी ताकत से विकसित होता है। खेल के मूल को अमूर्त करने और बिछाने की प्रक्रिया इसकी डिजाइन और विकास में बहुत मदद करेगी। एक विशिष्ट उद्देश्य के लिए एक गेम डिजाइन करने के बजाय, आप इसके प्रत्येक घटक और इसकी सामान्य कार्यक्षमता को डिज़ाइन कर सकते हैं। इस दृष्टिकोण का प्रभाव यह होगा कि आप बेहतर समझ सकते हैं कि आपको वास्तव में क्या करने की ज़रूरत है, बजाय इसके कि गेम के लिए प्रोजेक्ट डॉक्यूमेंटेशन में वर्णित व्यवहार का आँख बंद करके पालन करें।
उदाहरण के लिए, यदि किसी खेल में केवल चार प्रकार के हथियारों की आवश्यकता होती है, तो आप एक संपूर्ण प्रणाली का कार्यक्रम कर सकते हैं जो उन सभी का व्यक्तिगत रूप से वर्णन करता है। हालाँकि, यदि आप डेटा निर्धारण व्यवहार का उपयोग करते हुए प्रत्येक प्रकार के हथियार की कार्यक्षमता से अलग हैं, तो आप भविष्य में नए विचारों और गेमप्ले की गतिशीलता के साथ प्रयोग करने के लिए अनगिनत प्रकार के हथियार जोड़ सकते हैं। इस तरह की सोच अंततः खेल को सुधारने और विकसित करने की अनुमति देती है।
क्या तुमने मुझ पर विश्वास किया जब मैंने कहा "कुछ नहीं"?
सच्चाई यह है कि खेलों को अनुकूलन योग्य होना चाहिए, और बड़े खेलों को मूल संस्करण से, कथानक का अनुसरण करना चाहिए। आपका गेम बदलते नियमों, पात्रों, दौड़, हथियारों, स्तरों, नियंत्रण योजनाओं और वस्तुओं के साथ काम करने में सक्षम होना चाहिए। इस लचीलेपन के बिना, खेल में कोई भी परिवर्तन महंगा हो जाता है, और यहां तक ​​कि एक मामूली बदलाव के लिए एक प्रोग्रामर की भागीदारी की आवश्यकता होती है - जो अनिवार्य रूप से संसाधनों की बर्बादी है। यदि परिवर्तन जटिल हो जाते हैं, तो इससे खेल के मूल डिजाइन में थोड़ा सुधार हो सकता है, और खेल अपनी पूरी क्षमता को देखने के लिए जीवित नहीं रहेगा।

विचार 4: मुख्य नियंत्रण परिदृश्य

एक स्क्रिप्ट कोड के बाहर व्यवहार को परिभाषित करने का एक तरीका है। परिदृश्य ऐसे चरणों का क्रम निर्धारित करने के लिए महान हैं जो किसी गेम में होने चाहिए, या गेम इवेंट के लिए जो ट्रिगर होना चाहिए। उदाहरण के लिए, सरल कार्य-कारण तर्क का वर्णन करने वाले गेम दृश्य के लिए एक स्क्रिप्ट, जैसे "खोज पूरी होने पर क्या होता है" या "कौन सा ट्रिगर इस पर्यावरण के लिए काम करेगा।" ये सभी उदाहरण डेटा-चालित डिज़ाइन प्रतिमान के हैं।
स्क्रिप्ट डिजाइन करते समय, आपको ब्रांचिंग तर्क पर निर्णय लेने की आवश्यकता है और इसे कैसे व्यवस्थित किया जाएगा। दो दृष्टिकोण हैं। सबसे पहले स्क्रिप्ट के अंदर चर का उपयोग करना जारी रखना और उनकी तुलना ऑपरेटरों से करना: समानता (=), से कम (<), आदि। दूसरा तरीका सीधे मूल्यांकन फ़ंक्शन को कॉल करना है जो कोड के अंदर मौजूद चर की तुलना करता है, उदाहरण के लिए, isLifeBelowPercentage (50)। आप इन विधियों के संयोजन का उपयोग कर सकते हैं, लेकिन स्क्रिप्ट को सरल रखने का प्रयास करें। गेम डिज़ाइनर के लिए घोषित चर की तुलना में कार्यों का मूल्यांकन करना, उन्हें अपडेट करना और उनकी तुलना करना बहुत आसान होगा। इसके अलावा, दूसरा दृष्टिकोण डिबगिंग को सरल करेगा।
दुर्भाग्य से, स्क्रिप्टिंग के लिए एक उपयुक्त भाषा की आवश्यकता होती है। इसका मतलब है कि आपको खेल के व्यवहार को निर्धारित करने के लिए एक संपूर्ण वाक्यविन्यास बनाना होगा। स्क्रिप्टिंग भाषा में स्क्रिप्ट पार्सर का निर्माण और संभवतः, भविष्य में तेजी से निष्पादन के लिए स्क्रिप्ट को एक बाइनरी फ़ाइल में कनवर्ट करने के लिए एक कंपाइलर शामिल है। एक अन्य विकल्प मौजूदा भाषा का उपयोग करना है, जैसे कि जावा, लेकिन इस मामले में बड़ी संख्या में अतिरिक्त घटकों की आवश्यकता हो सकती है। स्क्रिप्टिंग भाषा पर अधिक समय न बिताने के लिए, आपको डिज़ाइनिंग सिस्टम को आसान तरीके से जीतना होगा। सामान्य तौर पर, स्क्रिप्टिंग भाषा को अत्यधिक शक्ति देने की प्रवृत्ति होती है। निम्नलिखित विचार एक जटिल पटकथा भाषा के कुछ नुकसान बताते हैं।

विचार 5: जब अच्छे परिदृश्य बुरे हो जाते हैं

डेटा-संचालित डिज़ाइन में व्यवहार का वर्णन करने के लिए स्क्रिप्ट का उपयोग करना इस पद्धति का एक स्वाभाविक परिणाम है। हालांकि, सामान्य ज्ञान के बारे में मत भूलना और मुख्य विचार को याद रखें: डेटा से तर्क का पृथक्करण। जटिल तर्क प्रोग्राम कोड को भेजा जाता है, और डेटा बाहर रहता है।
समस्या तब पैदा होती है जब डेटा पर भरोसा करने की इच्छा बहुत दूर चली जाती है। कुछ बिंदु पर, आप स्क्रिप्ट के अंदर जटिल तर्क का वर्णन करना चाहेंगे। जब किसी स्क्रिप्ट में किसी चीज़ की स्थिति होनी शुरू होती है और उसे ब्रांचिंग की आवश्यकता होती है, तो यह एक स्टेट मशीन की तरह हो जाती है। जैसे-जैसे उनकी किस्मत बढ़ती है, एक निर्दोष पटकथा लेखक (साथ ही कुछ खराब गेम डिजाइनर) को एक प्रोग्रामर के रूप में काम करना होगा। यदि स्क्रिप्ट बहुत जटिल हो जाती है, तो प्रोग्रामर के पास काम वापस आ जाता है, जिसे उसकी कड़ाई से सीमित भाषा में सभी कठिनाइयों का वर्णन करना होगा। परिदृश्य को लोगों के काम को आसान बनाना चाहिए, कठिन नहीं।
कोड में जटिल तर्क को संग्रहीत करना महत्वपूर्ण क्यों है? कार्यक्षमता और डिबगिंग का मुद्दा। क्योंकि स्क्रिप्ट कोड से बाहर हैं, वे प्रोग्रामिंग भाषाओं में मौजूद कई अवधारणाओं की नकल करते हैं। एक स्वाभाविक प्रवृत्ति लिपियों को वास्तविक प्रोग्रामिंग भाषा बनने तक अधिक से अधिक कार्यक्षमता प्रदान करना है। अधिक जटिल स्क्रिप्ट दिखाई देती हैं, और आपको डीबग करते समय अधिक जानकारी ट्रैक करने की आवश्यकता होती है, जो स्क्रिप्ट के साथ काम करने के शुरू में सरल विचार को जटिल करता है।
जैसा कि आप शायद अनुमान लगाते हैं, लिपियों में अनौपचारिक तर्क हो सकते हैं, और फिर स्क्रिप्ट पार्सर, संकलक और डिबगर लिखने में महीनों लग सकते हैं। यह तब होगा जब प्रोग्रामर यह नहीं समझ पाए कि उनके सामने बहुत अच्छा कंपाइलर था।
धुंधली सीमा
इसमें कोई संदेह नहीं है कि कोड और स्क्रिप्ट के बीच की सीमा धुंधली है। सामान्य तौर पर, लिपियों में कृत्रिम बुद्धिमत्ता (एआई) व्यवहार को रखना एक बुरा विचार है, जबकि दुनिया को अन्तरक्रियाशीलता प्रदान करने के लिए लिपियों में सिस्टम ट्रिगर्स लगाना एक अच्छा विचार है। यह निम्नलिखित नियम को बताता है: यदि तर्क जटिल है, तो उसे कोड में होना चाहिए। स्क्रिप्टिंग भाषाओं को सरल रहना चाहिए ताकि आपके गेम (और आपके सभी प्रोग्रामिंग संसाधनों) को अवशोषित न करें।
हालांकि, कुछ खेलों को खिलाड़ियों के लिए अपने एआई लिखने की क्षमता के साथ डिजाइन किया गया था। अक्सर, ये पहले व्यक्ति निशानेबाज होते हैं जो आपको बॉट्स जोड़ने की अनुमति देते हैं। जब लक्ष्य सिर्फ इतना है, तो वास्तविक प्रोग्रामिंग भाषाओं के लिए एक स्क्रिप्टिंग भाषा की समानता बस अपरिहार्य है। एक उदाहरण क्वेक सी है। चूंकि बॉट का निर्माण खेल में ही अंतर्निहित है, इसलिए संसाधन और ऊर्जा एक स्क्रिप्टिंग भाषा बनाने पर खर्च की गई जो सी भाषा की तरह सुविधाजनक है। इस पैमाने की एक स्क्रिप्टिंग भाषा बल्कि श्रमसाध्य है और इसे हल्के में नहीं लिया जाना चाहिए।
सबसे पहले, याद रखें कि आप गेम डिजाइनर और स्क्रिप्ट राइटर को गेम को प्रोग्राम करने के लिए नहीं चाहते हैं। कभी-कभी प्रोग्रामर गेम डिजाइनरों को गेम प्रोग्रामिंग में लुभाने के लिए स्क्रिप्टिंग लैंग्वेज बनाकर जिम्मेदारी से बचने की कोशिश करते हैं। आदर्श मामले में, प्रोग्रामर को गंभीर समस्याओं को हल करना चाहिए और नियंत्रण तर्क का एक महत्वपूर्ण हिस्सा बनाना चाहिए। नहीं तो उन्हें इतने पैसे क्यों दिए जाते! '

विचार 6: डेटा रिपीट सिंड्रोम से बचना

एक सामान्य प्रोग्रामिंग अभ्यास कभी भी डुप्लिकेट कोड नहीं है। यदि आपको दो अलग-अलग स्थानों में कुछ व्यवहार (उदाहरण के लिए, सामान्य कार्यक्षमता) की आवश्यकता है, तो यह केवल एक ही स्थान पर मौजूद होना चाहिए। यह विचार वैश्विक डेटा ब्लॉक के लिंक का उपयोग करके डेटा के विवरण पर भी लागू होता है। इसके अलावा, डेटासेट के संदर्भों का उपयोग करके और उनके कुछ मूल्यों को बदलकर, आप अंततः विरासत की अवधारणा से संपर्क करते हैं।
विरासत एक विशाल विचार है जिसे आपके डेटा पर लागू करने की आवश्यकता है। कल्पना करें कि आपका खेल काल कोठरी में रहने वाले goblins से आबाद है। आपका डेटा यह निर्धारित करता है कि प्रत्येक गॉब्लिन प्रत्येक तहखाने में अपने सभी गुणों के साथ खड़ा है। यह सही ढंग से प्रत्येक गॉब्लिन उदाहरण में वैश्विक परिभाषा डेटा को एन्क्रिप्ट करेगा। प्रत्येक गॉब्लिन अद्वितीय बनने के लिए, लिंक को पुन: परिभाषित करने योग्य गुणों की सूची के साथ हो सकता है। यह दृष्टिकोण डेटा को डुप्लिकेट नहीं करते हुए प्रत्येक गोबल को अपना व्यवहार रखने की अनुमति देगा।
इस विचार को कई स्तरों पर लागू किया जा सकता है, जिससे प्रत्येक डेटा को लिंक करने की अनुमति मिलती है। इस तकनीक का उपयोग करके, आप एक वैश्विक भूत परिभाषा बना सकते हैं जो बेस प्रकार के गोबलिन से विरासत में मिली है। प्रत्येक कालकोठरी के लिए परिभाषा के भीतर, साधारण या तेज़ गोबलिन का संकेत दिया जा सकता है। आंकड़ा संदर्भों और ओवरराइडिंग मानों का उपयोग करके विरासत की इस अवधारणा को दिखाता है।

विचार 7: डेटा के साथ काम करने के लिए एक उपकरण बनाएं

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

निष्कर्ष

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