🎥 😆 ♒️ मैं अपने घुटने पर एक इंडी गमेदेव-डेवलपर या राष्ट्रीय विकास की विशेषताएं कैसे बन गया 🏔️ 🚌 🤺

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

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

प्रागितिहास

आप लंबे समय तक इस बारे में बात कर सकते हैं कि एक gamedev डेवलपर के रूप में मेरा गठन कैसे हुआ - यह सब उबाऊ, थकाऊ और दिलचस्प नहीं है। मैं केवल इतना ही कह सकता हूं कि समय-समय पर मैंने जो कुछ भी किया, उससे मैं कभी नहीं थकता, मैं कभी भी चकित नहीं हुआ कि कितनी जंगली ऊर्जा और दृढ़ता है कि मैं अपनी खुद की "साइकिल" का आविष्कार करूं, और कभी-कभी वे सुंदर होते थे और समझने की कगार पर थे। वर्षों से, अनुभव आया है, विशिष्ट ज्ञान जमा हुआ है, आलस्य ने अधिक से अधिक प्रगति की है। आपके अपने गेम इंजन के निर्माण के कई अलग-अलग प्रयास थे (मुझे लगता है कि कम या ज्यादा प्रगति करने वाले हैलोवर्जन इस से गुजरे हैं)। GAPI (DX7 / 8/9 के बीच फेंकता है, बाद में OpenGL 1.1 / 2.1), प्रोग्रामिंग भाषाओं (C ++, C #) के तहत प्रयास किए गए थे। हालाँकि, यह सब आमतौर पर रेंडर और दृश्य ग्राफ के कार्यान्वयन से परे नहीं होता है - स्व-प्रेरणा एक बहुत ही अविश्वसनीय रूप से सहयोगी है। जैसे-जैसे समय बीतता गया, ओपनसोर्स के इंजनों को आज़माया गया, अलग-अलग सफलता के साथ अपने स्वयं के कुछ लिखने के विचारों को गहराई से चलाया गया।

इंजन चयन

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

टीम

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

लक्ष्य मंच

एंड्रॉइड को विकास के ~~मजाक के~~ लिए एक परीक्षण मैदान के रूप में चुना गया था: बाजार में प्रवेश करने के लिए एक छोटी सी कीमत (अब गूगल प्ले), एक कम प्रवेश सीमा और वर्तमान ग्रंथियों के लिए एक मोबाइल बाजार, जो अधिक दिलचस्प हो सकता है?

परियोजना

या PROEKT, यह क्या था, और अभी भी बना हुआ है। मुझे तुरंत कहना होगा कि हमारे पास विकास के लिए कोई अस्थायी योजना नहीं थी, भूमिकाओं को सिद्धांत रूप में सीमांकित नहीं किया गया था, सब कुछ बेतरतीब ढंग से हमारे खाली समय के शाम को किया गया था और हर दिन नहीं। यह डरावना लगता है, लेकिन यह काम करता है और टीम में कम संख्या में लोगों के कारण काम करता है, स्काइप के माध्यम से क्रियाओं का त्वरित समन्वय और नियमित रूप से आपसी मज़ाक। चूंकि हमने कभी साथ काम नहीं किया, इसलिए कुछ सरल चुनना तय किया गया था। पसंद बच्चों की परी कथा "जिंजरब्रेड मैन" पर गिर गई। यह मोबाइल उपकरणों पर बच्चों की किताबों की रसोई की हमारी अज्ञानता से किसी के लिए हास्यास्पद होगा, लेकिन फिर हमें यह लग रहा था कि यह सरल, दिलचस्प था, और हमें कामकाजी संबंध स्थापित करने की अनुमति देगा।
यह एक साधारण परी-कथा पुस्तक बनाने के लिए उबाऊ है, इसलिए इसे तुरंत इंटरैक्टिव बनाने का फैसला किया गया था: बच्चे का कार्य स्क्रीन पर उंगली पकड़ना था, पुस्तक का कार्य बच्चे को छूने और मनोरंजन करने के लिए प्रतिक्रिया देना था। वास्तव में, यह परियोजना के लिए सभी तकनीकी आवश्यकताएं थीं।
हम में से प्रत्येक को हमारे क्षेत्र में कुछ निश्चित ज्ञान था और पहले से ही कल्पना की थी कि यह कैसा और कैसा दिखेगा। कलाकार केवल 2 डी में आकर्षित करने में सक्षम था (लेकिन उसने इसे अच्छी तरह से किया), हमने बहस नहीं की, लेकिन डेटा पर चर्चा की कि मैं उसके साथ मिलूंगा। सभी कला मूल रूप से CorelDraw में बनाई गई थी और फ्लैश में आंशिक रूप से एनिमेटेड (जहां गैर-रैखिक एनीमेशन की आवश्यकता थी)। आउटपुट में, मुझे अल्फा के साथ png में स्प्राइट्स का प्रकीर्णन और एक पूर्वावलोकन छवि दी गई कि कलाकार के अनुसार सब कुछ कैसा दिखना चाहिए था। मुझे उपयोगकर्ता के साथ बातचीत करने के लिए यह सब, पुनर्जीवित और मजबूर करना पड़ा।
मुझे कहना होगा कि unity3d साधारण 2d के मामूली संकेत के बिना पूर्ण विकसित 3 डी इंजन है। यूनिटी 3 डी के लिए घटक बाजार पर (हां, एक है) स्प्राइट को लागू करने के लिए चार मुख्य प्रणालियां हैं। इन सभी में पैसा खर्च होता है, लेकिन जैसा कि पहले कहा गया था, मैं इसे खरीदने से बेहतर हूं, एक तरह की चुनौती होगी। सभी स्प्राइट सिस्टम को बस लागू किया जाता है: दो अक्ष स्क्रीन के विमान को परिभाषित करते हैं, तीसरा अक्ष स्प्राइट परतों के लिए गहराई बन जाता है। स्प्राइट्स एक बनावट-सुपरिम्पोज्ड कैमरा के लिए लंबवत हैं।
यह सरल लगता है, लेकिन वास्तव में, एक विशेषता को ध्यान में रखा जाना चाहिए - मोबाइल उपकरणों का बहुत कमजोर हार्डवेयर। ड्रैकल की संख्या (बाद में डीके के रूप में संदर्भित) (या ड्रिंडएक्सडप्रिमेटिव / ड्रैविलेसेस, जिसमें रेंडरिंग प्रक्रिया के दौरान यह सब आंतरिक रूप से अनुवादित है) के रूप में ऐसी कोई चीज है - प्रत्येक ऑब्जेक्ट को ग्राफिक एपीआई के लिए एक अलग कॉल द्वारा तैयार किया गया है। सब कुछ सरल है, लेकिन समस्या यह है कि अगर एक डेस्कटॉप पर ऐसे रेंडरिंग की संख्या 1000 तक पहुंच सकती है और अपेक्षाकृत आधुनिक हार्डवेयर चोक नहीं होता है, तो मोबाइल उपकरणों के लिए यह मान 20 के भीतर रखा जाना चाहिए। केवल 20 डीके! भगवान का शुक्र है, एकता में एक स्वचालित बैचिंग सिस्टम है (बैच - एक ही प्रकार के बहुत सारे डेटा पर एक ऑपरेशन करना, वास्तव में SIMD के लिए डेटा तैयार करना) - unity3d स्वतंत्र रूप से सामग्री के अनुसार ज्यामिति को सॉर्ट करता है (बनावट ब्लॉक की संख्या कम हो जाती है), ज्यामिति को बड़े संचय वाले शीर्ष बफ़र में जोड़ती है, जो तब वे प्रत्येक सामग्री के लिए एक समय पर तैयार होते हैं। नतीजतन, यदि आपके पास एक बनावट है, उदाहरण के लिए, शंकु और आप इस स्प्राइट का प्रचार करते हैं, तो एकता 3 डी एक डीसी में इन सभी स्प्राइट का अनुकूलन करेगा।
दूसरी अनुकूलन विधि बनावट एटलस का निर्माण है - कम सामग्री है, कम बनावट स्विच होंगे और कम डीसी। हमारे पास बहुत सारी कला थी और यह लगातार बदल रहा था - एक उपयोगिता को बनावट एटलस उत्पन्न करने के लिए लिखा गया था, और यह शेल के ही विस्तार के रूप में एकता 3 डी संपादक के अंदर किया गया था। सभी कलाओं को दृश्यों में क्रमबद्ध किया गया था, कई दृश्यों के आम दिन को एक अलग एटलस में रखा गया था। अब, जब कला बदल रही है, मैंने बस भविष्य के एटलस (सभी स्प्राइट्स, एनीमेशन के सभी चरणों सहित) की सामग्री के साथ एक फ़ोल्डर पर उपयोगिता सेट की है और आउटपुट पर मुझे एक ही बनावट + फ़ाइल मिली है जो इस बनावट के अंदर स्प्राइट्स की नियुक्ति का वर्णन करती है (फ्रेम नाम, क्षेत्र तस्वीर में निर्देशांक, एनीमेशन गति) , एनीमेशन का प्रकार - रैखिक / फ्लिप-फ्लॉप, आदि)।
रेंडर खुद सरल था: सभी ज्यामितीय प्रक्रियात्मक थे और पुनर्जीवित हो गए थे जब एनीमेशन फ्रेम बदल गया था (शीर्ष और बनावट निर्देशांक)। इन सभी चालों के परिणामस्वरूप, पुस्तक के कुछ दृश्य 4-5 डिक में खींचे जाते हैं, प्रदर्शन में नहीं आते हैं (वे स्मार्टफ़ोन पर भी अच्छी तरह से काम करते हैं, न केवल टैबलेट) और अच्छे लगते हैं।
जब यह सब विकसित किया जा रहा था, 2 अप्रिय सुविधाओं की खोज की गई थी:

कलाकार के हाथों को हरा दें यदि वह चिकनी ढालों का उपयोग करता है - वे हार्डवेयर-समर्थित संपीड़न प्रारूपों जैसे कि डीएक्स 1/5, आदि में भयानक दिखते हैं। हमारे मामले में, सभी बनावटों को पूर्ण-विकसित 32-बिट बनावट atlases 1k x 1k में परिवर्तित किया जाना था - आप कल्पना कर सकते हैं कि यह रैम और फिलाट को कैसे प्रभावित करता है।
अगर आप स्प्राइट को मापेंगे, तो जान लें कि वेक्टर बैच 3 के अलावा अन्य पैमाने पर स्वचालित बैचिंग काम नहीं करती है। अनुकूलन के लिए यह बहुत महत्वपूर्ण है, हमारे पास कई ऑब्जेक्ट थे जो आकार में भिन्न होते हैं और कुल्हाड़ियों के साथ प्रतिबिंबित होते हैं - उनके लिए हमें ज्यामिति में अतिरिक्त पैमाने पर बेकिंग करना था और पैमाने को एक में रीसेट करना था। डायनामिक्स के लिए, यह कोड की महत्वपूर्ण जटिलता के कारण काम नहीं करता था - मुझे इसके साथ काम करना था और इसे कम से कम उपयोग करना था।

उपकरणों की विविधता

Android उपकरणों के पूरे चिड़ियाघर ने मुझे नहीं डराया। प्रारंभ में, डेवलपर / कलाकार के लिए पिक्सेल-सटीक खिलौनों के अभ्यास को शातिर और घातक के रूप में अपनाया गया था - हमारे पास अलग-अलग डीपीआई और पहलू अनुपात के लिए कई ग्राफिक्स पैकेज तैयार करने की क्षमता नहीं है। सब कुछ केवल एक मानक आकार के लिए विकसित किया गया था - 1024x600, परिदृश्य अभिविन्यास। सब कुछ जो इन आकारों में फिट नहीं था, स्वचालित रूप से यूनिटी 3 डी आभासी कैमरे तक पहुंच गया और 600 आभासी इकाइयाँ ऊँची हो गईं, चौड़ाई भी अनुपात रखती थी और लगभग हमेशा वास्तविक स्क्रीन के आकार से बड़ी होती थी, किनारों से काटकर (जो हमें अनुकूल होती है - किनारों से दूर महत्वपूर्ण वस्तुएं बन जाती हैं) )। व्यावहारिक रूप से, क्योंकि "एक्सपीरिया पी" पर आवेदन का परीक्षण करना संभव हो गया - पर्याप्त 1024 पिक्सेल चौड़ा नहीं था और किनारों पर धारियां थीं। एक विकल्प के रूप में जो सभी को अनुकूल करता है, पृष्ठभूमि को थोड़ी चौड़ाई (गुणांक 1.05) में फैलाने का निर्णय लिया गया - यह आंख के लिए अदृश्य है और स्क्रीन पर धारियों को समाप्त करता है जो बहुत लंबा है।

ध्वनि

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

प्रकाशन की तैयारी

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

प्रकाशन

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

हमने सिद्धांत रूप में ऐसा नहीं किया था - मैंने कुछ संसाधनों के लिए एक मिनी-समीक्षा (वास्तव में, एक विज्ञापन घोषणा) लिखी और इस पर शांत हो गया। हम इस तथ्य के लिए तैयार थे कि बच्चों की किताबें और यहां तक कि एंड्रॉइड पर, और यहां तक कि रूसी में भी, बहुत लोकप्रिय सामान नहीं थे, इसलिए किसी भी महत्वपूर्ण लाभ के लिए इंतजार करना बेवकूफी है। यह भी ध्यान दिया गया कि लोग सिद्धांत में भुगतान करना पसंद नहीं करते हैं और अनुप्रयोगों के मुफ्त संस्करणों में टिप्पणियों को खराब करना पसंद करते हैं, ट्रिफ़ल्स के साथ गलती ढूंढते हैं, जो अनुप्रयोगों की रेटिंग को नकारात्मक रूप से प्रभावित करता है। यह एक मजबूत इरादों वाला निर्णय था - औसत कीमत पर केवल एक भुगतान किया संस्करण बनाने के लिए। बोर्ड एक प्रकार की प्रवेश सीमा बन गई है जो हमें ट्रॉल्स से बचाती है। इसका एक जादुई प्रभाव था: 4 दिनों में हमने 5 बिंदुओं के लिए 4 समीक्षाएँ और 4 बिंदुओं के लिए एक एकत्र किया, जिसने हमें हमारी श्रेणी में 13 वें स्थान पर और नए भुगतान किए गए अनुप्रयोगों के सामान्य शीर्ष में 17 वां स्थान दिया। और यह इस समय 56 प्रतियों और 5 टिप्पणियों की बिक्री के साथ है! मैं यह नहीं समझता कि वे रेटिंग्स पर कैसे विचार करते हैं, लेकिन हम शीर्ष पर हैं और यह आनन्दित नहीं कर सकता।
जो लोग भुगतान नहीं करना चाहते थे, उन्होंने पीआर संसाधनों पर क्रोध किया, वहाँ धमकी दी गई कि वे टूटेंगे और चोरी करेंगे, लेकिन उन्होंने हमारी रेटिंग को बर्बाद नहीं किया।

परिणाम

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

ZY मैंने अपमानजनक शब्द नहीं लिखने की कोशिश की, ताकि यह बहुमत के लिए स्पष्ट हो, क्षमा करें, यदि ऐसा है।

मैं अपने घुटने पर एक इंडी गमेदेव-डेवलपर या राष्ट्रीय विकास की विशेषताएं कैसे बन गया