मुझे कोड में अर्थव्यवस्था-आधारित गेम कैसे मॉडल करना चाहिए?

Question

मैं एक प्राचीन सभ्यता पर आधारित अर्थव्यवस्था का खेल बनाना चाहता हूं। मुझे यकीन नहीं है कि इसे कैसे डिजाइन किया जाए। अगर मैं एक छोटे से खेल पर काम कर रहा था, "स्पेस आक्रमणकारियों" की एक प्रति की तरह, तो मुझे इसे इस तरह से संरचित करने में कोई समस्या नहीं होगी:

• मुख्य नियंत्रण वर्ग
• ग्राफिक्स वर्ग
• खिलाड़ी वर्ग
• शत्रु वर्ग

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

Comments

आप एंटिटी-कंपोनेंट-सिस्टम (यहाँ विहित संदर्भ ) के कुछ रूप का उपयोग करना चाह सकते हैं - संस्थाओं के न होने से खुद को आकर्षित करना (खासकर यदि आपके पास उनमें से बहुत सारे हैं)।

— थोरीनी

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

— शॉन मिडिलडाइच

यहां तक ​​कि अगर आप पूर्ण विकसित ईसीएस नहीं जाते हैं तो भी कोड को डुप्लिकेट नहीं करने के लिए अच्छा है, नियंत्रक को संस्थाओं को पुनरावृत्त करने और रेंडरर को कॉल करने दें, या रेंडरर स्कैन करने दें। 100 जगहों पर मामूली कोड अपडेट करना एक दर्द है।

— मिकलएच

अंतरिक्ष आक्रमणकारियों से एक जटिल खेल में कूदना जैसा कि आपने वर्णित किया है, मेरी राय में थोड़ा कठोर है। इन दो खेलों के बीच अधिक सीखने के चरण हैं, इससे पहले कि आप एक बड़े गेम प्रोजेक्ट में जाएं। धीरे-धीरे एक 2D साइडक्रॉलर प्लेटफॉर्म बनाने और अपने गेम की जटिलता को बढ़ाने पर विचार करें। पहली से पाँचवीं गियर में ले जाना आपको 120 किमी / घंटा तक ले जा सकता है, लेकिन उसी दक्षता (समय / प्रयास) के साथ नहीं जो अगर आप स्तर से स्तर पर चलते हैं।

— अमीर लीमा

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

Answer 1

क्या मैं एक देश वर्ग बनाता हूं जिसमें शहरों का समूह है?

ज़रूर।

क्या कस्बों में बहुत अधिक निर्माण वर्ग हैं, अधिकांश में लोगों के वर्ग हैं?

ज़रूर।

क्या मैं एक पाथ फाइंडिंग क्लास बनाता हूं, जिसमें खिलाड़ी पहुंच सकता है?

ज़रूर।

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

आपने स्वाभाविक रूप से अवधारणाओं को अपने सिर में लिया है और उन्हें कुछ सरल नियमों के अनुसार कोड में वर्गीकृत किया है:

• क्या यह अवधारणा व्यवहार में या मेरे पास पहले से मौजूद अन्य वस्तुओं के डेटा में काफी भिन्न है? (देश और लोग बहुत कम साझा करते हैं, यदि कोई हो, तो सार्थक डेटा या व्यवहार, इसलिए उन्हें अलग-अलग प्रकार के इन-गेम द्वारा दर्शाया जाना चाहिए)।
• क्या मुझे इस अवधारणा को एक महत्वपूर्ण तरीके से कोड में हेरफेर करने की आवश्यकता होगी (यदि आपका गेम अलग-अलग लोगों के साथ व्यवहार करता है, तो आपको उस Personवर्ग की आवश्यकता हो सकती है , लेकिन अगर गेम केवल उनके बारे में परवाह करता है, जैसा कि SimCity के पुराने संस्करणों में है, तो आप किसी शहर की आबादी के 1: 1 मानचित्रण बनाने के लिए उस प्रकार की और न ही उस प्रकार के उदाहरणों की आवश्यकता नहीं int populationCountहो सकती है। पर्याप्त हो सकता है)।
• क्या इस अवधारणा को राज्य की आवश्यकता है ? यदि ऐसा है तो इसे किसी तरह से एनकैप्सुलेट किया जाना चाहिए जो मुझे मुफ्त कार्यों के एक समूह के बजाय इस राज्य (एक वर्ग) को स्टोर करने की अनुमति देता है। (एक पाथफाइंडिंग कार्यान्वयन में एक समरूप वास्तविक दुनिया वस्तु नहीं होती है, लेकिन इसके लिए डेटा पर नज़र रखने की आवश्यकता होती है जैसे कि मानचित्र में नोड्स जो पहले से ही माना गया है, और यह एक वर्ग के माध्यम से एक गुच्छा में संग्रहीत करके बेहतर होता है। छिपी ग्लोबल्स और फ्रीस्टैंडिंग फ़ंक्शंस बनाना)।

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

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

Answer 2

आपने जो वर्णन किया है (हर मुख्य प्रकार के तार्किक गेम ऑब्जेक्ट के लिए एक वर्ग) सरल गेम के लिए एकदम सही समझ में आता है। यदि यह आपका पहली बार इस प्रकार का खेल लिख रहा है, तो मैं इसे इस तरह से करने का सुझाव दूंगा।

बस कुछ सुझाव:

• क्या एक खिलाड़ी वास्तव में एक दुश्मन से अलग है ? बहुत सारी कार्यक्षमता समान होने की संभावना है, इसलिए इन्हें सामान्य रूप से एक ही वर्ग होना चाहिए या एक ही आधार वर्ग से बढ़ाया जाना चाहिए। दो उपवर्गों के साथ एक AbstractPlayer बेस क्लास पर विचार करें HumanPlayer और AIPlayer - सभी सामान्य कार्यक्षमता AbstractPlayer में जा सकती हैं ।
• विरासत के बजाय रचना के साथ वस्तुओं को कॉन्फ़िगर करना पसंद करें । अपने वंशानुगत पदानुक्रम को बहुत गहरा न बनाएं। यदि आप एक वर्ग ForgeWithSteelAnvil को कॉल करना शुरू करते हैं, तो आपको चिंतित होना चाहिए: एक फोर्ज बिल्डिंग का एक उपवर्ग हो सकता है , लेकिन उपयोग किए गए एविल का प्रकार भवन के भीतर निहित वस्तु होना चाहिए।
• इसी तरह उन गुणों को प्राथमिकता दें जो आपको सैकड़ों अलग-अलग ऑब्जेक्ट क्लास को जोड़ने के बजाय ऑब्जेक्ट को कॉन्फ़िगर करने में सक्षम करते हैं ।

अधिक जटिल खेलों में, अधिक उन्नत तकनीकें हैं जिनका आप उपयोग कर सकते हैं, लेकिन मेरा सुझाव है कि इनका उपयोग तब तक न करें जब तक कि आप मूल ओओपी दृष्टिकोण के साथ बहुत सहज नहीं हो जाते (अर्थात सफलतापूर्वक कुछ खेलों को पूरा कर चुके हैं)। अधिक उन्नत दृष्टिकोणों में शामिल हो सकते हैं:

• प्रोटोटाइप आधारित ऑब्जेक्ट मॉडल - सभी खेल वस्तुओं के लिए एक एकल वर्ग का उपयोग करें, और अपने सभी वस्तुओं को गुणों / विशेषताओं और संरचना के माध्यम से मॉडल करें। मानक OOP की तुलना में बहुत अधिक लचीला / गतिशील, लेकिन प्रबंधित करने के लिए ट्रिकियर (विशेष रूप से, कंपाइलर आपको कुछ बेवकूफ बनाने में बहुत मदद नहीं करेगा)। मैंने इसे अपने छोटे रोजुइलाइक गेम टायरेंट ( https://github.com/mikera/tyrant ) में अच्छे प्रभाव के लिए इस्तेमाल किया।
• इकाई घटक प्रणालियाँ - यदि आपके पास बहुत सारे जटिल व्यवहार हैं जिन्हें आप कई अलग-अलग प्रकार की खेल वस्तुओं में मिलाना और मेल खाना चाहते हैं। बहुत शक्तिशाली, लेकिन सही पाने के लिए कठिन।

Answer 3

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

यदि आप अपनी सामग्री को संरचित करने में अधिक मदद करना चाहते हैं तो एक पुराना गेम सोर्स कोड ढूंढें जो समान संरचना या शैली का उपयोग करता है और उनका समाधान ढूंढता है। फिर इसे परिष्कृत करें और इसे अपनी पसंद के अनुसार ठीक करें।

Comments

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