मोबाइल फ्री-टू-प्ले गेम विकसित करते समय पांच चुनौतियां

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

1. क्रॉस-प्लेटफॉर्म

एक बार में कई प्लेटफार्मों पर चल सकने वाले एप्लिकेशन बनाने का विचार नए से बहुत दूर है। इन उद्देश्यों के लिए, जावा प्लेटफ़ॉर्म बनाया गया था, माइक्रोसॉफ्ट ने .NET और XNA का उपयोग करके विंडोज, एक्सबॉक्स और विंडोज मोबाइल 7 के लिए विकास समस्या को हल करने की कोशिश की। मोनो बनाया गया था, और .NET रेडमंड द्वारा उल्लिखित सीमाओं से परे चला गया। सामान्य तौर पर, भाले टूट गए, किसी न किसी रूप में क्रॉस-प्लेटफॉर्म दिखाई दिया। हालांकि, वास्तविकता यह है कि मोबाइल फ्री-टू-प्ले गेम को फेसबुक पर iOS, Android और आदर्श रूप में एक साथ लॉन्च किया जाना चाहिए।

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

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

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

#if defined(_ANDROID_PLATFORM) // put your Android code here #elif defined(_IOS_PLATFORM) // put your iOS code here #endif 

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

2. वितरण का आकार

गेम डेवलपर्स, विशेष रूप से जो डेस्कटॉप वाले से मोबाइल प्लेटफार्मों पर स्विच करते हैं, अक्सर परिणामी वितरण के आकार के बारे में नहीं सोचते हैं। हाल के वर्षों में पीसी के लिए एक दुर्लभ गेम 4 जीबी से कम समय लेता है। तथ्य यह है कि लोकप्रिय MMORPG 20GB + है नफरत का एक बड़ा हमला नहीं करता है। प्रवृत्ति इस तथ्य को भी नहीं रोकती है कि खेलों का वितरण लगभग पूरी तरह से डिजिटल हो गया है। हालांकि, मोबाइल फ्री-टू-प्ले में, सब कुछ मौलिक रूप से अलग है।

समस्या यह है कि Google Play और ऐप स्टोर गेम वितरण के आकार को सीमित करता है जिसे मोबाइल नेटवर्क के माध्यम से डाउनलोड किया जा सकता है। आपके पास लगभग 50MB है। जो गेम बड़े हैं उन्हें केवल वाई-फाई नेटवर्क के माध्यम से डाउनलोड करने की अनुमति है। यह दिलचस्प है कि ऐसे देश हैं जिनमें 3 जी पर "आबादी" का बड़ा हिस्सा है, और स्पष्ट कारणों से इन देशों में आपके खेल के वितरण के परिणाम निराशाजनक होंगे।

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

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

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

3. राम

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

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

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

सामग्री का गतिशील लोडिंग और अनलोडिंग समस्या को दूर करने का एक और तरीका है। यह स्पष्ट है कि मेमोरी से लोडिंग और अनलोडिंग सामग्री के संचालन के साथ खेल चक्र को लोड करना, हम अनिवार्य रूप से फ्रेम समय बढ़ाते हैं। हालाँकि, विकल्प हैं, विशेष रूप से एक अलग थ्रेड में संसाधन लोडिंग का उपयोग और एक अलग ओपनजीएल ES संदर्भ में EAGLSharegroup का उपयोग करके ।

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

4. क्लाइंट-सर्वर इंटरैक्शन

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

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

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

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

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

5. प्रदर्शन

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

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

• मेमोरी लूप का उपयोग करें और गेम लूप के अंदर मेमोरी आवंटन को कम करें;
• उन डेटा के लिए कैश का उपयोग करें जिनकी गणना करना मुश्किल है;
• पाठ के बजाय बाइनरी डेटा प्रारूपों का उपयोग करें, जहां संभव हो;
• जटिल वर्ग पदानुक्रम न बनाएं और उनके लिए RTTI का उपयोग न करें;
• वस्तुओं को मूल्य से कॉपी न करें;
• और सबसे महत्वपूर्ण बात - "समय से पहले अनुकूलन" में संलग्न न हों ¹ ।

एक निष्कर्ष के बजाय

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

नोट

[१] "समयपूर्व अनुकूलन सभी (या अधिकांश) प्रोग्रामिंग समस्याओं की जड़ है।" डोनाल्ड नथ (मूल। "समय से पहले का अनुकूलन प्रोग्रामिंग में सभी बुराई (या कम से कम सबसे अधिक) की जड़ है।" )