2010-02-25 13 views
6

मैंने हाल ही में एक्सएनए पूल में कूद लिया है, और सी # में ढांचे के सभी इंस और आउट सीख रहा हूं। मेरे शोध में एक बात मैंने देखी है कि गेमकंपोनेंट्स को लागू करने के लिए कोई व्यापक रूप से स्वीकार्य "उचित" तरीका नहीं लगता है।एक्सएनए गेमकंपोनेंट कार्यान्वयन प्राथमिकताएं ...?

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

दिन के अंत में, यह निर्धारित करने के लिए गेम डेवलपर पर निर्भर करता है कि ढांचे को कैसे कार्यान्वित किया जाए। चूंकि स्टैक ओवरव्लो समझदार डेवलपर्स के साथ पैक किया गया है, जो मुझे कभी भी पता चलेगा उससे ज्यादा भूल गए हैं, मैं ढांचे के अपने उपयोग के साथ इस मार्ग को आगे बढ़ाने से पहले आम सहमति प्राप्त करना चाहता हूं।

कोई भी अपने विचारों के साथ झुकने की देखभाल करता है? अग्रिम में धन्यवाद!

उत्तर

2

मैं एक्सएनए के लिए भी काफी नया हूं इसलिए इस जवाब को नमक के अनाज के साथ लें।

मुझे लगता है कि यह एक शैली वरीयता के लिए उबाल सकता है। मुझे यकीन नहीं है कि GameComponent बनाम अधिक मैन्युअल तरीकों का उपयोग करने के बीच प्रदर्शन विशेषताओं, लेकिन मुझे पता है कि मेरे लिए, व्यक्तिगत रूप से, मैं जल्दी से गेमकंपोनेंट का उपयोग करने की कोशिश कर निराश हो गया क्योंकि यह वास्तव में सोच या प्रोग्रामिंग की मेरी शैली के साथ जाल नहीं था। दिल में मैं उन चीजों का मिश्रण हूं जिन्हें मैंने ओओपी, प्रक्रियात्मक, कार्यात्मक, और अन्य प्रोग्रामिंग प्रतिमानों से उठाया है। गेम कॉम्पोनेंट एक सख्त ओओपी दृष्टिकोण का उपयोग कर रहा है।

लेकिन मैं कहूंगा कि सब कुछ एक गेमकंपोनेंट, या यहां तक ​​कि सामान्य रूप से एक वर्ग भी समस्याग्रस्त हो सकता है जहां प्रदर्शन का संबंध है। अधिकतम पठनीयता और रखरखाव के प्रश्न खेल विकास की दुनिया में चाकू के किनारे पर लगते हैं, जहां कभी-कभी आपको वास्तव में अपने कोड से अनुकूलन निचोड़ना पड़ता है। उदाहरण के लिए, कभी-कभी अपनी गेम ऑब्जेक्ट्स को एक स्ट्रक्चर (वैल्यू-टाइप) में बदलना बेहतर होता है ताकि आप कुछ मेमोरी को बचा सकें और अपने गेम अंतराल से परेशान कचरा कलेक्टर को रोक सकें (जैसा कि मैं this question I asked में सीख रहा हूं)।

+0

प्रतिक्रिया के लिए धन्यवाद! मैंने सुना है कि गेम का उपयोग करना। कॉम्पोनेंट्स संग्रह कम ओवरहेड का कारण बनता है, लेकिन ऐसा लगता है जैसे आप अन्यथा विरोध करते हैं। क्या आपको लगता है कि अपनी खुद की इकाई पदानुक्रम/प्रबंधन प्रणाली बनाना अधिक प्रदर्शन क्षमता प्रदान करता है? – Syndog

+0

मुझे खेद है, मैं वास्तव में नहीं जानता। आप निश्चित रूप से अधिक नियंत्रण प्राप्त करते हैं, तो हो सकता है कि आप अधिक प्रदर्शन निचोड़ सकें। लेकिन फिर, एमएस शायद जानता है कि वे कहां कर रहे हैं और गेमकंपोनेंट से प्रदर्शन शुरू कर रहे हैं :) लेकिन कुछ ऑब्जेक्ट्स के लिए, खासकर यदि आप स्क्रीन पर बहुत से (जैसे गोलियां) की योजना बनाते हैं, तो वे बेहतर छोड़ दिए जाते हैं प्रदर्शन कारणों के लिए structs – Bob

+0

गेमकंपोनेंट्स को आंतरिक रूप से एक सूची के रूप में लागू किया जा रहा है, उससे अधिक कुशल नहीं हो सकता है! Structs के लिए, मुझे यकीन नहीं है कि यह एक अच्छा विचार है, सी # में एक संरचना को पारित करने में बहुत सारे प्रतिलिपि मूल्य शामिल होंगे। कचरा कलेक्टर एक्सबॉक्स पर केवल धीमा है, पीसी पर आप इसके बारे में बहुत कुछ भूल सकते हैं। – Martin