कैसे ECS, C # जॉब सिस्टम, और SRP चेंज आर्किटेक्चर

हम लंबे समय से एकता के साथ काम कर रहे हैं और मदद नहीं कर सकते थे लेकिन अपने लोगों को Pixonic DevGAMM वार्ता में आमंत्रित कर सकते थे, जो सितंबर में थी। फील्ड इंजीनियर वैलेन्टिन सिमोनोव ने बताया कि नई प्रौद्योगिकियों के फायदे को ध्यान में रखते हुए खेलों की वास्तुकला की योजना कैसे बनाई जाए। एकता पिछले कई वर्षों से उन पर काम कर रही है जो पहले अप्राप्य स्तर के प्रदर्शन को प्राप्त करने के लिए हैं। आप YouTube पर प्रस्तुति सुन सकते हैं, और कट के नीचे स्लाइड के साथ प्रतिलेख पढ़ सकते हैं।


क्या होगा यदि मैं कहता हूं कि आप अपने खेल की उत्पादकता को 10 गुना बढ़ा सकते हैं? वास्तव में, यह पूरी तरह से सच नहीं है, लेकिन हर मजाक में कुछ सच्चाई है। मैं इस बारे में बात करना चाहता हूं कि हम अभी क्या काम कर रहे हैं, एकता का भविष्य क्या होगा और अब आप इसका क्या उपयोग कर सकते हैं।

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



और हम एक ऐसी परियोजना पर काम कर रहे हैं जिसे हम डिफ़ॉल्ट रूप से प्रदर्शन कहते हैं। ये कुछ विशेष विशेषताएं हैं, जिनका यदि ठीक से उपयोग किया जाए, तो एक महत्वपूर्ण प्रदर्शन को बढ़ावा मिलेगा। कुछ कार्यों में, हमने x10 और यहां तक ​​कि x11 को भी मापा। विशेष रूप से बड़ी संख्या में वस्तुओं को अनुकरण करने की समस्याओं में जो एक दूसरे के साथ बातचीत करते हैं।

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

एक लोकप्रिय सवाल: “आप अपने ईसीएस में क्या कर रहे हैं? आप सभी GameObject को हटा दें, सभी Transform, पदानुक्रम और घटकों को हटा दें? " नहीं, हम सब इसे छोड़ देते हैं। आप यूनिटी के साथ ठीक उसी तरह काम कर सकते हैं जैसा अभी है, लेकिन यदि आप अधिक प्रदर्शन चाहते हैं, तो आपको उन तकनीकों के बारे में जानना होगा जो मैं संक्षेप में बात करना चाहता हूं।

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


और जिन नई सुविधाओं के बारे में मैं बात करना चाहता हूं वे हैं: एंटिटी कंपोनेंट सिस्टम (ईसीएस), सी # जॉब सिस्टम, हमारे नए बर्स्ट सुपरकंपलर और स्क्रिप्टेबल रेंडर पाइपलाइन (एसआरपी)।



मैं दोहराता हूं: यह आप पर निर्भर करता है कि आप हमारे साथ आगे बढ़ना चाहते हैं, नई तकनीकों को सीखते हैं, या आप ऐसे गेम विकसित करने के लिए ठीक हैं जो अच्छी तरह से पैसा कमाते हैं और बस बने हैं।

यह समझने के लिए कि हम क्या हल करने की कोशिश कर रहे हैं, 2018 में लोहे की स्थिति को समझना महत्वपूर्ण है।



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



मेरे फोन में 8 कोर हैं: 4 मजबूत और 4 कमजोर। और एक आधुनिक फोन एक आधुनिक कंप्यूटर के रूप में तेजी से काम कर सकता है (लेकिन ज़्यादा गरम होने के कारण बहुत लंबा नहीं)। आपको यह भी समझने की आवश्यकता है कि बढ़ते प्रदर्शन न केवल सभी कोर का उपयोग कर रहे हैं, बल्कि एकल-कोर प्रदर्शन का अनुकूलन भी कर रहे हैं।

और अंतिम तस्वीर, जिसे हम हमेशा एक उदाहरण के रूप में देते हैं कि प्रक्रिया प्रदर्शन कैसे बढ़ता है और मेमोरी एक्सेस की गति इतनी नहीं बढ़ती है:



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

आप में से कई लोग एकता में एक समान छवि को देखते हुए घंटों बिताने की संभावना रखते हैं:



यहां आप देख सकते हैं कि बहुमूत्रता है, लेकिन शेष कोर और धागे ज्यादातर व्यस्त नहीं हैं। कुछ किया जा रहा है, लेकिन मैं पूरी तरह से उन पर कब्जा करना चाहूंगा।

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



और हम सभी एकता में वास्तुकला के बारे में जानते हैं: घटक, GameObjects, ट्रांसफॉर्म के पदानुक्रम, सभी कोड, मोनोबीहॉर में सभी डेटा और प्रत्येक घटक इसके डेटा को संसाधित करता है।



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



और प्रोसेसर के संदर्भ में सबसे महत्वपूर्ण बात यह है कि सभी घटक, सभी डेटा मेमोरी में बिखरे हुए हैं, जो प्रोसेसर कैश के उपयोग को तोड़ता है।

अब मैं जल्दी से नई सुविधाओं के माध्यम से जाना चाहता हूं।



मैं इस बात पर ज्यादा ध्यान नहीं दूंगा कि ईसीएस क्या है और यह कैसे काम करता है। मुद्दा यह है कि हमारे पास इकाई है, जो कि खेल में कुछ संस्थाओं की आईडी है - वे घटकों के रूप में डेटा संग्रहीत करते हैं, अर्थात। डेटा केवल, कोई कोड नहीं। और सिस्टम कुछ घटकों के साथ इकाई की प्रक्रिया करते हैं और किसी तरह इस डेटा को बदलते हैं।

हम अपना ईसीएस क्यों कर रहे हैं और यह प्रतियोगियों से बेहतर कैसे होगा? कुछ बिंदु हैं। पहले, काफी आधिकारिक तौर पर नहीं, लेकिन हमें लगता है कि हम अब इंजन करेंगे। यह स्पष्ट है कि हम गेमऑब्जेक्ट से छुटकारा नहीं चाहते हैं, एकता के वर्तमान घटक, पूरी तरह से सबकुछ फेंक देते हैं और सीसीएस स्थापित करते हैं। लेकिन हम एक बेहतर इंजन की ओर बढ़ना चाहते हैं।



हम उच्च प्रदर्शन पर भरोसा कर रहे हैं। बहुत पहले नहीं, माइक एक्टन हमारे साथ शामिल हुए (यदि आप C ++ विकास में हैं, तो आप जानते हैं कि वह डेटा-ओरिएंटेड प्रोग्रामिंग इंजीलवादियों में से एक है)। और हम पूरे सिस्टम को यथासंभव तेज करना चाहते हैं - सी ++ की तुलना में तेज।

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

एकता में डिबगिंग टूल पर काम करना। यानी जबकि ECS मौजूद है, क्योंकि यह GameObjects और घटकों से अलग था, और यह बहुत असुविधाजनक है। हम चीजों को सरल बनाना चाहते हैं।

अब एक डीबगव्यू है जो कुछ इस तरह दिखता है:



यहां आप देख सकते हैं कि आपके पास किस तरह की एंटिटी है, किस सिस्टम को प्रोसेस करने में कितना समय लगता है, कौन से सिस्टम किस कंपोनेंट्स के साथ काम करते हैं और प्रत्येक कंपोनेंट के लिए आप इंस्पेक्टर में देख सकते हैं कि कंपोनेंट्स में हर एंटिटी का कौन सा डेटा है (मैं ध्यान देता हूं कि एपीआई अक्सर बदलता रहता है और कई ट्यूटोरियल पहले से ही पुराने हो सकते हैं)।

इसके अलावा, अगर आपने हमारे नए विकास के बारे में सुना है यूनिटी फॉर स्मॉल थिंग्स (यह एक बहुत ही छोटा रनटाइम है जो आपको तत्काल दूतों के लिए गेम बनाने की अनुमति देता है) - सब कुछ वहां ईसीएस पर भी बनाया गया है।

हाल ही में, ईसीएस के विकास और परिवर्तन का उछाल एक बहुत लोकप्रिय तकनीक है और सभी को इसे जानने की आवश्यकता है।

हमारे पास प्रोग्रामर के लिए एक सम्मेलन है, इसलिए कोड स्लाइड के बिना ऐसा करना मुश्किल है। वहां बहुत कोड है, इसलिए कुछ स्पष्ट करने के लिए किसी तरह के समझदार टुकड़े को बाहर निकालना मुश्किल है।



वास्तव में, मैंने उदाहरण के लिए एक सिस्टम लिया जो C # जॉब सिस्टम के साथ काम करता है (बाद में इसके बारे में अधिक), और हम कोड की मात्रा को कम करने के लिए बहुत कुछ करते हैं, एक सिंटैक्स शूगर जोड़ते हैं।

एक सिस्टम है जो RotationData घटकों के साथ काम करता है और इसे GameObject रूपांतरों की भी आवश्यकता होती है, जो एक विशेष TransformAccessArray द्वारा दर्शाए जाते हैं। और हम जो भी जॉब क्रिएट करते हैं, उसका हर अपडेट, इस जॉब को चलाता है, यह कहीं न कहीं अपडेट होता है, इसे कई ग्रुप्स में विभाजित किया जा सकता है और अलग-अलग थ्रेड पर निष्पादित किया जा सकता है।

परियोजना में कैसे उपयोग करें? अन्य ईसीएस कार्यान्वयन की तरह, आपको यह समझने की आवश्यकता है कि आपको पूरी तरह से अलग तरीके से सोचना होगा (गेमऑब्जेक्ट और ट्रांसफॉर्म के विपरीत)। और इस विचार के लिए अभ्यस्त हो जाओ। यह स्पष्ट है कि आपको परियोजना की शुरुआत से ही शुरुआत करने की आवश्यकता है, क्योंकि मुझे अक्सर "हम खेल बनाया और ईसीएस - कैसे?" पर स्विच करना चाहते हैं जैसे प्रश्न मिलते हैं। समाप्त खेल में, यह करना बहुत मुश्किल है।



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

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



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

हम ईसीएस के साथ बहुत तेजी से संग्रह और एकीकरण भी प्रस्तुत करते हैं। यह ईसीएस और जॉब सिस्टम संरचना बहुत तेज कोड निष्पादन के लिए अनुमति देता है।

उसी समय, हम आपको न केवल इन तकनीकों का उपयोग करने का अवसर देते हैं - हम इन प्रणालियों के साथ स्वयं काम करते हैं और नए एपीआई बनाते हैं ताकि उनका उपयोग नौकरियों में किया जा सके।



हमने भौतिकी के लिए Async Raycasts बनाया, जिसके साथ आप कह सकते हैं कि "मुझे 600 rakecasts चाहिए, किसी दिन यह मेरे लिए कर दीजिए, कृपया।" हम यह सुनिश्चित करने के लिए काम कर रहे हैं कि इन तकनीकों का उपयोग करके, वर्तमान प्रणालियों का विस्तार करना संभव है, उदाहरण के लिए, Play API के माध्यम से एनीमेशन। और हम एकता में नए सिस्टम बनाने के बारे में सोच रहे हैं जो C ++ में बंद नहीं होंगे, और जिनका कोड C # में होगा और आपके लिए उपलब्ध होगा।



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

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



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

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

फिर सब कुछ बहुत सरल है। बर्स्ट कंपाइलर हमारी अनूठी तकनीक है, इस सी # (हाई परफॉर्मेंस सी #) का एक विशेष कंपाइलर वर्तमान प्लेटफॉर्म के मशीन कोड में सबनेट है, जिसे आप अपने प्रोजेक्ट में प्रकाशित करेंगे।



दोस्तों ने कुछ ऐसा जादू किया कि शायद उन्हें समझने वाला कोई नहीं है, लेकिन यह बात 10 बार जॉब कोड को गति देती है, जो सुपर-कूल है। और सबसे अच्छी बात यह है कि इसे आप से किसी भी कार्रवाई की आवश्यकता नहीं है - यदि आपके पास एक जॉब-कोड है, तो आप बस [BurstCompile] विशेषता जोड़ते हैं, बर्स्ट आपके कोड को संकलित करता है, और आपको "फ्री" प्रदर्शन मिलता है। यह हमारी नई तकनीक है और आप इसे अभी आज़मा सकते हैं।



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



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



हम वर्तमान में पाइपलाइनों के दो उदाहरणों पर काम कर रहे हैं। एक LWRP, जिसे हम मोबाइल फोन और कमजोर उपकरणों और HDRP पर लक्षित करते हैं, जिसे हम PC, कंसोल, और जिस पर उद्योग के बहुत प्रसिद्ध लोग काम करते हैं, पर लक्षित करते हैं। इससे पहले, उन्होंने AAA गेम बनाया। निश्चित रूप से, आपने हमारे डेमो बुक ऑफ द डेड को देखा।


यहां हमने इस तकनीक की पूरी शक्ति दिखाने के लिए एचडीआरपी का उपयोग किया।

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



बहुत अच्छा है अगर आप खरोंच से शुरू कर सकते हैं और अपने पाइपलाइन के साथ प्रयोग कर सकते हैं। यदि आप अपनी पाइपलाइन पर कुछ करना चाहते हैं, तो कृपया हमसे संपर्क करें।

फिर से, समझें कि आपको क्या चाहिए, क्योंकि अब आपके पास कुछ करने के लिए अधिक अवसर हैं, लेकिन आपको ऐसे लोगों की आवश्यकता होगी जो इसे कर सकते हैं या आपको यह सीखने की आवश्यकता होगी कि यह कैसे करना है।



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

श्रोताओं से सवाल

- मैं ईसीएस कब प्राप्त कर सकता हूं और इसे विकसित कर सकता हूं?

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

- ईसीएस और बाकी सामान कुछ बेसिक गेमऑबजेक्ट लेने और इसके क्लोन के 150 हजार बनाने और उन्हें प्रबंधित करने पर केंद्रित हैं। लेकिन क्या होगा अगर मेरे पास कुछ वस्तुएं हैं, लेकिन उनके पास अलग-अलग संस्थाएं हैं?

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

- हमारे पास एकता पर एक क्लाइंट है, जो .NET पर एक सर्वर है, हमने एकता पर एक सर्वर की कोशिश की, इसका कुछ भी नहीं आता है। लेकिन साथ ही, मैं उन तकनीकों का उपयोग करना चाहता हूं जो सर्वर पर भी एकता में हैं।

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

Pixonic DevGAMM वार्ता के साथ अधिक वार्ता

• कंसूल का उपयोग राज्य स्तरीय सेवाओं (इवान बुबनोव, BIT.GAMES में DevOps) के लिए;
• CICD: डाउनटाइम (Egor Panov, Pixonic सिस्टम एडमिनिस्ट्रेटर) के बिना वितरित क्लस्टर सिस्टमों में निर्बाध तैनाती ;
• क्वेक चैंपियंस गेम के बैकएंड प्लेटफ़ॉर्म में अभिनेता मॉडल का उपयोग करने की प्रथा (रोमन रोजोज़िन, बैकएंड डेवलपर कृपाण इंटरएक्टिव);
• टैक्टिकूल मोबाइल ऑनलाइन शूटर मेटा सर्वर आर्किटेक्चर (पावेल प्लाटो, पैंजरडॉग में लीड सॉफ्टवेयर इंजीनियर);
• के विकास में KISS सिद्धांत (Konstantin Gladyshev, लीड खेल 1C खेल स्टूडियो में प्रोग्रामर);
• क्लाइंट और सर्वर पर सामान्य गेम लॉजिक (एंटोन ग्रिगोरिव, पिक्सेल में उप तकनीकी अधिकारी)।
• क्लाउड में ककड़ी: उत्पाद तनाव परीक्षण के लिए बीडीडी लिपियों का उपयोग करना (एंटोन कोसयाकिन, एलिस प्लेटफॉर्म पर तकनीकी उत्पाद प्रबंधक)।