क्या इकाई को अपने स्वयं के आंदोलन को संभालना चाहिए?
वर्तमान में मैं एक साधारण टर्न-आधारित गेम बना रहा हूं जिसमें एक कक्ष है जिसमें 2 डी सरणी वाली टाइल ऑब्जेक्ट्स हैं। वे वॉलटाइल या फ्लोरलाइल हो सकते हैं। टाइल की वस्तुओं में उत्तर, पूर्व, दक्षिण और पश्चिम पड़ोसी होते हैं। फ्लोरटाइल्स में ढेर सारी इकाइयाँ होती हैं ताकि मैं आसानी से शीर्ष इकाई को आकर्षित कर सकूँ।
अब मैं सोच रहा था, मेरा खिलाड़ी एक इकाई है, जब खिलाड़ी चलता है, तो क्या खिलाड़ी को उस तर्क को संभालना चाहिए, या खेल जो मेरे खिलाड़ी को रखता है?
पहले मामले में यह कुछ इस तरह होगा:
class Player : Entity {
public Tile CurrentLocation
public bool CanMoveTo(Direction) {
// Let's say that direction is East
return CurrentLocation.EastNeighbour == FloorTile
}
// This method does the actual move
public void MoveTo(Direction)
}
दूसरे मामले में यह इस प्रकार होगा:
class Game {
public Player Player;
public Room Room;
public void Update() {
// Lets say we get direction from some input from somewhere
if Room.TileAt(player.Y, player.X) is FloorTile then MoveThere()
}
}
मुझे पूरा यकीन नहीं है कि दोनों विकल्पों में से सबसे अच्छा विकल्प क्या है। शुरू में मैं पहले उपाय के बारे में सोच रहा हूं। किसी भी मदद या सुझावों की सराहना की जाएगी।
जवाब
चीजों को करने के कोई सही या गलत तरीके नहीं हैं। केवल वे तरीके जो आपके लिए काम करते हैं या आपके लिए काम नहीं करते हैं।
मुख्यधारा की खेल वास्तुकला में कई प्रतिस्पर्धी दर्शन हैं।
ए: ऑब्जेक्ट-ओरिएंटेड आर्किटेक्चर
प्रत्येक इकाई को एक वस्तु द्वारा दर्शाया जाना चाहिए। उन वस्तुओं में अपने स्वयं के सभी तर्क शामिल होने चाहिए, अपनी आंतरिक स्थिति को अलग करना चाहिए और अच्छी तरह से परिभाषित इंटरफेस के माध्यम से अन्य वस्तुओं के साथ संवाद करना चाहिए। कोर गेम इंजन बस सभी संस्थाओं के "अपडेट" और "रेंडर" तरीकों को एक लूप में कॉल करता है और फिर संस्थाओं को बाकी काम करने देता है।
जब आपके पास ऐसी वस्तुएँ होती हैं जो कुछ कार्यक्षमता साझा करती हैं, तो आप आम तौर पर विरासत के माध्यम से - एक सामान्य आधार-वर्ग में सामान्य कार्यक्षमता को निकालकर करेंगे। उदाहरण के लिए, आप एक वर्ग खिलाड़ी और एक वर्ग शत्रु हो सकते हैं जो दोनों एक वर्ग Combatant से विरासत में मिला है जिसमें सभी लड़ाकू कोड शामिल हैं और Entity से विरासत में मिला है जिसमें आंदोलन के लिए मूल कोड है। और शत्रु संभवतः एक अमूर्त वर्ग होगा, जिसमें सभी शत्रुओं के तर्क समान होते हैं, शत्रु से विरासत में प्राप्त विभिन्न वर्गों में लागू विभिन्न प्रकार के दुश्मन और उनके अनूठे व्यवहार के साथ।
मूल रूप से जिस तरह से आप पुस्तक द्वारा OOP करने वाले हैं।
यह शैली अक्सर डेवलपर्स में देखी जाती है जो अनुप्रयोग विकास से आए थे, क्योंकि यह वहां की प्रमुख शैली है। और अनुप्रयोगों के लिए जो काम करता है वह जरूरी नहीं कि खेलों के लिए पूरी तरह से गलत हो।
बी: इकाई-घटक वास्तुकला
यह शैली वंशानुक्रम पर रचना पसंद करती है । एक इकाई एक वस्तु नहीं है, यह उस इकाई की एक अलग विशेषता को लागू करने वाली प्रत्येक वस्तु के साथ वस्तुओं का एक संग्रह है। इसलिए आपके पास "खिलाड़ी" वर्ग नहीं है जो एक खिलाड़ी कर सकता है। आपके पास एक "स्प्राइट", एक "मूवर", एक "शूटर", एक "हिटप्वाइंट" और एक "प्लेयरइन्पुट" घटक के साथ एक सामान्य इकाई है।
इस दृष्टिकोण का लाभ यह है कि नए प्रकार की गेम इकाइयां बनाने के लिए घटकों को मिश्रण और मैच करना बहुत आसान है। यह आपके गेम डिज़ाइन पर तेजी से पुनरावृत्तियों के लिए बहुत उपयोगी है। यह कुछ लोकप्रिय गेम इंजन द्वारा पसंदीदा दृष्टिकोण है। उदाहरण के लिए, एकता की तरह।
सी: इकाई-घटक-प्रणाली वास्तुकला
एक इकाई को "इकाई-घटक" वास्तुकला की तरह घटकों का एक संग्रह होना चाहिए। लेकिन इस वास्तुकला में, उन घटकों को केवल गूंगा डेटा-धारक होना चाहिए। आमतौर पर केवल सार्वजनिक चर के साथ संरचनाओं के रूप में और कोई विधि नहीं। सभी तर्क सिस्टम में होने चाहिए। प्रत्येक प्रणाली एक प्रकार के घटकों, या घटकों के एक समूह के प्रबंधन के लिए जिम्मेदार है। उदाहरण के लिए, आपके पास एक मूवमेंट सिस्टम है जो मूवमेंट कंपोनेंट के साथ हर एंटिटी के पोजिशन को अपडेट करता है।
लेकिन यह सिर्फ एक निरीक्षण है। यदि आप अधिक जानना चाहते हैं, तो प्रश्न की जांच करें "शुद्ध ईसीएस क्या है?" । आप हमारी इकाई-घटक-प्रणाली टैग के अंतर्गत अन्य प्रश्नों को भी देख सकते हैं ।
ईसीएस दृष्टिकोण वर्तमान में बहुत फैशन में है। इसके लिए मुख्य तर्क यह है कि यह इकाई-घटक दृष्टिकोण के प्रतिरूपकता और पुनरावृत्ति गति का त्याग किए बिना कुछ बहुत साफ-सुथरे प्रदर्शन अनुकूलन (विशेषकर जब यह मेमोरी इलाके और मल्टीथ्रेडिंग की बात आती है) की अनुमति देता है। लेकिन नुकसान यह है कि एक ठोस और लचीले ईसीएस आर्किटेक्चर को बहुत सारे आर्किटेक्चर कोड की आवश्यकता होती है जो "पर्दे के पीछे" चलता है और जो शुरुआती लोगों के लिए लागू करना मुश्किल हो सकता है।
आपको किसका उपयोग करना चाहिए?
यह कुछ ऐसा है जिसे आपको खुद ही पता लगाना है। लेकिन जो भी आप अपने खेल के लिए चुनते हैं, आपको उससे चिपके रहने की सलाह दी जाएगी। संभव होने पर अपने खेल में मिक्स-एंड-मैचिंग आर्किटेक्चर पैटर्न से बचें।
यह मूल रूप से आपके गेम नेटवर्क को ट्रेस करने वाले डेटा की मात्रा पर निर्भर करता है। किसी भी बड़े पैमाने पर मल्टीप्लेयर को ट्रैक रखने की आवश्यकता है कि वह कौन है जो हमेशा कर रहा है (अन्यथा बड़े पैमाने पर धोखा हो सकता है)। हालाँकि, सर्वर से पैकेट प्राप्त करना और भेजना प्रत्येक ग्राहक (जिसे एक आधिकारिक सर्वर के रूप में जाना जाता है) शायद ही कभी किसी महत्वपूर्ण उपयोगकर्ता के लिए व्यावहारिक होता है। तो, फिलाओस्कोपी लगता है कि आप अन्य खिलाड़ियों को प्रभावित किए बिना खिलाड़ी को कितना तर्क दे सकते हैं। दूसरे शब्दों में, आपको और केवल आपको (लुटने के अलावा) क्या प्रभावित करता है, ग्राहक द्वारा नियंत्रित किया जा सकता है। जबकि जो भी कई खिलाड़ियों को प्रभावित करता है उसे सर्वर द्वारा नियंत्रित किया जाना चाहिए। या, यदि संभाला नहीं गया है, तो कम से कम किसी भी प्रभाव क्षेत्र से पहले अधिकृत है।