यूनिटी 3 डी: गेम आर्किटेक्चर, स्क्रिप्टेबल ओब्जेक्ट्स, सिंगलेटोन्स

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

यह लेख एक लंबे और दर्दनाक तरीके से एक खेल को विकसित करने के तरीके का वर्णन करता है, इस प्रक्रिया में उपयोग किए जाने वाले विभिन्न दृष्टिकोण। सबसे अधिक संभावना है, शुरुआती लोगों के लिए बहुत उपयोगी जानकारी होगी और "दिग्गजों" के लिए कुछ भी नया नहीं होगा।

स्क्रिप्ट और ऑब्जेक्ट्स के बीच लिंक

पहला सवाल जो एक नौसिखिए डेवलपर का सामना करता है वह यह है कि सभी लिखित वर्गों को एक साथ कैसे जोड़ा जाए और उन दोनों के बीच बातचीत को कॉन्फ़िगर किया जाए।

सबसे आसान तरीका सीधे कक्षा के लिए एक लिंक निर्दिष्ट करना है:

public class MyScript : MonoBehaviour { public OtherScript otherScript; } 

और फिर - इंस्पेक्टर के माध्यम से स्क्रिप्ट को मैन्युअल रूप से बांधें।

इस दृष्टिकोण में कम से कम एक महत्वपूर्ण कमी है - जब स्क्रिप्ट की संख्या कई दसियों से अधिक हो जाती है, और उनमें से प्रत्येक को एक दूसरे से दो या तीन लिंक की आवश्यकता होती है, खेल जल्दी से एक वेब में बदल जाता है। उसकी एक नज़र सिरदर्द का कारण बनने के लिए पर्याप्त है।

संदेशों और सदस्यता की एक प्रणाली को व्यवस्थित करने के लिए (मेरी राय में) यह बहुत बेहतर है, जिसके अंदर हमारी वस्तुओं को उनकी आवश्यकता की जानकारी प्राप्त होगी - और केवल वही! - एक दूसरे को आधा दर्जन लिंक की आवश्यकता के बिना।

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

स्क्रिप्ट योग्य

ScriptableObject के बारे में जानने के लिए मूल रूप से दो बातें हैं:

• वे MonoBehaviour की तरह एकता के अंदर कार्यान्वित कार्यक्षमता का हिस्सा हैं।
• MonoBehaviour के विपरीत, वे दृश्य वस्तुओं से बंधे नहीं हैं, लेकिन अलग-अलग संपत्ति के रूप में मौजूद हैं और खेल सत्रों के लिए डेटा संग्रहीत और स्थानांतरित करने में सक्षम हैं ।

मैं तुरंत उनके गर्म प्यार में पड़ गया। वे, एक तरह से, किसी भी समस्या के लिए मेरी रामबाण दवा बन चुके हैं:

• खेल सेटिंग्स को स्टोर करने की आवश्यकता है? स्क्रिप्ट योग्य!
• एक इन्वेंट्री बनाएं? स्क्रिप्ट योग्य!
• ऐ लिखो? स्क्रिप्ट योग्य!
• एक चरित्र, दुश्मन, आइटम के बारे में जानकारी रिकॉर्ड करें? ScriptableObject आपको कभी निराश नहीं करेगा!

दो बार सोचने के बिना, मैंने कई प्रकार के ScriptableObject को बनाया, और फिर उनके लिए एक रिपॉजिटरी:

 public class Database: ScriptableObject { public PlayerData playerData; public GameSettings gameSettings; public SpellController spellController; } 

जिनमें से प्रत्येक अपने आप में सभी उपयोगी जानकारी संग्रहीत करता है और संभवतः, अन्य वस्तुओं से लिंक करता है। उनमें से प्रत्येक निरीक्षक के माध्यम से एक बार बांधने के लिए पर्याप्त है - वे कहीं और नहीं जाएंगे।

अब मुझे स्क्रिप्ट्स के बीच अनंत संख्याओं को निर्दिष्ट करने की आवश्यकता नहीं है! प्रत्येक स्क्रिप्ट के लिए, मैं एक बार अपनी रिपॉजिटरी के लिए एक लिंक निर्दिष्ट कर सकता हूं - और यह वहां से सभी जानकारी प्राप्त करेगा।

इस प्रकार, चरित्र की गति की गणना बहुत ही सुंदर लगती है:

 //   float speed = database.playerData.speed; //    if (database.spellController.haste.active) speed = speed * database.spellController.haste.speedModifier; // ,     if (database.playerData.health<database.playerData.healthThreshold) speed = speed * database.playerData.woundedModifier; 

और अगर कहते हैं, एक जाल केवल एक चल चरित्र पर आग चाहिए:

 if (database.playerData.isSprinting) Activate(); 

इसके अलावा, वर्ण को मंत्र या जाल के बारे में कुछ भी जानने की आवश्यकता नहीं है। यह सिर्फ स्टोरेज से डेटा रिकवर करता है। बुरा नहीं है? बुरा नहीं है।

लेकिन लगभग तुरंत ही मैं एक समस्या में चला गया। ScriptableOnjects दृश्य वस्तुओं के लिंक को सीधे स्टोर नहीं कर सकते हैं। दूसरे शब्दों में, मैं खिलाड़ी के लिए लिंक नहीं बना सकता, इसे इंस्पेक्टर के माध्यम से बाँध सकता हूँ और खिलाड़ी के निर्देशांक के सवाल को हमेशा के लिए भूल सकता हूँ।

और अगर आप इसके बारे में सोचते हैं, तो यह समझ में आता है! एसेट्स ऑफ-स्टेज मौजूद हैं और इन्हें किसी भी दृश्य में एक्सेस किया जा सकता है। और अगर आप संपत्ति के अंदर किसी अन्य दृश्य में स्थित वस्तु का लिंक छोड़ते हैं तो क्या होता है?

कुछ भी अच्छा नहीं।

एक लंबे समय के लिए, एक बैसाखी ने मेरे लिए काम किया: एक सार्वजनिक लिंक रिपॉजिटरी में बनाया गया है, और फिर प्रत्येक ऑब्जेक्ट, जिस लिंक को आप याद रखना चाहते हैं, इस लिंक को भरा:

 public class PlayerController : MonoBehaviour { void Awake() { database.playerData.player = this.gameObject; } } 

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

 public Database database; Vector3 destination; void Update () { destination = database.playerData.player.transform.position; } 

यह प्रतीत होता है: प्रणाली एकदम सही है! लेकिन नहीं। हमें अभी भी 2 समस्याएं हैं।

1. मुझे अभी भी प्रत्येक स्क्रिप्ट के लिए रिपॉजिटरी का लिंक मैन्युअल रूप से निर्दिष्ट करना होगा।
2. किसी ScriptableObject के अंदर दृश्य वस्तुओं के संदर्भ निर्दिष्ट करना अजीब है।

अधिक विस्तार से दूसरे के बारे में। मान लीजिए किसी खिलाड़ी के पास एक हल्का स्पेल है। खिलाड़ी इसे कास्ट करता है, और गेम स्टोर को कहता है: लाइट डाली गई है!

 database.spellController.light.CastSpell(); 

और यह प्रतिक्रियाओं की एक श्रृंखला को जन्म देता है:

• कर्सर बिंदु पर एक नया (या पुराना) गेमबजेक्ट लाइट बनाया गया है।
• एक GUI मॉड्यूल लॉन्च किया गया है, जो हमें बता रहा है कि प्रकाश सक्रिय है।
• दुश्मन, एक खिलाड़ी को खोजने के लिए एक अस्थायी बोनस मिलता है।

यह सब कैसे करें?

यह प्रकाश में रुचि रखने वाली प्रत्येक वस्तु के लिए संभव है, सीधे अपडेट () और लिखें, वे कहते हैं, इस तरह और वह, प्रत्येक फ्रेम प्रकाश का अनुसरण करता है (यदि (database.spellController.light.isActive)), और जब वह रोशनी करता है - प्रतिक्रिया! और इस बात की परवाह न करें कि इस चेक का 90% समय बेकार चलेगा। कई सौ वस्तुओं पर।

या तैयार लिंक के रूप में यह सब व्यवस्थित करें। यह पता चला है कि साधारण कास्टसेल () फ़ंक्शन को खिलाड़ी के लिंक तक, प्रकाश तक और दुश्मनों की सूची तक पहुंच होनी चाहिए। और यह सबसे अच्छा है। बहुत सारे लिंक, हुह?

आप निश्चित रूप से, दृश्य के शुरू होने पर हमारी रिपॉजिटरी में महत्वपूर्ण सभी चीजों को बचा सकते हैं, परिसंपत्तियों पर लिंक को तितर बितर कर सकते हैं, जो सामान्य रूप से, इसके लिए अभिप्रेत नहीं हैं ... लेकिन फिर, मैं एक एकल रिपॉजिटरी के सिद्धांत का उल्लंघन करता हूं, इसे लिंक के एक वेब में बदल देता हूं।

एकाकी वस्तु

यह वह जगह है जहाँ सिंगलटन खेल में आता है। वास्तव में, यह एक ऐसी वस्तु है जो केवल मौजूद है (और मौजूद हो सकती है)।

 public class GameController : MonoBehaviour { public static GameController Instance; //   ,      public Database database; public GameObject player; public GameObject GUI; public List<Enemy> enemies; public List<Spell> spells; void Awake () { if (Instance == null) { DontDestroyOnLoad (gameObject); Instance = this; } else if (Instance != this) { Destroy (gameObject); } } } 

मैं इसे एक खाली दृश्य वस्तु पर स्नैप करता हूं। चलो इसे GameController कहते हैं।

इस प्रकार, मेरे पास दृश्य में एक ऑब्जेक्ट है जो गेम के बारे में सभी जानकारी संग्रहीत करता है । इसके अलावा, यह दृश्यों के बीच स्थानांतरित कर सकता है, इसके डबल्स को नष्ट कर सकता है (यदि नए दृश्य पर पहले से ही कोई अन्य गेमकंट्रोलर है), दृश्यों के बीच डेटा स्थानांतरित करें, और, यदि वांछित है, तो गेम को बचाने / लोड लागू करें।

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

हमें क्या मिलता है?

किसी भी वस्तु को उस खेल के बारे में कोई भी जानकारी मिल सकती है जिसकी उसे आवश्यकता है:

 if (GameController.Instance.database.playerData.isSprinting) ActivateTrap(); 

इस मामले में, वस्तुओं के बीच लिंक को कॉन्फ़िगर करने की बिल्कुल आवश्यकता नहीं है, सब कुछ हमारे गेमकंट्रोलर में संग्रहीत है।

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

खतरे

यदि आप इस बिंदु तक पढ़ते हैं, तो मुझे आपको इस दृष्टिकोण के खतरों के बारे में चेतावनी देनी चाहिए।

बहुत बुरी स्थिति तब होती है जब कई स्क्रिप्ट्स हमारे ScriptableObject के अंदर एक वैरिएबल का संदर्भ देती हैं। मूल्य पाने में कुछ भी गलत नहीं है, लेकिन जब वे विभिन्न स्थानों से एक चर को प्रभावित करना शुरू करते हैं, तो यह एक संभावित खतरा है।

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

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

इसके अलावा, यह मत भूलो कि सिंगलनेट कोमल प्राणी हैं। उन्हें गाली मत दो।

आज के लिए बस इतना ही।

आधिकारिक यूनिटी ट्यूटोरियल से अनधिकृत लोगों में से कुछ को चमकाया गया है। मुझे खुद कुछ हासिल करना था। इसलिए, उपरोक्त दृष्टिकोणों में उनके खतरे और नुकसान हो सकते हैं, जो मुझे याद आया।

और इसलिए - चर्चा का स्वागत है!