मैं वर्तमान में एक सरल ऑनलाइन मल्टीप्लेयर गेम की योजना बना रहा हूं। और यहाँ सवाल है। यह सर्वर पर पूरे खेल तर्क बनाने के लिए समझ में आता है और सिर्फ ग्राहक से सर्वर को इनपुट भेजने के लिए? जो पेशेवरों और विपक्ष हैं या कोई कारण है कि मुझे ऐसा क्यों नहीं करना चाहिए?
जवाबों:
आप सर्वर पर प्लेयर इनपुट नहीं भेजना चाहते हैं। जो आप शायद करना चाहते हैं, वह एक सार प्रतिनिधित्व है कि खिलाड़ी सर्वर पर क्या करना चाहता है, और फिर वहां पर तर्क चलाएं।
इसी तरह आप जरूरी नहीं कि सब कुछ ग्राहक को वापस भेजना चाहते हैं। उदाहरण के लिए, आप "एनपीसी एक्स मर गया" कहकर किसी प्रकार का संदेश भेज सकते हैं, और ग्राहक यह निर्धारित करता है कि एनीमेशन / खेलने के लिए क्या लगता है। इस तरह के सामान।
चाल उस रेखा को खोजने के लिए है जहां बैंडविड्थ और प्रसंस्करण शक्ति (सर्वर पर) लोगों को धोखा देने से रोककर ट्रम्प किया जाता है। आमतौर पर आप सर्वर पर किसी भी प्रकार का गेम-चेंजिंग ऑथरिटिव निर्णय लेते हैं, और क्लाइंट को सभी सहायक दृश्य सामग्री छोड़ देते हैं।
इस विषय पर सभी साइट पर बहुत अधिक विशिष्ट प्रश्न हैं। उदाहरण के लिए:
एक एआईजी में एआई गणना कौन करता है?
क्या खेल होस्ट को प्राधिकरण, या किसी अन्य गूंगा ग्राहक होना चाहिए?
ठीक है, आपको उत्तर मिल गए लेकिन आपका असली उत्तर "स्वयं को आज़माने" पर है। खेल से खेल में चीजें अलग होती हैं।
मैंने कुछ वितरित नेटवर्क गेम डिज़ाइन कोर्स के लिए मल्टीप्लेयर गेम के कुछ जोड़े। सबसे चुनौतीपूर्ण एक रियलटाइम एक्शन गेम कर रहा था जिसमें कई खिलाड़ी शामिल थे और नरक जैसे इनपुट भेज रहे थे। जब उस बिंदु पर आता है, तो सब कुछ समस्या बन जाता है। जैसा कि आप पहली लिंक टेट्रैट को भेजे गए देखते हैं, यहां तक कि एक मिलीभगत का निर्धारण भी एक समस्या बन जाती है। और आप लैग, इंटरपोलेशन, एक्सट्रपलेशन, प्रीडिक्शन जैसे शब्द पढ़ेंगे ... लेकिन अगर आपने कभी अपने आप को स्क्रैच से कोडिंग करने की कोशिश नहीं की, तो आप बस इन शब्दों को स्वीकार करेंगे और नहीं जान पाएंगे कि उनका वास्तव में क्या मतलब है।
मेरी सिफारिश है:
चरण 1
अभी के लिए पूरी तरह से अधिकृत सर्वर आधारित डिजाइन के साथ शुरू करें। जैसा कि आपने कहा, बस सर्वर को उपयोगकर्ता इनपुट भेजें और सर्वर को सब कुछ करने दें और ग्राहकों को परिणाम प्राप्त हों। आपका खेल पूरी तरह से सुसंगत काम करेगा। लेकिन जब आप अपने ग्राहकों को देखते हैं, तो आप कुछ अंतराल, कुछ टेलीपोर्ट समस्याओं पर ध्यान देंगे, न कि चिकनी चाल ... ect के।
चरण 2
क्लाइंट पक्ष पर समस्याओं को ठीक करना प्रारंभ करें। उदाहरण के लिए teleporting समस्याओं। आपका चरित्र (0,0) पर था और सर्वर ने कहा कि अब आप (100,100) पर हैं। आपका चरित्र बस (100,100) को टेलीपोर्ट करेगा जो अच्छा नहीं है। वहाँ प्रक्षेप आता है। आपके पास क्लाइंट साइड में एक कोड होना चाहिए जो चरित्र को (0,0) से (100, 100) तक सुचारू रूप से स्लाइड करेगा। हां, आप अपने चरित्र को (0,0) से (100,100) तक ले जाएंगे, लेकिन कितनी तेजी से? अभी के लिए आप प्रत्येक सर्वर अपडेट के बीच के समय के अंतर का उपयोग कर सकते हैं। यदि आपका सर्वर एक पैकेट में 10 पैकेट भेजता है जिसका अर्थ है कि प्रत्येक पैकेट के बीच 100 एमएस देरी।
चरण 3
अब आपका गेम पहले से ही तेज नेटवर्क के लिए अच्छा है जहां देरी (1-50) एमएस है। लेकिन यह बर्बाद हो जाता है अगर कोई पैकेट नुकसान होता है, उच्च विलंबता या गणना सर्वर में लंबा समय लगता है ... ect के। उन स्थितियों में जब आप बायां तीर दबाते हैं, तो आप देखेंगे कि आप अपने चरित्र को 200 एमएस की देरी से छोड़ते हुए देखेंगे। आपके पैकेट के बीच की देरी सर्वर, गणना समय पर जाती है और आपकी अंतिम स्थिति के साथ आपके पास वापस आती है। यह खराब है, सर्वर अधिकृत डिज़ाइन का सबसे खराब नुकसान है। खिलाड़ी चाहता है कि जैसे ही वह बाईं ओर दबाए उसके चरित्र को छोड़ दिया जाए, आप उसे इंतजार नहीं करवा सकते। सौभाग्य से क्लाइंट के पास सर्वर के समान कोड है, इसलिए इसे क्लाइंट पर तुरंत निष्पादित क्यों न करें और सर्वर से उत्तर के साथ अंतिम परिणाम को ठीक करें? मूल रूप से इनपुट भविष्यवाणी क्या है। ग्राहक बाईं ओर दबाता है, उसके पक्ष में कोड उसे बाईं ओर ले जाएगा, कुछ समय के बाद 200 ms कहने देता है, वास्तविक स्थिति सर्वर से आती है और क्लाइंट इसके साथ अपनी स्थिति ठीक करता है। अगर सब कुछ ठीक हो गया, तो क्लाइंट कुछ भी नोटिस नहीं करेगा, "चरण 2" भी हमें इसमें मदद करेगा।
खैर, इस विषय में नेट के कई ट्यूटोरियल और चीजें हैं। लेकिन वहाँ 2 मैं वास्तव में पसंद कर रहे हैं:
वास्तव में अच्छा है, काले धब्बे कवर करता है: वाल्व-सोर्स इंजन मल्टीप्लेयर नेटवर्किंग की
तरह इतिहास, पढ़ने के लिए मजेदार और इसके लायक: 28.88 पर 1500 आर्चर ,
पेशेवरों:
विपक्ष:
सर्वर साइड तर्क भी स्केलेबिलिटी की समस्या पैदा करता है - आपको अपने सर्वर पर सभी क्लाइंट के लिए सभी काम करने होंगे - प्रत्येक क्लाइंट को कुल काम का अपना हिस्सा देने की छंद।
निर्भर करता है कि आप किस खेल को बनाना चाहते हैं और खेल का क्या हिस्सा है। यदि आरटीएस (या लॉकस्टेड मॉडल के साथ कोई गेम) विकसित किया जा रहा है, तो आपको निश्चित रूप से केवल इनपुट भेजना चाहिए और कौन से सिमुलेशन कदम से इनपुट प्राप्त किया गया था।
यदि आप एक शूटर करना चाहते हैं तो आप इनपुट और अमूर्त कार्यों दोनों का उपयोग कर सकते हैं। यदि आप मामले के रूप में अवास्तविक टूर्नामेंट 3 लेते हैं, तो उन्होंने मुख्य रूप से प्रतिकृति फ़ंक्शन कॉल के माध्यम से मल्टीप्लेयर बनाया।
आंदोलन के लिए वे खिलाड़ी इनपुट लेते हैं (प्रत्येक क्रिया के लिए एक ही बिट में संकुचित) डेल्टा रोटेशन, त्वरण और टाइमस्टैम्प और इसे सर्वर पर भेजते हैं।
जब आप गोली मारते हैं, तो हथियार जैसे अन्य उद्देश्यों के लिए वे सिंक्रनाइज़ करते हैं (AFAIK, अभी तक इस हिस्से को गहराई से नहीं देखा है)।
स्वास्थ्य की तरह अधिक स्थिर / कम अक्सर बदले हुए मूल्यों के लिए वे क्लाइंट या सर्वर को वैरिएबल भेजते हैं जो प्रोग्रामर द्वारा निर्दिष्ट के आधार पर होता है।
और गैर-आरटीएस गेम के लिए, ग्राहक की भविष्यवाणी को याद रखें।