पछिल्लो दुई हप्तादेखि म मेरो खेलको लागि अनलाइन इन्जिनमा काम गरिरहेको छु। यस अघि, मलाई खेलहरूमा नेटवर्किङको बारेमा केही थाहा थिएन, त्यसैले मैले धेरै लेखहरू पढें र सबै अवधारणाहरू बुझ्न र मेरो आफ्नै नेटवर्किङ इन्जिन लेख्न सक्षम हुन धेरै प्रयोगहरू गरें।

यस गाइडमा, म तपाइँसँग तपाइँको आफ्नै खेल इन्जिन लेख्नु अघि तपाइँले सिक्न आवश्यक विभिन्न अवधारणाहरू, साथै तिनीहरूलाई सिक्नको लागि उत्कृष्ट स्रोतहरू र लेखहरू साझा गर्न चाहन्छु।

सामान्यतया, त्यहाँ दुई मुख्य प्रकारका नेटवर्क आर्किटेक्चरहरू छन्: पियर-टु-पियर र क्लाइन्ट-सर्भर। पियर-टु-पियर (p2p) आर्किटेक्चरमा, डेटा जडित खेलाडीहरूको कुनै पनि जोडीहरू बीच स्थानान्तरण गरिन्छ, जबकि क्लाइन्ट-सर्भर आर्किटेक्चरमा, डेटा केवल खेलाडीहरू र सर्भरहरू बीच स्थानान्तरण गरिन्छ।

यद्यपि पियर-टु-पियर आर्किटेक्चर अझै पनि केही खेलहरूमा प्रयोग गरिन्छ, क्लाइन्ट-सर्भर मानक हो: यसलाई कार्यान्वयन गर्न सजिलो छ, सानो च्यानल चौडाइ चाहिन्छ, र धोखाधडीबाट जोगाउन सजिलो बनाउँछ। त्यसकारण, यस ट्यूटोरियलमा हामी क्लाइन्ट-सर्भर आर्किटेक्चरमा फोकस गर्नेछौं।

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

सञ्जाल गेमिङ प्रणालीमा तीन मुख्य कम्पोनेन्टहरू छन्:

• यातायात प्रोटोकल: कसरी डाटा ग्राहक र सर्भर बीच स्थानान्तरण गरिन्छ।
• एप्लिकेसन प्रोटोकल: क्लाइन्टहरूबाट सर्भरमा र सर्भरबाट ग्राहकहरूमा र कुन ढाँचामा प्रसारित हुन्छ।
• एप्लिकेसन तर्क: कसरी ट्रान्सफर गरिएको डाटा ग्राहक र सर्भरको स्थिति अद्यावधिक गर्न प्रयोग गरिन्छ।

प्रत्येक भागको भूमिका र तिनीहरूसँग सम्बन्धित चुनौतीहरू बुझ्न यो धेरै महत्त्वपूर्ण छ।

यातायात प्रोटोकल

पहिलो चरण सर्भर र ग्राहकहरु बीच डाटा ढुवानी को लागी एक प्रोटोकल चयन गर्न को लागी छ। यसको लागि दुई इन्टरनेट प्रोटोकलहरू छन्: टीसीपी и UDP। तर तपाईं ती मध्ये एकको आधारमा आफ्नै यातायात प्रोटोकल सिर्जना गर्न सक्नुहुन्छ वा तिनीहरूलाई प्रयोग गर्ने पुस्तकालय प्रयोग गर्न सक्नुहुन्छ।

TCP र UDP को तुलना

TCP र UDP दुवै मा आधारित छन् IP। IP ले प्याकेटलाई स्रोतबाट प्रापकमा पठाउन अनुमति दिन्छ, तर पठाइएको प्याकेट चाँडो वा चाँडो प्रापकमा पुग्ने, कम्तिमा एक पटक पुग्ने र प्याकेटहरूको क्रम सही रूपमा आइपुग्छ भन्ने ग्यारेन्टी दिँदैन। आदेश। यसबाहेक, एउटा प्याकेटले मानद्वारा दिइएको डेटाको सीमित मात्रा मात्र समावेश गर्न सक्छ MTU.

UDP IP को शीर्ष मा एक पातलो तह मात्र हो। त्यसैले, यसको समान सीमाहरू छन्। यसको विपरीत, TCP धेरै सुविधाहरू छन्। यसले त्रुटि जाँचको साथ दुई नोडहरू बीच एक विश्वसनीय, व्यवस्थित जडान प्रदान गर्दछ। तसर्थ, TCP धेरै सुविधाजनक छ र धेरै अन्य प्रोटोकलहरूमा प्रयोग गरिन्छ, उदाहरणका लागि। HTTP, एफटीपी и SMTP। तर यी सबै सुविधाहरू मूल्यमा आउँछन्: ढिला.

यी कार्यहरूले किन विलम्बता निम्त्याउन सक्छ भनेर बुझ्नको लागि, हामीले TCP कसरी काम गर्छ भनेर बुझ्न आवश्यक छ। जब पठाउने नोडले प्राप्त गर्ने नोडमा प्याकेट पठाउँछ, यसले एक स्वीकृति (ACK) प्राप्त गर्ने अपेक्षा गर्दछ। यदि एक निश्चित समय पछि यो प्राप्त गर्दैन भने (किनकि प्याकेट वा स्वीकृति हराएको थियो, वा कुनै अन्य कारणले), त्यसपछि यो प्याकेट पुन: पठाउँछ। यसबाहेक, TCP ले ग्यारेन्टी दिन्छ कि प्याकेटहरू सही क्रममा प्राप्त हुन्छन्, त्यसैले हराएको प्याकेट प्राप्त नभएसम्म अन्य सबै प्याकेटहरू प्रशोधन गर्न सकिँदैन, यद्यपि तिनीहरू प्राप्तकर्ताले पहिले नै प्राप्त गरिसकेका छन्।

तर तपाईले कल्पना गर्न सक्नुहुन्छ, मल्टिप्लेयर खेलहरूमा विलम्बता धेरै महत्त्वपूर्ण छ, विशेष गरी FPS जस्ता कार्य-प्याक विधाहरूमा। यसैले धेरै खेलहरूले आफ्नै प्रोटोकलसँग UDP प्रयोग गर्छन्।

नेटिभ UDP-आधारित प्रोटोकल विभिन्न कारणहरूको लागि TCP भन्दा बढी कुशल हुन सक्छ। उदाहरणका लागि, यसले केही प्याकेटहरूलाई विश्वसनीय र अरूलाई अविश्वसनीय रूपमा चिन्ह लगाउन सक्छ। तसर्थ, अविश्वसनीय प्याकेट प्रापकमा पुग्छ कि गर्दैन भन्ने कुराको मतलब छैन। वा यसले धेरै डाटा स्ट्रिमहरू प्रशोधन गर्न सक्छ ताकि एक स्ट्रिममा हराएको प्याकेटले बाँकी स्ट्रिमहरूलाई ढिलो गर्दैन। उदाहरणका लागि, प्लेयर इनपुटको लागि एउटा थ्रेड र च्याट सन्देशहरूको लागि अर्को थ्रेड हुन सक्छ। अत्यावश्यक नभएको च्याट सन्देश हरायो भने, यसले आवश्यक इनपुटलाई ढिलो गर्दैन। वा एक मालिकाना प्रोटोकलले भिडियो गेम वातावरणमा अधिक कुशल हुन TCP भन्दा फरक रूपमा विश्वसनीयता लागू गर्न सक्छ।

त्यसोभए, यदि TCP यति धेरै बेकार छ भने, हामी UDP मा आधारित हाम्रो आफ्नै यातायात प्रोटोकल सिर्जना गर्नेछौं?

यो अलि बढी जटिल छ। यद्यपि TCP गेमिङ नेटवर्क प्रणालीहरूको लागि लगभग सबोप्टिमल छ, यसले तपाइँको विशिष्ट खेलको लागि राम्रोसँग काम गर्न सक्छ र तपाइँको बहुमूल्य समय बचत गर्न सक्छ। उदाहरणका लागि, पालो-आधारित खेल वा ल्यान नेटवर्कहरूमा मात्र खेल्न सकिने खेलको लागि विलम्बता समस्या नहुन सक्छ, जहाँ विलम्बता र प्याकेट हानि इन्टरनेटको तुलनामा धेरै कम हुन्छ।

Warcraft, Minecraft र Terraria लगायत धेरै सफल खेलहरूले TCP प्रयोग गर्छन्। यद्यपि, धेरैजसो FPS हरूले आफ्नै UDP-आधारित प्रोटोकलहरू प्रयोग गर्छन्, त्यसैले हामी तल तिनीहरूको बारेमा थप कुरा गर्नेछौं।

यदि तपाईंले TCP प्रयोग गर्ने निर्णय गर्नुभयो भने, यो असक्षम गरिएको छ भनी सुनिश्चित गर्नुहोस् Nagle को एल्गोरिथ्म, किनकि यसले पठाउनु अघि प्याकेटहरू बफर गर्दछ, जसको मतलब यसले विलम्बता बढाउँछ।

मल्टिप्लेयर खेलहरूको सन्दर्भमा UDP र TCP बीचको भिन्नताहरू बारे थप जान्नको लागि, तपाईंले Glenn Fiedler को लेख पढ्न सक्नुहुन्छ। UDP बनाम TCP.

आफ्नै प्रोटोकल

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

पहिलो लेख खेल प्रोग्रामरहरूको लागि नेटवर्किङ 2008, दोस्रो भन्दा सजिलो, खेल नेटवर्क प्रोटोकल निर्माण गर्दै 2016। म सुझाव दिन्छु कि तपाइँ पुरानो संग सुरु गर्नुहोस्।

ध्यान दिनुहोस् कि ग्लेन फिडलर UDP मा आधारित अनुकूलन प्रोटोकल प्रयोग गर्ने एक ठूलो समर्थक हो। र उहाँका लेखहरू पढिसकेपछि, तपाईंले सायद उहाँको विचारलाई स्वीकार गर्नुहुनेछ कि भिडियो गेमहरूमा TCP का गम्भीर कमीहरू छन्, र तपाईं आफ्नै प्रोटोकल लागू गर्न चाहानुहुन्छ।

तर यदि तपाइँ नेटवर्किङमा नयाँ हुनुहुन्छ भने, आफैलाई एक पक्ष दिनुहोस् र TCP वा पुस्तकालय प्रयोग गर्नुहोस्। तपाईंको आफ्नै यातायात प्रोटोकल सफलतापूर्वक लागू गर्न, तपाईंले पहिले धेरै सिक्न आवश्यक छ।

नेटवर्क पुस्तकालयहरू

यदि तपाइँलाई TCP भन्दा बढी कुशल केहि चाहिन्छ, तर तपाइँको आफ्नै प्रोटोकल लागू गर्न र धेरै विवरणहरूमा जाने झन्झट मार्फत जान चाहनुहुन्न भने, तपाइँ नेटवर्किङ पुस्तकालय प्रयोग गर्न सक्नुहुन्छ। तिनीहरूमध्ये धेरै छन्:

• योजिम्बो ग्लेन फिडलर
• RakNet, जुन अब समर्थित छैन, तर यसको एक काँटा SLikeNet यो अझै सक्रिय छ जस्तो देखिन्छ।
• ENet मल्टिप्लेयर FPS को लागि सिर्जना गरिएको पुस्तकालय हो घन
• गेमनेटवर्किङसकेटहरू भल्भ

मैले ती सबै प्रयास गरेको छैन, तर म ENet लाई रुचाउँछु किनभने यो प्रयोग गर्न सजिलो र भरपर्दो छ। थप रूपमा, यसमा स्पष्ट कागजात र शुरुआतीहरूको लागि ट्यूटोरियल छ।

यातायात प्रोटोकल: निष्कर्ष

संक्षेपमा: त्यहाँ दुई मुख्य यातायात प्रोटोकलहरू छन्: TCP र UDP। TCP मा धेरै उपयोगी सुविधाहरू छन्: विश्वसनीयता, प्याकेट अर्डर संरक्षण, त्रुटि पत्ता लगाउने। UDP मा यो सबै छैन, तर TCP ले यसको प्रकृतिले विलम्बता बढाएको छ, जुन केहि खेलहरूको लागि अस्वीकार्य छ। त्यो हो, कम विलम्बता सुनिश्चित गर्न, तपाईंले UDP मा आधारित आफ्नो प्रोटोकल सिर्जना गर्न सक्नुहुन्छ वा UDP मा यातायात प्रोटोकल लागू गर्ने र मल्टिप्लेयर भिडियो गेमहरूको लागि अनुकूल भएको पुस्तकालय प्रयोग गर्न सक्नुहुन्छ।

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

मसँग दुईवटा सल्लाह छ:

• बाँकी एप्लिकेसनबाट ट्राफिक प्रोटोकललाई सकेसम्म धेरै सार्नुहोस् ताकि यो सबै कोड पुन: लेखी बिना सजिलै प्रतिस्थापन गर्न सकिन्छ।
• अति अप्टिमाइज नगर्नुहोस्। यदि तपाइँ नेटवर्किङ विशेषज्ञ हुनुहुन्न र तपाइँलाई अनुकूलन UDP-आधारित यातायात प्रोटोकल चाहिन्छ कि भनेर निश्चित हुनुहुन्न भने, तपाइँ TCP वा एक पुस्तकालय जसले विश्वसनीयता प्रदान गर्दछ, र त्यसपछि परीक्षण र प्रदर्शन मापन गर्न सक्नुहुन्छ। यदि समस्याहरू उत्पन्न हुन्छन् र तपाईं ढुक्क हुनुहुन्छ कि कारण यातायात प्रोटोकल हो, तब यो तपाईंको आफ्नै यातायात प्रोटोकल सिर्जना गर्ने समय हुन सक्छ।

यस भागको अन्त्यमा, म तपाईंलाई पढ्न सिफारिस गर्दछु मल्टिप्लेयर गेम प्रोग्रामिङको परिचय ब्रायन हुक द्वारा, जसले यहाँ छलफल गरिएका धेरै विषयहरूलाई समेट्छ।

आवेदन प्रोटोकल

अब जब हामी ग्राहक र सर्भर बीच डाटा आदान प्रदान गर्न सक्छौं, हामीले कुन डाटा स्थानान्तरण गर्ने र कुन ढाँचामा निर्णय गर्न आवश्यक छ।

क्लासिक योजना भनेको ग्राहकहरूले सर्भरमा इनपुट वा कार्यहरू पठाउँछन्, र सर्भरले ग्राहकहरूलाई हालको खेल स्थिति पठाउँदछ।

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

क्रमिकरण

पहिलो चरण भनेको हामीले पठाउन चाहेको डाटा (इनपुट वा खेल अवस्था) लाई प्रसारणको लागि उपयुक्त ढाँचामा रूपान्तरण गर्नु हो। यो प्रक्रिया भनिन्छ क्रमबद्धता.

तुरुन्तै दिमागमा आउने विचार भनेको मानव-पढ्न सकिने ढाँचा प्रयोग गर्नु हो, जस्तै JSON वा XML। तर यो पूर्ण रूपमा प्रभावहीन हुनेछ र धेरै च्यानल बर्बाद हुनेछ।

यसको सट्टा बाइनरी ढाँचा प्रयोग गर्न सिफारिस गरिन्छ, जुन धेरै कम्प्याक्ट छ। त्यो हो, प्याकेटहरूमा केही बाइटहरू मात्र हुनेछन्। यहाँ विचार गर्न समस्या छ बाइट अर्डर, जुन विभिन्न कम्प्युटरहरूमा फरक हुन सक्छ।

डेटा क्रमबद्ध गर्न, तपाईं पुस्तकालय प्रयोग गर्न सक्नुहुन्छ, उदाहरणका लागि:

• फ्ल्याटबफरहरू गूगल
• Cap'n Proto बालुवा आँधी कम्पनी
• खाद्यान्न शेन ग्रान्ट र रान्डोल्फ वुरहिस

केवल सुनिश्चित गर्नुहोस् कि पुस्तकालयले पोर्टेबल अभिलेखहरू सिर्जना गर्दछ र endianness को बारे मा ख्याल राख्छ।

एक वैकल्पिक समाधान यसलाई आफैं लागू गर्न हो; यो विशेष गरी गाह्रो छैन, विशेष गरी यदि तपाइँ आफ्नो कोडमा डेटा-केन्द्रित दृष्टिकोण प्रयोग गर्नुहुन्छ। थप रूपमा, यसले तपाईंलाई अप्टिमाइजेसनहरू प्रदर्शन गर्न अनुमति दिनेछ जुन पुस्तकालय प्रयोग गर्दा सधैं सम्भव हुँदैन।

ग्लेन फिडलरले क्रमबद्धताको बारेमा दुई लेख लेखे: पढ्ने र लेख्ने प्याकेटहरू и क्रमबद्ध रणनीतिहरू.

कम्प्रेसन

ग्राहकहरु र सर्भर बीच स्थानान्तरण डाटा को मात्रा च्यानल ब्यान्डविथ द्वारा सीमित छ। डाटा कम्प्रेसनले तपाईंलाई प्रत्येक स्न्यापसटमा थप डाटा स्थानान्तरण गर्न, अपडेट फ्रिक्वेन्सी बढाउन, वा च्यानल आवश्यकताहरू कम गर्न अनुमति दिनेछ।

बिट प्याकेजिङ्ग

पहिलो प्रविधि बिट प्याकिङ हो। यसमा चाहिने मान वर्णन गर्न आवश्यक पर्ने बिट्सको ठ्याक्कै संख्या प्रयोग हुन्छ। उदाहरणका लागि, यदि तपाइँसँग 16 फरक मानहरू हुन सक्ने enum छ भने, त्यसपछि सम्पूर्ण बाइट (8 बिट) को सट्टा, तपाइँ केवल 4 बिटहरू प्रयोग गर्न सक्नुहुन्छ।

ग्लेन फिडलरले लेखको दोस्रो भागमा यसलाई कसरी लागू गर्ने भनेर बताउँछन् पढ्ने र लेख्ने प्याकेटहरू.

बिट प्याकिङ विशेष गरी नमूनाको साथ राम्रोसँग काम गर्दछ, जुन अर्को खण्डको विषय हुनेछ।

नमूना

नमूना एउटा हानिपूर्ण कम्प्रेसन प्रविधि हो जसले मान सङ्केत गर्न सम्भावित मानहरूको उपसमूह मात्र प्रयोग गर्छ। विवेकलाई लागू गर्ने सबैभन्दा सजिलो तरिका फ्लोटिंग पोइन्ट नम्बरहरू राउन्डिङ गरेर हो।

ग्लेन फिडलर (फेरि!) आफ्नो लेखमा नमूनालाई व्यवहारमा कसरी राख्ने भनेर देखाउँछन् स्न्यापसट कम्प्रेसन.

कम्प्रेसन एल्गोरिदम

अर्को प्रविधि हानिरहित कम्प्रेसन एल्गोरिदम हुनेछ।

यहाँ, मेरो विचारमा, तपाईंले जान्न आवश्यक तीनवटा सबैभन्दा रोचक एल्गोरिदमहरू छन्:

• Huffman कोडिङ पूर्व-कम्प्युटेड कोडको साथ, जुन अत्यन्त छिटो छ र राम्रो परिणामहरू उत्पादन गर्न सक्छ। यसलाई Quake3 नेटवर्किङ इन्जिनमा प्याकेटहरू कम्प्रेस गर्न प्रयोग गरिएको थियो।
• zlib एक सामान्य-उद्देश्य कम्प्रेसन एल्गोरिथ्म हो जसले डेटाको मात्रा कहिल्यै बढाउँदैन। कसरी हेर्न सक्नुहुन्छ यहाँ, यो विभिन्न अनुप्रयोगहरूमा प्रयोग गरिएको छ। राज्यहरू अद्यावधिक गर्न यो अनावश्यक हुन सक्छ। तर यो उपयोगी हुन सक्छ यदि तपाईंलाई सर्भरबाट ग्राहकहरूलाई सम्पत्ति, लामो पाठ वा भूभाग पठाउन आवश्यक छ।
• रन लम्बाइहरू प्रतिलिपि गर्दै - यो सायद सबैभन्दा सरल कम्प्रेसन एल्गोरिथ्म हो, तर यो निश्चित प्रकारको डेटाको लागि धेरै प्रभावकारी छ, र zlib अघि पूर्व-प्रशोधन चरणको रूपमा प्रयोग गर्न सकिन्छ। यो विशेष गरी टाइल्स वा भोक्सेलले बनेको भूभाग कम्प्रेस गर्नको लागि उपयुक्त छ जसमा धेरै छेउछाउका तत्वहरू दोहोर्याइएको छ।

डेल्टा कम्प्रेसन

अन्तिम कम्प्रेसन प्रविधि डेल्टा कम्प्रेसन हो। यो तथ्यमा समावेश छ कि हालको खेल स्थिति र ग्राहक द्वारा प्राप्त अन्तिम राज्य बीचको भिन्नता मात्र प्रसारण गरिन्छ।

यो पहिलो पटक Quake3 नेटवर्क इन्जिन मा प्रयोग भएको थियो। यसलाई कसरी प्रयोग गर्ने भनेर यहाँ दुई लेखहरू छन्:

• Quake3 नेटवर्किङ मोडेल ब्रायन हुक
• भूकम्प 3 स्रोत कोड समीक्षा: नेटवर्क मोडेल फाबियन संग्लर्स [अनुवाद Habré मा लेख, खण्ड "नेटवर्क मोडेल" हेर्नुहोस्]

ग्लेन फिडलरले आफ्नो लेखको दोस्रो भागमा पनि यसलाई प्रयोग गरे स्न्यापसट कम्प्रेसन.

ईन्क्रिप्शन

थप रूपमा, तपाईंले क्लाइन्टहरू र सर्भर बीच जानकारीको स्थानान्तरण इन्क्रिप्ट गर्न आवश्यक पर्दछ। यसका धेरै कारणहरू छन्:

• गोपनीयता/गोपनीयता: सन्देशहरू प्राप्तकर्ताद्वारा मात्र पढ्न सकिन्छ, र नेटवर्क सुँघ्ने अन्य कुनै व्यक्तिले तिनीहरूलाई पढ्न सक्षम हुनेछैन।
• प्रमाणीकरण: एक व्यक्ति जसले खेलाडीको भूमिका खेल्न चाहन्छ उसको कुञ्जी थाहा हुनुपर्छ।
• धोखा रोकथाम: खराब खेलाडीहरूलाई आफ्नै धोखा प्याकेजहरू सिर्जना गर्न धेरै गाह्रो हुनेछ, तिनीहरूले एन्क्रिप्शन योजना पुन: उत्पादन गर्नुपर्नेछ र कुञ्जी फेला पार्नु पर्छ (जुन प्रत्येक जडानको साथ परिवर्तन हुन्छ)।

म दृढताका साथ यसको लागि पुस्तकालय प्रयोग गर्न सिफारिस गर्दछु। म प्रयोग गर्न सुझाव दिन्छु लाइबसोडियम, किनभने यो विशेष गरी सरल छ र उत्कृष्ट ट्यूटोरियलहरू छन्। विशेष गरी रोचक मा ट्यूटोरियल छ कुञ्जी विनिमय, जसले तपाईंलाई प्रत्येक नयाँ जडानसँग नयाँ कुञ्जीहरू उत्पन्न गर्न अनुमति दिन्छ।

आवेदन प्रोटोकल: निष्कर्ष

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

आवेदन तर्क

हामी अब क्लाइन्टमा स्थिति अद्यावधिक गर्न सक्षम छौं, तर विलम्बता मुद्दाहरूमा चल्न सक्छ। खेलाडीले इनपुट पूरा गरेपछि, सर्भरबाट खेलको स्थिति अद्यावधिक हुनको लागि यसले विश्वमा कस्तो प्रभाव पारेको छ भनेर कुर्नु पर्छ।

यसबाहेक, दुई राज्य अद्यावधिकहरू बीच, संसार पूर्ण रूपमा स्थिर छ। यदि राज्य अपडेट दर कम छ भने, आन्दोलनहरू धेरै झटका हुनेछन्।

यस समस्याको प्रभावलाई कम गर्न धेरै प्रविधिहरू छन्, र म तिनीहरूलाई अर्को खण्डमा कभर गर्नेछु।

लेटन्सी स्मूथिङ प्रविधिहरू

यस खण्डमा वर्णन गरिएका सबै प्रविधिहरू श्रृंखलामा विस्तृत रूपमा छलफल गरिएको छ द्रुत-गति मल्टिप्लेयर गेब्रियल गाम्बेटा। म लेखहरूको यो उत्कृष्ट श्रृंखला पढ्न सिफारिस गर्दछु। यसले एक अन्तरक्रियात्मक डेमो पनि समावेश गर्दछ जसले तपाईंलाई यी प्रविधिहरूले व्यवहारमा कसरी काम गर्छ भनेर हेर्न दिन्छ।

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

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

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

ग्लेन फिडलर (जस्तै!) 2004 मा एक लेख लेखे नेटवर्क भौतिकी (2004), जसमा उनले सर्भर र क्लाइन्ट बीच भौतिकी सिमुलेशनहरू सिङ्क्रोनाइज गर्ने आधार राखे। 2014 मा उहाँले लेख को एक नयाँ श्रृंखला लेखे नेटवर्किङ भौतिकी, जसले भौतिकी सिमुलेशनहरू सिङ्क्रोनाइज गर्नका लागि अन्य प्रविधिहरू वर्णन गरेको छ।

भल्भ विकिमा दुईवटा लेख पनि छन्, स्रोत मल्टिप्लेयर नेटवर्किङ и क्लाइन्ट/सर्भर इन-गेम प्रोटोकल डिजाइन र अप्टिमाइजेसनमा विलम्बता क्षतिपूर्ति विधिहरू जसले ढिलाइको लागि क्षतिपूर्तिलाई विचार गर्दछ।

ठगी रोक्न

धोखाधडी रोक्न दुई मुख्य प्रविधिहरू छन्।

पहिलो: धोखाधडीहरूलाई दुर्भावनापूर्ण प्याकेटहरू पठाउन अझ गाह्रो बनाउँदै। माथि उल्लेख गरिए अनुसार, यसलाई कार्यान्वयन गर्ने एउटा राम्रो तरिका भनेको इन्क्रिप्सन हो।

दोस्रो: एक अधिनायकवादी सर्भरले आदेश/इनपुट/कार्यहरू मात्र प्राप्त गर्नुपर्छ। ग्राहकले इनपुट पठाएर बाहेक सर्भरमा स्थिति परिवर्तन गर्न सक्षम हुनुहुँदैन। त्यसपछि, प्रत्येक पटक सर्भरले इनपुट प्राप्त गर्दा, यो प्रयोग गर्नु अघि यो मान्य छ कि छैन जाँच गर्नुपर्छ।

आवेदन तर्क: निष्कर्ष

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

अन्य उपयोगी स्रोतहरू

यदि तपाइँ नेटवर्क मोडेलहरूमा अन्य स्रोतहरू अन्वेषण गर्न चाहनुहुन्छ भने, तपाइँ तिनीहरूलाई यहाँ फेला पार्न सक्नुहुन्छ:

• ग्लेन फिडलरको ब्लग - उनको सम्पूर्ण ब्लग पढ्न लायक छ, त्यहाँ धेरै उत्कृष्ट लेखहरू छन्। यो छ नेटवर्क टेक्नोलोजीहरूमा सबै लेखहरू सङ्कलन गरिएका छन्।
• अद्भुत खेल नेटवर्किंग M. Fatih MAR द्वारा अनलाइन भिडियो गेम इन्जिनहरूमा लेख र भिडियोहरूको विस्तृत सूची हो।
• В r/gamedev subreddit को विकी त्यहाँ धेरै उपयोगी लिङ्कहरू पनि छन्।

स्रोत: www.habr.com