गेल्या दोन आठवड्यांपासून मी माझ्या गेमसाठी ऑनलाइन इंजिनवर काम करत आहे. याआधी, मला गेममधील नेटवर्किंगबद्दल काहीही माहिती नव्हते, म्हणून मी बरेच लेख वाचले आणि सर्व संकल्पना समजून घेण्यासाठी आणि माझे स्वतःचे नेटवर्किंग इंजिन लिहू शकण्यासाठी बरेच प्रयोग केले.

या मार्गदर्शकामध्ये, मी तुम्हाला तुमचे स्वतःचे गेम इंजिन लिहिण्यापूर्वी शिकण्यासाठी आवश्यक असलेल्या विविध संकल्पना, तसेच ते शिकण्यासाठी सर्वोत्तम संसाधने आणि लेख सामायिक करू इच्छितो.

सर्वसाधारणपणे, नेटवर्क आर्किटेक्चरचे दोन मुख्य प्रकार आहेत: पीअर-टू-पीअर आणि क्लायंट-सर्व्हर. पीअर-टू-पीअर (p2p) आर्किटेक्चरमध्ये, कनेक्टेड प्लेअर्सच्या कोणत्याही जोड्यांमध्ये डेटा ट्रान्सफर केला जातो, तर क्लायंट-सर्व्हर आर्किटेक्चरमध्ये, डेटा केवळ प्लेअर आणि सर्व्हर दरम्यान हस्तांतरित केला जातो.

जरी पीअर-टू-पीअर आर्किटेक्चर अजूनही काही गेममध्ये वापरले जात असले तरी, क्लायंट-सर्व्हर हे मानक आहे: ते अंमलात आणणे सोपे आहे, लहान चॅनेल रुंदी आवश्यक आहे आणि फसवणूकीपासून संरक्षण करणे सोपे करते. म्हणून, या ट्यूटोरियलमध्ये आपण क्लायंट-सर्व्हर आर्किटेक्चरवर लक्ष केंद्रित करू.

विशेषतः, आम्हाला हुकूमशाही सर्व्हरमध्ये सर्वात जास्त स्वारस्य आहे: अशा सिस्टममध्ये, सर्व्हर नेहमीच योग्य असतो. उदाहरणार्थ, जर एखाद्या खेळाडूला वाटत असेल की तो निर्देशांकांवर आहे (10, 5), आणि सर्व्हर त्याला सांगतो की तो (5, 3) वर आहे, तर क्लायंटने त्याची स्थिती सर्व्हरने नोंदवलेल्या स्थानासह बदलली पाहिजे, आणि उलट नाही. उलट अधिकृत सर्व्हर वापरल्याने फसवणूक करणाऱ्यांना ओळखणे सोपे होते.

नेटवर्क गेमिंग सिस्टममध्ये तीन मुख्य घटक असतात:

• ट्रान्सपोर्ट प्रोटोकॉल: क्लायंट आणि सर्व्हर दरम्यान डेटा कसा हस्तांतरित केला जातो.
• ऍप्लिकेशन प्रोटोकॉल: क्लायंटकडून सर्व्हरवर आणि सर्व्हरकडून क्लायंटकडे आणि कोणत्या स्वरूपात प्रसारित केले जाते.
• ऍप्लिकेशन लॉजिक: ट्रान्सफर केलेला डेटा क्लायंट आणि सर्व्हरची स्थिती अपडेट करण्यासाठी कसा वापरला जातो.

प्रत्येक भागाची भूमिका आणि त्यांच्याशी निगडीत आव्हाने समजून घेणे खूप महत्त्वाचे आहे.

वाहतूक प्रोटोकॉल

सर्व्हर आणि क्लायंट दरम्यान डेटा वाहतूक करण्यासाठी प्रोटोकॉल निवडणे ही पहिली पायरी आहे. यासाठी दोन इंटरनेट प्रोटोकॉल आहेत: टीसीपी и UDP. परंतु तुम्ही त्यापैकी एकावर आधारित तुमचा स्वतःचा वाहतूक प्रोटोकॉल तयार करू शकता किंवा त्यांचा वापर करणारी लायब्ररी वापरू शकता.

TCP आणि UDP ची तुलना

TCP आणि UDP दोन्ही आधारित आहेत IP. आयपी पॅकेटला स्त्रोताकडून प्राप्तकर्त्याकडे प्रसारित करण्याची परवानगी देतो, परंतु पाठवलेले पॅकेट लवकर किंवा नंतर प्राप्तकर्त्यापर्यंत पोहोचेल, ते किमान एकदा तरी पोहोचेल आणि पॅकेटचा क्रम योग्य प्रकारे येईल याची हमी देत ​​​​नाही. ऑर्डर शिवाय, पॅकेटमध्ये मूल्याद्वारे दिलेला डेटा मर्यादित प्रमाणात असू शकतो एमटीयू.

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

या फंक्शन्समुळे विलंब का होऊ शकतो हे समजून घेण्यासाठी, आम्हाला TCP कसे कार्य करते हे समजून घेणे आवश्यक आहे. जेव्हा पाठवणारा नोड रिसिव्हिंग नोडला पॅकेट पाठवतो, तेव्हा त्याला पावती (ACK) मिळण्याची अपेक्षा असते. ठराविक वेळेनंतर ते न मिळाल्यास (पॅकेट किंवा पोचपावती गहाळ झाल्यामुळे किंवा इतर काही कारणांमुळे), तर ते पॅकेट पुन्हा पाठवते. शिवाय, टीसीपी हमी देतो की पॅकेट्स योग्य क्रमाने प्राप्त होतील, म्हणून हरवलेले पॅकेट प्राप्त होईपर्यंत, इतर सर्व पॅकेट्सवर प्रक्रिया केली जाऊ शकत नाही, जरी ते प्राप्तकर्त्याद्वारे आधीच प्राप्त झाले असले तरीही.

परंतु तुम्ही कदाचित कल्पना करू शकता की, मल्टीप्लेअर गेममध्ये विलंब खूप महत्त्वाचा आहे, विशेषत: FPS सारख्या अॅक्शन-पॅक शैलींमध्ये. म्हणूनच अनेक गेम त्यांच्या स्वतःच्या प्रोटोकॉलसह UDP वापरतात.

मूळ UDP-आधारित प्रोटोकॉल विविध कारणांसाठी TCP पेक्षा अधिक कार्यक्षम असू शकतो. उदाहरणार्थ, ते काही पॅकेट्स विश्वसनीय म्हणून चिन्हांकित करू शकतात आणि इतरांना अविश्वासू म्हणून चिन्हांकित करू शकतात. त्यामुळे, अविश्वसनीय पॅकेट प्राप्तकर्त्यापर्यंत पोहोचते की नाही याची काळजी घेत नाही. किंवा ते एकाधिक डेटा प्रवाहांवर प्रक्रिया करू शकते जेणेकरुन एका प्रवाहातील हरवलेले पॅकेट उर्वरित प्रवाह कमी करू शकत नाही. उदाहरणार्थ, प्लेअर इनपुटसाठी एक थ्रेड आणि चॅट संदेशांसाठी दुसरा थ्रेड असू शकतो. जर तातडीचा ​​नसलेला चॅट मेसेज गहाळ झाला, तर तो तातडीचा ​​इनपुट धीमा करणार नाही. किंवा व्हिडिओ गेम वातावरणात अधिक कार्यक्षम होण्यासाठी मालकी प्रोटोकॉल TCP पेक्षा वेगळ्या पद्धतीने विश्वसनीयता लागू करू शकते.

तर, जर टीसीपी खूप शोषत असेल, तर आम्ही यूडीपीवर आधारित आमचा स्वतःचा वाहतूक प्रोटोकॉल तयार करू?

हे थोडे अधिक क्लिष्ट आहे. जरी गेमिंग नेटवर्क सिस्टीमसाठी TCP जवळजवळ सबऑप्टिमल आहे, तरीही ते तुमच्या विशिष्ट गेमसाठी चांगले कार्य करू शकते आणि तुमचा मौल्यवान वेळ वाचवू शकते. उदाहरणार्थ, वळण-आधारित गेम किंवा फक्त LAN नेटवर्कवर खेळल्या जाऊ शकणार्‍या गेमसाठी विलंबता ही समस्या असू शकत नाही, जेथे विलंबता आणि पॅकेट लॉस इंटरनेटपेक्षा खूपच कमी आहे.

वर्ल्ड ऑफ वॉरक्राफ्ट, मिनेक्राफ्ट आणि टेरारियासह अनेक यशस्वी गेम TCP वापरतात. तथापि, बहुतेक FPSs त्यांचे स्वतःचे UDP-आधारित प्रोटोकॉल वापरतात, म्हणून आम्ही खाली त्यांच्याबद्दल अधिक बोलू.

तुम्ही TCP वापरण्याचे ठरविल्यास, ते अक्षम केले असल्याची खात्री करा नागलेचा अल्गोरिदम, कारण ते पाठवण्यापूर्वी पॅकेट बफर करते, याचा अर्थ ते लेटन्सी वाढवते.

मल्टीप्लेअर गेमच्या संदर्भात UDP आणि TCP मधील फरकांबद्दल अधिक जाणून घेण्यासाठी, आपण ग्लेन फिडलरचा लेख वाचू शकता UDP वि. TCP.

स्वतःचा प्रोटोकॉल

तर तुम्हाला तुमचा स्वतःचा वाहतूक प्रोटोकॉल तयार करायचा आहे, पण कुठून सुरुवात करावी हे माहित नाही? आपण भाग्यवान आहात कारण ग्लेन फिडलरने याबद्दल दोन आश्चर्यकारक लेख लिहिले आहेत. तुम्हाला त्यांच्यामध्ये बरेच स्मार्ट विचार आढळतील.

पहिला लेख गेम प्रोग्रामरसाठी नेटवर्किंग 2008, दुसऱ्यापेक्षा सोपे, गेम नेटवर्क प्रोटोकॉल तयार करणे 2016. मी शिफारस करतो की तुम्ही जुन्यापासून सुरुवात करा.

लक्षात घ्या की ग्लेन फिडलर हे UDP वर आधारित सानुकूल प्रोटोकॉल वापरण्याचे मोठे समर्थक आहेत. आणि त्याचे लेख वाचल्यानंतर, आपण कदाचित त्याचे मत स्वीकाराल की व्हिडिओ गेममध्ये टीसीपीमध्ये गंभीर कमतरता आहेत आणि आपण आपला स्वतःचा प्रोटोकॉल लागू करू इच्छित असाल.

परंतु जर तुम्ही नेटवर्किंगसाठी नवीन असाल, तर स्वत:ला अनुकूल करा आणि TCP किंवा लायब्ररी वापरा. तुमचा स्वतःचा वाहतूक प्रोटोकॉल यशस्वीरित्या अंमलात आणण्यासाठी, तुम्हाला आधीच खूप काही शिकण्याची गरज आहे.

नेटवर्क लायब्ररी

जर तुम्हाला TCP पेक्षा अधिक कार्यक्षम काहीतरी हवे असेल, परंतु तुमचा स्वतःचा प्रोटोकॉल लागू करण्याची आणि बर्‍याच तपशीलांमध्ये जाण्याची अडचण येत नसेल, तर तुम्ही नेटवर्किंग लायब्ररी वापरू शकता. त्यापैकी बरेच आहेत:

• योजिंबो ग्लेन फिडलर
• RakNet, जे यापुढे समर्थित नाही, परंतु त्याचा एक काटा SLikeNet असे दिसते की ते अद्याप सक्रिय आहे.
• ENet मल्टीप्लेअर FPS साठी तयार केलेली लायब्ररी आहे घन
• गेमनेटवर्किंगसॉकेट्स झडप

मी त्या सर्वांचा प्रयत्न केला नाही, परंतु मी ENet ला प्राधान्य देतो कारण ते वापरण्यास सोपे आणि विश्वासार्ह आहे. याव्यतिरिक्त, त्यात स्पष्ट दस्तऐवजीकरण आणि नवशिक्यांसाठी एक ट्यूटोरियल आहे.

वाहतूक प्रोटोकॉल: निष्कर्ष

थोडक्यात: दोन मुख्य वाहतूक प्रोटोकॉल आहेत: TCP आणि UDP. TCP मध्ये अनेक उपयुक्त वैशिष्ट्ये आहेत: विश्वसनीयता, पॅकेट ऑर्डर संरक्षण, त्रुटी शोधणे. यूडीपीमध्ये हे सर्व नाही, परंतु टीसीपीने त्याच्या स्वभावानुसार विलंबता वाढवली आहे, जी काही गेमसाठी अस्वीकार्य आहे. म्हणजेच, कमी विलंबता सुनिश्चित करण्यासाठी, तुम्ही UDP वर आधारित तुमचा स्वतःचा प्रोटोकॉल तयार करू शकता किंवा UDP वर ट्रान्सपोर्ट प्रोटोकॉल लागू करणारी आणि मल्टीप्लेअर व्हिडिओ गेमसाठी अनुकूल असलेली लायब्ररी वापरू शकता.

TCP, UDP आणि लायब्ररीमधील निवड अनेक घटकांवर अवलंबून असते. प्रथम, खेळाच्या गरजेनुसार: त्याला कमी विलंब आवश्यक आहे का? दुसरे म्हणजे, ऍप्लिकेशन प्रोटोकॉल आवश्यकतांनुसार: त्याला विश्वासार्ह प्रोटोकॉलची आवश्यकता आहे का? जसे आपण पुढील भागात पाहणार आहोत, एक अ‍ॅप्लिकेशन प्रोटोकॉल तयार करणे शक्य आहे ज्यासाठी अविश्वासू प्रोटोकॉल योग्य आहे. शेवटी, आपल्याला नेटवर्क इंजिन विकसकाचा अनुभव देखील विचारात घेणे आवश्यक आहे.

माझ्याकडे दोन सल्ले आहेत:

• उर्वरित ऍप्लिकेशनमधून ट्रान्सपोर्ट प्रोटोकॉलला शक्य तितके अ‍ॅबस्ट्रॅक्ट करा जेणेकरून सर्व कोड पुन्हा न लिहिता ते सहजपणे बदलता येईल.
• जास्त ऑप्टिमाइझ करू नका. तुम्ही नेटवर्किंग तज्ञ नसल्यास आणि तुम्हाला सानुकूल UDP-आधारित वाहतूक प्रोटोकॉलची आवश्यकता आहे की नाही याची खात्री नसल्यास, तुम्ही TCP किंवा विश्वासार्हता प्रदान करणार्‍या लायब्ररीसह प्रारंभ करू शकता आणि नंतर कार्यक्षमतेची चाचणी आणि मापन करू शकता. जर समस्या उद्भवल्या आणि तुम्हाला खात्री असेल की त्याचे कारण वाहतूक प्रोटोकॉल आहे, तर तुमचा स्वतःचा वाहतूक प्रोटोकॉल तयार करण्याची वेळ येऊ शकते.

या भागाच्या शेवटी, मी तुम्हाला वाचण्याची शिफारस करतो मल्टीप्लेअर गेम प्रोग्रामिंगचा परिचय ब्रायन हुक द्वारे, ज्यामध्ये येथे चर्चा केलेल्या अनेक विषयांचा समावेश आहे.

अनुप्रयोग प्रोटोकॉल

आता आम्ही क्लायंट आणि सर्व्हरमध्ये डेटाची देवाणघेवाण करू शकतो, आम्हाला कोणता डेटा हस्तांतरित करायचा आणि कोणत्या स्वरूपात हे ठरवायचे आहे.

क्लासिक योजना अशी आहे की क्लायंट सर्व्हरला इनपुट किंवा क्रिया पाठवतात आणि सर्व्हर क्लायंटला वर्तमान गेम स्थिती पाठवते.

सर्व्हर पूर्ण स्थिती पाठवत नाही, परंतु प्लेअरच्या जवळ असलेल्या घटकांसह फिल्टर केलेली स्थिती पाठवते. तो हे तीन कारणांसाठी करतो. प्रथम, संपूर्ण स्थिती उच्च वारंवारतेवर प्रसारित होण्यासाठी खूप मोठी असू शकते. दुसरे म्हणजे, क्लायंटला प्रामुख्याने व्हिज्युअल आणि ऑडिओ डेटामध्ये स्वारस्य असते, कारण बहुतेक गेम लॉजिक गेम सर्व्हरवर नक्कल केले जातात. तिसरे म्हणजे, काही गेममध्ये खेळाडूला विशिष्ट डेटा माहित असणे आवश्यक नसते, उदाहरणार्थ, नकाशाच्या दुसऱ्या बाजूला शत्रूची स्थिती, अन्यथा तो पॅकेट स्निफ करू शकतो आणि त्याला ठार मारण्यासाठी नेमके कुठे हलवायचे हे जाणून घेऊ शकतो.

अनुक्रमांक

पहिली पायरी म्हणजे आम्‍हाला पाठवायचा असलेला डेटा (इनपुट किंवा गेम स्‍टेट) ट्रान्समिशनसाठी योग्य अशा फॉरमॅटमध्‍ये रूपांतरित करणे. या प्रक्रियेला म्हणतात अनुक्रमणिका.

जेएसओएन किंवा एक्सएमएल सारखे मानवी-वाचनीय स्वरूप वापरणे हा विचार लगेच मनात येतो. परंतु हे पूर्णपणे कुचकामी ठरेल आणि बहुतेक चॅनेल वाया घालवेल.

त्याऐवजी बायनरी स्वरूप वापरण्याची शिफारस केली जाते, जे अधिक संक्षिप्त आहे. म्हणजेच, पॅकेटमध्ये फक्त काही बाइट्स असतील. येथे विचारात घेण्यासारखी समस्या आहे बाइट ऑर्डर, जे वेगवेगळ्या संगणकांवर भिन्न असू शकतात.

डेटा अनुक्रमित करण्यासाठी, आपण लायब्ररी वापरू शकता, उदाहरणार्थ:

• फ्लॅटबफर Google
• कॅपॉन प्रोटो वाळूचे वादळ कंपनी
• अन्नधान्य शेन ग्रांट आणि रँडॉल्फ वुरहीस

फक्त लायब्ररी पोर्टेबल संग्रहण तयार करते आणि एंडियननेसची काळजी घेते याची खात्री करा.

एक पर्यायी उपाय म्हणजे ते स्वतः अंमलात आणणे; हे विशेषतः कठीण नाही, विशेषतः जर तुम्ही तुमच्या कोडसाठी डेटा-केंद्रित दृष्टीकोन वापरत असाल. याव्यतिरिक्त, हे आपल्याला ऑप्टिमायझेशन करण्यास अनुमती देईल जे लायब्ररी वापरताना नेहमीच शक्य नसते.

ग्लेन फिडलरने क्रमवारीबद्दल दोन लेख लिहिले: वाचन आणि लेखन पॅकेट и क्रमिकरण धोरणे.

संक्षिप्त

क्लायंट आणि सर्व्हर दरम्यान हस्तांतरित केलेल्या डेटाचे प्रमाण चॅनेलच्या बँडविड्थद्वारे मर्यादित आहे. डेटा कॉम्प्रेशन तुम्हाला प्रत्येक स्नॅपशॉटमध्ये अधिक डेटा हस्तांतरित करण्यास, अपडेट वारंवारता वाढविण्यास किंवा चॅनेल आवश्यकता कमी करण्यास अनुमती देईल.

बिट पॅकेजिंग

पहिले तंत्र बिट पॅकिंग आहे. त्यात इच्छित मूल्याचे वर्णन करण्यासाठी आवश्यक असलेल्या बिट्सची संख्या वापरणे समाविष्ट आहे. उदाहरणार्थ, जर तुमच्याकडे 16 भिन्न मूल्ये असू शकतात असे एनम असल्यास, संपूर्ण बाइट (8 बिट्स) ऐवजी, तुम्ही फक्त 4 बिट वापरू शकता.

ग्लेन फिडलर लेखाच्या दुसऱ्या भागात हे कसे अंमलात आणायचे ते स्पष्ट करतात वाचन आणि लेखन पॅकेट.

बिट पॅकिंग विशेषतः सॅम्पलिंगसह चांगले कार्य करते, जो पुढील विभागाचा विषय असेल.

नमुना

नमुना एक हानीकारक कॉम्प्रेशन तंत्र आहे जे मूल्य एन्कोड करण्यासाठी संभाव्य मूल्यांचा फक्त उपसंच वापरते. डिस्क्रिटिझेशन अंमलात आणण्याचा सर्वात सोपा मार्ग म्हणजे फ्लोटिंग पॉइंट नंबर्सला गोलाकार करणे.

ग्लेन फिडलर (पुन्हा!) त्याच्या लेखात नमुना सराव कसा लावायचा ते दाखवतो स्नॅपशॉट कॉम्प्रेशन.

कॉम्प्रेशन अल्गोरिदम

पुढील तंत्र लॉसलेस कॉम्प्रेशन अल्गोरिदम असेल.

येथे, माझ्या मते, तुम्हाला माहित असणे आवश्यक असलेले तीन सर्वात मनोरंजक अल्गोरिदम आहेत:

• हफमन कोडिंग प्री-कॉम्प्युटेड कोडसह, जे अत्यंत जलद आहे आणि चांगले परिणाम देऊ शकते. हे Quake3 नेटवर्किंग इंजिनमधील पॅकेट्स कॉम्प्रेस करण्यासाठी वापरले होते.
• झिलिब एक सामान्य-उद्देश कम्प्रेशन अल्गोरिदम आहे जो डेटाचे प्रमाण कधीही वाढवत नाही. आपण कसे पाहू शकता येथे, हे विविध अनुप्रयोगांमध्ये वापरले गेले आहे. राज्ये अद्यतनित करण्यासाठी ते अनावश्यक असू शकते. परंतु तुम्हाला सर्व्हरवरून क्लायंटला मालमत्ता, लांब मजकूर किंवा भूभाग पाठवायचा असल्यास ते उपयुक्त ठरू शकते.
• रन लांबी कॉपी करत आहे - हे कदाचित सर्वात सोपा कॉम्प्रेशन अल्गोरिदम आहे, परंतु विशिष्ट प्रकारच्या डेटासाठी ते खूप प्रभावी आहे, आणि zlib आधी प्री-प्रोसेसिंग चरण म्हणून वापरले जाऊ शकते. हे विशेषतः टाइल्स किंवा व्हॉक्सेलने बनलेले भूभाग संकुचित करण्यासाठी योग्य आहे ज्यामध्ये अनेक समीप घटकांची पुनरावृत्ती होते.

डेल्टा कॉम्प्रेशन

शेवटचे कॉम्प्रेशन तंत्र डेल्टा कॉम्प्रेशन आहे. यात केवळ वर्तमान गेम स्थिती आणि क्लायंटद्वारे प्राप्त झालेल्या शेवटच्या स्थितीमधील फरक प्रसारित केला जातो.

हे प्रथम Quake3 नेटवर्क इंजिनमध्ये वापरले गेले. ते कसे वापरावे हे स्पष्ट करणारे दोन लेख येथे आहेत:

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

ग्लेन फिडलरनेही आपल्या लेखाच्या दुसऱ्या भागात त्याचा वापर केला आहे स्नॅपशॉट कॉम्प्रेशन.

कूटबद्धीकरण

याव्यतिरिक्त, आपल्याला क्लायंट आणि सर्व्हर दरम्यान माहितीचे हस्तांतरण एन्क्रिप्ट करण्याची आवश्यकता असू शकते. याची अनेक कारणे आहेत:

• गोपनीयता/गोपनीयता: संदेश केवळ प्राप्तकर्त्याद्वारेच वाचले जाऊ शकतात आणि नेटवर्क शोधणारी कोणतीही व्यक्ती ते वाचण्यास सक्षम असणार नाही.
• प्रमाणीकरण: ज्या व्यक्तीला खेळाडूची भूमिका करायची आहे त्याला त्याची किल्ली माहित असणे आवश्यक आहे.
• फसवणूक प्रतिबंध: दुर्भावनापूर्ण खेळाडूंना त्यांचे स्वतःचे फसवणूक पॅकेज तयार करणे अधिक कठीण होईल, त्यांना एन्क्रिप्शन योजना पुन्हा तयार करावी लागेल आणि की शोधावी लागेल (जी प्रत्येक कनेक्शनसह बदलते).

मी यासाठी लायब्ररी वापरण्याची जोरदार शिफारस करतो. मी वापरण्याचा सल्ला देतो लिबसोडियम, कारण ते विशेषतः सोपे आहे आणि उत्कृष्ट ट्यूटोरियल आहेत. वरील ट्यूटोरियल विशेषतः मनोरंजक आहे की एक्सचेंज, जे तुम्हाला प्रत्येक नवीन कनेक्शनसह नवीन की व्युत्पन्न करण्यास अनुमती देते.

ऍप्लिकेशन प्रोटोकॉल: निष्कर्ष

हे आमच्या ऍप्लिकेशन प्रोटोकॉलला समाप्त करते. माझा विश्वास आहे की कॉम्प्रेशन पूर्णपणे पर्यायी आहे आणि ते वापरण्याचा निर्णय केवळ गेम आणि आवश्यक बँडविड्थवर अवलंबून आहे. माझ्या मते, एन्क्रिप्शन अनिवार्य आहे, परंतु पहिल्या प्रोटोटाइपमध्ये आपण त्याशिवाय करू शकता.

अर्ज तर्क

आम्‍ही आता क्‍लायंटमध्‍ये स्‍थिती अपडेट करण्‍यास सक्षम आहोत, परंतु लेटन्सी समस्‍या येऊ शकतात. खेळाडूने, इनपुट पूर्ण केल्यानंतर, त्याचा जगावर काय परिणाम झाला हे पाहण्यासाठी सर्व्हरवरून गेम स्थिती अपडेट होण्याची प्रतीक्षा करावी लागेल.

शिवाय, दोन राज्य अद्यतनांमध्ये, जग पूर्णपणे स्थिर आहे. जर राज्य अद्ययावत दर कमी असेल, तर हालचालींना खूप धक्का बसेल.

या समस्येचा प्रभाव कमी करण्यासाठी अनेक तंत्रे आहेत आणि मी त्यांना पुढील भागात कव्हर करेन.

लेटन्सी स्मूथिंग तंत्र

या विभागात वर्णन केलेल्या सर्व तंत्रांची मालिकेत तपशीलवार चर्चा केली आहे वेगवान मल्टीप्लेअर गॅब्रिएल गॅम्बेटा. मी लेखांची ही उत्कृष्ट मालिका वाचण्याची शिफारस करतो. यात परस्परसंवादी डेमो देखील समाविष्ट आहे जो तुम्हाला ही तंत्रे सरावात कशी कार्य करतात हे पाहू देतो.

सर्व्हरकडून प्रतिसादाची वाट न पाहता थेट इनपुट परिणाम लागू करणे हे पहिले तंत्र आहे. असे म्हणतात क्लायंट-साइड अंदाज. तथापि, जेव्हा क्लायंटला सर्व्हरकडून अपडेट प्राप्त होते, तेव्हा त्याने त्याची भविष्यवाणी बरोबर असल्याचे सत्यापित करणे आवश्यक आहे. जर असे नसेल, तर त्याला सर्व्हरकडून मिळालेल्या माहितीनुसार त्याची स्थिती बदलणे आवश्यक आहे, कारण सर्व्हर हुकूमशाही आहे. हे तंत्र प्रथमच भूकंपात वापरले गेले. आपण लेखात याबद्दल अधिक वाचू शकता क्वेक इंजिन कोड पुनरावलोकन फॅबियन सांगलर्स [हस्तांतरण Habré वर].

तंत्रांचा दुसरा संच दोन राज्य अद्यतनांमधील इतर घटकांच्या हालचाली सुलभ करण्यासाठी वापरला जातो. या समस्येचे निराकरण करण्याचे दोन मार्ग आहेत: इंटरपोलेशन आणि एक्सट्रापोलेशन. इंटरपोलेशनच्या बाबतीत, शेवटच्या दोन अवस्था घेतल्या जातात आणि एकापासून दुसर्‍या स्थितीत संक्रमण दाखवले जाते. त्याचा तोटा असा आहे की यामुळे थोडासा विलंब होतो कारण क्लायंट नेहमी भूतकाळात काय घडले ते पाहतो. एक्स्ट्रापोलेशन म्हणजे क्लायंटला मिळालेल्या शेवटच्या स्थितीवर आधारित संस्था आता कुठे असावीत याचा अंदाज लावणे. त्याचा गैरसोय असा आहे की जर घटकाने हालचालीची दिशा पूर्णपणे बदलली तर अंदाज आणि वास्तविक स्थिती दरम्यान मोठी त्रुटी असेल.

फक्त FPS मध्ये उपयुक्त नवीनतम, सर्वात प्रगत तंत्र आहे अंतर भरपाई. लॅग कॉम्पेन्सेशन वापरताना, सर्व्हर क्लायंटच्या लक्ष्यावर शूट करताना होणारा विलंब विचारात घेतो. उदाहरणार्थ, जर एखाद्या खेळाडूने त्यांच्या स्क्रीनवर हेडशॉट केले, परंतु प्रत्यक्षात त्यांचे लक्ष्य विलंबामुळे वेगळ्या ठिकाणी होते, तर विलंबामुळे खेळाडूला मारण्याचा अधिकार नाकारणे अयोग्य ठरेल. त्यामुळे, प्लेअरने त्यांच्या स्क्रीनवर जे दिसले त्याचे अनुकरण करण्यासाठी आणि त्यांचा शॉट आणि लक्ष्य यांच्यातील टक्कर तपासण्यासाठी सर्व्हर प्लेअरने गोळीबार केला त्या क्षणी परत फिरवतो.

ग्लेन फिडलर (नेहमीप्रमाणे!) 2004 मध्ये एक लेख लिहिला नेटवर्क भौतिकशास्त्र (2004), ज्यामध्ये त्याने सर्व्हर आणि क्लायंट दरम्यान भौतिकशास्त्र सिम्युलेशन सिंक्रोनाइझ करण्यासाठी पाया घातला. 2014 मध्ये त्यांनी लेखांची एक नवीन मालिका लिहिली नेटवर्किंग भौतिकशास्त्र, ज्याने भौतिकशास्त्र सिम्युलेशन सिंक्रोनाइझ करण्यासाठी इतर तंत्रांचे वर्णन केले आहे.

वाल्व विकीवर दोन लेख देखील आहेत, स्त्रोत मल्टीप्लेअर नेटवर्किंग и क्लायंट/सर्व्हर इन-गेम प्रोटोकॉल डिझाइन आणि ऑप्टिमायझेशनमध्ये विलंब भरपाई करण्याच्या पद्धती जे विलंबासाठी भरपाई मानतात.

फसवणूक रोखणे

फसवणूक रोखण्यासाठी दोन मुख्य तंत्रे आहेत.

प्रथम: फसवणूक करणाऱ्यांना दुर्भावनायुक्त पॅकेट पाठवणे अधिक कठीण बनवणे. वर नमूद केल्याप्रमाणे, याची अंमलबजावणी करण्याचा एक चांगला मार्ग म्हणजे एन्क्रिप्शन.

दुसरा: हुकूमशाही सर्व्हरला फक्त आज्ञा/इनपुट/क्रिया प्राप्त झाल्या पाहिजेत. क्लायंट इनपुट पाठवण्याव्यतिरिक्त सर्व्हरवर स्थिती बदलण्यास सक्षम नसावे. त्यानंतर, प्रत्येक वेळी सर्व्हरला इनपुट प्राप्त झाल्यावर, ते वापरण्यापूर्वी ते वैध आहे की नाही हे तपासणे आवश्यक आहे.

अर्ज तर्क: निष्कर्ष

मी शिफारस करतो की तुम्ही उच्च विलंब आणि कमी रीफ्रेश दरांचे अनुकरण करण्याचा एक मार्ग अंमलात आणा जेणेकरून क्लायंट आणि सर्व्हर एकाच संगणकावर चालत असताना देखील तुम्ही खराब परिस्थितीत तुमच्या गेमच्या वर्तनाची चाचणी घेऊ शकता. हे विलंब स्मूथिंग तंत्रांची अंमलबजावणी मोठ्या प्रमाणात सुलभ करेल.

इतर उपयुक्त संसाधने

तुम्हाला नेटवर्क मॉडेल्सवर इतर संसाधने एक्सप्लोर करायची असल्यास, तुम्ही ती येथे शोधू शकता:

• ग्लेन फिडलरचा ब्लॉग - त्याचा संपूर्ण ब्लॉग वाचण्यासारखा आहे, तेथे बरेच छान लेख आहेत. तो आहे नेटवर्क तंत्रज्ञानावरील सर्व लेख एकत्रित केले आहेत.
• अप्रतिम गेम नेटवर्किंग M. Fatih MAR द्वारे ऑनलाइन व्हिडिओ गेम इंजिनवरील लेख आणि व्हिडिओंची सर्वसमावेशक यादी आहे.
• В r/gamedev subreddit चे विकी अनेक उपयुक्त दुवे देखील आहेत.

स्त्रोत: www.habr.com