किसी एकल-खिलाड़ी इंजन को अमान्य डेटा को कैसे अस्वीकार करना चाहिए?

Question

एक एकल-खिलाड़ी गेम में, जब बाहरी स्क्रिप्ट में निर्दिष्ट घटकों में से एक इकाई बनाने की कोशिश की जाती है, तो आपको क्या लगता है कि किसी एक घटक के बीमार होने पर क्या करना है?

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

ध्यान दें, मैं त्रुटियों को लॉग करने के बारे में बात नहीं कर रहा हूं - जो कि बिना कहे आना चाहिए - बस इकाई के बारे में क्या होना चाहिए।

Comments

क्या हम एकल-खिलाड़ी या बहु-खिलाड़ी के बारे में बात कर रहे हैं?

— ओ ० '।

@ लोरिस एकल खिलाड़ी।

— पॉल मंटा

जैसा कि अधिकांश उत्तर पहले ही बता चुके हैं कि आपके दर्शक कौन हैं? क्या आप एक मामूली खेल बना रहे हैं या आप आंतरिक विकास के उद्देश्यों के बारे में बात कर रहे हैं?

— टेट्राद सेप

@ टेट्राड मैं चाहूंगा कि खेल यथासंभव अनुकूल हो।

— पॉल मंटा

Answer 1

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

Comments

मुझे लगता है कि यह एक महान डाइकोटॉमी है, उपयोगकर्ता त्रुटियों और डेवलपर त्रुटियों के बीच अंतर करता है। यह ठीक उसी कारण से समझ में आता है कि कंपाइलर त्रुटियां आम तौर पर ठीक करने में आसान होती हैं, लेकिन रनटाइम / सिमेंटिक एरर्स शैतान हैं।

— झॉकिंग

यदि इंजन में खेल शुरू होने के बाद संस्थाओं को संशोधित करने का एक तरीका शामिल है, तो आपको कम से कम अपने आप को असफल होने से पहले त्रुटि को ठीक करने का मौका देना चाहिए।

— ब्लेकी

Answer 2

उपयोगकर्ता और डेवलपर के बीच का अंतर खेल के विकास में हमेशा स्पष्ट नहीं होता है। मानक प्रोग्रामिंग तकनीक जैसे "फेल फास्ट" हमेशा लाभप्रद नहीं होती हैं, खासकर टीम आकार बढ़ने के रूप में।

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

इसलिए आपका डेमो 2PM द्वारा तैयार नहीं है और आपके निवेशक आश्चर्यचकित हैं कि आप गेम में एक भी दुश्मन क्यों नहीं ला सकते हैं और आपकी परियोजना बंद हो जाती है।

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

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

Comments

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

— जॉन मैकडोनाल्ड

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

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

@ जोए रेचन: यह समझ में आता है। इसलिए मुझे लगता है कि एक ऐसा बिंदु होना चाहिए जिस पर तेजी से असफल होना अब एक संपत्ति नहीं है। या तो उन लोगों के प्रकार में जो इसका उपयोग करते हैं, या एक निश्चित आकार की परियोजनाओं पर। मुझे लगता है कि टीम में लोगों के लिए यह तय करना है कि उनके लिए क्या काम करता है।

— जॉन मैकडॉनल्ड्स

मुझे यकीन नहीं है कि तेज कठिन असफलता, जो वास्तव में सवाल है, क्या कभी संपत्ति है। यहां तक ​​कि एक व्यक्ति "टीम" पर भी, शायद मैं shader कोड से निपटना नहीं चाहता क्योंकि मुझे वास्तव में इस स्तर पर काम करना है। निश्चित रूप से अच्छा त्रुटि हैंडलिंग लिख सकते हैं और सभी त्रुटियों को लॉग इन करें, लेकिन मैं लगभग हमेशा क्या महत्वपूर्ण है की एक बेहतर विचार है अब सही से मैंने किया था जब मैं छह माह पहले त्रुटि कोड लिखा था अभी।

Answer 3

उपयोगकर्ता को उस इकाई का पूर्वावलोकन करने में सक्षम होना चाहिए जिसे वह आयात करने जा रहा है, और अग्रिम में पता करें कि क्या त्रुटियां हैं।

आपको किसी तरह तय करना चाहिए कि कौन सी त्रुटियां घातक होनी चाहिए, जिससे इसे खेल में जोड़ा जा सके और जिसे चेतावनी के रूप में खारिज किया जा सके ।

बेशक अगर किसी भी कारण से आयातित इकाई किसी तरह से अपरिवर्तनीय रूप से savegame डेटा को बदलने में सक्षम हो सकती है, तो आपको इसके लिए निर्दोष होने की आवश्यकता होगी।

Answer 4

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

void setValue(int value) {
    if (value < MIN_VALUE) {
       log(value + " is too low, using " + MIN_VALUE);
       value = MIN_VALUE;
    }
    if (value > MAX_VALUE) {
       log(value + " is too high, using " + MAX_VALUE);
       value = MAX_VALUE;
    }
}

यहां तक ​​कि एक मल्टी-प्लेयर गेम में यह स्वीकार्य है जब तक आप यह नहीं मान रहे हैं कि एक खिलाड़ी सिस्टम को धोखा देने की कोशिश कर रहा है।

सॉफ्टवेयर जारी करने के बाद, आप इस लॉग को डिफ़ॉल्ट रूप से बंद करना चाहते हैं, यह मानकर कि खिलाड़ी इन लॉग को पढ़ने नहीं जा रहे हैं।

Comments

लॉग को कोई प्रदर्शन समस्या नहीं मानकर, आपको रिलीज़ बिल्ड में लॉगिंग चालू रखनी चाहिए और रिपोर्ट को वापस विकास टीम को भेजना चाहिए। (उचित रूप से सूचित करने वाले खिलाड़ी, निश्चित रूप से।)

आपको रिलीज़ के लिए अधिक संक्षिप्त लॉग रिकॉर्ड करने में सक्षम होना चाहिए। विकास में आप अधिक क्रियाशील हो सकते हैं।

— पीटर लॉरी