क्रॉस प्लेटफॉर्म चंदेलियर

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

रुचि रखते हैं? कट के नीचे आओ!

कार्य

तो, मंच का चयन किया जाता है, कलाकार भी सरल और स्पष्ट प्रतीत होते हैं, क्षितिज पर कोई भी दृश्यमान समस्या नहीं दिखाई देती है।
विकास को सशर्त रूप से 2 भागों में विभाजित किया जा सकता है - बैकएंड (बाद में तर्क के रूप में संदर्भित) और फ्रंटेंड (प्लेटफ़ॉर्म सुविधाओं के साथ जीयूआई, इसके बाद ग्राहक के रूप में संदर्भित)। यूनिटी 3 डी को प्लेटफॉर्म के रूप में चुना गया था (यह पाठ में आगे कैसे होगा ताकि वे रीब्रांडिंग और "3 डी" इकाइयों की कमी के बारे में बात न करें)। तर्क पहले ही लिखा जा चुका है और पूरी तरह से काम कर रहा है। एकमात्र समस्या यह थी कि जिस भाषा में तर्क लिखा गया था वह जावा थी, और चयनित मंच के लिए केवल C # या JS ही उपयुक्त था। तदनुसार, मुख्य कार्य मौजूदा कोड को वैध सी # कोड में पोर्ट करना था, जबकि कार्यक्षमता एक से एक बनाए रखना।
क्लाइंट का हिस्सा भी पहले ही लागू हो चुका है, लेकिन तर्क की तरह, यह एंड्रॉइड में GUI के कार्यान्वयन के लिए सख्ती से बंधा हुआ था। तदनुसार, ग्राहक को स्कैच से लिखना पड़ता था, तकनीकी रूप से सक्षम टीके के अनुसार वाक्यांश के रूप में "ताकि यह एंड्रॉइड संस्करण में जैसा हो" :)

तर्क पोर्टिंग

यह कार्य न्यूनतम पुनर्लेखन के साथ जल्दी से जल्दी करना था। लेकिन समस्याओं की एक पूरी श्रृंखला अभी भी सामना करना पड़ा।

C # में, किसी भी प्रकार का enum नहीं है, और हमारे वरीयता में इस प्रकार का बहुत व्यापक रूप से उपयोग किया गया था: कार्ड सूट और रैंक, कार्ड खुद, सम्मेलनों, दांव और सीटी, गेम स्टेट्स। कुछ मामलों में, हम C # में मानक एनम के साथ प्राप्त करने में कामयाब रहे। लेकिन ज्यादातर मामलों में, एनम केवल एन्यूमरेटेड प्रकारों से अधिक थे: डेटा की एक किस्म उनके लिए बाध्य थी और सहायक तरीके थे। मैं पोर्टेड कोड में यह सब नहीं खोना चाहता था। परिणामस्वरूप, C # के लिए एक न्यूनतम समान जावा वर्ग Enum बनाया गया था। सभी मूल एनुम-एस पिछले डेटा और कार्यक्षमता के संरक्षण के साथ अलग-अलग वर्ग बन गए, सी # से सामान्य एनुम-एस उनके साथ जुड़े थे, जिन्होंने अनुक्रम (Enum.ordinal () विधि) और एनुमेरेटेड नाम (Enum.name) () सेट किया, साथ ही साथ। स्विच में उपयोग किया जाता है।

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

C # में सरणियों के समृद्ध चयन के बावजूद, वहाँ कोई समान जावा कार्यक्षमता नहीं थी। समस्या यह है कि प्रपत्र int [] [] की एक सरणी नए int [10] [20] जैसे एकल ऑपरेटर द्वारा नहीं बनाई जा सकती है। हर जगह आयताकार सरणियों में जाना संभव नहीं था, कुछ मामलों में, अलग-अलग उपयोग किए गए थे। मुझे सहायक तरीके लिखने थे जो पूरी तरह से एक बहुआयामी सरणी बनाते थे।

अन्य अप्रिय असुविधाएँ थीं:

• स्विच..केस, डिफ़ॉल्ट सहित, बहुत अंतिम स्थिति में भी ब्रेक की आवश्यकता;
• बूल के साथ बूलियन का सामूहिक प्रतिस्थापन;
• अंतिम सफाई, या आसानी से / सील के साथ प्रतिस्थापन;
• अहस्ताक्षरित प्रकार की उपस्थिति के कारण दाईं ओर एक अहस्ताक्षरित शिफ्ट की अनुपस्थिति (>>>);
• गोटो ऑपरेटर, जो जावा नेस्टेड लूप में संक्रमण का प्रबंधन करता है, लेकिन सी # में अपने प्राचीन उद्देश्य को बरकरार रखता है।

लेकिन यह सब संकलक द्वारा पता चला था। लेकिन जावा प्रतीकात्मक प्रकार के बाइट को काटने और बिना किसी मदद के इसे C # से एनालॉग एनालॉग में बदलने के लिए आवश्यक था।

ग्राहक कार्यान्वयन

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

सभी सामग्री को तार्किक समूहों में सॉर्ट किया गया और 2048x2048 डॉट्स प्रति एटर्स के प्रतिबंध के आधार पर एटलस में एकत्र किया गया:


शहर के आइकन का एटलस (अभी भी कम से कम 6 शहरों के लिए एक जगह है)।


सभी "स्क्रीन" पर उपयोग किए जाने वाले मुख्य नियंत्रणों का एटलस।

ग्राफिक सामग्री के इस तरह के एक संगठन ने पीक में 15 तक ड्रॉ कॉल्स की संख्या को कम करने की अनुमति दी (उदाहरण के लिए, जब एक स्क्रॉल बिड पैनल खोलना और दृश्य सेटिंग्स के साथ एक मेनू खोलना)।

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

• संदर्भ समाधान सेट करें (1280x800 चुना गया था);
• जगह नियंत्रित करती है कि उन्हें सही कैसे दिखना चाहिए;
• आनुपातिक स्केलिंग / रिपोजिशनिंग के लिए नियंत्रण सहायकों पर लटका;
• लाभ।

किसी भी रिज़ॉल्यूशन पर लॉन्च किए जाने पर, स्क्रीन की ऊँचाई को हमेशा 800 आभासी बिंदुओं के बराबर माना जाता है, और पहलू के आधार पर चौड़ाई भिन्न होती है। शुरुआत में मदद करने वाले पुराने पहलू और नए के बीच के संबंध पर विचार करते हैं, परिणाम के अनुसार वे प्रदर्शन और ज़ूमिंग करते हैं।

संदर्भ संकल्प (1280x800)।


व्यापक पहलू (1136640) - धारियां किनारों पर दिखाई देती हैं।


एक ही संकल्प (1136x640), सहायकों के काम करने का परिणाम - यह देखा जा सकता है कि नियंत्रण आनुपातिक रूप से व्यापक रखे गए हैं, और पृष्ठभूमि को छोटा किया गया है।

नतीजतन, सब कुछ संदर्भ रिज़ॉल्यूशन पर किया गया था + संकरे पहलू पर परीक्षण किया गया (4: 3)।

नियंत्रण के गैर-मानक व्यवहार को लागू करना भी आवश्यक था, जो एकीकृत संदेश प्रणाली एनजीयूआई के लिए धन्यवाद, अपेक्षाकृत सरल निकला। यह है कैसे LongPress बटन, क्लिपिंग के साथ रेंगने की रेखा, और ग्रिड तत्वों के एनिमेटेड repositioning के साथ लागू किया गया। मुझे परियोजना के अनुकूलन के लिए मानक घटकों के स्थानों के एक जोड़े को पैच करना था (UIPopup निर्दिष्ट माता-पिता में पॉप-अप भाग प्रदर्शित करने में सक्षम था, और वर्तमान एक में नहीं - UIPANP घटकों द्वारा पॉप-अप सामग्री की क्लिपिंग के साथ समस्याओं को हल किया गया था। बच्चे द्वारा स्क्रॉल पैनल को केंद्रित करना अक्षम तत्वों और अन्य को अनदेखा करना सीखा; छोटे सुधार)।

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

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

बाहरी सिस्टम

इसमें विज्ञापन प्लेटफ़ॉर्म और GoogleAnalytics के कुछ कार्यों के लिए आईएपी-कार्यक्षमता, बैनर विज्ञापन, टैप-क्लाइंट को इन-गेम मुद्रा प्राप्त करने के लिए मुफ्त में लागू करना शामिल हो सकता है।

Soom.la को मूल रूप से IAP ढांचे के रूप में चुना गया था: एक क्रॉस-प्लेटफॉर्म एपीआई, दो प्रमुख मोबाइल प्लेटफार्मों के लिए समर्थन, एंड्रॉइड स्टार्टअप स्टार्टअप पैचिंग के आसपास बैसाखी के बिना सहज एकीकरण, और यह सब कुछ भी नहीं है। यह प्राइम 31 डिवीजनों के एकीकरण की भयावहता की तुलना करने के लिए पर्याप्त है, जब उन्होंने अपने प्रियजनों के लिए विशेष रूप से मैनिफ़ेस्टोस को विशेष रूप से पीस लिया था + विभिन्न प्लेटफार्मों पर अलग-अलग एपीआई थे यह समझने के लिए कि यह ढांचा केवल शानदार है। भविष्य में (यदि एक winphone संस्करण की आवश्यकता है और soomla को नियमित समर्थन प्राप्त नहीं होता है), Unibill के लिए एक संक्रमण संभव है ।

Admob ने एक बैनर प्रदाता के रूप में काम किया, और http://www.neatplug.com के एक उत्पाद को इसके लिए ग्राहक के रूप में चुना गया। कारण एक ही है - आसान एकीकरण, एक एकीकृत एपीआई, दो मुख्य मोबाइल प्लेटफार्मों के लिए समर्थन, 2 प्लेटफार्मों के लिए सार्वभौमिक संस्करण की लागत $ 56 (प्राइम 31 के खिलाफ और प्रत्येक प्लेटफॉर्म के लिए $ 50 के लिए आईएपी के लिए ऊपर वर्णित जाम है)। ढांचे का पर्याप्त पर्याप्त व्यवहार नहीं पाया गया था जब बैनर पूरी तरह से अलग डीपीआई पर तैनात थे, इसलिए परिणामस्वरूप, यह स्क्रीन की सीमाओं के लिए मानक बंधन में खुद को सीमित करने का निर्णय लिया गया था।

साइट से एक मानक फ्रेमवर्क ने ही Tapjoy के लिए एक ग्राहक के रूप में काम किया। संपादक में सही काम के लिए कोड थोड़ा समाप्त हो गया था, सामान्य एकीकरण ने कोई समस्या नहीं पैदा की, यह एमुलेटर में बिल्ड की 4-5 शुरुआत से लॉग द्वारा घटनाओं की ट्रिगरिंग की जांच करने के लिए पर्याप्त था।

GoogleAnalytics वेब साइटों के लिए संस्करण से अनुकूलित, स्व-निर्मित है। परिणाम डब्ल्यूडब्ल्यूडब्ल्यू के माध्यम से एक क्रॉस-प्लेटफ़ॉर्म समाधान है जिसमें $ 50 के लिए विभिन्न प्लेटफार्मों के लिए पुस्तकालयों के मूल संस्करणों की आवश्यकता नहीं है।

इंटरफ़ेस तर्क और ग्राहक

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

लक्ष्य रनटाइम मुद्दे

एक अलग सूत्र में तर्क के काम के साथ, एक नहीं-तो-अच्छी कहानी हुई। जैसा कि आप जानते हैं, iOS पर किसी भी गैर-देशी कोड का उपयोग करने के लिए मना किया जाता है, इसलिए unity3d जब कोई प्रोजेक्ट निर्यात करता है तो AOT के माध्यम से प्रबंधित असेंबली चलाता है, आउटपुट लाइब्रेरी उत्पन्न करता है जो पहले से सिस्टम से जुड़े होते हैं + obj-c पर सभी प्रकार के ग्लपर रैपर को गोदी में जोड़ा जाता है। अच्छा। इसके अलावा, एमुलेटर के लिए एक अलग बिल्ड बनाया गया है, जिसमें जेआईटी है और सब कुछ काम करेगा क्योंकि यह संपादक में काम करता है - यह महत्वपूर्ण है, क्योंकि वास्तविक हार्डवेयर पर होने वाली त्रुटियां कभी भी संपादक या एमुलेटर में नहीं हो सकती हैं।
यानी वास्तव में, जब असली हार्डवेयर पर चल रहा है - परियोजना का कोई डिबगिंग नहीं है, केवल लॉग पर स्पर्श करें और टाई करें।
इसलिए, थ्रेड मुद्दे पर वापस जाएं। ऐसा लगता है कि सब कुछ काम कर गया, और फिर अचानक यह पूरी तरह से दुर्घटनाग्रस्त होने लगा, आवेदन पूरी तरह से गिर गया। Xcode लॉग्स के अनुसार, यह पता चला है कि थ्रेड से सो जाने के बाद दुर्घटना मोनो में चलती है। सोलेप () या Thread.Current.IsAlive यदि थ्रेड बाधित हुआ था (लेकिन हर बार नहीं)। यानी एक स्ट्रीम को बाधित करने के लिए एक प्रतीत होता है मानक प्रयास में मानक तरीकों की एक कॉल पर दुर्घटना। मज़ेदार बात यह है कि बिल्ड के जेआईटी संस्करण पर (उदाहरण के लिए, एंड्रॉइड, स्टैंडअलोन, वेबप्लेर) सब कुछ काम करना चाहिए जैसा कि हमें करना चाहिए। प्रहार विधि का उपयोग करके उपरोक्त विधियों का निर्धारण किया गया, जिससे दुर्घटना हुई। नतीजतन, धारा के मजबूर रुकावट को छोड़ने का फैसला किया गया था, और इसके बजाय तर्क को संकेत दिया कि यह समय समाप्त होने का समय होगा, और फिर धारा के बंद होने की प्रतीक्षा करें। क्रैश गायब हो गया और कभी वापस नहीं लौटा।

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

परीक्षण

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

यदि आप अच्छा करना चाहते हैं - तो स्वयं करें!

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

परिणाम

यूनिटी 3 डी वर्तमान में क्रॉस-प्लेटफॉर्म गेम बनाने के लिए सबसे अच्छा प्लेटफॉर्म है। हमें GUI बनाने में कोई विशेष समस्या नहीं हुई, हालाँकि विभिन्न प्लगइन्स का एकीकरण मूल रूप से अपेक्षित से अधिक लंबा था। इसके अलावा, प्लगइन्स या यूनीट 3 डी को स्वयं अपडेट न करें यदि सब कुछ आपके लिए काम करता है और सुखद शगल के लिए कोई अतिरिक्त दिन नहीं हैं। और यह मत भूलो कि कोई गारंटीकृत क्रॉस-प्लेटफॉर्म नहीं होगा, आपको सभी प्लेटफार्मों पर तर्क को डीबग करने के लिए तैयार होना चाहिए।
एंड्रॉइड के लिए, हमने अब तक क्रॉस-प्लेटफ़ॉर्म संस्करण का उपयोग नहीं करने का निर्णय लिया है, क्योंकि 2.2 और 2.3 के आधार पर डिवाइस (जो क्रमशः 4% और 10% उपयोगकर्ताओं द्वारा उपयोग किए जाते हैं), बस इसे बाहर न निकालें, आउटऑफमेरी से बाहर गिरते हुए। हम आशा करते हैं कि जल्द ही ये उपकरण अतीत की बात हो जाएंगे, जिससे ऑनलाइन संस्करण के विकास में सरलता आएगी।