क्या आधुनिक मल्टीप्लेयर गेम्स में सर्वर से क्लाइंट तक पर्यावरण जैसी विशाल, स्थैतिक वस्तुएं संचारित होती हैं?


18

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

यह इस तरह दिख रहा है:

  1. Client पहुँच टोकन को भेजता है Server
  2. Client से स्वीकृति प्राप्त करता है Server
  3. Client खेल के दृश्य के लिए दृश्य स्विच
  4. Serverखिलाड़ियों, बक्से, वस्तुओं को भेजता है जिनसे आप बातचीत clientकर सकते हैं और उन्हें स्पॉन और प्रदर्शित कर सकते हैं।

लेकिन जमीनी वस्तु का क्या? अभी के लिए, मेरे पास सर्वर और क्लाइंट पर एक ही समान दृश्य है - एक मंजिल के रूप में अभिनय करने वाले एक स्थिर विमान के साथ। वर्तमान में मैं नया सामान, पेड़, सीढ़ियाँ जोड़ रहा हूँ और चीजों का निर्माण कर रहा हूँ।

मैंने सोचा - हम अच्छे हैं। लेकिन क्या पर्यावरण को भी सिंक्रनाइज़ नहीं किया जाना चाहिए? किसी तरह नेटवर्क हो? सर्वर द्वारा स्वामित्व?

आइए लेते हैं League of Legends:

यहाँ छवि विवरण दर्ज करें

यह एक स्थिर वातावरण है, शायद एक संयुक्त जाल (सीढ़ियाँ, घास, दीवारें, दुकान)। लेकिन क्या यह वास्तव में क्लाइंट पर रखा गया है या इसे लोडिंग स्क्रीन के दौरान सर्वर द्वारा भेजा गया है?


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

जवाबों:


41

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

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

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


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

@hoffmale हां, अच्छी बात है; परिदृश्य का उल्लेख अंत में स्थिर था, इसलिए मैंने उस बिंदु को उठाने के लिए नहीं सोचा था, लेकिन यह एक अच्छा है।

3
यदि कोई परिसंपत्ति एक स्पॉइलर है, तो आमतौर पर परिसंपत्ति क्लाइंट पर होती है, एन्क्रिप्ट की जाती है, और डिक्रिप्शन कुंजी को सर्वर से क्लाइंट में तब स्थानांतरित किया जाता है जब परिसंपत्ति की आवश्यकता होती है।
ग्रांट डेविस

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

5

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

वास्तव में, मेष को आमतौर पर नहीं भेजा जाएगा, क्योंकि यह पहले से ही अधिकांश आरटीएस मामलों में क्लाइंट पर होगा। टकराव का नक्शा है या नहीं , जो दो को सिंक में रखने के लिए वास्तव में महत्वपूर्ण है, भेजा गया है, एक और सवाल है। लेकिन अधिकांश आरटीएस में, यह फिर से क्लाइंट पर प्री-स्टोर किया जाएगा।

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

इसके बाद, सिंक किए जाने के कुछ विशिष्ट तरीके हैं:

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

4

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

लेकिन सामान्य तौर पर, आपके प्रश्न का उत्तर काफी सरल और सीधा है:

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

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

यह सभी नेटवर्क संचारों पर लागू होता है, न कि केवल इलाके डेटा पर। सब कुछ


2

नहीं।

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

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

तो फिर यह कैसे हल किया जाता है? प्रत्येक खिलाड़ी केवल सर्वर पर खेल में अन्य खिलाड़ियों के लिए मायने रखता है कि केवल डेटा भेजता है। किसी को यह जानने की जरूरत नहीं है कि आपके पास Q cooldown पर 5 सेकंड बचे हैं, या कि डीप टेरर थ्रेश स्किन आपके लिए बुलबुले बनाता है। चीजें जो खेल में पास हो जाती हैं, वे चीजें हैं, जैसे कि वेल'कोज ने क्यू, विक्टर ने बाईं ओर ले जाया, आदि ...

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

ध्यान दें:

यदि आप ग्राहक के पास क्या देखना चाहते हैं, और इसलिए, सर्वर आपको पास नहीं करता है, तो C: \ Riot Games \ RADS \ lol_Game_Client \ Project फ़ोल्डर ढूंढें (जो थोड़ा बंद हो सकता है, क्षमा करें) अभी मेमोरी बंद कर रहा हूं) और .RAF फाइल को ऑनलाइन अनपैक करें। फिर आप सभी सामान देख सकते हैं जो स्थानीय रूप से लोड हो रहे हैं स्क्रीन लोडिंग और त्वचा की बनावट, यहां तक ​​कि चैंपियन कंकाल भी।


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

1
@JeremyFriesner यह स्पष्ट तरीका क्यों होगा? इस पोस्ट में उल्लिखित वर्तमान कार्यान्वयन से भी बदतर लगता है, जिसे आपने समय से पहले सभी संपत्तियों को स्थापित किया है ताकि आप उन्हें जरूरत पड़ने पर तुरंत उपलब्ध करा सकें। यह एक एकल खिलाड़ी खेल के लिए ठीक काम कर सकता है, हालांकि मुझे लगता है कि बहुत से लोग खेल के दौरान डाउनलोड की जाने वाली नई संपत्तियों के लिए लगातार प्रतीक्षा करने के लिए एक अधिक स्थापना समय (और अधिक डिस्क स्थान उपयोग) पसंद करेंगे।
एंथनी ग्रिस्ट

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

1
@AnthonyGrist यही कारण है कि दिग्गजों की लीग जैसे कई खेलों में एक खिलाड़ी को एक मैच खोजने के लिए कतार में शामिल होने से पहले सभी खेल संपत्ति डाउनलोड करने की आवश्यकता होती है। जब आप एक बड़ी संपत्ति के लिए इंतजार करेंगे तो यह गेम लैग होने से कहीं बेहतर है। ध्यान रखें कि खेल के इस सामान्य में, खिलाड़ी पिंग में 10 एमएस की कमी पर उत्साहित हो जाते हैं और अक्सर पिंग के <50 एमएस के साथ खेल रहे हैं और यह बता सकते हैं कि क्या 100 से 150 की सीमा में कूदता है। एक खेल के दौरान एक संपत्ति लाने के लिए इंतजार करना एक MOBA या FPS में एक आपदा होगी, और अगर यह गलत समय पर हुआ तो यह एक खेल के परिणाम को भी बदल सकता है।
JustWannaFly

@AnthonyGrist (जारी) मुझे लगता है कि आप इसके बारे में इस तरह सोच सकते हैं। कुछ मल्टीप्लेयर / प्रतिस्पर्धी खेलों में, खिलाड़ी एक अधिक वास्तविक समय गेम खेलने के अनुभव के लिए अधिक लोडिंग / पैचिंग / इंस्टॉलेशन समय का व्यापार करते हैं, जिसमें क्लाइंट को सभी अपडेट करने और कतार में प्रवेश करने का ध्यान होता है। इससे ऐसा होता है कि केवल विशिष्ट खिलाड़ी को संपत्ति की आवश्यकता होती है, जब तक कि वह किसी प्रीमियर पार्टी में शामिल नहीं होना चाहता है, तब तक इंतजार करना होगा, तब पार्टी के सभी खिलाड़ियों को विरोधियों को खोजने के लिए कतार में प्रवेश करने के लिए इंतजार करना होगा
JustWannaFly

1

जहां ऐसा नहीं किया गया था, उसका एक उदाहरण एल्डर स्क्रॉल ऑनलाइन था, जहां यह ग्राउंड लेवल की ऊंचाई के बारे में क्लाइंट पर भरोसा करता था ।

स्वर्ण-खनिकों ने कई फीट नीचे जमीन का स्तर गिरा दिया। इसके बाद वे इलाके के नीचे "घूमना" कर सकते हैं, और नीचे से खनन संसाधन पीसी द्वारा देखे बिना या एनपीसी द्वारा हमला किया जा सकता है।

इसी तरह के संपादन ने उन्हें चिकनी चट्टानों की अनुमति दी, ताकि वे उनके ऊपर चल सकें, स्थैतिक दीवारों के नीचे हटा या मार्ग कर सकें, सभी स्थिर वस्तुओं के माध्यम से देख सकें, आदि।

अनिवार्य रूप से, सर्वर ने ग्राहक को खिलाड़ी के स्थान के बारे में भरोसा किया, सभी आंकड़ों के खिलाफ हर एक खिलाड़ी के लिए सर्वर की तरफ से टक्कर की गणना काफी भारी होगी।

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


1
टी एल; डॉ: हमेशा लगता है कि ग्राहक एक झूठ बोल रही है, धोखाधड़ी, है बस्टर्ड । लेकिन सब कुछ के सर्वर सत्यापन आपकी क्षमता को कम करती है।
Draco18s अब SE
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.