उन्नीवर्ल्ड: पोस्टमार्टम

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



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

संक्षेप में खेल के बारे में

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



अन्य खिलाड़ियों पर हमला करें जो आप अपने पात्रों में से एक हैं और आप इसे नियंत्रित करते हैं।

Arenas - अलग-अलग मोड (ध्वज कैप्चर, पॉइंट कैप्चर, आदि) के साथ ठेठ MOBA 3v3।



प्रत्येक चरित्र के अपने मंत्र होते हैं, जिन्हें अन्य खिलाड़ियों के साथ जोड़ा जा सकता है।


लड़ाई से पहले, आप मंत्र बदल सकते हैं।



एक पूरे के रूप में खेल चक्र इस तरह दिखता है:

1. पम्पिंग मंत्र के लिए, स्क्रॉल की आवश्यकता होती है जो चेस्ट से गिरते हैं। चेस्ट विभिन्न तरीकों से प्राप्त किया जा सकता है (एक लीग के लिए, बैटल रॉयल जीतने के लिए, आदि) या खरीद।
2. वर्तनी को पंप करने के लिए, आपको नायक के निर्माण को एक निश्चित स्तर तक बनाने और सुधारने की आवश्यकता है।
3. नायक के भवन को बेहतर बनाने के लिए, अन्य इमारतों (मुख्य भवन, वेदी, आदि) में सुधार करना आवश्यक है।

यही है, हमने किसी तरह ग्रह और एरेनास के शासन को समेटने की कोशिश की। हमने शायद सब कुछ गलत किया।

एक स्पष्ट योजना और रणनीति का अभाव

हां, कई चीजों पर लगातार चर्चा की गई थी, लेकिन पहली जगह में क्या किया जाना चाहिए, इसका गहन विश्लेषण किए बिना, उन्हें जगह से बाहर महसूस किया गया।

नतीजतन, उन्होंने एक ही बार में सब कुछ करने की कोशिश की। जब गेम में डेढ़ उपयोगकर्ता हैं, तो क्या आपको गिल्ड सिस्टम की आवश्यकता है? हम्म, शायद ही।

क्या आपको एक ऐसी प्रणाली की आवश्यकता है जो आपको एक कस्टम मैच बनाने की अनुमति दे, जहां दोस्तों और सह-अपराधियों को आमंत्रित किया जाए जब खेल में एक छोटा CCU हो? यकीन नहीं होता।

विकास की प्रक्रिया के दौरान, हमने बहुत कुछ करने की कोशिश की, जो शायद उस स्तर पर करने की जरूरत नहीं थी। परिणामस्वरूप, वास्तव में आवश्यक चीजों को लागू नहीं किया गया था।

अनुभव की कमी

क्योंकि इससे पहले कि हम मुख्य रूप से केवल सिंगल-प्ले गेम्स के साथ काम करते थे, तब हमने एक या दूसरी तकनीक को चुनते समय बड़ी संख्या में रेक पर कदम रखा।

आइए प्रश्न के तकनीकी भाग के बारे में थोड़ा बात करते हैं।

प्रौद्योगिकी चयन

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

किस क्लाउड प्रदाता का उपयोग करें? एडब्ल्यूएस? Azure? नरम परत

उस समय कोई बुनियादी अंतर नहीं था। इसके अलावा, हमारे पास एक स्टार्टअप के रूप में सॉफ्टलेयर के लिए ऋण था।

ओह, बोई, यदि आप केवल जानते थे कि चीजें कितनी बुरी थीं:

- सपोर्ट समस्या में विशेष रूप से पारंगत नहीं है। ऐसे मामले थे जब मैंने उन्हें एक निश्चित आभासी मशीन पर समस्या के बारे में बताया (मैं कनेक्ट नहीं कर सका, आदि)। जिसको लेकर मुझे जवाब मिला:

हमने कार को रिबूट किया, अब सब ठीक है

- ऐसे मामले थे जब वर्चुअल मशीन घंटों तक चलती थी । जैसा कि आप देख सकते हैं, मैंने 4 घंटे इंतजार किया, लेकिन वर्चुअल मशीन कभी नहीं बनाई गई थी।



- बार-बार आने वाली बीमारी।



- ऐसा होता है कि चेतावनी के बिना एक कार रिबूट होगी, या एक निजी नेटवर्क काट दिया जाएगा।

परिणामस्वरूप, वे Azure में चले गए। ऐसी कोई समस्या नहीं थी। समर्थन जल्दी से प्रतिक्रिया करता है और अगर कुछ होता है तो हमेशा मदद करता है।

अच्छा: -

खराब: उन्होंने सभी संभावित विकल्पों का ठीक से विश्लेषण नहीं किया। लेकिन सर्वर ऑनलाइन गेम के लिए सबसे महत्वपूर्ण हिस्सा है = /

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

यदि हम इस तथ्य को त्याग देते हैं कि आपको इस तकनीक के साथ काम करने के लिए अनुभव की आवश्यकता है, यहां तक ​​कि इस व्यवसाय के मूल सेटअप के साथ, यह गिरने में कामयाब रहा। कुछ सेवाएं गिर गईं, आदि।

खैर, और क्या है? मेसोस्फीयर और अपाचे मेसोस! उसके साथ सब कुछ समान है, अनुभव के बिना यह मुश्किल है। यदि कुछ गिर जाता है, तो बिना किसी परेशानी के आप समस्या को ठीक नहीं कर सकते।

नतीजतन, उन्होंने खुद ही सब कुछ लिखा। उदाहरण पर्यवेक्षक से शुरू होते हैं, जैसा कि उनके ऊपर का छोटा प्रबंधक (जावा में लिखा गया) है। जावा एप्लिकेशन स्थिति की खोज की सेवा में ttl'it (उदाहरणों पर मुफ्त कमरों की संख्या)। जब इंस्टेंस के बारे में इस जानकारी का उपयोग करके एपीआई के लिए एक कमरा बनाने के लिए अधिकृत और अनुरोध किया जाता है, तो अनुरोध सही नोड पर जाता है, जो सही उदाहरण पर कमरे को उठाता है।

यानी उदाहरण हमेशा प्री-रन होते हैं। एक कमी के साथ, हम एक नया VPS बढ़ा रहे हैं।

अच्छा: विकल्पों का विश्लेषण किया।

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

हमने खोज सेवा के लिए www.consul.io का उपयोग किया। यह शायद उन समाधानों में से एक है, जिनके लिए हमें खेद नहीं था। सच है, जब रिबूट के दौरान कॉन्फ़िगरेशन टूट जाता है तो ऐसी समस्याएं होती हैं। लेकिन यह दुर्लभ और कार के अनियोजित रिबूट के साथ है। सामान्य तौर पर, सभी समय के लिए यह कौंसल के साथ काम करने में खुशी थी।

अच्छा: उन्होंने एक तैयार समाधान किया, लेकिन खुद कुछ देखना शुरू नहीं किया।

तैनाती के लिए, मूल रूप से बैश स्क्रिप्ट का उपयोग किया गया था।


बाद में, मैंने पूरी तैनाती अंसिबल को हस्तांतरित कर दी। मैं इस दिन के लिए पर्याप्त नहीं हो सकता बेशक, पहली बार में समस्याएं थीं। लेकिन सिस्टम सीखने में काफी सरल है, और थोक में प्रलेखन।

अच्छा: जल्दी से एक बैश स्क्रिप्ट लिखो, कोई विशेष ज्ञान की आवश्यकता नहीं है।

ख़राब: जब एक सामान्य परिनियोजन प्रणाली पर स्विच किया जाता है, तो मुझे पहले लिखी गई लगभग हर चीज को फेंक देना पड़ता था।

उनकी सेवाओं के बीच संचार के लिए हमने www.rabbitmq.com की कोशिश की। लेकिन वह कुछ दिनों में सिर्फ इतना ही विषय छोड़ सकता है। नतीजतन, उन्होंने इसे एक सरल तरीके से किया - सभी सेवाएं या तो शुद्ध टीसीपी सॉकेट्स के माध्यम से बातचीत करती हैं, या http-Keep के साथ HTTP अनुरोध, यदि आपको केवल एक दिशा में अनुरोध भेजने की आवश्यकता है।

अच्छा: विकल्पों का विश्लेषण किया। हमने एक अच्छा समाधान चुना।

खराब: तकनीक के साथ अनुभव की कमी। चीजों को उत्पादन में खींचने की आवश्यकता नहीं है जो आप समस्याओं के मामले में ठीक नहीं कर सकते हैं।

ऑनलाइन खेलने का मतलब है कि आपको एक चैट रूम की आवश्यकता है। खुद लिखो? यह स्केलेबल होने की संभावना नहीं है। चलो कुछ तैयार हो जाओ। XMPP? Ejabberd? अच्छा लगता है। सामान्य तौर पर, हमने हेजहोग और मोंगोज़ीम दोनों की कोशिश की, लेकिन अंततः हेजहोग पर बस गए। उनके सर्वर पर इसे बढ़ाने में कुछ समस्याएं थीं (संदेश, क्रैश आदि में टाइमिंग के साथ जाम)। हमने उनके क्लाउड समाधान ejabberd-saas.com का उपयोग करने का निर्णय लिया। हाँ, यह भुगतान किया है। लेकिन यह समस्याओं के बिना काम किया।

अच्छा: विकल्पों का विश्लेषण किया। उपयुक्त विकल्प चुनें।

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

पहले, हमारे पास सर्वरों पर मीट्रिक एकत्र करने के लिए आमतौर पर कोई प्रणाली नहीं थी। अनुरोध धीमा क्यों होता है? सेवा में क्या गलत है? अब कितने कमरे उपलब्ध हैं? हाँ, हम यह भी नहीं देख सके कि वर्तमान में कितने कमरे उपलब्ध हैं!

बाद में एहसास हुआ कि कुछ करने की जरूरत है। ग्रेफाइट + ग्राफाना का उपयोग करने की कोशिश की। यहां तक ​​कि पूर्व-कर्ता की छवि ने भी यह सब किया: github.com/Suvitruf/docker-grafana-graphite-diamond

लेकिन इसका फायदा नहीं हुआ। मैं इस पर समय नहीं बिताना चाहता था, हमने तैयार किए गए कुछ का उपयोग करने का फैसला किया। चुनाव www.datadoghq.com पर गिर गया

सब कुछ महान है। मीटर, अलर्ट, चार्ट। क्लाइंट ड्राइवर ग्रेफाइट के लिए लगभग समान है। सौंदर्य। लेकिन ... प्रति माह प्रत्येक मेजबान के लिए 10 + $। III ... यह प्रति माह 200 + $ पर निकलता है।

यह अहसास कि हमने इस पर एक टन पैसा लगाया, बहुत देर हो चुकी थी। हमने तय किया, फिर भी, हमारे सर्वर पर ऐसा करने के लिए। Www.influxdata.com सेट करें। नतीजतन, दर्जन रुपये के एक जोड़े के लिए एक कार चुपचाप दसियों / सैकड़ों कारों से मैट्रिक्स की प्रक्रिया करती है।

अच्छा: हमने इसे जल्दी से आज़माया। एक तैयार किया गया विकल्प मिला। उन्हें एहसास हुआ (हालांकि देर से) कि निर्णय गलत था। स्थानीय स्तर पर एक सुविधाजनक प्रणाली स्थापित करें।

बुरा: इस मुद्दे को ठीक से नहीं समझा। बहुत पैसा खर्च किया।

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

वैचारिक और डीजी समाधान के बारे में थोड़ा सा

मैं अब इन सभी घटनाओं के लिए पहले से ही सही क्रम नहीं बना सकता, मैं उन कुछ महत्वपूर्ण निर्णयों का नाम दूंगा जो हमने किए थे।

क्षेत्र द्वारा खेल का विभाजन

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

अच्छा: कुछ लोगों को बेहतर पिंग मिला (a • ̀ •｡ got)

खराब: क्षेत्रों, हस्तांतरण प्रणालियों आदि को बनाने में बहुत समय व्यतीत होता है।

खिलाड़ियों के सुझावों / सुझावों को सुनना आवश्यक है, लेकिन आपको तुरंत भागकर यह सब महसूस नहीं करना चाहिए।

हेक्स के साथ एक चौकोर ग्रिड को बदलना और ग्रहों पर हमले करना

पहले, ग्रह इस तरह दिखते थे:



और हमले:



हेक्स पर स्विच करना तकनीकी रूप से कई चीजों को सरल बनाता है। इसके अलावा यह बहुत बेहतर लग रहा था, खेल तत्वों के साथ काम करना आसान है।

नियमबद्ध वर्तनी प्रणाली

यह इस तरह दिखता था:



अपग्रेड स्वयं पत्थरों के लिए किया गया था जो चेस्ट से गिर गए थे। सब कुछ स्पष्ट नहीं था, भ्रामक।

नतीजतन, उन्होंने पत्थरों के सिस्टम को स्क्रॉल रॉयल के रूप में स्क्रॉल के साथ बदल दिया।



वर्तनी सुधारने के लिए, आपको एक निश्चित संख्या में स्क्रॉल की आवश्यकता होती है। सब कुछ सरल और स्पष्ट है।

अच्छा: उन्होंने एक समस्या की जगह देखी और उसे भुनाया।

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

चिकोटी पर खरीदारी

हम गेम पेज पर इन-गेम खरीदारी करने के लिए www.twitch.tv से भी सहमत थे।



लेकिन कब से किसी ने हमारे खेल को प्रवाहित नहीं किया, तो इस तरह के निर्णय का अर्थ आम तौर पर शून्य है।

अच्छा: खिलाड़ियों से उचित धन निकासी के लिए एक संभावित स्थान।

खराब: अगर आपका खेल स्ट्रीम नहीं है, तो इसका कोई मतलब नहीं है। बस समय बर्बाद किया।

लड़ाई रोयाले मोड

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

बग के बारे में

इस तरह की परियोजना में, बग बनाना मुश्किल नहीं है। कई अपेक्षाकृत हानिरहित जीयूआई कीड़े थे।



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

चरित्र को स्विच करते समय एक अजीब बग पिछले एक के मॉडल को हटाया नहीं गया था। नतीजतन, एक पार्टी को मुश्किल से व्यवस्थित करना संभव था।



प्लेटफॉर्म / इंजन से संबंधित बग भी थे।

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


हमने इस समस्या के बारे में एकता को बताया। उन्होंने उत्तर दिया कि वे हमें प्रति माह $ 10k की मदद के लिए एक कर्मचारी दे सकते हैं could (that_ಠ ლ)

गेम प्लेटफ़ॉर्म पर गलत जगह पर टैची पर प्रतिक्रिया देने पर फेसबुक प्लेटफॉर्म पर गेमरूम को स्केलिंग की समस्या थी।



यह, विभिन्न पुस्तकालयों में बग का उल्लेख नहीं करना है। उदाहरण के लिए, कुछ स्टीमवर्कs.NET मशीनों पर, github.com/rlabrecque/Steamworks.NET/issues/121 क्रैश हो सकता है।

परिणाम

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

विशेष रूप से कोई भी खिलाड़ियों के साथ सामग्री प्रबंधन और संचार में नहीं था, कोई समाचार पत्र नहीं थे।

विकास के दौरान, विभिन्न प्रौद्योगिकियों के चयन और परीक्षण में बहुत समय नष्ट हो गया।

सुविधाओं / सामग्री के कार्यान्वयन के लिए कोई स्पष्ट योजना नहीं थी।

सामान्य तौर पर, इन सभी समस्याओं में से अधिकांश अनुभवहीनता के कारण होती हैं।

आगे क्या है?

Unnyworld को बंद कर दिया गया है। हमने वर्तमान अवसरों के ढांचे में परियोजना को छोटा बनाने का निर्णय लिया।

एक लेख में सब कुछ शामिल नहीं है। और एक बाहरी व्यक्ति के लिए मैंने जो कुछ भी लिखा है, वह तथ्यों के कुछ असंगत सेट की तरह लग सकता है। दुर्भाग्य से, यह इस तरह के ग्रंथों को लिखने के लिए एक विशेषज्ञ नहीं है।

यदि आपके कोई प्रश्न हैं, तो मुझे टिप्पणियों में या नए लेख में उत्तर देने में खुशी होगी।