ब्राउज़र रणनीति विकास

सभी को नमस्कार!

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



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

गेम को द फेट ऑफ नेशन http://fatenation.com कहा जाता है

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

गेम बनाने के लिए, मैंने क्लाइंट पर सर्वर, html और जावास्क्रिप्ट पर php और MySQL का उपयोग किया। फ्लैश का उपयोग नहीं किया जाता है। Html5 का, साइट पर केवल वीडियो और गेम में कैनवास के साथ कई क्षेत्रों में है - नक्शे की सतह और न्यूनतमप सहित। क्लाइंट साइड कोड सर्वर साइड से कई गुना बड़ा है, इसलिए मैं मुख्य रूप से क्लाइंट डेवलपमेंट के बारे में बात करूंगा, लेकिन सर्वर से शुरू करते हैं।

सामान्य वास्तुकला

एप्लिकेशन का समग्र आर्किटेक्चर पूरी तरह से अतुल्यकालिक जावास्क्रिप्ट वेब एप्लिकेशन जैसा दिखता है। कोई पृष्ठ पुनः लोड नहीं हैं। Ajax और JSON के माध्यम से विशेष रूप से सर्वर के साथ संचार। JSON में, केवल HTML कोड के बिना डेटा प्रसारित होता है। Html मार्कअप एप्लिकेशन लोडिंग की शुरुआत में अलग से डाउनलोड किया जाता है और क्लाइंट टेम्पलेट इंजन के माध्यम से डेटा के साथ संसाधित किया जाता है क्योंकि सर्वर से डेटा डाउनलोड किया जाता है।



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

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



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

अब खेल के बारे में थोड़ा।

नक्शा

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

कुल में, यह कार्ड के लिए डेटाबेस में 1000 * 1000 = 1 000 000 रिकॉर्ड निकला। इससे पहले, मैंने इतने सारे रिकॉर्ड के साथ काम नहीं किया था, और इसने मुझे चिंतित कर दिया। मुझे लगा कि यह धीमा हो जाएगा।



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

• x, y कोशिका के निर्देशांक हैं।
• इलाके - क्षेत्र का प्रकार (घास का मैदान, जंगल, पहाड़ ...)।
• संसाधन - एक संसाधन यदि यह कोशिका (मिट्टी, घोड़ों) पर है।
• wens9_code - फ़ील्ड का नाम पश्चिम-पूर्व-उत्तर से आता है ... 9 - इसका मतलब है कि इस सेल की छवि 8 आसन्न कोशिकाओं के क्षेत्रों पर और निश्चित रूप से इस सेल के क्षेत्र पर ही निर्भर करती है - केवल 9. यह तर्क 3 जी सभ्यता से चुराया गया है, पर्याप्त देखा जा रहा है प्रदेशों के उनके प्रेत जहां एक सेल के लिए माउस के 512 वेरिएंट हैं!)) फिर मेरे दिमाग में उबाल आना शुरू हो गया, इस पर निर्भरता का विश्लेषण करते हुए कि उन्होंने माउस का चयन किया और मुझे एहसास हुआ कि बवासीर कितनी बड़ी थी। =) और यह सिर्फ एक चीज के लिए है: स्प्राइट्स के लिए 128 x 64 पिक्सेल rhombuses के रूप में कठिन छोर हैं। अंत में, हमने png24 का उपयोग पारदर्शी किनारों के साथ एक दूसरे को ओवरलैप करने और Tsiv3 से वर्णित उदाहरण की तुलना में 10 गुना बेहतर और अधिक विविध परिदृश्य बनाने का किया। और हम पड़ोसी कोशिकाओं की परवाह किए बिना बेतरतीब ढंग से माउस का चयन करते हैं। इसे स्क्रीन पर देखा जा सकता है - आप तुरंत नहीं बता सकते हैं कि समान फ़ील्ड आइकन कहां हैं। वे किनारों के आसपास के पहाड़ों को धोना भूल गए और उनके पास स्पष्ट सीमाएं हैं - जो बुरा दिखता है।
• start_position - इसका मतलब है कि एक खिलाड़ी इस सेल में दिखाई देगा।

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

क्षेत्र

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

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



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

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

मानचित्र अनुसंधान

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



यह मैंने ब्राउज़र गेम्स में नहीं देखा है (वास्तव में, नक्शे के चारों ओर घूमने वाली इकाइयाँ, हवा के ऊपर नहीं)। मैंने काम करना तय किया। खिलाड़ी की शुरुआती स्थिति क्षेत्र के भीतर स्थित है। यही है, खिलाड़ियों की अधिकतम संख्या 10,000 के साथ-साथ क्षेत्र भी हैं। प्रत्येक खिलाड़ी पूरे नक्शे को स्काउट कर सकता है। कुल 10 000 * 1 000 000 = 10 बिलियन रिकॉर्ड सेल के लिए अनुमतियों की तालिका में हो सकते हैं! मानचित्र तालिका इस बच्चे की पृष्ठभूमि के खिलाफ लग रही थी =)। बेशक, यह आंकड़ा बहुत अधिक है। यह संभावना नहीं है कि कोई भी पूरे नक्शे को स्काउट करने में सक्षम होगा - यह बहुत बड़ा है। लेकिन अनुमति तालिका में दसियों और सैकड़ों लाखों प्रविष्टियाँ निश्चित रूप से खेल के अंत में हो सकती हैं।

और इस तालिका में क्षेत्रों का चयन करते समय प्रत्येक बार कार्ड सहित सभी संस्थाओं को शामिल करना आवश्यक था। यहाँ फिर से कुंजी ने मुझे क्षेत्र के क्षेत्र में बचाया, जिसने मुझे इन जोड़ियों को बहुत तेजी से बनाने की अनुमति दी।



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

चलती इकाइयाँ

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

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

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



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

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

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

पी एस धन्यवाद विषय लिखने में मदद और समर्थन के लिए धन्यवाद! =)