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