इस हफ्ते, मैंने अपने वागाबोंड इंजन पर काम करना शुरू कर दिया और इकाई-घटक-प्रणाली टेम्पलेट को लागू करना शुरू कर दिया।

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

परिचय

प्रेरणा

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

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

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

उदाहरण

कोड में डील करने से पहले, मैं आपको दिखाना चाहता हूं कि हम क्या डिजाइन करने जा रहे हैं।

घटकों को सौंपना बहुत सरल है:

struct Position : public Component<Position> { float x; float y; }; struct Velocity : public Component<Velocity> { float x; float y; }; 

जैसा कि आप देख सकते हैं, हम CRTP टेम्पलेट का उपयोग करेंगे।

फिर, तकनीकी कारणों से, जिसे मैं बाद में समझाऊंगा, हमें घटकों की संख्या और प्रणालियों की संख्या को ठीक करने की आवश्यकता है:

 constexpr auto ComponentCount = 32; constexpr auto SystemCount = 8; 

इसके बाद, आप एक ऐसी प्रणाली को निर्दिष्ट कर सकते हैं जो सभी संस्थाओं को ले जाएगी जिसमें दोनों घटक होंगे और अपनी स्थिति को अपडेट करेंगे:

 class PhysicsSystem : public System<ComponentCount, SystemCount> { public: PhysicsSystem(EntityManager<ComponentCount, SystemCount>& entityManager) : mEntityManager(entityManager) { setRequirements<Position, Velocity>(); } void update(float dt) { for (const auto& entity : getManagedEntities()) { auto [position, velocity] = mEntityManager.getComponents<Position, Velocity>(entity); position.x += velocity.x * dt; position.y += velocity.y * dt; } } private: EntityManager<ComponentCount, SystemCount>& mEntityManager; }; 

सिस्टम बस अपने setRequirements घटकों को setRequirements करने के लिए setRequirements विधि का उपयोग करता है। फिर, update विधि में, यह getManagedEntities को सभी संस्थाओं को पुनरावृत्त कर सकता है जो आवश्यकताओं को पूरा करते हैं।

अंत में, चलो एक इकाई प्रबंधक बनाते हैं, घटकों को पंजीकृत करते हैं, एक सिस्टम और कई इकाइयाँ बनाते हैं, और फिर सिस्टम का उपयोग करके अपने पदों को अपडेट करते हैं:

 auto manager = EntityManager<ComponentCount, SystemCount>(); manager.registerComponent<Position>(); manager.registerComponent<Velocity>(); auto system = manager.createSystem<PhysicsSystem>(manager); for (auto i = 0; i < 10; ++i) { auto entity = manager.createEntity(); manager.addComponent<Position>(entity); manager.addComponent<Velocity>(entity); } auto dt = 1.0f / 60.0f; while (true) system->update(dt); 

मानक

मैं सर्वश्रेष्ठ ईसीएस लाइब्रेरी बनाने का ढोंग नहीं करूंगा। मैं बस इसे खुद लिखना चाहता था। इसके अलावा, मैंने केवल एक सप्ताह के लिए इस पर काम किया।

हालांकि, यह पूरी तरह से अप्रभावी कुछ बनाने का कारण नहीं है। तो चलो मानक स्थापित करें:

• पहले संस्थाएँ बनाएंगे;
• दूसरा सिस्टम को पुनरावृत्त रूप से पार करने वाली संस्थाओं का उपयोग करेगा;
• उत्तरार्द्ध संस्थाओं को बनाएंगे और नष्ट करेंगे;

इन सभी बेंचमार्क के पैरामीटर संस्थाओं की संख्या, प्रत्येक इकाई के लिए घटकों की संख्या, घटकों की अधिकतम संख्या और सिस्टम की अधिकतम संख्या हैं। इस तरह, हम देख सकते हैं कि हमारा कार्यान्वयन कितना अच्छा है। विशेष रूप से, मैं तीन अलग-अलग प्रोफाइल के परिणाम दिखाऊंगा:

• प्रोफाइल ए: 32 घटक और 16 सिस्टम;
• एए प्रोफाइल: 128 घटक और 32 सिस्टम;
• एएए प्रोफाइल: 512 घटक और 64 सिस्टम।

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

कार्यान्वयन

सार

मेरे कार्यान्वयन में, एक इकाई सिर्फ एक आईडी है:

 using Entity = uint32_t; 

इसके अलावा, Entity.h में हम एक उपनाम Index को भी परिभाषित करेंगे, जो बाद में काम आएगा:

 using Index = uint32_t; static constexpr auto InvalidIndex = std::numeric_limits<Index>::max(); 

मैंने स्थान बचाने और कैश ऑप्टिमाइज़ेशन में सुधार करने के लिए 64-बिट प्रकार या std::size_t बजाय uint32_t का उपयोग करने का निर्णय लिया। हम इतना नहीं हारेंगे: यह संभावना नहीं है कि किसी के पास अरबों इकाइयां होंगी।

अंग

अब घटकों के आधार वर्ग को परिभाषित करते हैं:

 template<typename T, auto Type> class Component { public: static constexpr auto type = static_cast<std::size_t>(Type); }; 

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

पहला टेम्पलेट पैरामीटर घटक का प्रकार है। दूसरा std::size_t कनवर्ट किया गया मान है, जो घटक प्रकार आईडी के रूप में काम करेगा।

उदाहरण के लिए, हम निम्नानुसार घटक घटक को परिभाषित कर सकते हैं:

 struct Positon : Component<Position, 0> { float x; float y; }; 

हालांकि, एक गणना अधिक सुविधाजनक हो सकती है:

 enum class ComponentType { Position }; struct Positon : Component<Position, ComponentType::Position> { float x; float y; }; 

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

EntityContainer

EntityContainer वर्ग उनमें से प्रत्येक के लिए संस्थाओं और std::bitset प्रबंधन के लिए जिम्मेदार होगा। बिट्स का यह सेट उन घटकों को इंगित करेगा जो इकाई का मालिक है।

चूंकि हम कंटेनरों को इंडेक्स करने के लिए संस्थाओं का उपयोग करेंगे, और विशेष रूप से std::vector , हमें आईडी की आवश्यकता होगी जितना छोटा हो और कम मेमोरी ले। इसलिए, हम नष्ट की गई संस्थाओं की आईडी का पुन: उपयोग करेंगे। ऐसा करने के लिए, मुफ्त आईडी को mFreeEntities नामक कंटेनर में संग्रहीत किया जाएगा।

यहाँ EntityContainer :

 template<std::size_t ComponentCount, std::size_t SystemCount> class EntityContainer { public: void reserve(std::size_t size); std::vector<std::bitset<ComponentCount>>& getEntityToBitset(); const std::bitset<ComponentCount>& getBitset(Entity entity) const; Entity create(); void remove(Entity entity); private: std::vector<std::bitset<ComponentCount>> mEntityToBitset; std::vector<Entity> mFreeEntities; }; 

आइए देखें कि तरीकों को कैसे लागू किया जाता है।

getEntityToBitset और getBitset सामान्य छोटे getBitset हैं:

 std::vector<std::bitset<ComponentCount>>& getEntityToBitset() { return mEntityToBitset; } const std::bitset<ComponentCount>& getBitset(Entity entity) const { return mEntityToBitset[entity]; } 

create विधि अधिक दिलचस्प है:

 Entity create() { auto entity = Entity(); if (mFreeEntities.empty()) { entity = static_cast<Entity>(mEntityToBitset.size()); mEntityToBitset.emplace_back(); } else { entity = mFreeEntities.back(); mFreeEntities.pop_back(); mEntityToBitset[entity].reset(); } return entity; } 

यदि कोई स्वतंत्र संस्था है, तो वह इसका पुन: उपयोग करता है। अन्यथा, विधि एक नई इकाई बनाती है।

remove विधि केवल इकाई को mFreeEntities में हटाए जाने के लिए mFreeEntities :

 void remove(Entity entity) { mFreeEntities.push_back(entity); } 

अंतिम विधि reserve । इसका काम विभिन्न कंटेनरों के लिए मेमोरी आरक्षित करना है। जैसा कि हम जानते हैं, मेमोरी आवंटित करना एक महंगा ऑपरेशन है, इसलिए यदि हम लगभग गेम में भविष्य की संस्थाओं की संख्या जानते हैं, तो रिजर्व मेमोरी काम को गति देगा:

 void reserve(std::size_t size) { mFreeEntities.resize(size); std::iota(std::begin(mFreeEntities), std::end(mFreeEntities), 0); mEntityToBitset.resize(size); } 

एक साधारण मेमोरी बैकअप के अलावा, यह mFreeEntities भी आबाद mFreeEntities ।

ComponentContainer

ComponentContainer वर्ग निर्दिष्ट प्रकार के सभी घटकों को संग्रहीत करने के लिए जिम्मेदार होगा।

मेरी वास्तुकला में, दिए गए प्रकार के सभी घटकों को एक साथ संग्रहीत किया जाता है। यही है, प्रत्येक प्रकार के घटक के लिए एक बड़ा सरणी है, जिसे mComponents कहा जाता है।

इसके अलावा, किसी संस्था से किसी घटक को निरंतर समय में जोड़ने, प्राप्त करने या निकालने में सक्षम होने के लिए, हमें एक इकाई से एक घटक तक और घटक से इकाई तक जाने का एक तरीका चाहिए। ऐसा करने के लिए, हमें mComponentToEntity और mEntityToComponent नामक दो और डेटा संरचनाओं की mEntityToComponent ।

इस ComponentContainer घोषणा है:

 template<typename T, std::size_t ComponentCount, std::size_t SystemCount> class ComponentContainer : public BaseComponentContainer { public: ComponentContainer(std::vector<std::bitset<ComponentCount>>& entityToBitset); virtual void reserve(std::size_t size) override; T& get(Entity entity); const T& get(Entity entity) const; template<typename... Args> void add(Entity entity, Args&&... args); void remove(Entity entity); virtual bool tryRemove(Entity entity) override; Entity getOwner(const T& component) const; private: std::vector<T> mComponents; std::vector<Entity> mComponentToEntity; std::unordered_map<Entity, Index> mEntityToComponent; std::vector<std::bitset<ComponentCount>>& mEntityToBitset; }; 

आप देख सकते हैं कि यह BaseComponentContainer से विरासत में BaseComponentContainer , जो इस प्रकार सेट है:

 class BaseComponentContainer { public: virtual ~BaseComponentContainer() = default; virtual void reserve(std::size_t size) = 0; virtual bool tryRemove(Entity entity) = 0; }; 

इस बेस क्लास का एकमात्र उद्देश्य एक कंटेनर में ComponentContainer सभी उदाहरणों को संग्रहीत करने में सक्षम होना है।

आइए अब हम विधियों की परिभाषा देखें।

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

 ComponentContainer(std::vector<std::bitset<ComponentCount>>& entityToBitset) : mEntityToBitset(entityToBitset) { } 

get करने का तरीका सरल है, हम सिर्फ mEntityToComponent में एक इकाई घटक के सूचकांक को खोजने के लिए mEntityToComponent का उपयोग करते हैं।

 T& get(Entity entity) { return mComponents[mEntityToComponent[entity]]; } 

add विधि mComponents के अंत में एक नया घटक सम्मिलित करने के लिए अपने तर्कों का उपयोग mComponents , और फिर यह इकाई से घटक और घटक से इकाई तक जाने के लिए लिंक तैयार करती है। अंत में, यह entity बिट सेट के बिट को सेट करता है जो घटक को true मेल खाता true :

 template<typename... Args> void add(Entity entity, Args&&... args) { auto index = static_cast<Index>(mComponents.size()); mComponents.emplace_back(std::forward<Args>(args)...); mComponentToEntity.emplace_back(entity); mEntityToComponent[entity] = index; mEntityToBitset[entity][T::type] = true; } 

remove विधि संबंधित बिट घटक को false सेट करती है, और फिर हम जिसे हटाना चाहते हैं उसके सूचकांक में अंतिम mComponents घटक को स्थानांतरित करता है। यह उस घटक के लिंक को अद्यतन करता है जिसे हमने अभी स्थानांतरित किया था, और एक घटक को हटा देता है जिसे हम नष्ट करना चाहते हैं:

 void remove(Entity entity) { mEntityToBitset[entity][T::type] = false; auto index = mEntityToComponent[entity]; // Update mComponents mComponents[index] = std::move(mComponents.back()); mComponents.pop_back(); // Update mEntityToComponent mEntityToComponent[mComponentToEntity.back()] = index; mEntityToComponent.erase(entity); // Update mComponentToEntity mComponentToEntity[index] = mComponentToEntity.back(); mComponentToEntity.pop_back(); } 

हम उस अनुक्रमणिका में अंतिम घटक को स्थानांतरित करके निरंतर-समय पर आंदोलन कर सकते हैं जिसे हम नष्ट करना चाहते हैं। और वास्तव में, फिर हमें केवल अंतिम घटक को हटाने की आवश्यकता है, जो निरंतर समय में std::vector में किया जा सकता है।

tryRemove विधि यह देखने के लिए जांच करती है कि किसी संस्था के पास इसे हटाने की कोशिश से पहले कोई घटक है या नहीं:

 virtual bool tryRemove(Entity entity) override { if (mEntityToBitset[entity][T::type]) { remove(entity); return true; } return false; } 

getOwner विधि घटक का मालिकाना getOwner वाली इकाई को लौटाता है, इसके लिए यह सूचक अंकगणितीय और mComponentToEntity का उपयोग करता है:

 Entity getOwner(const T& component) const { auto begin = mComponents.data(); auto index = static_cast<std::size_t>(&component - begin); return mComponentToEntity[index]; } 

अंतिम विधि reserve , इसका एक ही उद्देश्य है EntityContainer में समान विधि:

 virtual void reserve(std::size_t size) override { mComponents.reserve(size); mComponentToEntity.reserve(size); mEntityToComponent.reserve(size); } 

प्रणाली

अब System क्लास को देखते हैं।

प्रत्येक प्रणाली में mRequirements बिट्स का एक सेट mRequirements है जो उन घटकों का वर्णन करता है जिनकी उन्हें आवश्यकता है इसके अलावा, यह mManagedEntities संस्थाओं का एक सेट संग्रहीत करता है जो इन आवश्यकताओं को पूरा करते हैं। मैं दोहराता हूं, निरंतर समय में सभी कार्यों को लागू करने में सक्षम होने के लिए, हमें एक इकाई से इसके mManagedEntities में स्थानांतरित करने का एक तरीका mManagedEntities । ऐसा करने के लिए, हम std::unordered_map उपयोग करेंगे जिसे mEntityToManagedEntity कहा जाता है।

यहाँ System घोषणा क्या दिखती है:

 template<std::size_t ComponentCount, std::size_t SystemCount> class System { public: virtual ~System() = default; protected: template<typename ...Ts> void setRequirements(); const std::vector<Entity>& getManagedEntities() const; virtual void onManagedEntityAdded([[maybe_unused]] Entity entity); virtual void onManagedEntityRemoved([[maybe_unused]] Entity entity); private: friend EntityManager<ComponentCount, SystemCount>; std::bitset<ComponentCount> mRequirements; std::size_t mType; std::vector<Entity> mManagedEntities; std::unordered_map<Entity, Index> mEntityToManagedEntity; void setUp(std::size_t type); void onEntityUpdated(Entity entity, const std::bitset<ComponentCount>& components); void onEntityRemoved(Entity entity); void addEntity(Entity entity); void removeEntity(Entity entity); }; 

बिट मान सेट करने के लिए setRequirements एक setRequirements का उपयोग करता है:

 template<typename ...Ts> void setRequirements() { (mRequirements.set(Ts::type), ...); } 

getManagedEntities एक ऐसा getManagedEntities है जिसका उपयोग उत्पन्न होने वाली संस्थाओं द्वारा संसाधित किए जाने के लिए उपयोग किया जाएगा:

 const std::vector<Entity>& getManagedEntities() const { return mManagedEntities; } 

यह एक निरंतर संदर्भ देता है ताकि उत्पन्न वर्ग mManagedEntities को संशोधित करने का प्रयास न करें।

onManagedEntityAdded और onManagedEntityRemoved रिक्त हैं। बाद में उन्हें फिर से परिभाषित किया जाएगा। mManagedEntities एक इकाई जोड़ते समय या इसे हटाते समय इन विधियों को बुलाया जाएगा।

निम्नलिखित विधियाँ केवल EntityManager ओर से निजी और सुलभ होंगी, जिन्हें एक दोस्ताना वर्ग के रूप में घोषित किया गया है।

setUp को सिस्टम को आईडी असाइन करने के लिए इकाई प्रबंधक द्वारा बुलाया जाएगा। तो यह सूचकांक सरणियों के लिए इसका इस्तेमाल कर सकते हैं:

 void setUp(std::size_t type) { mType = type; } 

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

 void onEntityUpdated(Entity entity, const std::bitset<ComponentCount>& components) { auto satisfied = (mRequirements & components) == mRequirements; auto managed = mEntityToManagedEntity.find(entity) != std::end(mEntityToManagedEntity); if (satisfied && !managed) addEntity(entity); else if (!satisfied && managed) removeEntity(entity); } 

onEntityRemoved को इकाई प्रबंधक द्वारा एक इकाई हटाए onEntityRemoved पर कहा जाता है। यदि इकाई को सिस्टम द्वारा संसाधित किया गया था, तो वह इसे हटा देती है:

 void onEntityRemoved(Entity entity) { if (mEntityToManagedEntity.find(entity) != std::end(mEntityToManagedEntity)) removeEntity(entity); } 

addEntity और removeEntity सिर्फ सहायक विधियाँ हैं।

addEntity इसके सूचकांक द्वारा जोड़े गए इकाई से जाने के लिए लिंक सेट करता है, इकाई जोड़ता है और onManagedEntityAdded कॉल onManagedEntityAdded :

 void addEntity(Entity entity) { mEntityToManagedEntity[entity] = static_cast<Index>(mManagedEntities.size()); mManagedEntities.emplace_back(entity); onManagedEntityAdded(entity); } 

removeEntity पहले कॉल onManagedEntityRemoved । फिर यह अंतिम संसाधित निकाय को हटाए जाने वाले के सूचकांक में ले जाता है। यह स्थानांतरित इकाई के संदर्भ को अद्यतन करता है। अंत में, यह mManagedEntities जाने वाली इकाई को mManagedEntities और mEntityToManagedEntity से हटा mEntityToManagedEntity :

 void removeEntity(Entity entity) { onManagedEntityRemoved(entity); auto index = mEntityToManagedEntity[entity]; mEntityToManagedEntity[mManagedEntities.back()] = index; mEntityToManagedEntity.erase(entity); mManagedEntities[index] = mManagedEntities.back(); mManagedEntities.pop_back(); } 

EntityManager

अन्य वर्गों में सभी महत्वपूर्ण तर्क हैं। एक इकाई प्रबंधक बस सब कुछ एक साथ जोड़ता है।

आइए उनके विज्ञापन पर एक नज़र डालें:

 template<std::size_t ComponentCount, std::size_t SystemCount> class EntityManager { public: template<typename T> void registerComponent(); template<typename T, typename ...Args> T* createSystem(Args&& ...args); void reserve(std::size_t size); Entity createEntity(); void removeEntity(Entity entity); template<typename T> bool hasComponent(Entity entity) const; template<typename ...Ts> bool hasComponents(Entity entity) const; template<typename T> T& getComponent(Entity entity); template<typename T> const T& getComponent(Entity entity) const; template<typename ...Ts> std::tuple<Ts&...> getComponents(Entity entity); template<typename ...Ts> std::tuple<const Ts&...> getComponents(Entity entity) const; template<typename T, typename... Args> void addComponent(Entity entity, Args&&... args); template<typename T> void removeComponent(Entity entity); template<typename T> Entity getOwner(const T& component) const; private: std::array<std::unique_ptr<BaseComponentContainer>, ComponentCount> mComponentContainers; EntityContainer<ComponentCount, SystemCount> mEntities; std::vector<std::unique_ptr<System<ComponentCount, SystemCount>>> mSystems; template<typename T> void checkComponentType() const; template<typename ...Ts> void checkComponentTypes() const; template<typename T> auto getComponentContainer(); template<typename T> auto getComponentContainer() const; }; 

EntityManager वर्ग के तीन सदस्य चर हैं: mComponentContainers , जो std::unique_ptr को BaseComponentContainer , mEntities , जो कि EntityContainer और mSystems का एक उदाहरण है, जो System unique_ptr पॉइंटर्स संग्रहीत unique_ptr ।

एक वर्ग के कई तरीके हैं, लेकिन वास्तव में वे सभी बहुत सरल हैं।

आइए सबसे पहले getComponentContainer पर एक नज़र getComponentContainer , जो एक कंपोनेंट कंटेनर को पॉइंटर देता है जो टाइप T कंपोनेंट्स को प्रोसेस करता है:

 template<typename T> auto getComponentContainer() { return static_cast<ComponentContainer<T, ComponentCount, SystemCount>*>(mComponentContainers[T::type].get()); } 

एक अन्य सहायक फ़ंक्शन checkComponentType , जो बस जाँचता है कि घटक प्रकार आईडी अधिकतम घटकों की संख्या से नीचे है:

 template<typename T> void checkComponentType() const { static_assert(T::type < ComponentCount); } 

checkComponentTypes कई प्रकार की जाँच करने के लिए एक checkComponentTypes का उपयोग करता है:

 template<typename ...Ts> void checkComponentTypes() const { (checkComponentType<Ts>(), ...); } 

registerComponent निर्दिष्ट प्रकार के घटकों का एक नया कंटेनर बनाता है:

 template<typename T> void registerComponent() { checkComponentType<T>(); mComponentContainers[T::type] = std::make_unique<ComponentContainer<T, ComponentCount, SystemCount>>( mEntities.getEntityToBitset()); } 

createSystem निर्दिष्ट प्रकार की एक नई प्रणाली बनाता है और इसके प्रकार को सेट करता है:

 template<typename T, typename ...Args> T* createSystem(Args&& ...args) { auto type = mSystems.size(); auto& system = mSystems.emplace_back(std::make_unique<T>(std::forward<Args>(args)...)); system->setUp(type); return static_cast<T*>(system.get()); } 

reserve विधि ComponentContainer और EntityContainer के reserve तरीकों को बुलाती है:

 void reserve(std::size_t size) { for (auto i = std::size_t(0); i < ComponentCount; ++i) { if (mComponentContainers[i]) mComponentContainers[i]->reserve(size); } mEntities.reserve(size); } 

createEntity विधि EntityManager प्रबंधक की create विधि का परिणाम देती है:

 Entity createEntity() { return mEntities.create(); } 

hasComponent , इस इकाई को निर्दिष्ट प्रकार के एक घटक को जल्दी से सत्यापित करने के लिए इकाई बिट्स के एक सेट का उपयोग करता है:

 template<typename T> bool hasComponent(Entity entity) const { checkComponentType<T>(); return mEntities.getBitset(entity)[T::type]; } 

hasComponents आवश्यक घटकों को दर्शाते हुए बिट्स का एक सेट बनाने के लिए एक कनवल्शन एक्सप्रेशन का उपयोग करता है, और फिर यूनिट के सभी आवश्यक घटकों की जाँच करने के लिए इकाई के बिट्स के सेट के साथ इसका उपयोग करता है:

 template<typename ...Ts> bool hasComponents(Entity entity) const { checkComponentTypes<Ts...>(); auto requirements = std::bitset<ComponentCount>(); (requirements.set(Ts::type), ...); return (requirements & mEntities.getBitset(entity)) == requirements; } 

getComponent आवश्यक घटक कंटेनर के अनुरोध को पुनर्निर्देशित करता है:

 template<typename T> T& getComponent(Entity entity) { checkComponentType<T>(); return getComponentContainer<T>()->get(entity); } 

getComponents अनुरोधित घटकों के लिंक का एक टपल देता है। ऐसा करने के लिए, यह std::tie और एक कनवल्शन एक्सप्रेशन का उपयोग करता है:

 template<typename ...Ts> std::tuple<Ts&...> getComponents(Entity entity) { checkComponentTypes<Ts...>(); return std::tie(getComponentContainer<Ts>()->get(entity)...); } 

addComponent और removeComponent आवश्यक घटक कंटेनर के अनुरोध को पुनर्निर्देशित करते हैं, और फिर onEntityUpdated सिस्टम onEntityUpdated कॉल करते हैं:

 template<typename T, typename... Args> void addComponent(Entity entity, Args&&... args) { checkComponentType<T>(); getComponentContainer<T>()->add(entity, std::forward<Args>(args)...); // Send message to systems const auto& bitset = mEntities.getBitset(entity); for (auto& system : mSystems) system->onEntityUpdated(entity, bitset); } template<typename T> void removeComponent(Entity entity) { checkComponentType<T>(); getComponentContainer<T>()->remove(entity); // Send message to systems const auto& bitset = mEntities.getBitset(entity); for (auto& system : mSystems) system->onEntityUpdated(entity, bitset); } 

अंत में, getOwner आवश्यक कंटेनर घटक के अनुरोध को पुनर्निर्देशित करता है:

 template<typename T> Entity getOwner(const T& component) const { checkComponentType<T>(); return getComponentContainer<T>()->getOwner(component); } 

यह मेरा पहला कार्यान्वयन था। इसमें कोड की केवल 357 लाइनें हैं। इस धागे में सभी कोड मिल सकते हैं।

प्रोफाइलिंग और बेंचमार्क

मानक

अब मेरे पहले ईसीएस कार्यान्वयन को बेंचमार्क करने का समय है!

यहाँ परिणाम हैं:




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

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

कैश छूट जाता है

कैश मिस की संख्या की जांच करने के लिए, मैंने यहां से लिया गया कैशग्रिंड उदाहरण दिया ।

यहाँ 10,000 संस्थाओं के लिए परिणाम है:

==1652== D refs: 277,577,353 (254,775,159 rd + 22,802,194 wr)
==1652== D1 misses: 20,814,368 ( 20,759,914 rd + 54,454 wr)
==1652== LLd misses: 43,483 ( 7,847 rd + 35,636 wr)
==1652== D1 miss rate: 7.5% ( 8.1% + 0.2% )
==1652== LLd miss rate: 0.0% ( 0.0% + 0.2% )

यहाँ 100,000 संस्थाओं के लिए परिणाम है:

==1738== D refs: 2,762,879,670 (2,539,368,564 rd + 223,511,106 wr)
==1738== D1 misses: 207,415,181 ( 206,902,072 rd + 513,109 wr)
==1738== LLd misses: 207,274,328 ( 206,789,289 rd + 485,039 wr)
==1738== D1 miss rate: 7.5% ( 8.1% + 0.2% )
==1738== LLd miss rate: 7.5% ( 8.1% + 0.2% )

परिणाम बहुत अच्छे हैं। यह थोड़ा अजीब है कि 100,000 संस्थाओं में इतने सारे LLD मिस क्यों हैं।

रूपरेखा

यह समझने के लिए कि वर्तमान कार्यान्वयन के किन हिस्सों में अधिक समय लगता है, मैंने उदाहरण को गैर-लाभकारी माना है ।

यहाँ परिणाम है:

Flat profile:

Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
57.45 1.16 1.16 200300000 0.00 0.00 std::__detail::_Map_base<unsigned int, std::pair<unsigned int const, unsigned int>, std::allocator<std::pair<unsigned int const, unsigned int> >, std::__detail::_Select1st, std::equal_to<unsigned int>, std::hash<unsigned int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true>, true>::operator[](unsigned int const&)
19.31 1.55 0.39 main
16.34 1.88 0.33 200500000 0.00 0.00 std::_Hashtable<unsigned int, std::pair<unsigned int const, unsigned int>, std::allocator<std::pair<unsigned int const, unsigned int> >, std::__detail::_Select1st, std::equal_to<unsigned int>, std::hash<unsigned int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_find_before_node(unsigned long, unsigned int const&, unsigned long) const
3.96 1.96 0.08 300000 0.00 0.00 std::_Hashtable<unsigned int, std::pair<unsigned int const, unsigned int>, std::allocator<std::pair<unsigned int const, unsigned int> >, std::__detail::_Select1st, std::equal_to<unsigned int>, std::hash<unsigned int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_insert_unique_node(unsigned long, unsigned long, std::__detail::_Hash_node<std::pair<unsigned int const, unsigned int>, false>*)
2.48 2.01 0.05 300000 0.00 0.00 unsigned int& std::vector<unsigned int, std::allocator<unsigned int> >::emplace_back<unsigned int&>(unsigned int&)
0.50 2.02 0.01 3 3.33 3.33 std::_Hashtable<unsigned int, std::pair<unsigned int const, unsigned int>, std::allocator<std::pair<unsigned int const, unsigned int> >, std::__detail::_Select1st, std::equal_to<unsigned int>, std::hash<unsigned int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::~_Hashtable()
0.00 2.02 0.00 200000 0.00 0.00 std::_Hashtable<unsigned int, std::pair<unsigned int const, unsigned int>, std::allocator<std::pair<unsigned int const, unsigned int> >, std::__detail::_Select1st, std::equal_to<unsigned int>, std::hash<unsigned int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::find(unsigned int const&)

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

ग्रिप के अनुसार, इस कार्यान्वयन में स्पष्ट अड़चन std::unordered_map । यदि हम इसे अनुकूलित करना चाहते हैं, तो यह उनसे छुटकारा पाने की कोशिश करने के लायक है।

के साथ तुलना std::map

मैं प्रदर्शन के बीच अंतर के बारे में उत्सुक हो गया , std::unordered_mapऔर std::mapइसलिए मैंने कोड के std::unordered_mapसाथ सब कुछ बदल दिया std::map। यह कार्यान्वयन यहाँ उपलब्ध है।

यहाँ बेंचमार्क परिणाम हैं:




हम देख सकते हैं कि इस बार कार्यान्वयन संस्थाओं की संख्या में वृद्धि के साथ अच्छी तरह से पैमाने पर नहीं है। और यहां तक ​​कि 1000 संस्थाओं के साथ, यह संस्करण सी के रूप में पुनरावृत्तियों में दोगुना है std::unordered_map।

निष्कर्ष

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

अगले भाग में हम कैसे बदल कर उत्पादकता बढ़ाने के लिए दिखाई देगा std::unordered_mapपर std::vector। इसके अलावा, हम दिखाएंगे कि कैसे स्वचालित रूप से आईडी प्रकार के घटकों को असाइन करना है।

Std की जगह :: unordered_map std के साथ :: वेक्टर

जैसा कि हमने देखा, वे std::unordered_mapहमारे कार्यान्वयन में एक अड़चन थे। इसलिए, std::unordered_mapहम इसके बजाय में और वैक्टर के mEntityToComponentलिए उपयोग करते हैं ।ComponentContainermEntityToManagedEntitySystemstd::vector

परिवर्तन

परिवर्तन बहुत सरल होंगे, आप उन्हें यहां देख सकते हैं ।

तथ्य यह है कि में केवल सूक्ष्मता झूठ vectorमें mEntityToComponentऔर mEntityToManagedEntityकाफी देर तक सूचकांक करने के लिए किसी भी संस्था की गई है। इस आसान तरीका करने के लिए, मैं इन स्टोर करने के लिए फैसला किया है vectorमें EntityContainer, जिसमें हम अधिकतम आईडी इकाई पता है। फिर मैं vectorइकाई प्रबंधक में संदर्भ या सूचक द्वारा घटक कंटेनरों में वैक्टर पास करता हूं ।

इस धागे में संशोधित कोड पाया जा सकता है ।

परिणाम

आइए देखें कि यह संस्करण पिछले एक से बेहतर कैसे काम करता है:




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

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

अब देखते हैं कि इससे कैश की संख्या में कमी आती है या नहीं।

यहाँ 10,000 संस्थाओं के साथ कैशग्रिंड का आउटपुट है: और यहाँ 100,000 संस्थाओं के लिए आउटपुट है: हम देखते हैं कि यह संस्करण लगभग तीन गुना कम लिंक बनाता है और चार बार कम कैश मिस करता है।

==1374== D refs: 94,563,949 (72,082,880 rd + 22,481,069 wr)
==1374== D1 misses: 4,813,780 ( 4,417,702 rd + 396,078 wr)
==1374== LLd misses: 378,905 ( 9,626 rd + 369,279 wr)
==1374== D1 miss rate: 5.1% ( 6.1% + 1.8% )
==1374== LLd miss rate: 0.4% ( 0.0% + 1.6% )



==1307== D refs: 938,405,796 (715,424,940 rd + 222,980,856 wr)
==1307== D1 misses: 51,034,738 ( 44,045,090 rd + 6,989,648 wr)
==1307== LLd misses: 5,866,508 ( 1,997,948 rd + 3,868,560 wr)
==1307== D1 miss rate: 5.4% ( 6.2% + 3.1% )
==1307== LLd miss rate: 0.6% ( 0.3% + 1.7% )

ऑटो प्रकार

अंतिम सुधार मैं बात करूँगा घटक प्रकार के पहचानकर्ताओं की स्वचालित पीढ़ी।

परिवर्तन

आईडी प्रकार की स्वचालित पीढ़ी को लागू करने के लिए सभी परिवर्तन यहां पाए जा सकते हैं ।

प्रत्येक प्रकार के घटक के लिए एक अद्वितीय आईडी असाइन करने में सक्षम होने के लिए, आपको CRTP और एक स्थैतिक फ़ंक्शन के साथ उपयोग करने की आवश्यकता है:

 template<typename T> class Component { public: static const std::size_t type; }; std::size_t generateComponentType() { static auto counter = std::size_t(0); return counter++; } template<typename T> const std::size_t Component<T>::type = generateComponentType(); 

आप देख सकते हैं कि टाइप आईडी अब रनटाइम पर उत्पन्न हुई है, और यह पहले संकलन समय पर जाना जाता था।

परिवर्तनों के बाद का कोड इस थ्रेड में पाया जा सकता है ।

परिणाम

इस संस्करण के प्रदर्शन का परीक्षण करने के लिए, मैंने बेंचमार्क का संचालन किया:




निर्माण और विलोपन के लिए, परिणाम लगभग समान थे। हालांकि, आप देख सकते हैं कि चलना थोड़ा धीमा हो गया है, लगभग 10%।

इस मंदी को इस तथ्य से समझाया जा सकता है कि संकलनकर्ता संकलन समय पर टाइप पहचानकर्ताओं को जानता था, जिसका अर्थ है कि यह कोड को बेहतर ढंग से अनुकूलित कर सकता है।

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

आगे के सुधार के लिए विचार

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

घटकों और प्रणालियों की गतिशील संख्या

टेम्पलेट पैरामीटर के रूप में घटकों और प्रणालियों की अधिकतम संख्या को अग्रिम में इंगित करना असुविधाजनक है। मुझे लगता है कि इसे बदलना संभव हो जाएगा std::arrayमें EntityManagerपर std::vectorएक मजबूत प्रदर्शन गिरावट के बिना।

हालांकि, इसे std::bitsetसंकलन समय पर बिट्स की संख्या जानने की आवश्यकता होती है। जब मैं बदल कर इस समस्या को ठीक लगता है std::vector<bitset<ComponentCount>>में EntityContainerपर std::vector<char>और बाइट्स के लिए पर्याप्त संख्या में जारी सभी संस्थाओं के टुकड़े के सेट का प्रतिनिधित्व करने के। फिर हम एक हल्के वर्ग को लागू करते हैं BitsetViewजो इनपुट पर प्राप्त होता है बिट्स के सेट की शुरुआत और अंत में पॉइंटर्स की एक जोड़ी होती है, और फिर std::bitsetइस मेमोरी रेंज में सभी आवश्यक संचालन करते हैं ।

एक और विचार: अब बिट सेट का उपयोग न करें और केवल यह देखने के लिए जांचें mEntityToComponentकि इकाई में घटक हैं या नहीं।

सरलीकृत घटक पुनरावृत्ति

फिलहाल, यदि सिस्टम इसे लागू करने वाली संस्थाओं के घटकों के आसपास चलना चाहता है, तो हमें इसे इस तरह से करने की आवश्यकता है:

 for (const auto& entity : getManagedEntities()) { auto [position, velocity] = mEntityManager.getComponents<Position, Velocity>(entity); ... } 

अगर हम ऐसा कुछ कर सकते हैं तो यह बहुत आसान और सरल होगा:

 for (auto& [position, velocity] : mEntityManager.getComponents<Position, Velocity>(mManagedEntities)) { ... } 

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



EntityRangeViewstd::vectorbeginend

घटना प्रबंधन अनुकूलन

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

क्षति को कम करने के लिए, हम उदाहरण के लिए, डेटा संरचना में निर्दिष्ट प्रकार के घटकों में रुचि रखने वाले सिस्टम को इंगित कर सकते हैं std::array<std::vector<System<ComponentCount, SystemCount>>, ComponentCount>। फिर, किसी घटक को जोड़ते या हटाते समय, हम बस onEntityUpdatedइस घटक में रुचि रखने वाले सिस्टम की विधि को कहेंगे ।

सिस्टम के बजाय इकाई प्रबंधक द्वारा प्रबंधित संस्थाओं के सब्सक्रिप्शन

मेरे अंतिम विचार से पुस्तकालय की संरचना में और अधिक व्यापक परिवर्तन होंगे।

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

सिस्टम केवल एक इकाई प्रबंधक के लिए अपनी आवश्यकताओं की घोषणा कर सकता है। फिर इकाई प्रबंधक सभी अलग-अलग उपसमुच्चय संस्थाओं को संग्रहीत करेगा। अंत में, सिस्टम समान सिंटैक्स का उपयोग करके संस्थाओं को क्वेरी करेगा:

 for (const auto& entity : mEntityManager.getEntitiesWith<Position, Velocity>()) { ... } 

निष्कर्ष

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

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

मुझे उम्मीद है कि यह लेख आपके लिए दिलचस्प या उपयोगी था।

अतिरिक्त पढ़ने

इकाई-घटक-प्रणाली पैटर्न के अधिक गहन अध्ययन के लिए यहां कुछ उपयोगी संसाधन हैं:

• मिशेल कैन, लेखक entt , इकाई घटक-सिस्टम कहा जाता के बारे में लेख की एक बहुत ही दिलचस्प श्रृंखला लिखा ईसीएस वापस और आगे ।
• एंटिटी सिस्टम विकी में बहुत उपयोगी जानकारी और लिंक शामिल हैं।