मैं और मेरी प्रेमिका का पहला वीडियो गेम। एकता के साथ विकास। भाग 1

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



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



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

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




ईमानदार होने के लिए, हम यह भी याद नहीं कर सकते हैं कि हमें पहले चरण में इतने सारे स्तर बनाने के लिए क्या प्रेरित किया है, लेकिन हमारे पास जो है वह है, और इसलिए पहली रिलीज में 95 स्तर शामिल थे। यह सच बताने के लिए बहुत दूर है, और हमें इसका पछतावा है। पछतावा क्यों? क्योंकि खेल पूरी तरह से तैयार नहीं था और रिलीज के बाद कई चीजें बदल गई थीं। ऐसा लग रहा था कि हम ग्राउंडहोग डे में फंस गए हैं, क्योंकि हमें 95 में से हर स्तर पर बदलाव करने की जरूरत है। सभी स्तरों पर दो महीने तक लगातार काम किया गया। फिर भी वे स्तर 100% तैयार नहीं थे लेकिन हम वहाँ से बहुत दूर नहीं थे। सबसे उत्पादक दिनों में 10 स्तर आसानी से सिर से कागज और बाद में दृश्य में स्थानांतरित किए गए थे। लेकिन ऐसे दिन भी थे जब आपको लगता है कि आप कैलिफ़ोर्निया के हैंक मूडी हैं, जो लेखक के ब्लॉक से ग्रस्त है, और आपको लगता है कि आप नीचे से टकराए हैं, लेकिन नया दिन नए विचारों को लाता है।

दृश्य घटक के संबंध में, यह थोड़ा कठिन था। अधिकांश खेलों की तरह ड्राइंग को ऑफ-स्क्रीन सतह पर देशी की तुलना में कम और प्राथमिक सतह पर फफोले के साथ किया जाता है, लेकिन बेहतर स्पष्टता और पठनीयता के लिए यूआई को बिना किसी बदलाव के तैयार किया जाता है। इस प्रकार, हम दो दुनियाओं में से सर्वश्रेष्ठ प्राप्त करते हैं - एक धुंधली यूआई नहीं, और खेल में एक प्रदर्शन भारी रेंडर नहीं। कई प्रयोगों के बाद हमने एंटीएलियासिंग के लिए 2x MSAA + FXAA चुना, क्योंकि वे कम से कम संसाधनों के साथ सबसे अच्छी तस्वीर देते हैं। हमने उचित रूप से निष्कर्ष निकाला है, कि एक तार्किक गेम को 60 फ्रेम प्रति सेकंड की आवश्यकता नहीं है, और पहिया को सुदृढ़ करने और फ्रेम सीमा को 30fps पर सेट करने का निर्णय नहीं लिया (यहां तक ​​कि कंसोल आमतौर पर ऐसा करते हैं)। फ्रेम की सीमा निर्धारित करने का न केवल ऊर्जा खपत पर, बल्कि फोन के गर्म होने पर भी सकारात्मक प्रभाव पड़ता है, जो ओवरहीटिंग के कारण फोन को थ्रॉटलिंग से बचाता है।

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



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



खेल में छाया (मोबाइल संस्करण में) पूरी तरह से quads के होते हैं जो बस हाथ से व्यवस्थित होते हैं, क्योंकि हम मोबाइल संस्करण में वास्तविक छाया नहीं जोड़ना चाहते हैं। कारणों में से एक OpenGLES 2.0 के साथ मोबाइल प्लेटफार्मों पर नरम छाया की अनुपस्थिति है, और निश्चित रूप से, कमजोर उपकरणों पर प्रदर्शन में गिरावट।



जैसा कि पहले उल्लेख किया गया था, हमने एंटी-अलियासिंग के लिए 2x MSAA + FXAA का उपयोग किया, लेकिन यह सब नहीं है! हमने अपनी पोस्ट प्रोसेसिंग में AmplifyColor को भी जोड़ा, क्योंकि यह उचित धन के लिए एक बड़ी संपत्ति है जो आपको पोस्ट प्रोसेसिंग पर अलग-अलग Lut-s लागू करने की अनुमति देता है। एक उचित रूप से चयनित लट चित्र को बेहतर बनाता है। विकास प्रक्रिया के दौरान हमने मानक एकता पोस्ट प्रोसेसिंग स्टैक सहित विभिन्न तरीकों की कोशिश की, लेकिन निर्माण में इसके शेड्स और विकल्प वास्तव में बहुत अधिक ले गए। कुछ समाधान बहुत सुंदर थे, लेकिन उन्होंने बहुत ताज़ा फोन पर बहुत खराब तरीके से काम किया (मेरा विश्वास करो, अगर आपको लगता है कि सभी के पास अब कम से कम 'सामान्य' फोन है, तो आप गलत हैं। बड़ी संख्या में लोग अभी भी $ 40 चीनी फोन रखते हैं और शिकायत करते हैं। टिप्पणियों में आपको बताया गया है कि आपका DOOM उनके कचरे पर ठीक नहीं चल रहा है)।

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

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



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

यदि हम उदाहरण के लिए Firebase में एक डिक्शनरी ऑब्जेक्ट पास करते हैं:

var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 2, new SlotState() }; 

जब हम इसे डेटाबेस से पढ़ते हैं, तो हमें Json ऑब्जेक्ट नहीं मिलेगा, बल्कि Json (क्या?) की एक सरणी मिलेगी।
ठीक है, ठीक है, हम हर जगह सूचियों का उपयोग करेंगे और समस्या नहीं होगी, है ना? लेकिन यह सही नहीं हुआ।

अगर हम फायरबेस में लिखते हैं:

 var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 100500, new SlotState() }; 

या यहां तक ​​कि:

 var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, null }, { 2, new SlotState() }; 

जब हम इसे डेटाबेस से पढ़ते हैं, तो हम चाबियाँ और मूल्यों के साथ एक Json ऑब्जेक्ट प्राप्त करेंगे।

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

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

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