🧓 💳 🐦 हमने अपना ECS कैसे और क्यों लिखा 💇🏾 🎅🏾 🎞️

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

उदाहरण के रूप में ईसीएस क्या है

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

ऊपर दिए गए आरेख प्लेयर के सार, उसके घटकों और उनके डेटा, और उन सिस्टम का वर्णन करते हैं जो खिलाड़ी और उसके घटकों के साथ काम करते हैं। आरेख में मुख्य वस्तु खिलाड़ी है:

अंतरिक्ष में स्थानांतरित कर सकते हैं - रूपांतरण और आंदोलन घटकों, MoveSystem ;
कुछ स्वास्थ्य है और मर सकते हैं - घटक स्वास्थ्य , नुकसान , नुकसान प्रणाली ;
मरने के बाद रिस्पांस पॉइंट पर प्रकट होता है - स्थिति के लिए ट्रांसफॉर्म घटक, रेस्पॉनसिस्टम ;
अजेय हो सकता है - घटक अजेय ।

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

public interface IComponent { // < > } public interface ISystem { void Execute(GameState gs); }

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

 [Component] public class Health { [Max(1000)] //  -  1000 public int Hp; // -   public Health(int hp) {} } [Component] public class Damage { [DontSend] //      ,      public uint Amount; // -  public Entity Victim; //    public Entity Source; //    public Damage(uint amount, Entity victim, Entity source) {} } [Component] public class Invincible //   ,  ,    { }

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

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

हमारे पास एक इकाई प्रीफ़ैब क्लास भी है, जहां हम किसी भी इकाई के सभी संभावित घटकों के बारे में जानकारी जोड़ते हैं, और जनरेटर पहले से ही एक वास्तविक वर्ग बना देगा:

 public class Entity { public Health Health; public Damage Damage; public Invincible Invincible; // ... < > }

उसके बाद, हमारा जनरेटर स्वास्थ्य , नुकसान और अजेय घटक वर्गों का कोड बनाएगा, जो पहले से ही गेम गेम में उपयोग किया जाएगा:

 public sealed class Health : IComponent { public int Hp; public void Reset() { Hp = default(int); } // ... <  > } public sealed class Damage : IComponent { public int Amount; public Entity Victim; public Entity Source; public void Reset() { Amount = default(int); Victim = default(Entity); Source = default(Entity); } // ... <  > } public sealed class Invincible : IComponent { }

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

दुनिया की स्थिति के लिए एक वर्ग भी उत्पन्न किया जाएगा, जिसमें सभी घटकों और संस्थाओं की सूची शामिल है:

 public sealed class GameState { //  public Table<Movement> Movements; public Table<Health> Healths; public Table<Damage> Damages; public Table<Transform> Transforms; public Table<Invincible> Invincibles; //   public Entity CreateEntity() { /* <> */ } public void Copy(GameState gs2) { /* <> */ } public Entity this[uint id] { /* <> */ } // ... <   > }

और अंत में, इकाई के लिए उत्पन्न कोड:

 public sealed class Entity { public uint Id; //   public GameState GameState; //     //     : public Health Health { get { return GameState.Healths[Id]; } } public Damage Damage { get { return GameState.Damages[Id]; } } public Invincible Invincible { get { return GameState.Invincibles[Id]; } } // …     public Damage AddDamage() { return GameState.Damages.Insert(Id); } public Damage AddDamage(int total, Entity victim, Entity source) { var c = GameState.Damages.Insert(Id); c.Amount = total; c.Victim = victim; c.Source = source; return c; } public void DelDamage() { GameState.Damages.Delete(Id); } // … <     > }

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

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

संस्थाओं को बनाना / हटाना;
किसी घटक को जोड़ें / निकालें / कॉपी करें, यदि मौजूद है तो उसे एक्सेस करें;
दुनिया के दो राज्यों की तुलना करें;
दुनिया की स्थिति को क्रमबद्ध करें;
डेल्टा संपीड़न;
दुनिया की स्थिति, संस्थाओं, घटकों (नीचे विवरण देखें) को प्रदर्शित करने के लिए एक वेब पेज या यूनिटी विंडो का कोड;
और अन्य

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

 public sealed class DamageSystem : ISystem { void ISystem.Execute(GameState gs) { foreach (var damage in gs.Damages) { var invincible = damage.Victim.Invincible; if (invincible != null) continue; var health = damage.Victim.Health; if (health == null) continue; health.Hp -= damage.Amount; } } }

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

सिस्टम की प्रमुख विशेषताओं पर विचार करें:

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

कुल, हम निम्नलिखित वर्गों और उनके बीच के रिश्तों को प्राप्त करते हैं:

ECS के बारे में कुछ तथ्य

ECS के विकास के लिए एक दृष्टिकोण और खेल की दुनिया का प्रतिनिधित्व करने के तरीके के रूप में इसके पेशेवरों और विपक्ष हैं, इसलिए हर कोई खुद का फैसला करता है कि इसका उपयोग करना है या नहीं। चलो पेशेवरों के साथ शुरू करते हैं:

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

और अब विपक्ष:

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

- मॉडल - ईसीएस से गेमस्टेट;
- देखें - हमारे साथ ये विशेष रूप से मानक मोनोबीहेयर यूनिटी कक्षाएं ( रेंडरर , टेक्स्ट , आदि) और प्रीफैब्स हैं;
- प्रस्तुतकर्ता संस्थाओं, घटकों आदि की उपस्थिति / गायब होने की घटनाओं को निर्धारित करने के लिए गेमस्टेट का उपयोग करता है, प्रीफ़ैब्स से एकता ऑब्जेक्ट बनाता है और उन्हें दुनिया की स्थिति में परिवर्तन के अनुसार बदलता है।

क्या आप जानते हैं कि:

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

ईसीएस ढांचे के लिए हमारा चयन मानदंड

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

Entitas
आर्टेमिस सी #
Ash.NET
जिस समय हमने इसकी कल्पना की थी, ईसीएस हमारा अपना समाधान है। यानी हमारी धारणाएँ और इच्छाएँ, हम खुद क्या कर सकते हैं।

हमने तुलना के लिए एक तालिका संकलित की है, जहां मैंने अपना वर्तमान समाधान भी शामिल किया है (इसे ईसीएस (अब) के रूप में निर्दिष्ट किया गया है):

लाल रंग - समाधान हमारी आवश्यकता का समर्थन नहीं करता है, नारंगी - आंशिक रूप से समर्थन करता है, हरा - पूरी तरह से समर्थन करता है।

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

हम अपनी आवश्यकताओं का वर्णन करेंगे और किस हद तक तीसरे पक्ष के पुस्तकालय और ढांचे उनके अनुरूप होंगे:

अलग-अलग डेटा सेट (इतिहास, वर्तमान, दृश्य, स्थैतिक) - विश्व राज्यों को अलग-अलग प्राप्त करने और संग्रहीत करने की क्षमता (उदाहरण के लिए, प्रसंस्करण के लिए वर्तमान स्थिति, प्रतिपादन के लिए राज्य इतिहास, आदि)। विचार किए गए सभी निर्णयों ने इस आवश्यकता का समर्थन किया ।
पूर्णांक के रूप में एंट्री आईडी - इसकी पहचानकर्ता-संख्या द्वारा एक इकाई का प्रतिनिधित्व करने के लिए समर्थन। यह नेटवर्क पर प्रसारण और राज्यों के इतिहास में संस्थाओं को जोड़ने की क्षमता के लिए आवश्यक है। कोई भी समाधान समर्थित नहीं माना जाता है। उदाहरण के लिए, एंटिटास में, एक इकाई को एक पूर्ण ऑब्जेक्ट (जैसे गेमऑबजेक्ट इन यूनिटी) द्वारा दर्शाया जाता है।
आईडी ओ (एन + एम) से जुड़ें - दो प्रकार के घटकों के अपेक्षाकृत तेजी से नमूने के लिए समर्थन। उदाहरण के लिए, जब आपको नुकसान की गणना करने और नुकसान के लिए स्वास्थ्य संस्थाओं (उदाहरण के लिए, उनके एन टुकड़े) और स्वास्थ्य (एम टुकड़े) के घटकों के साथ सभी संस्थाओं को प्राप्त करने की आवश्यकता होती है। आर्टेमिस में पूरा समर्थन था; Entitas और Ash.NET में यह O (N,) की तुलना में तेज़ है, लेकिन O (N + M) की तुलना में धीमा है। मुझे अब मूल्यांकन याद नहीं है।
आईडी संदर्भ ओ (एन + एम) से जुड़ें - केवल ऊपर जब एक इकाई के एक घटक का दूसरे से लिंक होता है, और बाद वाले को एक अन्य घटक प्राप्त करने की आवश्यकता होती है (हमारे उदाहरण में, सहायक इकाई पर नुकसान घटक खिलाड़ी इकाई को संदर्भित करता है। और वहां से आपको स्वास्थ्य घटक प्राप्त करने की आवश्यकता है)। विचार किए गए किसी भी समाधान द्वारा समर्थित नहीं है।
कोई क्वेरी आवंटित नहीं - दुनिया की स्थिति से घटकों और संस्थाओं को क्वेरी करते समय कोई अतिरिक्त मेमोरी आवंटन नहीं। एंटिटास में, यह कुछ मामलों में था, लेकिन हमारे लिए महत्वहीन था।
पूल टेबल - पूल में विश्व डेटा का भंडारण, मेमोरी का पुन: उपयोग करने की क्षमता, आवंटन केवल तभी जब पूल खाली हो। Entitas और Artemis में "कुछ" समर्थन था, Ash.NET में पूर्ण अनुपस्थिति।
आईडी (ऐड, डेल) द्वारा तुलना - आईडी के द्वारा संस्थाओं और घटकों के निर्माण / विनाश की घटनाओं के लिए अंतर्निहित समर्थन। प्रदर्शन स्तर (दृश्य) के लिए यह आवश्यक है कि वस्तुओं को दिखाने / छिपाने, एनिमेशन, प्रभाव दिखाने के लिए। विचार किए गए किसी भी समाधान द्वारा समर्थित नहीं है।
Δ सीरियलाइज़ेशन (मात्रा का ठहराव) - दुनिया के राज्य को क्रमबद्ध करने के लिए अंतर्निहित डेल्टा संपीड़न (उदाहरण के लिए, नेटवर्क पर भेजे गए डेटा के आकार को कम करने के लिए)। आउट ऑफ द बॉक्स किसी भी समाधान में समर्थित नहीं था।
इंटरपोलेशन दुनिया के राज्यों के बीच एक अंतर्निर्मित प्रक्षेप तंत्र है। कोई भी समाधान समर्थित नहीं है।
पुन: उपयोग घटक प्रकार - विभिन्न प्रकार की संस्थाओं में एक बार लिखित घटक प्रकार का उपयोग करने की क्षमता। केवल एंटेता का समर्थन किया ।
सिस्टम का स्पष्ट क्रम - अपने खुद के कॉल ऑर्डर सिस्टम को सेट करने की क्षमता। सभी फैसलों का समर्थन किया।
संपादक (एकता / सर्वर) - ग्राहक के लिए और सर्वर के लिए वास्तविक समय में संस्थाओं को देखने और संपादित करने के लिए समर्थन। Entitas ने इकाइयों और घटकों को एकता संपादक में देखने और संपादित करने की क्षमता का समर्थन किया।
फास्ट कॉपी / रिप्लेसमेंट - सस्ते डेटा को कॉपी / रिप्लेस करने की क्षमता। कोई भी समाधान समर्थित नहीं है।
मूल्य प्रकार (संरचना) के रूप में घटक - मूल्य प्रकार के रूप में घटक। सिद्धांत रूप में, मैं इसके आधार पर अच्छा प्रदर्शन हासिल करना चाहता था। एक भी प्रणाली का समर्थन नहीं किया गया था; घटक वर्ग हर जगह थे।

वैकल्पिक आवश्यकताएं ( उस समय समाधानों में से कोई भी उनका समर्थन नहीं करता ):

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

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

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

उसी समय, फिर भी हमें उन आवश्यकताओं में से एक का एहसास हुआ जो शुरू में हमारी राय में वैकल्पिक थीं:

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

ईसीएस में हमारे विकास की विशेषताएं

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

बोनस

— ECS — . , , , :

Unity, ECS -- — ECS . mopsicus , ECS, . : Unity ECS , . . «» ECS Unity. ECS-, : LeoECS , BrokenBricksECS , Svelto.ECS .
Unity3D ECS Job System — , ECS Unity. fstleo , Unity ECS, , - , JobSystem.
Entity System Framework ? — Ash- ActionScript. , , OOP- ECS-.
Ash Entity System — , FSM State ECS — , .
Entity-Component-System — — ECS C++.

हमने अपना ECS कैसे और क्यों लिखा

उदाहरण के रूप में ईसीएस क्या है

ECS के बारे में कुछ तथ्य

ईसीएस ढांचे के लिए हमारा चयन मानदंड

ईसीएस में हमारे विकास की विशेषताएं

बोनस

More articles: