हमने डेढ़ साल तक इंजन और उस पर खेल कैसे बनाया। भाग दो आधारभूत संरचना

पहले, पिछले लेख के निशान पर कुछ टिप्पणियां। हम वास्तव में वॉरगामिंग में काम करते थे, जहाँ हमने एक इंजन विकसित किया जिसे dava.framework या dava.engine के नाम से जाना जाता है। इसलिए, कई पुराने सहयोगी, जिनके साथ हम अभी भी अच्छे संबंधों में हैं, सक्रिय रूप से चर्चा में भाग लेते हैं।

कई लोगों को संदेह है: क्या यह वही तकनीक है या कोई और? उत्तर: यह खरोंच से लिखी गई एक नई तकनीक है।

हमने सिर्फ एक साल में कैसे प्रबंधन किया? हमारी टीम के पास विशाल अनुभव है। कई 15 वर्षों से इंजन और खेल विकसित कर रहे हैं।

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

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

और अब इस बिंदु पर: क्या उपकरण और तकनीकों ने हमें कम समय में इस महत्वाकांक्षी कार्य को पूरा करने में मदद की है?

आधारभूत संरचना

हमने Atlassian Bitbucket Server + Jenkins को चुना। बिटबकेट में मुख्य भंडार (मास्टर) है, जिसमें जेनकिन्स जुड़ा हुआ है। प्रत्येक डेवलपर का अपना कांटा होता है। प्रत्येक कार्य के लिए, कांटा में एक नया कांटा बनाया जाता है, जिसे पुल अनुरोध के माध्यम से वापस एकीकृत किया जाता है। सामान्य तौर पर, योजना सुंदर मानक है। प्रत्येक पुलब्रेक एक अनिवार्य समीक्षा और स्वचालित परीक्षणों से गुजरता है। और, सफल होने पर, यह स्वचालित रूप से गुरु में विलीन हो जाता है।

जेनकींस

जेनकिन्स की कई कमियां हैं: वह एक प्राचीन है, बहुत तेज नहीं, लसदार, वेब-थूथन 90 के दशक से एक इंटरनेट पोर्टल की तरह दिखता है। हालांकि, इसका लचीलापन, बड़ी संख्या में मॉड्यूल और फ्री-ऑफ-चार्ज 2019 में भी इसे एक अच्छा विकल्प बनाते हैं। मॉड्यूल और सेटिंग्स के साथ खेलने के बाद, आप एक पाचन उपस्थिति, पाइपलाइनों का एक घोषणात्मक विवरण (रिपॉजिटरी में झूठ बोलना) प्राप्त कर सकते हैं। वैसे, अब लगभग 40 पाइपलाइनें हैं: परीक्षण, संपादक, सभी प्लेटफार्मों के लिए एक खेल; सर्वर इंफ्रास्ट्रक्चर और मेटागेम के साथ काम करते हैं। यह सब 20 buildagentov लीजिए।

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

सिस्टम बनाएं

सिस्टम के लिए मुख्य आवश्यकता इस प्रकार थी: एक स्क्रिप्ट में आईओएस, मैकओएस, एंड्रॉइड, विंडोज, लिनक्स के लिए प्रोजेक्ट जनरेशन। हम प्रेमके, स्कोनस, बाजेल और सीमेक की कोशिश करने में कामयाब रहे। विभिन्न कारणों से, हम समय-परीक्षणित CMake पर रुक गए।

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

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

विकास की प्रक्रिया

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

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

निरंतर एकीकरण

जैसा कि ऊपर बताया गया है, डेवलपर के कांटे में प्रत्येक कार्य के लिए एक ब्रंच बनाया जाता है। अगला, इस ब्रंच से मुख्य रिपॉजिटरी तक एक पुल अनुरोध बनाया जाता है। यह पुल अनुरोध जेनकींस में स्वचालित परीक्षणों की एक श्रृंखला से गुजरता है:

1. सभी प्लेटफार्मों के लिए यूनिट परीक्षण (विंडोज़, लिनक्स, मैकोस, आईओएस, एंड्रॉइड)। Googletest का उपयोग आधार के रूप में किया जाता है, और OpenCppCoverage, जिसकी रिपोर्ट को अतिरिक्त अजगर स्क्रिप्ट द्वारा जांचा जाता है, का उपयोग कवरेज के प्रतिशत की जांच करने के लिए किया जाता है। यदि किसी विशेष फ़ाइल के लिए कवरेज का प्रतिशत 75% से कम है, तो परीक्षण विफल माना जाता है। इस प्रकार, हमने अधिकांश निम्न-स्तरीय इंजन वर्गों को परीक्षणों के साथ कवर किया है।
2. Codeformatter। C ++ कोड के लिए हम क्लैंग-फॉर्मेट का उपयोग करते हैं। परिवर्तित कोड का प्रारूपण सबसे पहले स्वचालित रूप से तब होता है जब डेवलपर की मशीन पर कमिट होता है, और फिर इसे परीक्षण में जांचा जाता है। जावास्क्रिप्ट के लिए, जिसे स्क्रिप्टिंग भाषा के रूप में उपयोग किया जाता है, npm लिंटर का उपयोग किया जाता है।
3. एसेट टेस्ट। परीक्षणों का एक बड़ा समूह: फ़ाइल स्वरूपों को मान्य करने से लेकर निर्भरता की जाँच करने के लिए (उदाहरण के लिए, जाँच करना कि खेल स्तर में प्रयुक्त बनावट मौजूद है)।
4. संपादक की इकाई और कार्यात्मक परीक्षण। इंजन का एक अभिन्न अंग संपादक है, जहां खेल के स्तर और अन्य संपत्ति बनाई और संपादित की जाती हैं। यूनिट परीक्षणों के अलावा, क्यूटी के लिए मेंढक स्क्विश का उपयोग संपादक का परीक्षण करने के लिए किया जाता है - स्वचालित जीयूआई परीक्षण के लिए एक उपयोगिता। यह सब हमें संपादक के मैनुअल परीक्षण के बिना करने की अनुमति देता है। इसके अलावा, कलाकारों और स्तरीय डिजाइनरों की समीक्षाओं के अनुसार, इसकी गुणवत्ता और स्थिरता का स्तर पिछली कंपनी की तुलना में अधिक है, जब हमारे पास पांच परीक्षकों की एक टीम थी। उसी समय, रिलीज़ प्रतिदिन होती हैं, और मैन्युअल परीक्षण के साथ, रिलीज़ हर 2 सप्ताह में होता है।
5. खेल के कार्यात्मक परीक्षण। यह स्पष्ट है कि मैं खेल के लिए स्वचालित कार्यात्मक परीक्षणों का उपयोग करना चाहता हूं। इसलिए, हमने निम्नलिखित प्रणाली विकसित करना शुरू किया:

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

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

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

आज तक, 6,600 पुल-क्वैस्ट इस तरह से बनाए और रखे गए हैं।

निरंतर वितरण

हम स्वचालित दैनिक (या बल्कि दैनिक) रिलीज की अवधारणा का उपयोग करते हैं। यह वास्तव में कैसे होता है:

1. git टैग बनाया गया है,
2. यह सभी परीक्षणों के पूर्ण संस्करण चलाता है,
3. यदि सफल हो, तो कलाकृतियों को एकत्र किया जाता है:

• MacOS और Windows के लिए संपादक। इस प्रकार, हर सुबह हर किसी के पास उपकरणों का एक ताजा संस्करण होता है। और, स्वचालित परीक्षणों के लिए धन्यवाद, हम उनकी निश्चित गुणवत्ता और स्थिरता में आश्वस्त हैं।
• सभी प्लेटफ़ॉर्म के लिए गेम क्लाइंट और सर्वर। IOS के लिए क्लाइंट को TestFlight, Android के लिए - Google Play पर, अन्य प्लेटफार्मों - JFrog Artifactory, गेम सर्वर और अन्य सेवाओं के लिए - क्लाउड पर अपलोड किया गया है। यही है, हर सुबह हमारे पास खेल का एक नया संस्करण है, जो परीक्षण और खेलने के लिए तैयार है।

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

1. प्रथम स्तर का परिचर। मुख्य भंडार में परीक्षणों की स्थिरता पर नज़र रखता है।
2. खेल पर दूसरा स्तर परिचर। खेल कीड़े की मरम्मत।
3. संपादकों पर दूसरा स्तर अटेंडेंट। संपादकीय बग को ठीक करता है, उपयोगकर्ताओं (कलाकारों, स्तरीय डिजाइनरों, गेम डिजाइनरों) को सलाह देता है।

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



अगले लेख में, हम इंजन के सॉफ्टवेयर आर्किटेक्चर, साथ ही साथ मुख्य मॉड्यूल और सबसिस्टम पर करीब से नज़र डालेंगे।

जारी रखने के लिए ...

पहला भाग: habr.com/en/post/461623