सरलतम इकाई घटक प्रणाली कार्यान्वयन

सभी को नमस्कार!

चौथी धारा "सी ++ डेवलपर" यहां से शुरू होती है, हमारे देश में सबसे सक्रिय पाठ्यक्रमों में से एक, वास्तविक बैठकों को देखते हुए, जहां न केवल "क्रूसेडर्स" दिमा शेबर्डेव के साथ बात करने के लिए आते हैं :) सामान्य तौर पर, पाठ्यक्रम पहले से ही बढ़ गया है हमारे देश में सबसे बड़े में से एक, यह अपरिवर्तित रहा है कि डिमा खुले सबक का आयोजन करता है और हम पाठ्यक्रम शुरू होने से पहले दिलचस्प सामग्री का चयन करते हैं।

चलो चलते हैं!

प्रविष्टि

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

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

ईसीएस

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

ठेठ सी ++ कार्यान्वयन

ECS कार्यान्वयन की पेशकश करने वाले कई पुस्तकालय हैं। आमतौर पर, वे सूची में से एक या अधिक आइटम शामिल करते हैं:

• GravitySystem : public ecs::System घटक प्रणाली के आधार घटक / प्रणाली का GravitySystem : public ecs::System ;
• टेम्पलेट्स का सक्रिय उपयोग;
• दोनों कि, और कुछ CRTP लुक में एक और;
• EntityManager वर्ग, जो निहितार्थ में संस्थाओं के निर्माण / भंडारण को नियंत्रित करता है।

कुछ त्वरित Google उदाहरण:

• अलेहोमस की संस्था ;
• redxdev की ईसीएस ;
• google का corgi (इसलिए मुझे पता चला कि google का ECS कार्यान्वयन है)।

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

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

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

मेरा सरल दृष्टिकोण

सार

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

 using EntityID = int64_t; //    , int64_t -   

इकाई घटक

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

इसलिए, मैं घटकों को इस प्रकार परिभाषित करता हूं:

 struct Position { float x; float y; }; struct Velocity { float x; float y; }; struct Health { int max; int current; }; template <typename Type> using ComponentMap = std::unordered_map<EntityID, Type>; using Positions = ComponentMap<Position>; using Velocities = ComponentMap<Velocity>; using Healths = ComponentMap<Health>; struct Components { Positions positions; Velocities velocities; Healths healths; }; 

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

 //given a Components instance c EntityID newID = /*obtain new entity ID*/; c.positions[newID] = Position{0.0f, 0.0f}; c.healths[newID] = Health{100, 100}; 

किसी दिए गए आईडी के साथ एक इकाई को नष्ट करने के लिए, हम बस .erase() प्रत्येक कार्ड से करते हैं।

प्रणाली

अंतिम घटक जो हमें चाहिए वह है सिस्टम। यह वह तर्क है जो किसी विशिष्ट व्यवहार को प्राप्त करने के लिए घटकों के साथ काम करता है। चूंकि मुझे चीजों को सरल करना पसंद है, इसलिए मैं सामान्य कार्यों का उपयोग करता हूं। ऊपर वर्णित स्वास्थ्य पुनर्जनन प्रणाली केवल अगला कार्य हो सकता है।

 void updateHealthRegeneration(int64_t currentFrame, Healths& healths) { if(currentFrame % 120 == 0) { for(auto& [id, health] : healths) { if(health.current < health.max) ++health.current; } } } 

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

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

 void updatePhysics(Positions& positions, const Velocities& velocities) { //   ,   N   //   ID,    . std::unordered_set<EntityID> targets = mapIntersection(positions, velocities); // target'     ,   //  ,       . for(EntityID id : targets) { Position& pos = positions.at(id); const Velocity& vel = velocities.at(id); pos.x += vel.x; pos.y += vel.y; } } 

या आप एक अधिक कॉम्पैक्ट सहायक लिख सकते हैं जो खोज के बजाय पुनरावृत्ति के माध्यम से अधिक कुशल पहुंच की अनुमति देता है।

 void updatePhysics(Positions& positions, const Velocities& velocities) { //   ,    //  .        //    . intersectionInvoke<Position, Velocity>(positions, velocities, [] (EntityID id, Position& pos, const Velocity& vel) { pos.x += vel.x; pos.y += vel.y; } ); } 

इस प्रकार, हमने एक नियमित ईसीएस की बुनियादी कार्यक्षमता के साथ खुद को परिचित किया।

लाभ

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

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

प्रतिबंध

लेकिन, किसी भी अन्य विधि की तरह, कुछ सीमाएं हैं। मेरे अनुभव में, यह किसी भी गैर-तुच्छ खेल में unordered_map का उपयोग करके सटीक रूप से ऐसा कार्यान्वयन है जो प्रदर्शन समस्याओं को जन्म देगा।

कई संस्थाओं के साथ unordered_map कई उदाहरणों पर महत्वपूर्ण चौराहों को अच्छी तरह से स्केल नहीं करता है क्योंकि आप वास्तव में N*M लुकअप कर रहे हैं, जहां N अतिव्यापी घटकों की संख्या है, M मिलान संस्थाओं की संख्या है, और unordered_map कैशिंग में बहुत अच्छा नहीं है। इस समस्या को unordered_map बजाय पुनरावृत्ति के लिए अधिक उपयुक्त कुंजी-मूल्य स्टोर का उपयोग करके ठीक किया जा सकता है।

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

अंत

यदि आपके पास प्रश्न और टिप्पणियां हैं, तो आप उन्हें यहाँ छोड़ सकते हैं या दीमा के साथ एक खुले पाठ में जा सकते हैं, उनकी बात सुन सकते हैं और पहले से ही पूछ सकते हैं।