🧞 🌈 😙 [अनुवाद] हीटमैप्स: हम गेम संकेतकों को इकट्ठा करने और उनका विश्लेषण करने के लिए एक सरल प्रणाली के साथ गेमप्ले को अनुकूलित करते हैं 🙍🏻 💅🏻 👩‍🌾

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

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

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

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

छोटी शुरुआत

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

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

मैं वर्तमान में Google Android के लिए गेम बनाने में एक सलाहकार के रूप में काम कर रहा हूं। इस मंच के लिए मेरा पहला खेल, रेप्लिका द्वीप आर्केड, गेम बॉय के लिए खेल से बहुत अलग नहीं है जो मैंने 10 साल पहले लिखा था। लेकिन कुछ बदल गया है - मैंने गेम बनाने वाली कंपनी के लिए अब काम नहीं किया, मैंने इसे अपने लिए लिखा, एक कलाकार की मदद से, मुख्य रूप से अपने खाली समय में काम कर रहा था।

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

आखिरकार, फोन पर गेम प्रगति की जानकारी एकत्र करने का कोई आसान तरीका नहीं है। एकमात्र तरीका खेल के दौरान "आत्मा के ऊपर" खड़ा होना है, लेकिन यह असुविधाजनक है और खिलाड़ी के खेलने के तरीके को प्रभावित कर सकता है, जिससे प्रयोग की शुद्धता कम हो जाती है।

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

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

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

एक स्कोरकार्ड पर प्रतिबिंबित

उस घटना के बाद, मैंने एक गेम-सभा और प्रसंस्करण प्रणाली के बारे में सोचा, जो शरारती कुत्ते द्वारा क्रैश बैंडिकूट गेम के लिए विकसित की गई थी।

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

इन समस्या क्षेत्रों को फिर से तैयार किया गया था, और इस जानकारी का उपयोग गेम की जटिलता को गतिशील रूप से समायोजित करने के लिए एक प्रणाली के लिए भी किया गया था।

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

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

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

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

ऐसा लगता है कि खिलाड़ी के लिए संकेतकों का एक सेट का गठन खेलों की एक विस्तृत श्रेणी के लिए लागू है, लेकिन यह केवल बड़ी कंपनियों के लिए उचित है जो एकत्र किए गए डेटा के प्रसंस्करण के लिए उपकरण बनाने के लिए महत्वपूर्ण संसाधनों का निवेश करते हैं।

इस प्रकार की प्रणाली का सबसे प्रभावी ढंग से उपयोग कैसे किया जा सकता है, इसका एक उदाहरण जॉर्ज ज़ोलेर की अद्भुत टेलीमेटरी प्रणाली के बारे में देखा जा सकता है जो वे बायोवेअर में उपयोग करते हैं।

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

यह हतोत्साहित करता है क्योंकि मैंने अपने टूलबॉक्स को यथासंभव सरल रखने की कोशिश की। लेकिन मैंने कुछ प्रमुख संकेतकों के साथ प्रयोग करने का निर्णय लिया।

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

आधार प्रणाली

मेरे द्वारा लिखी गई प्रणाली में तीन भाग शामिल थे: निष्पादन का एक धागा, जो खेल प्रक्रिया के दौरान खिलाड़ी के कार्यों पर डेटा एकत्र करता है और इसे सर्वर, सर्वर स्वयं, और एकत्रित डेटा को संसाधित करने के लिए एक उपकरण भेजता है।

सर्वर - यह बहुत जोर से, निश्चित रूप से कहा जाता है। मेरे सर्वर को एक PHP स्क्रिप्ट की 30 लाइनों द्वारा दर्शाया गया था जो HTTP के माध्यम से एक GET अनुरोध की जाँच करता है और परिणामों को MySQL डेटाबेस में लिखता है। बदले में, GET अनुरोध की संरचना भी बहुत सरल थी। यह इवेंट, निर्देशांक, कोड संस्करण, सत्र पहचानकर्ता और टाइमस्टैम्प का नाम है।

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

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

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

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

चमकीले लाल रंग में नक्शे पर विफलताओं

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

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

लेकिन समस्या के स्तर को परिभाषित करना पर्याप्त नहीं था। कभी-कभी मैं यह नहीं कह सकता था कि एक विशेष स्तर पर एक समस्या क्यों पैदा हुई।

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

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

रेप्लिका द्वीप में गेम कैरेक्टर डेथ डेटा के आधार पर उत्पन्न हीट मैप

खेल डिजाइन में दृश्य डिजाइन मिसकल्कुलेशन

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

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

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

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

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

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

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

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

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

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

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

खेल जारी

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

बेशक, हर बार जब गेम सर्वर को डेटा भेजता है, तो उपयोगकर्ता को सूचित करने के लिए सबसे अच्छा समाधान होगा।

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

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

अपने स्कोरकार्ड में अद्वितीय खिलाड़ियों की संख्या के साथ एंड्रॉइड मार्केट से प्रतिष्ठानों की संख्या की तुलना करते हुए, मैं इस निष्कर्ष पर पहुंचा कि 20% से कम गेम उपयोगकर्ताओं ने गेम प्रक्रिया के बारे में डेटा को सर्वर में स्थानांतरित करने से इनकार कर दिया।

एक प्राकृतिक परिणाम के रूप में, मुझे विश्लेषण के लिए बड़ी मात्रा में डेटा मिला - 14 मिलियन से अधिक सूचना बिंदु, मेरे खेल के उपयोगकर्ताओं द्वारा उत्पन्न की गई घटनाओं के बारे में जानकारी के एक गीगाबाइट के बारे में। लेखन के समय, उनकी संख्या 1,200,000 खिलाड़ी थी।

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

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

एक तरीका या दूसरा, इस योजना ने काम किया

मैं रेप्लिका द्वीप में अपने इवेंट अकाउंटिंग सिस्टम से बहुत संतुष्ट था। , ( , , , Xbox Live), , , .

, , , , , .

PHP MySQL . , , . PHP .

. , HTTP-, .

- , , . , .

. , . .

, , , . , , , , , . , .

,

. , .

PHP . PHP . , -. PHP JavaScript.

PHP , . PHP . . 20 000 PHP- .

PHP. PHP, -, , , .

PHP GD ( - ), .

Python ImageMagick .

. Game Developer magazine .

, , , , , , (game shelf moments).

, , -. , , , .

, . , , - .

, . , .

. , , , , . , , — , .

, , .

, . , .

. .

, , , .

, , , . .

. . , -, .

Replica Island. , , , , .

— , . , .

, . .

:

, . , .
. , , «» . . «» .
.
, . «» .
घटनाओं की सूची में प्रत्येक अद्वितीय स्थान के लिए, घटना के निर्देशांक के अनुसार एक वृत्त की एक छवि बनाएं। हम सूत्र द्वारा परिकलित एक अस्पष्टता गुणांक के साथ एक छवि बनाते हैं:

( )/( "") * 100%

हम एक दूसरे के साथ खींचे गए हलकों के बिंदुओं को मिलाने के लिए गुणा ट्रांसफर मोड (src * dst) का उपयोग करते हैं।

पारदर्शी कैनवास पर परिणामी छवि को ओवरले करें।

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

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

आप आसानी से उन संभावित बगों की पहचान कर सकते हैं जो बड़ी संख्या में घटनाओं के साथ ध्यान देने योग्य होंगे, ताकि समग्र चित्र में एक घटना का योगदान एक प्रतिशत से कम हो।

ImageMagick जैसे उपकरण आपको इस समस्या को हल करने में मदद कर सकते हैं।