शूटर कैसे गोली मारता है

[ नेटवर्क निशानेबाजों में टकराव की गणना के लिए सिद्धांतों पर अर्मिन रोनाचेर का लेख। यह तकनीकी प्रकृति की तुलना में एक सर्वेक्षण और शोध से अधिक है। इसके बाद वर्ग कोष्ठक में अनुवादक के नोट ]

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

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

थोड़ा सा संदर्भ

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

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

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

धिक्कार है भौतिकी।

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

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

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

तो सब कुछ है कि खेल वास्तव में सिर्फ चाल है कि खिलाड़ियों का मानना ​​है कि वहाँ कोई अंतराल है। अधिकांश खेलों के लिए, आपको 150 एमएस की देरी का भी ध्यान नहीं रहेगा (यह गेम में बिताए गए समय की तुलना में कुछ भी नहीं है)। शायद आपको महसूस होगा कि बढ़ती प्रतिक्रिया समय के साथ प्रदर्शन कैसे घटता है, लेकिन यदि आप कुछ अनुभव रखते हैं, तो आप केवल इस प्रदर्शन ड्रॉप को नेटवर्क विलंबता से जोड़ सकते हैं।

मूल बातें

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

यदि सर्वर गेम की स्थिति को प्रति सेकंड केवल 20 बार बताता है, तो सबसे आसान समाधान क्लाइंट को उसी 20 हर्ट्ज से बांधना होगा। ठीक है, अगर आपको अचानक किसी तरह एफपीएस बढ़ाने की आवश्यकता होती है, तो वे आमतौर पर प्रक्षेप का सहारा लेते हैं।

मान लीजिए कि सर्वर 20 हर्ट्ज पर चलता है और प्रत्येक रीकाउंट के लिए एक पैकेट क्लाइंट को भेजा जाता है। और क्लाइंट को प्रत्येक आने वाले पैकेज के लिए तीन फ्रेम प्रस्तुत करना होगा। प्रक्षेप के साथ पूरी बात यह है कि यह केवल मौजूदा डेटा पर काम कर सकता है। तो मान लें कि एक ग्राहक के पास 60 हर्ट्ज़ हैं, तो हमें लगभग 16 मिलीसेकेंड प्रति फ्रेम मिलता है, और अगर क्लाइंट सर्वर रिकॉल्यूशन के बीच की स्थिति को नियंत्रित करता है, तो प्रत्येक पैकेट के साथ हमारे पास 48 एमएस होगा जो पहले से ही प्रक्षेप के लिए समय बीत चुका है।

[जैसा कि मैं इसे समझता हूं, इसका मतलब है कि पोस्ट-प्रोसेसिंग प्रक्षेप के दौरान होता है। एक पैकेट आता है और, इसके आधार पर, तीन फ्रेम जो पहले से ही पारित हो चुके हैं, वास्तव में निर्मित होते हैं, अर्थात्। दिए गए उदाहरण में हमेशा उन 48 एमएस में एक अंतराल होगा।]

एक सैद्धांतिक विकल्प वर्तमान (ज्ञात) बिंदु से भविष्य के लिए एक्सट्रपलेशन है, लेकिन यह पारंपरिक लीनियर इंटरपोलेशन की तुलना में त्रुटियों के लिए बहुत अधिक और बहुत अधिक कठिन है।

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

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

टाइम मशीन।

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

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

क्या मैंने मारा?

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

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

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

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

असली गोलियां।

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

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

तकनीक और विनाशकारी।

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

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

प्रोटोकॉल को बढ़ाएं।

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

मेरे कंप्यूटर पर, 64 खिलाड़ियों के साथ सर्वर पर खेलते समय, खेल दोनों दिशाओं में लगभग 16kb / s स्थानांतरित करता है। और यह काफी एक सा है।

हेलो की रागडोल चाल

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

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

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

युद्धक्षेत्र 3 में टकराव का पता लगाना

इसलिए बैटलफील्ड 3 में असली गोलियां हैं और इन गोलियों ने प्रतिक्रिया समय की सही भरपाई की है। यदि आप अपने आप को किसी चीज में मिलते हुए देखते हैं, तो आप वास्तव में उसमें प्रवेश करते हैं और भी दिलचस्प बात यह है कि हिट पिक्सेल परफेक्ट के बहुत करीब है। यह सुनिश्चित करना कठिन है, क्योंकि पहले शॉट में भी 100% सटीकता नहीं है। लेकिन यह बहुत करीब लगता है।

बात यह है कि बैटलफील्ड 3 में टक्कर का पता लगाने की जिम्मेदारी क्लाइंट की है, सर्वर की नहीं। UT99 के लिए ZeroPing मॉड में लगभग पसंद है। बैटलफील्ड 3 में सभी बंदूकों द्वारा उत्पन्न कठिनाइयों को देखते हुए, यह सब समझ में आता है। क्लाइंट-साइड टकराव का पता लगाने के फायदे स्पष्ट हैं: सस्ते, 100% सटीक, कुछ भी नहीं के लिए स्वचालित विलंब मुआवजा। हालांकि, ये फायदे एक बड़े नुकसान के साथ आते हैं। इस तरह की टोह को आसानी से मूर्ख बनाया जाता है।

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

आप यह कैसे सुनिश्चित कर सकते हैं कि टक्कर वास्तविक थी? आप खिलाड़ी से एक शंकु विचलन बना सकते हैं। चूंकि आपके पास गुरुत्वाकर्षण है, एक शंकु एक आदर्श समाधान नहीं है, लेकिन यह काफी करीब है।

[जाहिर तौर पर लेखक के दिमाग में था - और यह देखने के लिए जांचें कि क्या लक्ष्य इस शंकु में आता है]

हम अपना नेटवर्क गेम लिखते हैं

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

यह सब है जो मैं देखने में कामयाब रहा। और मुझे यकीन है कि इस विषय पर बहुत अधिक साहित्य है, लेकिन मैं अभी तक कुछ भी सुझा नहीं सकता हूं।

[ अनुवाद अनुमति के साथ प्रकाशित। पाए गए टाइपो, विराम चिह्नों और अनुवाद की खामियां, कृपया पीएम को भेजें ]