उदाहरण के लिए एक गहरी विरासत पदानुक्रम के साथ एक GameObject बेस क्लास रखने से रखरखाव के लिए अच्छा हो सकता है ...
दरअसल, गहरी पदानुक्रम आम तौर पर उथले लोगों की तुलना में बनाए रखने के लिए बदतर होती हैं, और गेम ऑब्जेक्ट्स के लिए आधुनिक वास्तुशिल्प शैली उथले, एकत्रीकरण-आधारित दृष्टिकोण की ओर रुझान कर रही है ।
हालाँकि मुझे लगता है कि यह दृष्टिकोण प्रदर्शन के मुद्दे बना सकता है। दूसरी ओर सभी खेल वस्तुओं का डेटा और कार्य वैश्विक हो सकते हैं। जो एक रखरखाव सिरदर्द होगा, लेकिन एक बेहतर प्रदर्शन करने वाले गेम लूप के करीब हो सकता है।
आपके द्वारा संभावित रूप से दिखाए गए लूप में प्रदर्शन के मुद्दे हैं, लेकिन नहीं, जैसा कि आपके बाद के बयान से निहित है, क्योंकि आपके पास GameObjectकक्षा में डेटा और सदस्य फ़ंक्शन हैं । इसके बजाय, समस्या यह है कि यदि आप खेल में प्रत्येक वस्तु को ठीक उसी के समान मानते हैं , तो आप शायद उन वस्तुओं को समझदारी से समूहबद्ध नहीं कर रहे हैं - वे संभावित रूप से उस सूची में लगभग बिखरे हुए हैं। संभावित रूप से, फिर, उस ऑब्जेक्ट के लिए अपडेट विधि के लिए प्रत्येक कॉल (चाहे वह विधि एक वैश्विक फ़ंक्शन हो या नहीं, और ऑब्जेक्ट की तुलना में इंस्टेंस डेटा या "वैश्विक डेटा" किसी तालिका में चारों ओर तैर रहा हो, जो आप या जो कुछ भी अनुक्रमित कर रहे हैं) अंतिम लूप पुनरावृत्तियों में अद्यतन कॉल से अलग।
यह सिस्टम पर बढ़ा हुआ दबाव डाल सकता है क्योंकि आपको मेमोरी को संबंधित फ़ंक्शन के साथ और मेमोरी से बाहर पेज करने की आवश्यकता हो सकती है और निर्देश कैश को अधिक बार फिर से भरना पड़ सकता है, जिसके परिणामस्वरूप धीमी लूप हो सकती है। यह नंगी आँख से देखने योग्य है (या किसी प्रोफाइलर में भी) यह इस बात पर निर्भर करता है कि एक "गेम ऑब्जेक्ट" क्या माना जाता है, उनमें से कितने औसत रूप से मौजूद हैं, और आपके आवेदन में और क्या चल रहा है।
घटक-उन्मुख ऑब्जेक्ट सिस्टम अभी एक लोकप्रिय प्रवृत्ति है, इस दर्शन का लाभ उठाते हैं कि एकत्रीकरण विरासत के लिए बेहतर है । ऐसी प्रणालियां संभावित रूप से आपको घटकों के "अपडेट" तर्क को विभाजित करने की अनुमति देती हैं (जहां "घटक" को मोटे तौर पर कार्यक्षमता की कुछ इकाई के रूप में परिभाषित किया जाता है, जैसे कि वह चीज जो किसी वस्तु के भौतिक-सिम्युलेटेड हिस्से का प्रतिनिधित्व करती है, जिसे भौतिकी प्रणाली द्वारा संसाधित किया जाता है। ) कई थ्रेड्स पर - घटक प्रकार द्वारा भेदभाव - यदि संभव हो और वांछित, जिसका प्रदर्शन लाभ हो सकता है। बहुत कम से कम आप उन घटकों को व्यवस्थित कर सकते हैं जो किसी दिए गए प्रकार के सभी घटकों को एक साथ अपडेट करते हैं , जिससे सीपीयू के कैश का इष्टतम उपयोग होता है। इस तरह के घटक-उन्मुख प्रणाली का एक उदाहरण इस धागे में चर्चा की गई है ।
इस तरह की प्रणालियों को अक्सर अत्यधिक खराब कर दिया जाता है, जो रखरखाव के लिए भी एक वरदान है।
डेटा-उन्मुख डिज़ाइन एक संबंधित दृष्टिकोण है - यह पहली प्राथमिकता के रूप में वस्तुओं के लिए आवश्यक डेटा के आसपास खुद को उन्मुख करने के बारे में है, ताकि डेटा को थोक में प्रभावी रूप से संसाधित किया जा सके (उदाहरण के लिए)। यह आमतौर पर एक संगठन का अर्थ है जो एक ही उद्देश्य के क्लस्टर के लिए उपयोग किए गए डेटा को एक साथ रखने और एक ही बार में संचालित करने का प्रयास करता है। यह ओओ डिजाइन के साथ मौलिक रूप से असंगत नहीं है, और आप इस सवाल पर जीडीएसई में विषय पर कुछ बकबक पा सकते हैं ।
वास्तव में, गेम लूप के लिए एक अधिक इष्टतम दृष्टिकोण आपके मूल के बजाय होगा
foreach(GameObject g in gameObjects) g.update();
कुछ और पसंद है
ProcessUserInput();
UpdatePhysicsForAllObjects();
UpdateScriptsForAllObjects();
UpdateRenderDataForAllObjects();
RenderEverything();
इस तरह के एक दुनिया में, प्रत्येक GameObjectअपने स्वयं के लिए एक सूचक या संदर्भ हो सकता है PhysicsDataया Scriptया RenderData, जिन मामलों में आप एक व्यक्तिगत आधार पर वस्तुओं के साथ बातचीत करने के लिए आवश्यकता हो सकती है, लेकिन के लिए वास्तविक PhysicsData, Scripts, RenderData, वगैरह सब अपने-अपने उप के स्वामित्व में किया जाएगा (भौतिकी सिम्युलेटर, स्क्रिप्ट होस्टिंग वातावरण, रेंडरर) और थोक में संसाधित जैसा कि ऊपर संकेत दिया गया है।
यह ध्यान रखना बहुत महत्वपूर्ण है कि यह दृष्टिकोण एक जादू की गोली नहीं है और हमेशा प्रदर्शन में सुधार नहीं करेगा (हालांकि यह आमतौर पर एक गहरी विरासत पेड़ से बेहतर डिजाइन है)। यदि आपके पास बहुत कम ऑब्जेक्ट हैं, या बहुत अधिक ऑब्जेक्ट हैं जिन्हें आप प्रभावी रूप से अपडेट के लिए समानांतर नहीं कर सकते हैं, तो आपको मूल रूप से कोई प्रदर्शन अंतर दिखाई देने की संभावना है।
दुर्भाग्य से, ऐसा कोई जादू का लूप नहीं है जो सबसे इष्टतम है - हर गेम अलग है और अलग-अलग तरीकों से प्रदर्शन ट्यूनिंग की आवश्यकता हो सकती है। इसलिए इंटरनेट पर कुछ यादृच्छिक आदमी की सलाह लेने से पहले आँख बंद करके (प्रोफ़ाइल) चीजों को मापना बहुत महत्वपूर्ण है।