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