टेलीग्राम में एक गेम बॉट के उदाहरण से गेम देव दुनिया में मेरे कदम, सफलताएं और गलतियां

सभी को नमस्कार! मेरा नाम मैक्सिम है और मैं आपको बंजर भूमि युद्ध परियोजना के निर्माण की कहानी बताना चाहता हूं। मुझे आशा है कि आप रुचि लेंगे, और शायद इसमें से कुछ आपको मेरी गलतियों से बचने में मदद कर सकते हैं।

मंच का चयन

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

virality

विकास के शुरुआती दिनों में, गेम टेस्ट के लिए मेरे दोस्तों से एक फोकस समूह को इकट्ठा करने का निर्णय लिया गया था। आखिरकार, आईएमओ के साथ काम करते समय, अकेले परीक्षण करना समस्याग्रस्त था। इसलिए मैंने गेम के बंद बीटा टेस्ट को लॉन्च किया, जिससे वन-टाइम कीज़ का उपयोग करके बॉट तक पहुंच बनाई गई। इस तरह के 10 टुकड़े उत्पन्न करने के बाद, मैंने उन्हें टीजी में अपने दोस्तों को भेजा। रेफरल सिस्टम को पहले से ही इस बिंदु पर जोड़ा गया था, हालांकि यह बंद परीक्षण के मद्देनजर वास्तव में काम नहीं करता था। इसका सार यह है कि आपके रेफ के अनुसार खेल में पंजीकृत प्रत्येक व्यक्ति के लिए। लिंक, खिलाड़ी को अधिकतम सहनशक्ति और जेब खर्च के लिए कुछ कैप (स्थानीय मुद्रा) मिलती है। इस तथ्य के कारण पीटीए की शुरुआत से 2 सप्ताह बाद, 50 लोगों ने इसमें भाग लिया, और मेरे निजी संदेशों को लोगों से अनुरोध के साथ जाम कर दिया गया ताकि उन्हें अपने दोस्तों के लिए एक और 1-2-10 चाबियाँ दे सकें। लगातार नई चाबियां बनाने के बजाय, मैंने परीक्षण में पाए जाने वाले कीड़े को ठीक करने पर ध्यान केंद्रित करने का फैसला किया और चाबियों द्वारा अपंजीकृत एक खुले बीटा परीक्षण का शुभारंभ किया। एमबीटी के पहले दिन खेल में 120 लोगों ने पंजीकरण कराया। एक महीने बाद, दैनिक ऑनलाइन एक दिन में 200-250 लोग थे, और पंजीकृत खिलाड़ियों की कुल संख्या 800 के करीब पहुंच रही थी। और यह सब पीआर गेम के किसी भी आंदोलन के बिना, खेल विशेष रूप से वर्ड ऑफ माउथ और रेफरल सिस्टम के लिए धन्यवाद के रूप में जाना जाता है।

परियोजना की विशेषताएं जो खिलाड़ियों को पसंद आईं

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

तकनीकी विवरण

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

बॉट एपीआई से ही जटिलता के संदर्भ में, सब कुछ शांत था। एक क्षण तक।

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

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

एक पाठ खेल में दृश्य भाग

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

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

परियोजना विकास की योजनाएँ

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

इस प्रकार, किसी भी प्लेटफ़ॉर्म के लिए एक क्लाइंट विकसित करना क्लाइंट की तरह ही सरल होगा, इससे टेलीग्राम की कई सीमाएँ, इसे ब्लॉक करने में कठिनाई और साथ ही गेम के लिए बड़ी संख्या में नए दर्शकों को आकर्षित किया जा सकेगा।