ऑनलाइन मल्टीप्लेयर गेम में सर्वर साइड का कार्यान्वयन

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

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

कार्य

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

संकल्पना

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

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

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

योजनाबद्ध रूप से, यह इस तरह दिखता है:



शायद सबसे दिलचस्प अनुरोध हैंडलर है।

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

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

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

यह मत भूलो कि खिलाड़ियों की संख्या बहुत बड़ी हो सकती है और हमारे सर्वर में एक कठिन समय होगा।

कार्यान्वयन

इस तरह के डेमॉन को लागू करने के लिए, PHP 5.3 विमोचन विस्तार के साथ लेखक के लिए सबसे परिचित था।
Libevent के बारे में कई लेख हैं, कुख्यात phpDaemon बनाया गया है, इसलिए यह अपने काम में देरी करने के लिए कोई मतलब नहीं है।
यह केवल लंबित घटनाओं (झंडा EV_TIMEOUT) के निर्माण की संभावना को ध्यान में रखने योग्य है, जो हमारे मामले में बहुत सारी समस्याओं का हल करता है।

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

इसलिए, "भारी" अनुरोधों को संसाधित करने के लिए, आप थ्रेड्स (थ्रेड / वर्कर्स) की आवश्यक संख्या के साथ एक अतिरिक्त सर्वर डेमॉन प्रदान कर सकते हैं, जो सभी श्रमसाध्य कार्य करने में खुशी होगी।



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

निष्कर्ष

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

और अब कमियों के लिए।
सबसे बड़ा कार्यान्वयन दोष: PHP बह रही है। यहां तक ​​कि 5.3 में नया कचरा कलेक्टर सभी समस्याओं का समाधान नहीं करता है। और हमारे पास है:



समाधान: समय-समय पर वर्कर को ओवरलोड करते हैं जब उपयोग की गई मेमोरी की मात्रा एक निश्चित सीमा तक पहुंच जाती है।

सबसे सही समाधान जो मैं देख रहा हूं वह है प्रोग्रामिंग भाषा एरलंग \ ओटीपी का उपयोग।
यह कार्य FSM / gen_server की उनकी अवधारणा में पूरी तरह से फिट बैठता है, जिसे लेखक निकट भविष्य में करने की योजना बना रहा है।

मुझे उम्मीद है कि लेख शुरुआती गेम डेवलपर्स को रेक पर कदम नहीं रखने और उनके आवेदन को सही ढंग से डिजाइन करने में मदद करेगा।

PS यदि इस तरह का विषय हैबर के निवासियों के लिए दिलचस्प है, तो मैं ऐसी प्रणाली के प्रत्येक घटक के बारे में अधिक विस्तार से बताने के लिए तैयार हूं।