💋 🆚 👨🏻‍💻 स्वतंत्र डेवलपर्स द्वारा बनाए गए एक गेम की तकनीकी तैयारी 🧓🏿 🎞️ 🛌🏻

नमस्कार, कठोर लेकिन निष्पक्ष हब्र!

मैं आपके साथ मिलकर अपने अच्छे दोस्त के साथ मिलकर लिखे गए एक खेल को आपसे अलग करना चाहता हूं। यांत्रिकी में, एक खेल दो खिलाड़ियों के बीच एक वास्तविक समय की लड़ाई होती है, जिनमें से प्रत्येक कार्ड के डेक के साथ होती है। और कार्ड, बदले में, ऐसे सेनानियों को उत्पन्न करते हैं जो पहले से ही दुश्मन के बंकर पर स्वतंत्र रूप से मोड़ देते हैं, साथ ही साथ दुश्मन के योद्धाओं को सामान में गिराते हैं। लड़ाई के अलावा, गेम में नक्शे के साथ एक स्टोर है; मुख्यालय, जहां आप एक डेक बना सकते हैं और वर्ण डाउनलोड कर सकते हैं; एक अखाड़ा जहां आप एक खोज या वास्तविक लड़ाई चला सकते हैं; ठीक है, एक बैंक जहां आप खेल मुद्रा प्राप्त कर सकते हैं। मैं आपको याद दिलाता हूं कि हम स्वतंत्र डेवलपर्स हैं, इसलिए, संसाधनों में सीमित हैं और कई समाधान आदर्श नहीं हैं।
आपने यहां एक खेल कैसे शुरू किया: habrahabr.ru/post/142490

चलिए तैयारी शुरू करते हैं।

सामाजिक मंच

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

फ्लैश प्लेटफॉर्म

Vkontakte को चुनना, हमारे पास चुनने के लिए दो प्रौद्योगिकियाँ हैं: फ्लैश और iframe (html + जावास्क्रिप्ट)। ईमानदार होने के लिए, मैं HTML गेम को नहीं पचाता, इसके अलावा, मैं कई वर्षों तक एक फ्लैश डेवलपर रहा हूं। इसलिए, चर्चा भी नहीं हुई: उन्होंने तुरंत फ्लैश चुना।

फ्लेक्स

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

निम्नलिखित जानकारी फ़्लैश खिलाड़ियों के लिए है। (यह फ़्लैश प्लेयर है, शब्दजाल में फ्लैशर के लिए एक दोस्त है जो पार्कों में एक रेनकोट में नग्न चलता है ... और फिर आप जानते हैं)। यदि आप एक फ़्लैश प्लेयर नहीं हैं, तो आप अगले अनुभाग पर आगे बढ़ सकते हैं।

फ्लेक्स पर इंटरफेस बनाते समय, हमने तुरंत चमड़ी के घटक बनाए। ऐसा करने के लिए, प्रत्येक घटक SkinnableComponent से इनहेरिट करना होगा।

/** *  . * */ public class Card extends SkinnableComponent { /**    . */ private var _model:CardModel = new CardModel(); public function set model(value:CardModel):void { _model = value; modelChanged = true; this.invalidateProperties(); } public function get model():CardModel { return _model; } /** ,     .   .   commitProperties */ private var modelChanged:Boolean = false; [SkinPart(required="true")] /**  . */ public var nameLabel:Label; public function Card() { super(); } /** * @private */ override protected function partAdded(partName:String, instance:Object):void { super.partAdded(partName, instance); if (instance == nameLabel) { if(model) nameLabel.text = model.name; } } /** * @private */ override protected function commitProperties():void { super.commitProperties(); if(this.modelChanged) { if(model) nameLabel.text = model.name; } }

यहां आपको कोड के निम्नलिखित टुकड़ों पर ध्यान देना चाहिए:

 [SkinPart(required="true")] /**  . */ public var nameLabel:Label;

यह एक इंटरफ़ेस तत्व है जो एक विशिष्ट त्वचा में होगा। इस तथ्य को स्किनपार्ट मेटा टैग द्वारा नोट किया गया है। आवश्यक मेटा टैग पैरामीटर इंगित करता है कि क्या यह विशेष घटक त्वचा में लागू किया जाना चाहिए या छोड़ा जा सकता है।

हमारी त्वचा के तत्वों को शुरू करने के लिए इस विधि को फिर से परिभाषित करना होगा। मुझे कैसे करना है, मुझे लगता है, कोड से स्पष्ट है।

 override protected function partAdded(partName:String, instance:Object):void

यह इस विधि को ओवरराइड करने के लिए भी समझ में आता है:

 override protected function commitProperties():void

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

हम मॉडल में डेटा को अलग से स्टोर करते हैं:

  /**    . */ private var _model:CardModel = new CardModel(); public function set model(value:CardModel):void { _model = value; modelChanged = true; this.invalidateProperties(); } public function get model():CardModel { return _model; }

ध्यान दें, जब डेटा परिवर्तित किया जाता है, तो हम केवल इसे सहेजते हैं, डेटा मॉडल को संशोधित के रूप में चिह्नित करते हैं और अमान्यateperperties () विधि कहते हैं। यह विधि फ्लेक्स को बताती है कि डेटा बदल गया है और आपको समितियों () को कॉल करने की आवश्यकता है। आप अपने आप को प्रतिबद्ध नहीं कह सकते हैं; यह कहा जाता है, जैसा कि मैंने कहा, जब स्क्रीन को फिर से तैयार किया जाता है।

हमारे साथ डेटा मॉडल सिर्फ मॉडल का वर्णन करने वाले क्षेत्रों के साथ एक संरचना है।

  /** *    . * */ public class CardModel { /**  . */ public var name:String = ""; }

एक त्वचा इस तरह दिख सकती है:

 <?xml version="1.0" encoding="utf-8"?> <s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/mx" xmlns:components="view.components.*"> <!-- host component --> <fx:Metadata> [HostComponent("view.components.Card")] </fx:Metadata> <s:Label id="nameLabel"/> </s:Skin>

यहां आपको मेटाडेटा ब्लॉक पर ध्यान देना चाहिए। यह त्वचा के लिए "मूल" घटक को इंगित करता है।

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

फ़्लैश XML ग्राफिक्स

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

आर्किटेक्चर

वास्तुकला का निर्माण करते समय, हम भविष्य में गेम क्लोन बनाने का लक्ष्य निर्धारित करते हैं। इसलिए, हमने खेल को निम्नलिखित स्तरों में विभाजित किया है:

कोर
तर्क
डेटा मॉडल
विचार
खाल

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

लड़ाई का गणितीय मॉडल

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

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

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

सर्वर

हमने PHP में सर्वर पार्ट करने का निर्णय लिया। वास्तव में, विकल्प निम्नलिखित था - सॉकेट या HTTP पर क्लाइंट-सर्वर प्रोटोकॉल को लागू करने के लिए। और विकास की गति के पक्ष में एक विकल्प बनाया है और ग्राहक के साथ स्थिर काम की गारंटी देता है, आपने बाद को चुना है। अर्थात् PHP - क्योंकि हमारे पास इस क्षेत्र का व्यापक अनुभव है।

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

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

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

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

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

MMO तकनीक

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

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

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

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

निष्कर्ष में

मुझे, हेब्रा को माफ कर दो, चित्रों, रेखांकन और तालिकाओं की कमी के लिए एक पापी सिर, लेकिन हमारे खेल के सभी हिम्मत आपके सामने हैं। आप कर सकते हैं तो सलाह दें। हां, मैं कहना भूल गया। मैं विमुद्रीकरण के बारे में अगला लेख लिखूंगा, इसमें कितना खर्च आएगा और मैं पहले परिणाम दिखाऊंगा।

स्वतंत्र डेवलपर्स द्वारा बनाए गए एक गेम की तकनीकी तैयारी