Svelto.ECS परियोजना विकि का अनुवाद। यूनिटी 3 डी के लिए ईसीएस फ्रेमवर्क

नमस्कार, हेब्र! मैं आपके लिए सेबेस्टियानो मंडला द्वारा लिखित Svelto.ECS परियोजना के विकी का अनुवाद प्रस्तुत करता हूं।

Svelto.ECS एकता पर खेलों के विकास में कई वर्षों के शोध और SOLID सिद्धांतों के अनुप्रयोग का परिणाम है। यह पैटर्न की कमियों को दूर करने के लिए शुरू की गई विभिन्न विशिष्ट विशेषताओं के साथ C # के लिए उपलब्ध ECS पैटर्न के कई कार्यान्वयनों में से एक है।

पहले देखो

वनीला उदाहरण डाउनलोड करने के लिए Svelto.ECS की बुनियादी विशेषताओं को देखने का सबसे आसान तरीका है। यदि आप इसका उपयोग आसानी से सुनिश्चित करना चाहते हैं, तो मैं आपको एक उदाहरण दिखाऊंगा:

//  void ApplicationCompositionRoot() { var simpleSubmissionEntityViewScheduler = new SimpleSubmissionEntityViewScheduler(); _enginesRoot = new EnginesRoot(simpleSubmissionEntityViewScheduler); var entityFactory = _enginesRoot.GenerateEntityFactory(); var entityFunctions = _enginesRoot.GenerateEntityFunctions(); _enginesRoot.AddEngine(new BehaviourForSimpleEntityEngine(entityFunctions)); entityFactory.BuildEntity<SimpleEntityDescriptor>(new EGID(1), new[] { new SimpleImplementor() });` } //  class SimpleEntityDescriptor : GenericEntityDescriptor<BehaviourEntityViewForSimpleEntity> { } public class BehaviourEntityViewForSimpleEntity : EntityView { public ISimpleComponent simpleComponent; } public interface ISimpleComponent { public int counter {get; set;} } class SimpleImplementor : ISimpleComponent { public int counter { get; set; } } //  ()    public class BehaviourForSimpleEntityAsStructEngine : IQueryingEntityViewEngine { public IEntityViewsDB entityViewsDB { private get; set; } public void Ready() { Update().Run(); } //   . //    N ,  N    0  1. IEnumerator Update() { Console.Log("Task Waiting"); while (true) { var entityViews = entityViewsDB .QueryGroupedEntityViews<BehaviourEntityViewForSimpleEntity>(0); if (entityViews.Length> 0) { for (var i = 0; i < entityViews.Length; i++) AddOne(entityViews[i].counter); Console.Log("Task Done"); yield break; } yield return null; } } static void AddOne(int counter) { counter += 1; } } 

दुर्भाग्य से, इस कोड के पीछे के सिद्धांत को जल्दी से समझना संभव नहीं है, जो एक ही समय में सरल लेकिन भ्रमित लग सकता है। इसे समझने के लिए, आपको "पाठ की दीवार" पढ़ने में समय बिताना होगा और उपरोक्त उदाहरणों को आज़माना होगा।

परिचय

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

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

मैं इस लेख में अंतर्निहित सिद्धांतों के बारे में ज्यादा बात नहीं करने जा रहा हूं। मैं आपको केवल यह याद दिलाता हूं कि मैंने IoC कंटेनर का उपयोग करने से इनकार क्यों किया और विशेष रूप से ECS ढांचे का उपयोग करना शुरू कर दिया: IoC कंटेनर एक बहुत ही खतरनाक उपकरण है यदि इसका उपयोग नियंत्रण उलटा के बहुत सार को समझे बिना किया जाता है। जैसा कि आप अपने पिछले लेखों से देख सकते हैं, मैं निर्माण नियंत्रण के व्युत्क्रम (क्रिएशन कंट्रोल का उलटा) और प्रवाह नियंत्रण के व्युत्क्रम (फ्लो कंट्रोल का उलटा) के बीच अंतर करता हूं। प्रवाह को नियंत्रित करना हॉलीवुड के सिद्धांत की तरह है: "हमें कॉल मत करो, हम आपको कॉल करेंगे।" इसका मतलब यह है कि इंजेक्शन की निर्भरता को कभी भी सार्वजनिक तरीकों के माध्यम से सीधे उपयोग नहीं किया जाना चाहिए, क्योंकि ऐसा करने में आप केवल IoC कंटेनर को ग्लोबल इंजेक्शन के किसी अन्य रूप, जैसे सिंगलटन के विकल्प के रूप में उपयोग करते हैं। हालाँकि, यदि IoC कंटेनर का उपयोग Inversion of Management (IoC) के आधार पर किया जाता है, तो मूल रूप से यह सभी उन प्रबंधकों को शुरू करने के लिए "टेम्पलेट विधि" पैटर्न का पुन: उपयोग करने के लिए नीचे आता है, जिनका उपयोग केवल उन वस्तुओं को पंजीकृत करने के लिए किया जाता है जिन्हें वे प्रबंधित करते हैं। प्रवाह नियंत्रण आक्रमण के वास्तविक संदर्भ में, प्रबंधक हमेशा संस्थाओं के प्रबंधन के लिए जिम्मेदार होते हैं। क्या यह ईसीएस पैटर्न जैसा दिखता है? बेशक। इस तर्क के आधार पर, मैंने ईसीएस पैटर्न लिया और इसके आधार पर एक कठोर रूपरेखा विकसित की, और इसका उपयोग नए प्रोग्रामिंग प्रतिमान को लागू करने के लिए समान है।

रचना रूट और इंजन

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

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

EnginesRoot वर्ग Svelto.ECS का मूल है। इसकी मदद से, आप इंजन को पंजीकृत कर सकते हैं और खेल के सभी सार को डिजाइन कर सकते हैं। इंजनों को गतिशील रूप से बनाने का कोई मतलब नहीं होता है, इसलिए इन सभी को इंजन के उसी रूट से EnginesRoot उदाहरण में जोड़ा जाना चाहिए जहां इसे बनाया गया था। इसी तरह के कारणों के लिए, एक EnginesRoot उदाहरण को कभी भी तैनात नहीं किया जाना चाहिए, और इंजनों को हटाने के बाद उन्हें जोड़ा नहीं जाना चाहिए।

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

 void SetupEnginesAndEntities() { //Engines Root   Svelto.ECS.      EngineRoot // ,  Composition Root     ,   //   . //UnitySumbmissionEntityViewScheduler -  ,   //EnginesRoot,     EntityViews. //    ,   , //         Unity. _enginesRoot = new EnginesRoot(new UnitySumbmissionEntityViewScheduler()); //Engines root      ,   , //   . //   EntityFactory  EntityFunctions. //EntityFactory      //(    ), //   . _entityFactory = _enginesRoot.GenerateEntityFactory(); // EntityFunctions     //   , //  .        var entityFunctions = _enginesRoot.GenerateEntityFunctions(); //GameObjectFactory   Unity GameObject //   // GameObject.Instantiate.      // ,    ,   //       //(  ,   //         //      -  ) GameObjectFactory factory = new GameObjectFactory(); //    3     Svelto.ECS. //        //  . //         //     . var enemyKilledObservable = new EnemyKilledObservable(); var scoreOnEnemyKilledObserver = new ScoreOnEnemyKilledObserver(enemyKilledObservable); //ISequencer   3     Svelto.ECS // .       : //1)       //(   //,   ,     //  ). //2)   ,     // . ISequencer      //  Sequencer playerDamageSequence = new Sequencer(); Sequencer enemyDamageSequence = new Sequencer(); //    Unity. //     . IRayCaster rayCaster = new RayCaster(); ITime time = new Others.Time(); // .         //  . var playerHealthEngine = new HealthEngine(entityFunctions, playerDamageSequence); var playerShootingEngine = new PlayerGunShootingEngine(enemyKilledObservable, enemyDamageSequence, rayCaster, time); var playerMovementEngine = new PlayerMovementEngine(rayCaster, time); var playerAnimationEngine = new PlayerAnimationEngine(); //  var enemyAnimationEngine = new EnemyAnimationEngine(); var enemyHealthEngine = new HealthEngine(entityFunctions, enemyDamageSequence); var enemyAttackEngine = new EnemyAttackEngine(playerDamageSequence, time); var enemyMovementEngine = new EnemyMovementEngine(); var enemySpawnerEngine = new EnemySpawnerEngine(factory, _entityFactory); //    var hudEngine = new HUDEngine(time); var damageSoundEngine = new DamageSoundEngine(); // Sequencer  ,    // ,     . playerDamageSequence.SetSequence( new Steps // ,  ! { { //  //      Next   enemyAttackEngine, new To //        { //      //   Next playerHealthEngine, } }, { //  playerHealthEngine, //      Next   new To //       { //      Next     //DamageCondition.damage { DamageCondition.damage, new IStep[] { hudEngine, damageSoundEngine } }, //      Next     //DamageCondition.dead { DamageCondition.dead, new IStep[] { hudEngine, damageSoundEngine, playerMovementEngine, playerAnimationEngine, enemyAnimationEngine } }, } } }); enemyDamageSequence.SetSequence( new Steps { { playerShootingEngine, new To { enemyHealthEngine, } }, { enemyHealthEngine, new To { { DamageCondition.damage, new IStep[] { enemyAnimationEngine, damageSoundEngine } }, { DamageCondition.dead, new IStep[] { enemyMovementEngine, enemyAnimationEngine, playerShootingEngine, enemySpawnerEngine, damageSoundEngine } }, } } }); // ,     //  _enginesRoot.AddEngine(playerMovementEngine); _enginesRoot.AddEngine(playerAnimationEngine); _enginesRoot.AddEngine(playerShootingEngine); _enginesRoot.AddEngine(playerHealthEngine); _enginesRoot.AddEngine(new PlayerInputEngine()); _enginesRoot.AddEngine(new PlayerGunShootingFXsEngine()); //  _enginesRoot.AddEngine(enemySpawnerEngine); _enginesRoot.AddEngine(enemyAttackEngine); _enginesRoot.AddEngine(enemyMovementEngine); _enginesRoot.AddEngine(enemyAnimationEngine); _enginesRoot.AddEngine(enemyHealthEngine); //  _enginesRoot.AddEngine(new CameraFollowTargetEngine(time)); _enginesRoot.AddEngine(damageSoundEngine); _enginesRoot.AddEngine(hudEngine); _enginesRoot.AddEngine(new ScoreEngine(scoreOnEnemyKilledObserver)); 

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

तथ्य

रचना की खाली जड़ और EnginesRoot क्लास का एक उदाहरण बनाने के बाद पहला कदम उन वस्तुओं की पहचान करना है जिन्हें आप पहले काम करना चाहते हैं। एंटिटी प्लेयर के साथ शुरू करना तर्कसंगत है। Svelto.ECS का सार एकता गेम ऑब्जेक्ट (गेमऑब्जेक्ट) के साथ भ्रमित नहीं होना चाहिए। यदि आप ईसीएस से संबंधित अन्य लेख पढ़ते हैं, तो आप देख सकते हैं कि उनमें से कई में, संस्थाओं को अक्सर अनुक्रमित के रूप में वर्णित किया जाता है। यह संभवतः ईसीएस अवधारणा को पेश करने का सबसे खराब तरीका है। हालांकि Svelto.ECS के लिए सही है, यह इसमें छिपा हुआ है। मैं चाहता हूं कि Svelto.ECS उपयोगकर्ता गेम डिज़ाइन डोमेन भाषा के संदर्भ में प्रत्येक इकाई का प्रतिनिधित्व, वर्णन और पहचान करे। कोड में इकाई को गेम के डिज़ाइन दस्तावेज़ में वर्णित ऑब्जेक्ट होना चाहिए। इकाई परिभाषा का कोई अन्य रूप Svelto.ECS सिद्धांतों के लिए अपने पुराने विचारों को अपनाने का एक दूरगामी तरीका होगा। इस मूलभूत नियम का पालन करें और आप गलत नहीं होंगे। इकाई वर्ग स्वयं कोड में मौजूद नहीं है, लेकिन आपको अभी भी इसे संक्षेप में परिभाषित नहीं करना चाहिए।

इंजन

अगला कदम यह सोचना है कि एंटिटीज से क्या व्यवहार करना है। प्रत्येक व्यवहार को हमेशा इंजन के अंदर रखा जाता है; आप Svelto.ECS एप्लिकेशन के अंदर किसी अन्य वर्ग में तर्क नहीं जोड़ सकते। हम खिलाड़ी के चरित्र को आगे बढ़ाकर शुरू कर सकते हैं और PlayerMovementEngine वर्ग को परिभाषित कर सकते हैं । इंजन का नाम बहुत संकीर्ण रूप से केंद्रित होना चाहिए, क्योंकि यह जितना अधिक विशिष्ट है, उतनी ही अधिक संभावना है कि इंजन एकल जिम्मेदारी नियम का पालन करेगा। Svelto.ECS में उचित वर्ग का नामकरण मौलिक है। और लक्ष्य न केवल अपने इरादों को स्पष्ट रूप से दिखाने के लिए है, बल्कि आपको स्वयं उन्हें "देखने" में मदद करने के लिए भी है।

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

Svelto.ECS में, एब्स्ट्रैक्शन कुछ लाइनों को आगे बढ़ाता है, लेकिन ईसीएस अनिवार्य रूप से डेटा को प्रोसेस करने वाले लॉजिक से एब्सट्रैक्ट करने में मदद करता है। प्रविष्टियां उनके डेटा द्वारा निर्धारित की जाती हैं, न कि उनके व्यवहार से। इस मामले में, इंजन एक ऐसी जगह है जहां आप समान संस्थाओं के संयुक्त व्यवहार को रख सकते हैं ताकि इंजन हमेशा संस्थाओं के एक सेट के साथ काम कर सकें।

Svelto.ECS और ECS प्रतिमान शुद्ध एनकोडर को शुद्ध प्रोग्रामिंग में से एक को प्राप्त करने की अनुमति देते हैं, जो तर्क का आदर्श आवरण है। इंजन में सार्वजनिक कार्य नहीं होने चाहिए। एकमात्र सार्वजनिक कार्य जो मौजूद होना चाहिए, वे हैं जो ढांचे के इंटरफेस को लागू करने के लिए आवश्यक हैं। यह निर्भरता इंजेक्शन को भूल जाता है और खराब कोड से बचने में मदद करता है जो नियंत्रण उलटा के बिना निर्भरता इंजेक्शन का उपयोग करते समय होता है। इंजन को किसी अन्य इंजन या किसी अन्य प्रकार के वर्ग में एम्बेड किया जाना चाहिए। यदि आपको लगता है कि आप इंजन को लागू करना चाहते हैं, तो आप बस कोड डिज़ाइन में एक मौलिक गलती करते हैं।

यूनिटी मोनोबेवियर की तुलना में, इंजन पहले से ही बहुत बड़ा फायदा दिखाते हैं, जो कोड के एक ही क्षेत्र से इस प्रकार के सभी राज्यों की संस्थाओं तक पहुंचने की क्षमता है। इसका मतलब यह है कि कोड आसानी से सभी वस्तुओं के राज्य का उपयोग उसी स्थान से सीधे कर सकता है जहां सामान्य ऑब्जेक्ट के तर्क को निष्पादित किया जाएगा। इसके अलावा, व्यक्तिगत इंजन समान वस्तुओं को संसाधित कर सकते हैं ताकि इंजन वस्तु की स्थिति को बदल सके, जबकि दूसरा इंजन इसे पढ़ सकता है, प्रभावी ढंग से एक ही इकाई डेटा के माध्यम से संचार के लिए दो इंजनों का उपयोग कर सकता है। एक उदाहरण PlayerGunSourcingEngine और PlayerGunSourcingFxsEngine इंजन को देखकर देखा जा सकता है। इस स्थिति में, दो इंजन एक ही नाम स्थान पर हैं, इसलिए वे एक ही इकाई डेटा साझा कर सकते हैं। अगर कोई खिलाड़ी (शत्रु) क्षतिग्रस्त हो गया है, तो PlayerGunSourcingEngine निर्धारित करता है, और IGunAttributesComponent घटक (जो कि एक PlayerGunEntity घटक है) के lastTargetPosition मान लिखता है। PlayerGunShootFxsEngine हथियार के ग्राफिक प्रभाव को संसाधित करता है और खिलाड़ी द्वारा चयनित लक्ष्य की स्थिति को पढ़ता है। यह डेटा पोलिंग के माध्यम से इंजनों के बीच बातचीत का एक उदाहरण है। बाद में इस लेख में मैं दिखाऊंगा कि कैसे डेटा (डेटा पुश) या डेटा बाइंडिंग (डेटा बाइंडिंग) द्वारा एक तंत्र को उनके बीच संवाद करने की अनुमति दी जाए। तार्किक रूप से, इंजन को कभी भी स्टोर नहीं करना चाहिए।

इंजनों को यह जानने की आवश्यकता नहीं है कि अन्य इंजनों के साथ कैसे बातचीत करें। बाह्य संचार अमूर्तता के माध्यम से होता है, और Svelto.ECS इंजन के बीच के संबंध को तीन अलग-अलग आधिकारिक तरीकों से हल करता है, लेकिन मैं इस बारे में बाद में बात करूंगा। सबसे अच्छे इंजन वे हैं जिन्हें किसी बाहरी संचार की आवश्यकता नहीं है। ये इंजन अच्छी तरह से समझाया व्यवहार को दर्शाते हैं और आमतौर पर एक तार्किक लूप के माध्यम से काम करते हैं। लूप हमेशा Svelto.ECS अनुप्रयोगों के अंदर Svelto.Task कार्यों का उपयोग करके मॉडलिंग की जाती है। चूंकि खिलाड़ी के मूवमेंट को हर फिजिकल टिक को अपडेट करने की जरूरत होती है, इसलिए हर फिजिकल टिक पर टास्क करना स्वाभाविक होगा। Svelto.Tasks आपको कई प्रकार के शेड्यूलर्स पर प्रत्येक प्रकार के IEnumerator को चलाने की अनुमति देता है। इस मामले में, हमने PhysicScheduler पर एक कार्य बनाने का निर्णय लिया, जो आपको खिलाड़ी की स्थिति को अपडेट करने की अनुमति देता है:

 public PlayerMovementEngine(IRayCaster raycaster, ITime time) { _rayCaster = raycaster; _time = time; _taskRoutine = TaskRunner.Instance.AllocateNewTaskRoutine() .SetEnumerator(PhysicsTick()).SetScheduler(StandardSchedulers.physicScheduler); } protected override void Add(PlayerEntityView entityView) { _taskRoutine.Start(); } protected override void Remove(PlayerEntityView entityView) { _taskRoutine.Stop(); } IEnumerator PhysicsTick() { // ,      //  EnginesRoot    . // ,         . var _playerEntityViews = entityViewsDB.QueryEntityViews<PlayerEntityView>(); var playerEntityView = _playerEntityViews[0]; while (true) { Movement(playerEntityView); Turning(playerEntityView); //   yield,     ! yield return null; } } 

Svelto.T कार्यों को सीधे या ITaskRoutine ऑब्जेक्ट के माध्यम से किया जा सकता है। मैं यहाँ Svelto.Tasks के बारे में ज्यादा बात नहीं करूँगा, क्योंकि मैंने इसके लिए अन्य लेख लिखे हैं। IEnumerator कार्यान्वयन को सीधे शुरू करने के बजाय मैंने टास्क रूटीन का उपयोग करने का जो निर्णय लिया, वह काफी विवेकाधीन है। मैं यह दिखाना चाहता था कि जब खिलाड़ी के ऑब्जेक्ट को इंजन में जोड़ा जाता है और इसे हटा दिया जाता है, तो आप एक चक्र शुरू कर सकते हैं।हालाँकि, इसके लिए आपको यह जानना होगा कि कोई ऑब्जेक्ट कब जोड़ा और डिलीट किया गया है।

Svelto.ECS कुछ संस्थाओं को जोड़ने या हटाने के बारे में जानने के लिए कॉलबैक को जोड़ता और हटाता है। यह Svelto.ECS में कुछ अद्वितीय है, लेकिन इस दृष्टिकोण का बुद्धिमानी से उपयोग किया जाना चाहिए। मैंने अक्सर देखा कि इन कॉलबैक का दुरुपयोग किया जा रहा है, क्योंकि कई मामलों में वे संस्थाओं को क्वेरी करने के लिए पर्याप्त हैं। यहां तक ​​कि एक इंजन क्षेत्र के रूप में एक इकाई संदर्भ को एक नियम की तुलना में अधिक अपवाद माना जाना चाहिए।

केवल जब इन कॉलबैक का उपयोग किया जाना है, तो इंजन को सिंगलटेंट व्यू व्यूइन्गाइन या मल्टीएंटिटीज व्यूइंजीन <EntityView1, ..., EntityViewN> से विरासत में मिला होना चाहिए।। फिर से, इस डेटा का उपयोग दुर्लभ होना चाहिए, और वे किसी भी तरह से रिपोर्ट करने का इरादा नहीं रखते हैं कि इंजन किन वस्तुओं को संसाधित करेगा।

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

 public void Ready() { Tick().Run(); } IEnumerator Tick() { while (true) { var enemyTargetEntityViews = entityViewsDB.QueryEntityViews<EnemyTargetEntityView>(); if (enemyTargetEntityViews.Count > 0) { var targetEntityView = enemyTargetEntityViews[0]; var enemies = entityViewsDB.QueryEntityViews<EnemyEntityView>(); for (var i = 0; i < enemies.Count; i++) { var component = enemies[i].movementComponent; component.navMeshDestination = targetEntityView.targetPositionComponent.position; } } yield return null; } } 

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

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

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

इकाई प्रतिनिधित्व

इससे पहले, हमने इंजन की अवधारणा और सार की सार परिभाषा पेश की, चलो अब परिभाषित करते हैं कि सार का प्रतिनिधित्व क्या है। मुझे स्वीकार करना चाहिए कि Svelto.ECS पर बनाई गई 5 अवधारणाओं में से, Entity Views शायद सबसे अधिक भ्रमित करने वाले हैं। पहले Node ( ECS ऐश ढांचे से लिया गया एक नाम) कहा जाता था , मुझे एहसास हुआ कि "Node" नाम का मतलब कुछ भी नहीं था। EntityView भी भ्रामक हो सकता है, क्योंकि प्रोग्रामर आमतौर पर एक टेम्पलेट से आने वाली अवधारणा के साथ विचारों को जोड़ते हैं। मॉडल व्यू कंट्रोलर(मॉडल व्यू कंट्रोलर), हालांकि, Svelto.ECS View का उपयोग करता है, क्योंकि EntityView है कि इंजन एंटिटी को कैसे देखता है। मैं इसे इस तरह से वर्णन करना पसंद करता हूं क्योंकि यह सबसे स्वाभाविक लगता है, लेकिन मैं इसे EntityMap भी कह सकता हूं, क्योंकि EntityView उस इकाई के घटकों को प्रदर्शित करता है जिसे इंजन को एक्सेस करना चाहिए। Svelto.ECS अवधारणाओं की इस योजना को थोड़ा मदद करनी चाहिए:



मेरा सुझाव है कि इंजन के साथ शुरू करें, और अब हम इस योजना के दाईं ओर हैं। प्रत्येक इंजन में EntityViews का अपना सेट है। इंजन नामस्थान के साथ संगत EntityViews का पुन: उपयोग कर सकता है, लेकिन सबसे अधिक बार इंजन अपने EntityViews को परिभाषित करता है। इंजन इस बात की परवाह नहीं करता है कि क्या खिलाड़ी इकाई वास्तव में परिभाषित है, यह इस तथ्य को बताता है कि इसे PlayerEntityView की आवश्यकता हैकाम के लिए। कोड लिखना इंजन की जरूरतों पर निर्भर करता है, आपको उन्हें उपयोग करने के तरीके को समझने से पहले एक इकाई और उसका क्षेत्र नहीं बनाना चाहिए। अधिक जटिल परिदृश्य में, EntityView नाम और भी विशिष्ट हो सकता है। उदाहरण के लिए, हम हम हो सकता था प्रसंस्करण तर्क और प्रतिपादन प्लेयर प्लेयर चार्ट के लिए जटिल इंजन लिखने के लिए होता है, तो (डी। या एनिमेशन, और इतने पर।) PlayerPhysicEngine साथ PlayerPhysicEntityView , और PlayerGraphicEngine साथ PlayerGraphicEntityView या PlayerAnimationEngine साथ PlayerAnimationEntityView । अधिक विशिष्ट नामों का उपयोग किया जा सकता है, जैसे कि PlayerPhysicMovementEngine या PlayerPhysicJumpEngine (और इतने पर। डी)।

घटकों

हमने महसूस किया कि इंजन इकाई इकाई डेटा के एक सेट के लिए व्यवहार करते हैं, और हम समझते हैं कि इंजन सीधे संस्थाओं का उपयोग नहीं करते हैं, लेकिन संस्थाओं के प्रतिनिधित्व के माध्यम से इकाई घटकों का उपयोग करते हैं। हमने महसूस किया कि EntityView एक ऐसा वर्ग है जिसमें केवल सार्वजनिक घटक शामिल हो सकते हैं। मैंने यह भी संकेत दिया कि इकाई घटक हमेशा इंटरफेस होते हैं, इसलिए चलो एक बेहतर परिभाषा देते हैं:

इकाइयां डेटा का एक संग्रह है, और इकाई घटक उस डेटा तक पहुंचने का एक तरीका है। यदि आपने अभी तक इस पर ध्यान नहीं दिया है, तो इंटरफेस के रूप में इकाई घटकों को परिभाषित करना Svelto.ECS की एक और बहुत अनूठी विशेषता है। आमतौर पर, अन्य रूपरेखाओं में घटक ऑब्जेक्ट होते हैं। इसके बजाय इंटरफेस का उपयोग कोड को काफी कम कर सकता है। यदि आप सिद्धांत का पालन करते हैं" इंटरफ़ेस अलगाव सिद्धांत", जिसमें छोटे घटक इंटरफेस लिखे होते हैं, यहां तक ​​कि प्रत्येक एक संपत्ति के साथ, आप देखेंगे कि आपने विभिन्न संस्थाओं के भीतर घटक इंटरफेस का पुन: उपयोग करना शुरू कर दिया है। हमारे उदाहरण में, ITransformComponent को कई निकाय अभ्यावेदन में पुन: उपयोग किया जाता है। इंटरफेस के रूप में घटकों का उपयोग करना भी उन्हें एक ही वस्तु को लागू करने की अनुमति देता है, जो कई मामलों में संस्थाओं के बीच संबंध को सरल बनाता है जो संस्थाओं के विभिन्न अभ्यावेदन (या यदि संभव हो तो) का उपयोग करके एक ही इकाई को देखते हैं।

इसलिए, Svelto.ECS में, इकाई घटक हमेशा एक इंटरफ़ेस होता है, और इस इंटरफ़ेस का उपयोग केवल इंजन के अंदर EntityView फ़ील्ड के माध्यम से किया जाता है। इकाई घटक इंटरफ़ेस को तथाकथित द्वारा कार्यान्वित किया जाता है«». , .

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

यह वह जगह है जहाँ एंटिटी डिस्क्रिप्टर्स सब कुछ एक साथ रखने के बचाव में आते हैं। हम जानते हैं कि इंजन एंटिटी व्यूज़ में संग्रहित कंपोनेंट्स के माध्यम से एंटिटी डेटा तक पहुँच सकते हैं। हम जानते हैं कि इंजन वर्ग हैं, एंटिटी व्यू ऐसी कक्षाएं हैं जिनमें केवल घटक संस्थाएँ हैं और घटक इंटरफ़ेस हैं। हालांकि मैंने सार की एक सार परिभाषा दी, हमने एक भी वर्ग नहीं देखा है जो वास्तव में सार का प्रतिनिधित्व करता है। यह उन वस्तुओं की अवधारणा से मेल खाती है जो आधुनिक ईसीएस प्रणाली के भीतर पहचानकर्ता हैं। हालाँकि, Entities की सही परिभाषा के बिना, यह कोडर्स को संस्थाओं के प्रतिनिधियों के साथ Entities की पहचान करने के लिए मजबूर करेगा, जो कि भयावह गलत होगा। संस्थाओं का प्रतिनिधित्व वह तरीका है जिसमें कई इंजन एक ही इकाई को देख सकते हैं,लेकिन वे एंटिटी नहीं हैं। इकाई के अवयवों के माध्यम से परिभाषित इकाई को हमेशा डेटा का एक सेट माना जाना चाहिए, लेकिन यहां तक ​​कि यह एक कमजोर परिभाषा है। एक EntityDescriptor उदाहरण एनकोडर को सही ढंग से अपने Entities को निर्धारित करने में सक्षम बनाता है, भले ही उन इंजनों के लिए जो उन्हें संसाधित करेंगे। इसलिए, Entity Player के मामले में, हमें जरूरत हैPlayerEntityDescriptor । इस क्लास का उपयोग Entities बनाने के लिए किया जाएगा, और हालाँकि यह वास्तव में क्या करता है यह पूरी तरह से कुछ अलग है, तथ्य यह है कि उपयोगकर्ता BuildEntity <PlayerEntityDescriptor> () लिख सकते हैं और बहुत आसानी से दूसरों के निर्माण और संचार के लिए Entities कल्पना करने में मदद करता है। एनकोडर।

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

यहाँ क्या PlayerEntityDescriptor दिखता है :

 using Svelto.ECS.Example.Survive.Camera; using Svelto.ECS.Example.Survive.HUD; using Svelto.ECS.Example.Survive.Enemies; using Svelto.ECS.Example.Survive.Sound; namespace Svelto.ECS.Example.Survive.Player { public class PlayerEntityDescriptor : GenericEntityDescriptor<HUDDamageEntityView, PlayerEntityView, EnemyTargetEntityView, DamageSoundEntityView, HealthEntityView, CameraTargetEntityView> { } } 

इकाई विवरणकर्ता (और कार्यान्वयनकर्ता) एकमात्र वर्ग हैं जो एकाधिक नामस्थानों से पहचानकर्ताओं का उपयोग कर सकते हैं। इस स्थिति में, PlayerEntityDescriptor EntityViews की एक सूची को परिभाषित करता है कि PlayerEntity बनाते समय इंजन में तुरंत और इंजेक्ट करें।

EntityDescriptorHolder

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

 void BuildEntitiesFromScene(UnityContext contextHolder) { //EntityDescriptorHolder -    Svelto.ECS , //       . //         . //      , //    //     IEntityDescriptorHolder[] entities = contextHolder.GetComponentsInChildren<IEntityDescriptorHolder>(); //     Svelto.ECS, ,   //      . //        . //    EntityDescriptorHolder, //    for (int i = 0; i < entities.Length; i++) { var entityDescriptorHolder = entities[i]; var entityDescriptor = entityDescriptorHolder.RetrieveDescriptor(); _entityFactory.BuildEntity (((MonoBehaviour) entityDescriptorHolder).gameObject.GetInstanceID(), entityDescriptor, (entityDescriptorHolder as MonoBehaviour).GetComponentsInChildren<IImplementor>()); } } 

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

Implementory

हमारे सार को बनाने से पहले, आइए Svelto.ECS में अंतिम अवधारणा को परिभाषित करते हैं, जो कि इम्पेलर है । जैसा कि हम जानते हैं, Entity Components हमेशा इंटरफेस होते हैं, और C # इंटरफेस को लागू करना चाहिए। एक वस्तु जो इन इंटरफेस को लागू करती है उसे "कार्यान्वयनकर्ता" कहा जाता है। कार्यान्वयनकर्ताओं की कई महत्वपूर्ण विशेषताएं हैं:

• इकाई डेटा को निर्धारित करने के लिए आवश्यक इकाई घटकों की संख्या से इकट्ठा होने वाली वस्तुओं की संख्या को अनटाइट करने की क्षमता।
  
• विभिन्न घटकों के बीच डेटा का आदान-प्रदान करने की क्षमता, क्योंकि घटक गुणों के माध्यम से डेटा प्रदान करते हैं, घटक के विभिन्न गुण एक ही कार्यान्वयन क्षेत्र को वापस कर सकते हैं।
  
• एक इंटरफ़ेस घटक स्टब इकाई बनाने की क्षमता। परीक्षण किए गए इंजन कोड को छोड़ने के लिए यह महत्वपूर्ण है।
  
• Svelto.ECS (third party) . . Unity, , , Monobehaviour . , Unity, OnTriggerEnter / OnTriggerExit , Unity. , . :
  

 public class EnemyTriggerImplementor : MonoBehaviour, IImplementor, IEnemyTriggerComponent, IEnemyTargetComponent { public event Action<int, int, bool> entityInRange; bool IEnemyTriggerComponent.targetInRange { set { _targetInRange = value; } } bool IEnemyTargetComponent.targetInRange { get { return _targetInRange; } } void OnTriggerEnter(Collider other) { if (entityInRange != null) entityInRange(other.gameObject.GetInstanceID(), gameObject.GetInstanceID(), true); } void OnTriggerExit(Collider other) { if (entityInRange != null) entityInRange(other.gameObject.GetInstanceID(), gameObject.GetInstanceID(), false); } bool _targetInRange; } 

, , . , .

इकाई निर्माण

मान लीजिए कि हमने अपने इंजन बनाए , उन्हें EnginesRoot में जोड़ा , उनका Entity Views बनाया , जिसमें ऐसे घटकों की आवश्यकता होती है, जिन्हें इम्प्लीमेंटर्स के अंदर लागू किया जाएगा । यह हमारा पहला सार बनाने का समय है। एक इकाई हमेशा Entine Factory के एक उदाहरण के माध्यम से बनाई जाती है, जो कि EnginesRoot द्वारा GenerateEntityFactory फ़ंक्शन के माध्यम से बनाई जाती है । एक EnginesRoot उदाहरण के विपरीत, एक IEntityFactory उदाहरण तैनात और स्थानांतरित किया जा सकता है। ऑब्जेक्ट्स को रूट के अंदर या गतिशील रूप से कारखानों के अंदर बनाया जा सकता है, इसलिए बाद के मामले के लिए, आपको एक पैरामीटर के माध्यम से IEntityFactory पास करने की आवश्यकता होती है।

IEntityFactory कई समान विशेषताओं के साथ आता है। इस लेख के दौरान , मैं PreallocateEntitySlots और BuildMetaEntity फ़ंक्शन के स्पष्टीकरण को सबसे अधिक इस्तेमाल किए जाने वाले BuildEntity और BuildEntityInGroup कार्यों पर ध्यान केंद्रित करने के लिए छोड़ दूंगा ।

यह हमेशा BuildEntityInGroup का उपयोग करने के लिए सबसे अच्छा है , लेकिन अस्तित्व के उदाहरण के लिए आपको इसकी आवश्यकता नहीं है, तो आइए देखें कि सामान्य BuildEntity का उपयोग उदाहरण में कैसे किया जाता है:

 IEnumerator IntervaledTick() { //  :       //MonoBehaviour    . //       //   . // ,     , //         . //        ,     . //  ,        //   , //  .      , // ,   ,   . var enemiestoSpawn = ReadEnemySpawningDataServiceRequest(); while (true) { //Svelto.Tasks    yield  Unity, //    . //       . // ,  , //    . yield return _waitForSecondsEnumerator; if (enemiestoSpawn != null) { for (int i = enemiestoSpawn.Length - 1; i >= 0 && _numberOfEnemyToSpawn > 0; --i) { var spawnData = enemiestoSpawn[i]; if (spawnData.timeLeft <= 0.0f) { //          int spawnPointIndex = Random.Range(0, spawnData.spawnPoints.Length); //       . var go = _gameobjectFactory.Build(spawnData.enemyPrefab); //        MonoBehaviour. //      . var data = go.GetComponent<EnemyAttackDataHolder>(); //     MonoBehaviour   // : List<IImplementor> implementors = new List<IImplementor>(); go.GetComponentsInChildren(implementors); implementors.Add(new EnemyAttackImplementor(data.timeBetweenAttacks, data.attackDamage)); //         EntityViews, //     EntityDescriptor. //,       EntityView //  ,     ,  EntityDescriptorHolder //       , //    . _entityFactory.BuildEntity<EnemyEntityDescriptor>( go.GetInstanceID(), implementors.ToArray()); var transform = go.transform; var spawnInfo = spawnData.spawnPoints[spawnPointIndex]; transform.position = spawnInfo.position; transform.rotation = spawnInfo.rotation; spawnData.timeLeft = spawnData.spawnTime; numberOfEnemyToSpawn--; } spawnData.timeLeft -= 1.0f; } } } } 

इस उदाहरण में सभी टिप्पणियों को पढ़ने के लिए याद रखें, वे Svelto.ECS की अवधारणाओं को बेहतर ढंग से समझने में आपकी सहायता करेंगे। उदाहरण की सादगी के कारण, मैं BuildEntityInGroup का उपयोग नहीं करता हूं , जिसका उपयोग अधिक जटिल परियोजनाओं में किया जाता है। रोबोक्राफ्ट में, प्रत्येक इंजन जो कार्यात्मक क्यूब्स के तर्क को संसाधित करता है, खेल में इस विशेष प्रकार के सभी कार्यात्मक क्यूब्स के तर्क को संसाधित करता है। हालांकि, यह जानना अक्सर आवश्यक होता है कि क्यूब्स किस वाहन से संबंधित हैं, इसलिए प्रत्येक मशीन के लिए एक समूह का उपयोग करने से मशीनों में उसी प्रकार के क्यूब्स को तोड़ने में मदद मिलेगी, जहां मशीन आईडी समूह आईडी है। यह हमें शांत चीजों को लागू करने की अनुमति देता है, जैसे कि एक ही इंजन के अंदर एक मशीन पर एक Svelto.Tasks कार्य चलाना, जो मल्टीथ्रेडिंग का उपयोग करके समानांतर में काम कर सकता है।

कोड का यह टुकड़ा एक महत्वपूर्ण समस्या दिखाता है जिसे मैं निम्नलिखित लेखों में अधिक विवरण में शामिल कर सकता हूं ... टिप्पणी से (यदि आपने इसे नहीं पढ़ा है):

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

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

Svelto.ECS पर संचार

एक समस्या जिसका समाधान कभी भी किसी ईसीएस कार्यान्वयन द्वारा मानकीकृत नहीं किया गया है, सिस्टम के बीच संचार है। यह एक और जगह है जहां मैंने बहुत सोचा, और Svelto.ECS इसे दो नए तरीकों से हल करता है। तीसरा तरीका मानक पर्यवेक्षक / अवलोकन पैटर्न का उपयोग करना है, जो बहुत विशिष्ट और विशिष्ट मामलों में स्वीकार्य है।

DispatchOnSet / DispatchOnChange

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

अनुक्रमक

आदर्श इंजन पूरी तरह से समझाया जाता है, और आप इस इंजन के तर्क को Svelto.Tasks और IEnumerators का उपयोग करके निर्देशों के अनुक्रम के रूप में लिख सकते हैं। हालांकि, यह हमेशा संभव नहीं है, क्योंकि कुछ मामलों में इंजन को अन्य इंजनों को घटनाओं को भेजना होगा। यह आमतौर पर इकाई डेटा के माध्यम से किया जाता है, विशेष रूप से डिस्पैटोऑनसेट और डिस्पैचऑनचेंज का उपयोग करकेहालाँकि, उदाहरण के रूप में संस्थाओं के "क्षतिग्रस्त" होने के मामले में, स्वतंत्र और असंबंधित इंजनों की एक श्रृंखला इस पर काम करती है। अन्य मामलों में, आप चाहते हैं कि जिस क्रम में इंजनों को बुलाया गया था, उस क्रम में सख्त होना चाहिए, उदाहरण के लिए, जहां मैं चाहता हूं कि मृत्यु हमेशा बाद के लिए हो। इस मामले में, अनुक्रम न केवल उपयोग करना बहुत आसान है, बल्कि बहुत सुविधाजनक भी है! अनुक्रम रीफैक्टरिंग बहुत सरल है। इसलिए, "ऊर्ध्वाधर" इंजनों और इंजनों के बीच "क्षैतिज" तर्क के लिए दृश्यों के लिए IEnumerator Svelto कार्य का उपयोग करें।

प्रेक्षक / अवलोकन किया

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