रीप्ले सिस्टम: रिकॉर्ड इनपुट या ईवेंट?


9

मैंने इसे पढ़ा: रिप्ले सिस्टम को कैसे डिज़ाइन किया जाए लेकिन यह वास्तव में मेरे सवाल का जवाब नहीं देता है।

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

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

सवाल यह है: इस मामले में, एक रिप्ले सिस्टम को सेटअप करने के लिए, क्या मुझे इनपुट, या उपयोगकर्ता कार्रवाई अनुरोधों (जैसा कि वहां सुझाया गया है) या घटनाओं का उपयोग करना चाहिए?

यह मुझे लगता है कि दोनों बिल्कुल एक ही आउटपुट देंगे। केवल अंतर जो मैं देख सकता हूं वे हैं:

  • ईवेंट वास्तविक आउटपुट देता है जबकि ईवेंट अनुरोधों को ईवेंट देने के लिए संसाधित करना पड़ता है।
  • कार्य अनुरोध रिकॉर्ड करने के लिए बहुत कम डेटा हो सकते हैं।

क्या अन्य बातों पर विचार करना चाहिए?

जवाबों:


5

एक निर्धारण प्रणाली को देखते हुए वे तार्किक रूप से समतुल्य हैं ताकि आपका सारांश बहुत अधिक सही हो। हालाँकि, 2 और चीजें हैं जो मुझे आउटपुट घटनाओं के बजाय इनपुट क्रियाओं को रिकॉर्ड करने की दिशा में ले जाएंगी:

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

अच्छे अंक, विशेष रूप से पहले वाले। मैं इस उपयोग के बारे में भूल गया लेकिन यह काफी मददगार है।
21

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

1

या तो काम करता है, हालांकि विचार करने के लिए कुछ चीजें हैं।

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

आपको खेल के व्यवहार के लिए भी ट्वीक करने की आवश्यकता है। यदि आप इनपुट रिकॉर्ड करते हैं और फिर इनपुट संभाला जाता है, तो भौतिकी कैसे सुलझती है, आदि के किसी भी हिस्से को आपकी रिकॉर्डिंग अमान्य हो जाती है। यहां तक ​​कि अगर आप खेल की घटनाओं को रिकॉर्ड करते हैं, भले ही उन घटनाओं के किसी भी हिस्से में व्याख्यात्मक परिवर्तन कैसे हो, तो आप फंस गए हैं।

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


प्रश्न में मैं निर्दिष्ट करता हूं कि गेम मॉडल पूरी तरह से निर्धारक है। कोई भौतिकी नहीं है और फ्रेम दर भिन्नता केवल ग्राहक पक्ष पर दिखाई देती है, खेल मॉडल में नहीं जो "टिक" पर पूरी तरह से निर्भर है।
खुल्लम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.