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

• प्रतिपादन;
• एसडीके के साथ काम करें;
• ऑपरेटिंग सिस्टम के साथ काम करना;
• नेटवर्क और संसाधनों के साथ।

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

यहां मैं बताना चाहता हूं कि हमने इन सभी सुविधाओं को कैसे पेश किया और हम क्या करने आए।

अब क्या है

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

हमारे पास दृश्य वस्तुएं हैं जो दृश्यों में संग्रहीत हैं। इन ऑब्जेक्ट्स में नोड्स होते हैं जो एक पदानुक्रम में व्यवस्थित होते हैं और प्रत्येक नोड में कई इकाइयाँ हो सकती हैं, जैसे:

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

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

/// @category(VSO.Basic) class SpriteComponent : public MaterialComponent { VISUAL_CLASS(MaterialComponent) public: /// @getter const std::string& GetId() const; /// @setter void SetId(const std::string& id); protected: void OnInit() override; void Draw() override; protected: /// @property Color _color = Color::WHITE; /// @property Sprite _sprite; }; 

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

स्वचालित क्रमांकन और संपादकों की पीढ़ी को न केवल उन संस्थाओं के लिए समर्थित किया जाता है जो किसी दृश्य ऑब्जेक्ट में संग्रहीत होते हैं, बल्कि किसी भी वर्ग के लिए भी। ऐसा करने के लिए, यह विशेष सीरियल क्लास से विरासत में मिला और टैग के साथ आवश्यक गुणों को चिह्नित करने के लिए पर्याप्त है। और यदि आप चाहते हैं कि वर्ग के उदाहरण पूर्ण संपत्ति हों (एकता से ScriptableObject का एक एनालॉग), तो वर्ग को एसेट वर्ग से विरासत में मिला होना चाहिए।

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

मुख्य ब्लॉक

कोड जनरेशन

काम करने के लिए कई प्रणालियों के लिए, आपको काफी नियमित कोड लिखने की आवश्यकता होती है, जो कि C ++ ( प्रतिबिंब - प्रोग्राम कोड में प्रकारों के बारे में जानकारी तक पहुंचने की क्षमता) में कमी के कारण आवश्यक है। इसलिए, हम इस तकनीकी कोड को जेनरेट करते हैं।

एक जेनरेटर पाइथन स्क्रिप्ट का एक सेट है जो हेडर फ़ाइलों को पार्स करता है और उनके आधार पर आवश्यक कोड उत्पन्न करता है। लचीली पीढ़ी सेटिंग्स के लिए, टिप्पणियों में विशेष टैग का उपयोग किया जाता है।

हम निम्नलिखित सबसिस्टम के लिए कोड उत्पन्न कर सकते हैं:

• सीरियलाइज़ेशन - डिस्क से या नेटवर्क पर संचारित करते समय डेटा को बचाने / लोड करने के लिए उपयोग किया जाता है। बाद में और अधिक विस्तार से विचार किया जाएगा।
• प्रतिबिंब पुस्तकालय के लिए बाइंडिंग - डेटा को संपादक को स्वचालित रूप से प्रदर्शित करने के लिए उपयोग किया जाता है। संपादक पर अध्याय में चर्चा की जाएगी।
• क्लोनिंग संस्थाओं के लिए कोड - संपादक में और खेल में संस्थाओं को क्लोन करने के लिए उपयोग किया जाता है।
• हमारे हल्के रनटाइम प्रतिबिंब के लिए कोड।

→ एक वर्ग के लिए उत्पन्न कोड का एक उदाहरण यहाँ पाया जा सकता है।

पार्सिंग सी ++

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

इसलिए, एक और समाधान पाया गया: CppHeaderParser । यह एक पायथन सिंगल-फाइल लाइब्रेरी है जो हेडर फ़ाइलों को पढ़ सकता है। यह बहुत आदिम है, #include का पालन नहीं करता है, मैक्रोज़ को छोड़ देता है, पात्रों को पार्स नहीं करता है, और बहुत जल्दी काम करता है।

हम अभी भी इस दिन का उपयोग करते हैं, हालांकि, हमें बग को ठीक करने और अपनी क्षमताओं का विस्तार करने के लिए उचित मात्रा में परिवर्तन करना था, विशेष रूप से, सी ++ 17 से नवाचारों के लिए समर्थन जोड़ा गया था।

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

कोड जनरेटर

पीढ़ी के साथ, सब कुछ सरल है। टेम्प्लेट से कुछ भी उत्पन्न करने के लिए बहुत सारे पुस्तकालय हैं। हमने टेंपलाइट + चुना, क्योंकि यह बहुत छोटा है, इसमें आवश्यक कार्यक्षमता है और यह ठीक से काम करता है।

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

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

क्रमबद्धता

क्रमांकन के लिए, विभिन्न पुस्तकालयों पर विचार किया गया: प्रोटोबॉफ़, फ्लेक्सबफ़र्स, अनाज, आदि।

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

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

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

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

संपादक

हम संपादकों के लिए ImGui पुस्तकालय का उपयोग करते हैं, जिस पर हमने सभी मुख्य संपादक खिड़कियां लिखी थीं: दृश्य सामग्री, फ़ाइल और संपत्ति दर्शक, संपत्ति निरीक्षक, एनीमेशन संपादक, आदि।

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

प्रतिबिंब पुस्तकालय - rttr

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

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

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

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

→ rttr में एक वर्ग घोषित करने के लिए एक उदाहरण कोड यहाँ पाया जा सकता है

इंस्पेक्टर

खुद संपादकों का कोड बहुत कम ही सीधे rttr के साथ काम करता है। सबसे अधिक इस्तेमाल की जाने वाली परत यह है कि ऑब्जेक्ट इसके लिए एक ImGui निरीक्षक आकर्षित करने में सक्षम है। यह हस्तलिखित कोड है जो rttr के डेटा के साथ काम करता है और इसके लिए ImGui नियंत्रण बनाता है।

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

इसके अलावा, निरीक्षक कोड संचालन रद्द करने का समर्थन करता है - जब मूल्यों को बदलते हुए, डेटा को बदलने के लिए एक कमांड बनाया जाता है, जिसे बाद में वापस रोल किया जा सकता है।

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

विंडोज और संपादकों

फिलहाल, हमारे संपादकों, कोड पीढ़ी और संपत्ति निर्माण प्रणालियों के आधार पर कई अलग-अलग उपप्रणालियों और संपादकों का निर्माण किया गया है:

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

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

संक्षेप में देना

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

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

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