टेक्स्ट गेम विफलता स्थितियाँ: किसी झटके (सेटबैक) को इनपुट या डिलीवरी की समस्या से कैसे अलग पहचानें
चैट शैली के टेक्स्ट गेम में, किसी असफल टर्न का मतलब हमेशा यह नहीं होता कि खिलाड़ी ने गलत विकल्प चुना था। हो सकता है कि दृश्य एक वैध काल्पनिक झटके तक पहुँच गया हो, गेम शब्दों का समर्थन न करता हो, पात्र के पास कार्य करने के लिए आवश्यक जानकारी की कमी हो, या संदेश पहुँचने में ही विफल रहा हो। इन स्थितियों के लिए अलग-अलग फीडबैक और पुनः प्रयास (रीट्राई) के अलग प्रभावों की आवश्यकता होती है। सबसे पहले कारण को वर्गीकृत करें, फिर खिलाड़ी को बताएं कि क्या बदला है और आगे क्या हो सकता है।
शुरुआत यह पूछकर करें कि क्या विफल हुआ
एक व्यावहारिक पहला सवाल यह है: क्या गेम ने लक्षित क्रिया को समझा और कल्पना में उसका समाधान किया? यदि हाँ, तो परिणाम एक झटका (सेटबैक) हो सकता है। यदि नहीं, तो यह निर्धारित करें कि समस्या इनपुट की है, पात्र की जानकारी की है, या सिस्टम द्वारा डिलीवरी की है। यह चार-भागों वाला अंतर एक डिज़ाइन सहायता है जिसे इस बात से समझा गया है कि इंटरैक्टिव फिक्शन सिस्टम पार्सिंग, विश्व नियमों, कहानी के प्रवाह और अनडू व्यवहार को कैसे अलग करते हैं; यह कोई सार्वभौमिक तकनीकी मानक नहीं है। उदाहरण के लिए, इन्फॉर्म का दस्तावेज़ीकरण पार्सर और सिम्युलेटेड विश्व मॉडल को गेम के अलग-अलग हिस्सों के रूप में वर्णित करता है, और इसका पार्सर कई अलग-अलग कारणों की रिपोर्ट कर सकता है कि कोई कमांड मेल क्यों नहीं खाया। (इन्फॉर्म 6 डिज़ाइनर्स मैनुअल: परिचय, इन्फॉर्म 6 डिज़ाइनर्स मैनुअल §33: पार्सर को मुश्किल से बाहर निकालने में मदद करना)
संदेश को गेम के प्रतिक्रिया अनुबंध के हिस्से के रूप में मानें। इसे तीन बातों का उत्तर देना चाहिए: क्या हुआ, क्या काल्पनिक स्थिति बदली, और खिलाड़ी अब क्या कर सकता है। एक छोटी सी पंक्ति जैसे “कागज़ की नाव उस पार के किनारे तक पहुँचने से पहले ही पलट जाती है। मुड़ा हुआ नोट अभी भी आपके हाथ में है। आप एक चौड़े चैनल पर प्रयास कर सकते हैं या पार जाने का कोई दूसरा रास्ता चुन सकते हैं” झटके, बची हुई वस्तु और अगले कदम को स्पष्ट बनाती है।
1. एक वैध काल्पनिक झटका (सेटबैक)
एक झटका तब उपयुक्त होता है जब गेम ने क्रिया को समझ लिया हो, वर्तमान दृश्य के विरुद्ध उसकी जाँच की हो, और जानबूझकर इन-वर्ल्ड परिणाम उत्पन्न किया हो। हो सकता है कि खिलाड़ी एक साथ बहुत सारी लाइब्रेरी की किताबें ले जाने की कोशिश करता है और एक किताब पास की कुर्सी पर फिसल जाती है। हो सकता है कि कागज़ की नाव उथली धारा के दूसरी तरफ पहुँचने से पहले पानी भर जाने से डूबने लगे। यह परिणाम बातचीत को खिलाड़ी के मूल्यांकन में बदले बिना असुविधाजनक या आश्चर्यजनक हो सकता है।
इसकी परिभाषित करने वाली विशेषता स्थिति में परिवर्तन (स्टेट चेंज) है। यदि दृश्य कहता है कि नाव डूब गई, तो वह परिणाम कहानी में सच होना चाहिए। यदि खिलाड़ी इसे वापस पा सकता है, तो बताएं कि कैसे; यदि नाव चली गई है, तो यह संकेत न दें कि उसी टेक्स्ट को दोबारा लिखने से वह घटना उलट जाएगी। पुनः प्रयास करने का मतलब दूसरी नाव बनाना, दूसरा मार्ग चुनना या बदले हुए दृश्य से आगे बढ़ना हो सकता है। सटीक विकल्प गेम के नियमों पर निर्भर करता है।
एक उपयोगी झटके का संदेश प्रयास की गई क्रिया, परिणाम और उपलब्ध आगे के रास्ते का नाम देता है। इसे केवल इसलिए किसी समर्थित क्रिया को इनपुट त्रुटि के रूप में नहीं दिखाना चाहिए क्योंकि परिणाम प्रतिकूल था। इसके विपरीत, यदि गेम ने वास्तव में कहानी की स्थिति को नहीं बदला है, तो यह संकेत न दें कि कोई परिणाम हुआ है। यह अंतर खिलाड़ी को यह समझने देता है कि क्या वे किसी नई स्थिति से आगे बढ़ रहे हैं या किसी अप्रसंस्कृत (अनप्रोसेस्ड) कमांड को ठीक कर रहे हैं।
2. असमर्थित इनपुट: गेम शब्दों का समाधान नहीं कर सका
असमर्थित इनपुट का अर्थ है कि सिस्टम खिलाड़ी के संदेश को अपने समर्थित किसी कार्य के साथ मैप नहीं कर सकता है। हो सकता है कि खिलाड़ी किसी ऐसे दृश्य में “बेकर से खुबानी के बारे में पूछें” टाइप करे जहाँ गेम केवल बटन विकल्पों के एक छोटे सेट को स्वीकार करता है, या किसी ऐसे नाम का उपयोग करे जिसे पार्सर नहीं पहचानता है। यह इंटरफ़ेस के कवरेज के बारे में बताता है, खिलाड़ी के विचार की गुणवत्ता के बारे में नहीं।
इंटरैक्टिव फिक्शन पार्सर बताते हैं कि उपयोगी फीडबैक विशिष्ट क्यों होना चाहिए: इन्फॉर्म एक गैर-मान्यता प्राप्त क्रिया, एक अस्पष्ट संदर्भ, बहुत कम इनपुट, और एक ऐसी वस्तु जिसे देखा नहीं जा सकता, के लिए अलग-अलग त्रुटियों को सूचीबद्ध करता है। इसका मैनुअल यह भी दिखाता है कि कोई गेम एक सामान्य पार्सर त्रुटि को अधिक जानकारीपूर्ण संदेश से कैसे बदल सकता है। (इन्फॉर्म 7 §18.35: एक पार्सर त्रुटि प्रिंट करना) चैट गेम में, एक संक्षिप्त प्रतिक्रिया हो सकती है: “मैं यहाँ ‘खुबानी के बारे में पूछें’ का समाधान नहीं कर सकता। आप डिलीवरी के बारे में पूछ सकते हैं या काउंटर से कोई विषय चुन सकते हैं।”
सुधार का एक मार्ग प्रस्तुत करें। इंटरफ़ेस के आधार पर, इसका मतलब पहचाने गए विकल्पों को दिखाना, एक केंद्रित स्पष्टीकरण पूछना, या खिलाड़ी को दोबारा शब्द बदलने के लिए आमंत्रित करना हो सकता है। किसी असमर्थित कमांड को काल्पनिक विफलता के रूप में वर्णित न करें: यदि कोई कार्रवाई नहीं हुई, तो उसे स्पष्ट रूप से बताएं। पिछले दृश्य को बरकरार रखें, और स्पष्ट करें कि एक सही इनपुट भेजने से किसी कहानी की घटना को रिवाइंड करने के बजाय उसी क्षण का पुनः प्रयास होगा।
3. अनुपलब्ध पात्र ज्ञान: एक वैध प्रश्न जिसका अभी कोई उत्तर नहीं है
कभी-कभी इनपुट समझने योग्य होता है, लेकिन पात्र उस पर कार्य करने के लिए पर्याप्त नहीं जानता है। एक खिलाड़ी दुकानदार के सहायक से पूछ सकता है कि पार्सल कहाँ डिलीवर किया गया था, इससे पहले कि सहायक ने रसीद देखी हो। गेम निश्चित उत्तर को सही ढंग से रोकते हुए प्रश्न को पहचान सकता है।
यह असमर्थित इनपुट से भिन्न है: विषय या क्रिया वैध है, और सीमा कल्पना में पात्र की जानकारी की है। उस सीमा को स्पष्ट रूप से चिह्नित करें। उदाहरण के लिए: “मीना ने डिलीवरी स्लिप नहीं देखी है, इसलिए वह सड़क का नाम नहीं बता सकती। पार्सल का लेबल अभी भी काउंटर पर है।” यदि खिलाड़ी लेबल का निरीक्षण कर सकता है, किसी अन्य से पूछ सकता है, या बाद में वापस आ सकता है, तो उस मार्ग का नाम बताएं। यदि नहीं, तो कोई संकेत गढ़ने या प्रश्न को विकृत मानने के बजाय यह बताएं कि वास्तव में क्या ज्ञात है।
तय करें कि क्या यह प्रतिक्रिया समय को आगे बढ़ाती है या स्थिति को बदलती है। यदि प्रश्न पूछना एक सामान्य इन-वर्ल्ड क्रिया है, तो गेम उस बातचीत को रिकॉर्ड कर सकता है या बदल सकता है कि कोई पात्र बाद में कैसे प्रतिक्रिया देता है। यदि गेम ज्ञान संबंधी प्रश्नों को निःशुल्क (बिना टर्न/रिसोर्स खर्च किए) रखना चाहता है, तो दृश्य को सुरक्षित रखें और दूसरा प्रश्न पूछने दें। खिलाड़ी को यह अनुमान नहीं लगाना चाहिए कि क्या जानकारी के अनुरोध ने चुपचाप किसी अवसर को खर्च कर दिया।
4. तकनीकी डिलीवरी विफलता: हो सकता है कि कार्रवाई कहानी तक कभी पहुँची ही न हो
डिलीवरी विफलता कल्पना से बाहर होती है: प्रतिक्रिया का टाइम आउट होना, दो बार दिखाई देना, या वाक्य के बीच में ही रुक जाना। जब तक गेम को यह पता न हो कि कार्रवाई संसाधित हो चुकी है, वह सुरक्षित रूप से यह दावा नहीं कर सकता कि पात्र ने कार्रवाई की या कहानी आगे बढ़ी। यह “कूरियर को पता नहीं मिल सका” जैसे इन-वर्ल्ड संदेश से अलग है, जो कि एक काल्पनिक परिणाम है।
सरल स्थिति वाले शब्दों का उपयोग करें और ज्ञात स्थिति की रिपोर्ट करें। यदि गेम यह सत्यापित कर सकता है कि टर्न को संसाधित नहीं किया गया था, तो ऐसा कहें और खिलाड़ी को इसे फिर से भेजने दें। यदि यह निर्धारित नहीं कर सकता कि टर्न संसाधित हुआ था या नहीं, तो अंधे दोबारा प्रयास (ब्लाइंड रिपीट) के लिए आमंत्रित करने से बचें जो क्रिया को दो बार निष्पादित कर सकता है। अनिश्चितता को संक्षेप में समझाएं और वर्तमान दृश्य की जाँच करने या अंतिम पुष्ट बिंदु से फिर से शुरू करने का एक तरीका प्रदान करें। ये डिजाइन सिफारिशें कहानी के परिणाम से असफल इनपुट मिलान को अलग करने की आवश्यकता से निकाली गई हैं; उद्धृत फिक्शन सिस्टम चैट डिलीवरी विफलताओं के लिए एक सार्वभौमिक प्रोटोकॉल को परिभाषित नहीं करते हैं।
जब डिलीवरी ठीक हो जाए, तो अंतिम पुष्ट संदेश को पुनर्स्थापित करें या दृश्य का एक संक्षिप्त रीकैप और पूरी हुई सबसे हालिया ज्ञात कार्रवाई दिखाएं। किसी रीकैप को रीकैप के रूप में लेबल करें, न कि एक नए स्टोरी टर्न के रूप में। यदि खिलाड़ी फिर से भेजना चुनता है, तो स्पष्ट करें कि क्या इसे एक नए प्रयास के रूप में माना जाएगा। पारदर्शिता का वह छोटा सा हिस्सा किसी डुप्लिकेट कार्रवाई को जानबूझकर किए गए दोहराव के रूप में समझे जाने से रोकता है।
रीट्राई (पुनः प्रयास), अनडू (वापस लेना), और रिज्यूम (फिर शुरू करना) के अलग-अलग अर्थ रखें
ये शब्द अलग-अलग स्थिति प्रभावों का वर्णन करते हैं, इसलिए इनका परस्पर उपयोग करने से बचें। रीट्राई (पुनः प्रयास) वर्तमान स्थिति में फिर से एक कार्रवाई सबमिट करता है; इसे किसी स्थापित परिणाम को चुपचाप मिटाना नहीं चाहिए। एक अनडू पिछली स्थिति को पुनर्स्थापित करता है। रिज्यूम रुकावट के बाद अंतिम पुष्ट स्थिति से जारी रहता है। रीस्टार्ट कहानी को नए सिरे से शुरू करता है।
ट्विन का हार्लो मैनुअल अनडू को पिछले गद्यांश (पैसेज) पर लौटने और वर्तमान गद्यांश में किए गए चर परिवर्तनों (वेरिएबल चेंजेस) को भूल जाने के रूप में प्रलेखित करता है; यह रीस्टार्ट को कहानी को फिर से शुरू करने के लिए पृष्ठ को पुनः लोड करने के रूप में वर्णित करता है। यह यह भी नोट करता है कि अनडू का इतिहास सीमित हो सकता है। वे यांत्रिकी दर्शाती हैं कि किसी नियंत्रण को एक अस्पष्ट “फिर प्रयास करें” लेबल पर भरोसा करने के बजाय अपने दायरे को क्यों संप्रेषित करना चाहिए। (हार्लो 3.3.8 मैनुअल: अनडू और रीस्टार्ट)
एक कॉम्पैक्ट निर्णय क्रम इंटरफ़ेस को सुसंगत रखने में मदद करता है:", "क्या गेम ने कार्रवाई को समझा और उसका समाधान किया? यदि हाँ, तो काल्पनिक परिणाम और बची हुई स्थिति की रिपोर्ट करें।", "क्या सिस्टम शब्दों को किसी समर्थित क्रिया के साथ मैप करने में विफल रहा? बताएं कि यह किसका समाधान नहीं कर सका और सुधार का मार्ग दिखाएं; दृश्य को सुरक्षित रखें।", "क्या कार्रवाई को समझा गया था, लेकिन पात्र के पास जानकारी की कमी है? ज्ञान की सीमा और अधिक जानने के किसी भी इन-वर्ल्ड तरीके की व्याख्या करें।", "क्या प्रसंस्करण (प्रोसेसिंग) या डिलीवरी अनिश्चित है? बताएं कि क्या पुष्ट है, फिर जाँच करने या जारी रखने का एक सुरक्षित तरीका पेश करें।", "यदि खिलाड़ी वापस जाना चाहता है, तो नियंत्रण को “अनडू” लेबल करें और बताएं कि यह किस क्षण या परिवर्तन को पुनर्स्थापित करता है। शुरू से आरंभ करने के लिए “रीस्टार्ट” आरक्षित रखें।
प्रत्येक विफलता संदेश के लिए एक संक्षिप्त संगति जाँच
किसी प्रतिक्रिया को भेजने से पहले, कहानी की स्थिति के विरुद्ध उसकी जाँच करें। यदि यह किसी झटके का वर्णन करता है, तो क्या दुनिया वास्तव में बदली? यदि यह असमर्थित इनपुट का वर्णन करता है, तो क्या गेम ने यह दिखावा करने से परहेज किया कि कार्रवाई हुई थी? यदि पात्र में ज्ञान की कमी है, तो क्या प्रतिक्रिया इसे किसी गायब कमांड से अलग करती है? यदि डिलीवरी विफल हो गई, तो क्या खिलाड़ी को पता है कि टर्न संसाधित हुआ था या नहीं? अंत में, क्या रीट्राई या रिज्यूम नियंत्रण वही करता है जो उसका लेबल वादा करता है?", "एक टेक्स्ट गेम तब निष्पक्ष लगता है जब इसका फीडबैक खिलाड़ी को यह अंतर करने में मदद करता है कि पात्र ने क्या अनुभव किया और इंटरफ़ेस क्या नहीं कर सका। स्पष्ट परिणाम कहानी को सुरक्षित रखते हैं; विशिष्ट इनपुट मार्गदर्शन एक और प्रयास संभव बनाता है; ईमानदार ज्ञान सीमाएं कल्पना को सुसंगत रखती हैं; और एक परिभाषित रिकवरी पथ खिलाड़ी को आगे बढ़ने का एक विश्वसनीय तरीका देता है।
