नाटक "मल्टीप्लेयर ऑनलाइन गेम का विकास।" भाग 1: वास्तुकला

भाग 2: प्रोटोकॉल
भाग 3: क्लाइंट-सर्वर इंटरैक्शन
भाग 4: 3 डी में जा रहा है

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



मुफ्त के शौकीन और हार्ड कॉपी पेस्टर्स के लिए, मैं तुरंत कहता हूं कि कोई पूर्ण स्रोत कोड नहीं होगा। मैं सर्वर और क्लाइंट दोनों के केवल कुछ दिलचस्प (जटिल?) क्षण अपलोड करूंगा।

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

भाग एक कार्रवाई एक: परियोजना का सामान्य विवरण।

हम क्रम में लिखेंगे कि हम क्या करेंगे।

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

टास्क : नेटवर्क गेम जैसे कि "बांका टैंक"। फ्लैश पर क्लाइंट का हिस्सा, स्काला पर सर्वर। सॉकेट्स के माध्यम से कनेक्शन। कई परेशानियों को दूर करने के लिए, हम "कौन पहले उठ गया - और चप्पल" के सिद्धांत पर एक अतुल्यकालिक सर्वर बनाएगा।

सामान्य रूप से क्लाइंट का खेल में सर्वर इंटरैक्शन के रूप में क्या मतलब है?
1. उपयोगकर्ता लॉगिन
2. सर्वर के साथ आदान-प्रदान (क्लाइंट से सर्वर पर कमांड भेजना, सर्वर से कमांड की प्रतिक्रिया प्राप्त करना, सर्वर से कमांड प्राप्त करना)
सर्वर प्रबंधन का हिस्सा 3. Adiminsky

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

व्यवस्थापक भाग भी आदिम है। हम उपयोगकर्ताओं की एक सूची ऑनलाइन प्रदर्शित करेंगे। तनाव परीक्षण के लिए उपयोगी।

सर्वर के साथ विनिमय - यह खेल का प्रोटोकॉल है। हम इसे तब लिखेंगे जब हम सर्वर कार्यान्वयन करेंगे।

सर्वर

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

परियोजना के सामान्य विवरण के साथ, सब कुछ स्पष्ट प्रतीत होता है।

भाग एक चरण दो: सर्वर आर्किटेक्चर।

मैं तुरंत चेतावनी देना चाहता हूं कि लेख कुछ हद तक शोध का है। यानी सर्वर के कार्यान्वयन और लोड परीक्षण की प्रक्रिया में, विभिन्न परिस्थितियों के प्रभाव में इसकी वास्तुकला (और इच्छाशक्ति) बदल सकती है ...

सामान्य योजना इस प्रकार है:



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

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

यह मूल रूप से वह सब है जो इरादा है।

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

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

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

युपीडी। हैबरचियंस के अनुरोध पर इस परियोजना के लिए जीथब को खोला गया