क्लाइंट और सर्वर पर सामान्य गेम लॉजिक

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


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

हम जानते थे कि कैसे और क्या करना है, लेकिन हमारे पास कोई अनुभव नहीं था। फिर हमने एक ऐसे व्यक्ति को काम पर रखा, जिसे यह अनुभव था और उसने कहा: वही काम करो जो आप पहले ही सौ बार कर चुके हैं, केवल बेहतर। फिर वे बैठ गए और वास्तुकला के बारे में सोचने लगे।



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

इस तरह की वास्तुकला की अपनी विशेषताएं हैं। ईसीएस पर विकसित करते समय, आपको चीजों को अलग तरीके से सोचने और करने की आवश्यकता होती है। प्लसस में से एक बहु विरासत के बजाय रचना है। C ++ में एकाधिक वंशानुक्रम के साथ इस कविता को याद रखें? उसकी सारी समस्याएं। ECS में ऐसा नहीं है।



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

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

अंत में, हमारे लिए मुख्य और सबसे महत्वपूर्ण विशेषता यह है कि हम क्लाइंट और सर्वर दोनों पर समान कोड निष्पादित कर सकते हैं।

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



स्लाइड पर जो लिखा गया है उसे पढ़ने की कोशिश न करें, यह इतना महत्वपूर्ण नहीं है। महत्वपूर्ण बात यह है कि स्तंभों में हरे और लाल कितने हैं। ग्रीन का मतलब है कि समाधान आवश्यकताओं का समर्थन करता है, लाल - समर्थन नहीं करता है, पीला - समर्थन करता है, लेकिन काफी नहीं।

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



यह सबसे अकल्पनीय संस्करण निकला। खिलाड़ी ने लगातार रोल किया, ब्रेक, सर्वर ने मैच के बीच में लटका दिया। इसे निभाना असंभव था। असफलताओं के कारण क्या थे?

कारण # 1 और सबसे महत्वपूर्ण अनुभवहीनता है। लेकिन ऐसा कैसे? हमने एक अनुभवी व्यक्ति को काम पर रखा था जो सब कुछ खूबसूरती से करना चाहता था। हां, लेकिन वास्तव में हमने उसे केवल काम का हिस्सा दिया। हमने कहा: "यहां आपके लिए एक गेम सर्वर है, इस पर काम करें।" और हमारी वास्तुकला में (इस पर बाद में), ग्राहक बहुत महत्वपूर्ण भूमिका निभाता है। और यह वह हिस्सा था जो हमने एक ऐसे व्यक्ति को दिया था जिसके पास आवश्यक अनुभव नहीं था। नहीं, वह एक अच्छा प्रोग्रामर है, सीनेटर - बस कोई अनुभव नहीं था। यानी उसे कोई अंदाजा नहीं था कि वहां किस तरह की रेक हो सकती है।

कारण # 2 - अवास्तविक आवंटन। 80 KB / फ्रेम। यह बहुत है या नहीं? यदि हम यह ध्यान रखते हैं कि हमारे पास प्रति सेकंड 30 फ्रेम हैं, तो एक सेकंड में हमें 2.5 एमबी मिलता है, और 5 मिनट के मैच के लिए पहले से ही 600 एमबी से अधिक हैं। संक्षेप में, बहुत कुछ। कचरा संग्रहकर्ता तीव्रता से इस सभी मेमोरी को मुक्त करने की कोशिश करना शुरू कर देता है (जब हम इससे अधिक से अधिक मांग करते हैं), जो स्पाइक्स की ओर जाता है। यह देखते हुए कि हम प्रति सेकंड 30 फ्रेम चाहते थे, इन स्पाइक्स ने हमारे साथ बहुत हस्तक्षेप किया। इसके अलावा, क्लाइंट और सर्वर पर दोनों।

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

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

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

इन सभी आबंटनों से यह तथ्य सामने आया कि जब 33 की जरूरत थी, तब हमें लगभग 100 मिलीसेकंड का एक फ्रेम मिला था। और वहाँ, रेंडरिंग, सिमुलेशन और अन्य कार्यों - यह सब सीपीयू लेता है। ये सभी समस्याएं जटिल हैं, अर्थात एक को तय करना असंभव था, और सब कुछ ठीक हो जाएगा। उन सभी को एक बार में हल करना आवश्यक था।

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

यह समस्या का एक बड़ा हल था। हमारे पास एक सर्वर के साथ एक फ़ोल्डर है और एक क्लाइंट के साथ एक फ़ोल्डर है। सर्वर में एक गेम सर्वर प्रोजेक्ट, एक कोड जनरेटर और सहायक उपकरण होते हैं।



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

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

मैच में एक सामान्य भाग (ECS के रूप में निर्दिष्ट) और एक प्रस्तुति शामिल है (ये एकात्मक मोनोबेवियर क्लासेस, गेमऑब्जेक्ट, मॉडल, प्रभाव - ये सब जो दुनिया का प्रतिनिधित्व करता है)। वे जुड़े नहीं हैं।



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

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



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

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

कोड जनरेशन पर वापस आते हैं।



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



1 केबी <1.5 - i.e. हम MTU से मिले। फोटॉन ने काटना बंद कर दिया और नेटवर्क काफी बेहतर हो गया। उसकी लगभग सभी समस्याएं दूर हो गई हैं। लेकिन हम आगे बढ़े और एक डेल्टा संपीड़न किया।



यह तब होता है जब आप एक पूर्ण राज्य भेजते हैं, और उसके बाद केवल उसके परिवर्तन। ऐसा नहीं होता कि पूरी दुनिया तुरंत पूरी तरह से बदल गई। केवल कुछ हिस्से लगातार बदल रहे हैं और ये परिवर्तन राज्य की तुलना में आकार में बहुत छोटे हैं। हमें औसतन 300 बाइट्स मिले, यानी यह मूल से 17 गुना कम था।

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

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



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

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

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

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

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

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



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

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



तो, हम 30 टिक प्रति सेकंड, 30 फ्रेम प्रति सेकंड तक पहुंच गए हैं। अब लगभग 600 खिलाड़ी एक ही समय में हमारे सर्वर पर खेल रहे हैं। मैच में 6 खिलाड़ी हैं, अर्थात् लगभग 100 मैच। हमारे पास एक सर्वर प्रोग्रामर नहीं है, हमें इसकी आवश्यकता नहीं है। ग्राहक C # में एकता संपादक, राइडर में सभी तर्क लिखते हैं और यह गेम सर्वर पर काम करता है। लगभग हमेशा। हमने पैकेट का आकार 17 गुना घटा दिया और मेमोरी एलोकेशन को 80 गुना कम कर दिया - अब क्लाइंट और सर्वर पर एक किलोबाइट से भी कम है। औसत पिंग 200-250 एमएस था, अब यह 150 है। 200 पीसी के विपरीत, मोबाइल नेटवर्क गेम के लिए मानक है, जहां सब कुछ बहुत तेजी से होता है, खासकर स्थानीय नेटवर्क पर।



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

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

श्रोताओं से सवाल

- आप कोड पीढ़ी के लिए क्या उपयोग कर रहे हैं? आपका अपना निर्णय?

- सब कुछ सरल है - हाथ। हमने कुछ तैयार करने के लिए सोचा, लेकिन यह सिर्फ अपने हाथों से लिखने के लिए तेजी से निकला। इस रास्ते का अनुसरण करें, यह तब और अब अच्छी तरह से काम करता है।

- आपने सर्वर डेवलपर को मना कर दिया, लेकिन आपने इस कोड के दोबारा उपयोग किए जाने के कारण विकास के समय को कम नहीं किया। एकता सी # के नवीनतम संस्करण का समर्थन नहीं करती है, हुड के नीचे इसका अपना इंजन है। आप .NET कोर का उपयोग नहीं कर सकते, आप नवीनतम सुविधाओं, कुछ संरचनाओं, और अधिक का उपयोग नहीं कर सकते। क्या प्रदर्शन इससे एक तिहाई के बारे में पीड़ित नहीं है?

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

- अब आप बिना इंटरपोल के कैसे रहते हैं? और अगर आप स्नैपशॉट सही फ्रेम में नहीं आते हैं तो आप खिलाड़ी होने का दिखावा कैसे करते हैं?

- हमारे पास प्रक्षेप है, केवल यह दृश्य नहीं है, लेकिन उन पैकेटों पर है जो नेटवर्क पर आते हैं। मान लीजिए कि हमारे पास 18 वें, 19 वें और 20 वें राज्य हैं। 18-, 20-, 19- , — . , .

— , ?

— 2D — , . : UDP, , : , . .

— ?

"हाँ, बिल्कुल।" - ( , , ), 2 : , .

— . ? ? 1000 , ? , ?

— , . , -, , . , 30 .

— , ?

— . , ( ), . — , , . - , , . , , , , . .

— ECS, , ? ?

— 30 , . 80 , . .

— prediction. 20- - , , - — , ? , . - ?

— : . (, 15-) 16-,17-,18- .

— ?

— , . , , . Entity ( ), . — , . ID , .

— - — , , , ? , ?

— , , . 3D , — , , - . , , . top-down, — . . , , , . .

— ?

— . ऐसा भी होता है।

— , , - . - . - , , , 500 , , - - . ?

— .



, .. 20- 20- , . — , . : 20- , ? , . , — - . , . , « - , 21-, 18-». : «, - ». .

— .. , ?

— , .

— reliable UDP — - ?

— Photon, Photon reliable UDP, unreliable, c .

— ?

— , -. , . , . , . , . 100%, , 80%, .

— ?

— , , Photon , MTU.

— ? ?

— , , , . . , . , , , .

— , , ?

— , . , . , , . , - . , . , .

— / — - . , .

— , . , ( ), -, , -. , . — , .

— , - . ?

— , . : ECS, . , ECS . , ECS . , . , , , ( , , , , , ). 2D , , 3D — . 3D , , . . - , . , - -, .

— , ECS , . , , C#?

— — .

— .. ES ? , ECS — , , , . .. ECS — , .

— , , . , . — , , . , O - , , .

— , ECS- ?

— -, ECS , , ( ) — , . , — . — , , . , , , ..

Pixonic DevGAMM Talks

• Consul stateful- ( , DevOps BIT.GAMES);
• CICD: ( , Pixonic);
• - Quake Champions ( , backend- Saber Interactive);
• - - Tacticool ( , Lead Software Engineer PanzerDog);
• ECS, C# Job System SRP ( , Field Engineer Unity);
• KISS ( , Lead Game Programmer 1C Game Studios);
• Cucumber : BDD- ( , Technical Product Manager, ALICE Platform).