एकता में खेल के विकास के लिए कैओस गोब्लिन दृष्टिकोण

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

क्योंकि जब आप यह तय कर लेते हैं कि आपका गेम एक ROGUELITE-RTS-MMORPG बनने जा रहा है, तो आपको वास्तव में वह चीज बनानी होगी, समझे?

और मान लीजिए कि आपने तय कर लिया है कि पहली चीज़ जो आप बनाने जा रहे हैं वह इसका आरटीएस भाग है। तो आप उपयोगकर्ता की कहानी, कार्य, या काम की जो भी इकाई आप स्वयं को व्यवस्थित करने के लिए उपयोग करते हैं, उसे लिख लें।

तो फिर मान लें कि उस सूची में पहला आइटम "स्क्रॉल करने योग्य मानचित्र लागू करें" है।

और उफ़! आपने कभी स्क्रॉल करने योग्य मानचित्र लागू नहीं किया है। लेकिन चिंता न करें, Google बचाव के लिए है, क्या मैं सही हूं?

लेकिन क्या होगा यदि आपको ऑनलाइन मिलने वाला समाधान ठीक वैसा नहीं करता जैसा आपको चाहिए? या जो समाधान आप ढूंढ रहे हैं वह 15 साल पुराना है? या फिर नीचे ढेर सारी टिप्पणियाँ हैं जो बता रही हैं कि यह कितना ख़राब समाधान है लेकिन एक भी बेहतर समाधान निर्दिष्ट किए बिना है[^0]?

इसलिए, आप जो कुछ भी बनाने का प्रयास कर रहे हैं उसके लिए आपको कोई कोड संदर्भ नहीं मिल रहा है। गेम डेवलपर को क्या करना चाहिए?

उत्तर कैओस गोब्लिन मोड में प्रवेश करना है।

कैओस गोब्लिन मोड में प्रवेश

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

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

इस बिंदु को और स्पष्ट करने के लिए मैं आपको फॉलआउट 3 के प्रेसिडेंशियल मेट्रो हेड के बारे में बताता हूं (आप पूरी कहानी यहां पढ़ सकते हैं)। इसका सार यह है कि खेल के एक दृश्य के दौरान जहां खिलाड़ी सोचता है कि वे मेट्रो के अंदर खड़े हैं, खिलाड़ी के हेडगियर को वास्तव में मेट्रो कार के मॉडल से बदल दिया गया है, और यह खिलाड़ी का अपना मॉडल है जो कार पर चल रहा है पूर्व निर्धारित ट्रैक.

कुछ खिलाड़ी इसे पढ़ सकते हैं और सोच सकते हैं कि डेवलपर्स आलसी हो रहे थे। लेकिन मामले की सच्चाई यह है कि डेवलपर्स हर समय इस तरह का काम करते हैं।

और यह ठीक उसी तरह की प्रथाएं हैं जो कैओस गोब्लिन मोड के सिद्धांतों का निर्माण करती हैं, जो इस प्रकार हैं।

खिलाड़ी को जो नहीं पता वह उन्हें नुकसान नहीं पहुंचा सकता

मान लीजिए कि आपके गेम के एक हिस्से में, खिलाड़ी एक महल टॉवर के अंदर खड़ा है और बाहर उड़ रहे एक ड्रैगन पर तीर चला रहा है। समय-समय पर ड्रैगन करीब आता है और खिलाड़ी को काटने की कोशिश करने के लिए खिड़की से अपना सिर धकेलता है।

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

कुछ चीज़ें जो की जा सकती हैं वे इस प्रकार हैं:

• ड्रैगन खिलाड़ी से कितनी दूर है, इसके आधार पर विभिन्न मॉडलों का उपयोग करें। खिलाड़ी ड्रैगन का विवरण केवल तभी देख सकता है जब वह करीब हो, तो क्यों न ड्रैगन के 3डी मॉडल को किसी ऐसी चीज़ से बदल दिया जाए जिसमें कम विवरण हो, लेकिन मेमोरी में भी कम जगह घेरे?

  
  

• जब खिलाड़ी ड्रैगन को नहीं देख रहा हो तो उसे बंद कर दें। प्लेयर कहां देख रहा है, इस पर नज़र रखकर, हम रेंडरिंग पर बचत करने के लिए चुनिंदा 3डी मॉडल को चालू और बंद कर सकते हैं।

  
  

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

  
  

• शायद जब ड्रैगन खिड़की के माध्यम से अपना सिर डालता है तो हम पूरे ड्रैगन मॉडल को एक छोटे लेकिन अधिक विस्तृत सिर मॉडल से बदल देते हैं। यह हमें उस मॉडल से मेमोरी मुक्त करने की अनुमति देगा जिसका हम उपयोग नहीं कर रहे हैं, जबकि हमें प्लेयर को एक बेहतर अनुभव देने की अनुमति देगा।

  
  

यदि आप खेल उद्योग में लंबे समय से हैं, तो आप संभवतः उपरोक्त को मानक प्रथाओं के रूप में पहचानते हैं, लेकिन एक समय था जब इन तकनीकों को चतुर चालबाजी और काफी नवीन माना जाता था।

अब यह आप पर निर्भर है कि आप अपने खिलाड़ियों को यह सोचने के लिए नए तरीके अपनाएं कि वे जो देख रहे हैं उसमें और भी बहुत कुछ है।

सबसे अच्छा समाधान वह है जो वर्तमान में काम कर रहा है

बहुत सारे गेम डेवलपर फंस जाते हैं क्योंकि वे ऐसे समाधानों के साथ आने की कोशिश करते हैं जो भविष्य के सभी संभावित परिदृश्यों को कवर करते हैं। यह रवैया सही परिस्थितियों में मूल्यवान हो सकता है, लेकिन जब आप कैओस गोब्लिन मोड में होते हैं, तो उद्देश्य जितनी जल्दी हो सके कुछ काम करना होता है।

इसका एक परिशिष्ट:

एक त्रुटिपूर्ण प्रोटोटाइप किसी भी अधूरी कृति से अधिक मूल्यवान है

उपरोक्त बिंदु के समान, कई डेवलपर किसी सुविधा को लागू करने का प्रयास करते समय स्थिर हो जाते हैं क्योंकि वे बहुत जल्दी अनुकूलन करने का प्रयास करते हैं।

अनुकूलन को तब तक छोड़ दिया जाना चाहिए जब तक कि परियोजना को डेवलपर्स के नियंत्रण से बाहर मशीनों पर चलाने की आवश्यकता न हो[^1]।

एक्स करने से पहले मुझे कितना जानना आवश्यक है? इसका उत्तर यह है कि अभी आपके पास जितना भी ज्ञान है वह पर्याप्त है

यह एक और बड़ी बाधा है जिसका सामना कई शुरुआती गेम डेवलपर्स को करना पड़ता है। वे एक सुविधा को लागू करना बंद कर देंगे ताकि वे सिर्फ एक और कोर्स, एक और ऑनलाइन ट्यूटोरियल ले सकें, एक और वीडियो देख सकें, और फिर वे अपने गेम को लागू करने के लिए तैयार हो जाएंगे।

मैं इसके लिए विशेष रूप से दोषी हूं और जानता हूं कि यह कितना घातक हो सकता है।

आपको अधिक ठोस उदाहरण देने के लिए, मान लें कि आपको स्क्रैच से पोंग गेम की प्रोग्रामिंग करने का काम सौंपा गया है।

आप क्या जानते हैं या क्या नहीं जानते, इसके आधार पर, इसके लिए अलग-अलग दृष्टिकोण अपनाए जा सकते हैं:

• यदि आप यूनिटी की भौतिकी प्रणाली से परिचित हैं, तो यह अपेक्षाकृत सरल प्रयास है। आप बस कुछ कठोर पिंडों और कोलाइडरों का उपयोग कर सकते हैं, बल और वेग लागू कर सकते हैं, गेंद की उछाल के लिए भौतिकी सामग्री का उपयोग कर सकते हैं और बस इतना ही। एक नंगे पैर पोंग क्लोन।

  
  

• लेकिन मान लीजिए कि आप यूनिटी की टक्कर प्रणाली से परिचित नहीं हैं, आप केवल यूनिटी के ट्रांसफॉर्म घटकों का उपयोग करना जानते हैं, इसलिए आप केवल एक वस्तु की स्थिति और आकार प्राप्त कर सकते हैं।

  • लेकिन! यह पोंग को लागू करने के लिए पर्याप्त है, आप एक स्क्रिप्ट लिख सकते हैं जो गेंद की स्थिति और आकार पर नज़र रखती है और इसकी तुलना पैडल की स्थिति और आकार से करती है ताकि यह जांचा जा सके कि टक्कर हुई है या नहीं।

    
    

• या शायद आप यूनिटी को भी नहीं जानते, आप केवल C++ और कंसोल पर प्रिंट करना जानते हैं।

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

    
    

• या आप कंप्यूटर विज्ञान पृष्ठभूमि से भी नहीं आते हैं या आपने C++ कक्षा नहीं ली है, और केवल जावास्क्रिप्ट जानते हैं?

  • कोई बात नहीं! आप फेज़र का उपयोग कर सकते हैं जो जेएस को अपनी मुख्य भाषा के रूप में उपयोग करता है और रेंडरिंग और भौतिकी दोनों घटकों के साथ आता है।

    
    

• प्रोग्राम भी नहीं कर सकते? बिल्कुल कोई समस्या नहीं.

  • गेममेकर एक मुफ़्त संस्करण वाला एक व्यावसायिक गेम इंजन है, और इसमें नो-कोड विकल्प है।
  • GDevelop एक निःशुल्क ओपन-सोर्स गेम इंजन है जिसमें नो-कोड विकल्प भी है।

आपने यह पता लगा लिया है कि मैं इसके साथ कहाँ जा रहा हूँ, ठीक है?

यहां कोई असफल परियोजनाएं नहीं हैं, केवल स्क्रैप के ढेर हैं जो पुन: उपयोग की प्रतीक्षा कर रहे हैं

अधिकांश गेम डेवलपर्स के पास आमतौर पर एक या दो (या 10,000) परित्यक्त प्रोजेक्ट कहीं न कहीं पड़े रहते हैं। उन्हें बर्बाद करने का कोई मतलब नहीं. यदि वहां पॉज़ सिस्टम जैसा कोड है, तो उसका पुनः उपयोग करें। एक ही बात को दोबारा लिखने का कोई मतलब नहीं है. भले ही आपको ठीक से याद हो कि इसे कैसे लिखना है, फिर भी इसे कॉपी करें; यदि इसे अनुकूलित करना कठिन है तो इसे दोबारा दोहराएं ताकि अगली बार यह आसान हो जाए।

शायद आपके पास एक वर्कशॉप प्रोजेक्ट[^2] भी हो जिसमें कोड के कई बिट्स हों जिनका आप पुन: उपयोग कर सकें।

कोई चमकदार चीज़ देखी? कोई चमकदार चीज लें

संवाद प्रणाली की आवश्यकता है? एक ओपन-सोर्स का पता लगाएं और उसका पुन: उपयोग करें। क्या यह आपकी सभी आवश्यकताओं को पूरा करता है? नहीं? क्या यह 50% से अधिक मिलता है? हाँ? फिर स्क्रैच से नया बनाने के बजाय उसका उपयोग करना उचित है।

सूची प्रणाली? itch.io पर एक ओपन-सोर्स गेम ढूंढें और उनके सिस्टम को अपनाएं।

प्रथम-व्यक्ति कैमरे की आवश्यकता है? इसे संभालने के लिए पूर्वनिर्मित संपत्ति का उपयोग करें[^3]।

वहाँ कई शानदार गेम डेवलपर हैं, निस्संदेह आपसे या मुझसे अधिक कुशल।

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

जब संदेह हो तो नकल करें

यदि आप किसी सुविधा को लागू करने के बारे में अनिश्चित हैं, तो एक ऐसा गेम ढूंढें जिसने कुछ वैसा ही किया हो जैसा आप चाहते हैं और उसका अनुकरण करें।

"कॉपी" से मेरा तात्पर्य कला शैली, कहानी या पात्रों के बजाय नियंत्रण संचालन, कैमरा दृश्य और यांत्रिकी जैसे डिज़ाइन पहलुओं से है।

उदाहरण के लिए, हमारे अब भूले हुए काल्पनिक ROGUELIKE-RTS-MMORPG में स्क्रॉल कितनी तेज़ होनी चाहिए?

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

बिदाई विचार

तो, अपनी अराजकतापूर्ण हरकतों का निष्कर्ष निकालने के बाद आपको क्या करना चाहिए? ठीक है, एक राहत की सांस लें, अपने लिए एक कुप्पा बनाएं और बाद में अपने कोड पर वापस आएं।

अपने कोड को आराम देने के बाद (यदि मौसम बहुत शुष्क है तो एक नम तौलिये के नीचे), आपको इसे थोड़ा सा सजाना चाहिए और साझा करना चाहिए। हाँ! इसे आदर्श रूप से किसी वरिष्ठ डेवलपर, सहकर्मी, साथी छात्र या, सबसे खराब स्थिति में, किसी ऑनलाइन समुदाय के साथ साझा करें[^4]।

आप इसे क्यों साझा कर रहे हैं? क्योंकि कैओस गॉब्लिन होने का मतलब कुछ टिकाऊ या इष्टतम बनाना नहीं है; यह कुछ ऐसा बनाने के बारे में है जो काम करे। इसे पूरी तरह से काम करना या सुंदर दिखना ज़रूरी नहीं है, इसे बस काम करना है। इस प्रकार का विकास परिणाम उत्पन्न करता है, लेकिन परिणाम शायद ही उत्पादन के लिए तुरंत तैयार होते हैं। इस प्रकार, फीडबैक देने के लिए किसी से परामर्श करना अत्यंत महत्वपूर्ण है।

आपके प्रोजेक्ट के चरण के आधार पर, आपके पास इस व्यक्ति की टिप्पणियों को तुरंत लागू करने का समय नहीं हो सकता है। यदि ऐसा मामला है, तो आपको कम से कम उन टिप्पणियों को कोड[^5] में दर्ज करना चाहिए।

और बस! अब आपके पास दुनिया भर में पेशेवर गेम डेवलपर्स द्वारा समस्याओं को हल करने के लिए उपयोग की जाने वाली #1 तकनीक है।

मेरा सुझाव है कि यह दूसरे कप का समय है, है ना?

टिप्पणियाँ

[^0] - यह आश्चर्यजनक रूप से सामान्य घटना है और इसे "द डेनवर पैरेबल" कहा जाता है, अधिक जानकारी के लिए, निम्नलिखित विद्वान लेख देखें।

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

[^2] - कार्यशाला उन काटा या प्रथाओं में से एक है जिनका उपयोग मैं एकता के बारे में अपनी समझ बढ़ाने के लिए करता हूं। आप इसके बारे में और अन्य तकनीकों के बारे में यहां अधिक पढ़ सकते हैं।

[^3] - आप इस आलेख में अन्य उपयोगी टूल के साथ एक बहुत अच्छा एफपीएस नियंत्रक पैकेज पा सकते हैं

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

[^5] - अलग-अलग टीमें अपने कोड दस्तावेज़ीकरण को बनाए रखने के संबंध में अलग-अलग मानदंडों का पालन करती हैं, और आपको उनका पालन करना चाहिए। हालाँकि, आम तौर पर, मैं कोड के दस्तावेज़ीकरण को कोड के निकट ही रखने की वकालत करूँगा। यदि यह संभव नहीं है, तो अपने चुने हुए कोड वर्जनिंग सिस्टम में गिट सबमॉड्यूल या इसके समकक्ष का उपयोग करने पर विचार करें। यदि दस्तावेज़ीकरण मुख्य भंडार में नहीं हो सकता है, तो इसे कम से कम गिट सबमॉड्यूल में रहना चाहिए।