किसी खिलाड़ी के अदृश्य होने पर आंदोलन की सही भविष्यवाणी कैसे करें?

मेरे पास एक मल्टीप्लेयर गेम है और मैं क्लाइंट-साइड की भविष्यवाणी कर रहा हूं, लेकिन कुछ खिलाड़ी पोशन पी सकते हैं और अदृश्य हो सकते हैं ...

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

एक समाधान कुछ साझा करने के लिए होगा ताकि ग्राहक बता सके, लेकिन तब हैकर्स इसका उपयोग यह पता लगाने के लिए कर सकते हैं कि अदृश्य खिलाड़ी कहां हैं, धोखा दे रहे हैं।

Btw मैं पहले से ही नियमित आंदोलन भविष्यवाणी को हल करता हूं, यह पूरी तरह से काम करता है।

multiplayer client-server

— affiszervmention
स्रोत

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

— user1306322

@ user1306322 Cheaters के लिए इसे आसान बनाने से आप ईमानदार खिलाड़ियों को भी पंगु बना सकते हैं। एक फ़्लैगिंग सिस्टम एक अच्छा विचार है, लेकिन अगर अदृश्यता खेल का एक बड़ा हिस्सा है, तो कुछ निवारक उपशम हो सकता है।

— ThatOneGuy 11

@ user1895420 यह आम तौर पर काफी अच्छा है कि इस तरह की चीजें सादे पाठ में न भेजें, ताकि कोई भी औसत खिलाड़ी आसानी से उस डेटा को प्राप्त न कर सके। यदि केवल एक तकनीक-प्रेमी व्यक्ति ही कर सकता है, तो यह किसी भी तरह के रूप में अच्छा निवारक उपाय है।

— user1306322

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

— user1306322

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

— jdm

जवाबों:

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

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

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

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

अदृश्य-अदृश्य टक्कर थोड़ी पेचीदा होती है। यह उन पर सिर्फ टकरावों को अक्षम करने के लिए फायदेमंद हो सकता है क्योंकि कोई भी नहीं देख सकता है कि दो अदृश्य वस्तुएं एक साथ क्लिप कर रही हैं ("अदृश्य" मानकर हमारा मतलब है कि दोनों ऑब्जेक्ट एक ही ग्राहक के लिए दृश्यमान नहीं हैं)। यदि कोई वस्तु दृश्यमान हो जाती है तो वह स्वतः ही दृश्य-अदृश्य टक्कर प्रतिक्रिया (अदृश्य वस्तु को दूर धकेलती है) पर लौट जाती है।

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

— शॉन मिडिल्डिच
स्रोत

खेल टीम किले 2 उस पहले दृष्टिकोण का उपयोग करता है ... यदि एक अदृश्य जासूस किसी अन्य खिलाड़ी को छूता है तो दूसरा खिलाड़ी जासूस को देखने में सक्षम है (या यदि पीछे से, कम से कम कुछ बाधा समझे)।

— Xantix 3

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

— डैनियल रुस्ज़नाइक
स्रोत

अदृश्य खिलाड़ियों के लिए टकराव को नजरअंदाज करने की समस्या यह है कि यदि कोई अदृश्य खिलाड़ी किसी अन्य व्यक्ति से टकरा रहा है तो अदृश्य अधिकार होना बंद हो जाता है। इसके अलावा, यह सही नहीं लगता है। मेरे खेल में मेरे पास वास्तव में रास्ते या पथ-प्रदर्शक नहीं हैं, खिलाड़ी केवल 4 दिशाओं में ही आगे बढ़ सकते हैं, एक समय में एक कदम

— 23

तब जो भी भविष्यवाणी की जाती है उसे भेजने के लिए (या तो एक वेक्टर या वैक्टर की एक श्रृंखला) है और सर्वर-साइड जांच करते हैं। या केवल सुधार को चेतन करें, जैसा कि बोला गया।

— डैनियल रुस्नायक

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

— डैनियल रूसज़िक 1

मैं उस काम को देख सकता हूं। मेरे सबसे छोटे नक्शे में 1500 विभिन्न पद हैं। क्या मुझे हर स्थिति को बदलने के लिए HMAC का उपयोग करना चाहिए ताकि हमलावर को सभी पदों को प्रीकोमप्यूट करने से रोका जा सके?

— एफिस

नहीं, आप जिस किसी भी योजना के साथ आ सकते हैं, वह हैकर्स के खिलाफ "सुरक्षित" नहीं होगी। यदि ग्राहक यह निर्धारित कर सकता है कि खिलाड़ी किसी दिए गए पद से टकराएगा या नहीं, तो कोई आपके गेम को हैक कर सकता है। घूर्णन कुंजी के साथ HMACing क्लाइंट को 1500 HMACs सेकंड में करने से नहीं रोकेगा। करो नहीं क्रिप्टोग्राफी अपने आप को ऐसा करने के लिए प्रयास करते हैं। यदि आप मूल लक्ष्य को प्राप्त करना चाहते हैं, तो केवल ग्राहक को अदृश्य खिलाड़ी की स्थिति भेजें अगर वे खिलाड़ी के 1 या 2 टाइल्स के भीतर हैं। तब आप केवल यह जानने के लिए हैक कर सकते हैं कि क्या कोई व्यक्ति आपके ठीक बगल में है (जो उपयोगी नहीं है क्योंकि आप इसे जांचने के लिए आगे बढ़ सकते हैं)।

जब तक मैं कुछ गलत नहीं कर रहा हूँ, समाधान सरल है। सभी अदृश्य खिलाड़ियों पर ग्राहक की जानकारी न भेजें, केवल वे जो सीमा के भीतर हैं कि वे उस अंतराल के दौरान गति की सीमा के भीतर टकराव के अधीन हो सकते हैं जिसकी भविष्यवाणी की जा रही है। दूसरे शब्दों में, यदि क्लाइंट को भविष्य में केवल 200 एमएस की भविष्यवाणी करनी है, तो केवल अदृश्य खिलाड़ियों के बारे में जानकारी max_player_velocity units/sec * 1/5 secयूनिटों के भीतर भेजें ।

— आर ..
स्रोत

मुझे लगता है कि काम कर सकता है, लेकिन मेरा खेल टाइल-आधारित (कहने के लिए भूल गया) है।

— चक्कर

तो केवल आसन्न टाइलों में अदृश्य खिलाड़ियों को प्रकट करें, या 2 कदम दूर, या जो भी हो।

— आर ..

तब यह सुनिश्चित नहीं होता है कि वे टकराएंगे, और अदृश्य खिलाड़ियों को खोजे नहीं जाने के लिए हैकिंग से दूर रहना होगा

— टकराएंगे करनी होगी