किसी मिस्ट्री गेम में किसी लापता पात्र के AI सहायक को वास्तव में क्या पता हो सकता है?
एक काल्पनिक मिस्ट्री गेम के लिए, एक AI सहायक को केवल वही कहानी रिकॉर्ड पता होने चाहिए जो लेखक ने उसे उपलब्ध कराए हैं—और केवल कहानी के उसी बिंदु से जब वे रिकॉर्ड सुलभ होते हैं। प्रत्येक तथ्य को एक स्रोत, उसके ज्ञात होने का समय और एक एक्सेस नियम दें। इससे सहायक चुपचाप एक सर्वज्ञ सूत्रधार बने बिना खिलाड़ियों को सुराग जोड़ने में मदद कर सकता है।
कहानी के रिकॉर्ड को सहायक की पहुँच से अलग रखें
कहानी के लेखक-उन्मुख संपूर्ण रिकॉर्ड से शुरुआत करें: घटनाएँ, पात्रों के बयान, वस्तुएँ, संदेश और खेल में उनके प्रवेश का क्रम। फिर सहायक के लिए एक छोटा दृश्य परिभाषित करें। कोई तथ्य कहानी की बाइबिल में मौजूद हो सकता है, भले ही वह सहायक के लिए अभी उपलब्ध न हो। यह अंतर एक निष्पक्ष रहस्य का आधार है: लेखक जान सकता है कि क्या हुआ था, जबकि सहायक केवल उन्हीं रिकॉर्ड्स का उपयोग कर सकता है जिन्हें देखने की अनुमति उसकी काल्पनिक भूमिका देती है।
ट्विन (Twine) जैसे इंटरएक्टिव-फिक्शन टूल कहानियों को अनुच्छेदों में व्यवस्थित करते हैं और खिलाड़ी को क्या दिखता है, इसे बदलने के लिए चरों (variables) और सशर्त तर्क (conditional logic) का उपयोग कर सकते हैं। यह एक उपयोगी डिज़ाइन सादृश्य प्रदान करता है: प्रत्येक लिखित रिकॉर्ड को एक अलग इकाई मानें, और इस तक पहुँच को प्रासंगिक अनुच्छेद, घटना या विकल्प पर सशर्त बनाएं। ट्विन की बुनियादी अवधारणाएँ
उदाहरण के लिए, मान लें कि मारा नाम का एक काल्पनिक पात्र एक सामुदायिक उद्यान प्रदर्शनी की तैयारी कर रहा है। हो सकता है कि सहायक के पास उसके द्वारा साझा किए गए एक योजना नोट, समूह बोर्ड पर पोस्ट किए गए एक शेड्यूल, और चित्रित संकेतों (signs) को घर के अंदर ले जाने के बारे में उसके द्वारा बाद में भेजे गए एक संदेश तक पहुँच हो। इसे केवल यह जानने से कि मारा को बागवानी पसंद है, यह अनुमान नहीं लगाना चाहिए कि वह कहाँ है, और इसे एक ऐसा निजी ड्राफ्ट नहीं देखना चाहिए जिसे इसके साथ कभी साझा ही नहीं किया गया था। वे सीमाएँ कहानी के लिखित एक्सेस नियमों से आती हैं, न कि इस दावे से कि वास्तविक AI प्रणालियाँ क्या एक्सेस कर सकती हैं।
प्रत्येक तथ्य को एक स्रोत और ज्ञात होने का समय दें
एक उपयोगी तथ्य रिकॉर्ड कम से कम चार सवालों के जवाब देता है: क्या दावा किया जा रहा है, इसे किसने या किस चीज़ ने प्रदान किया, यह सहायक के लिए कब उपलब्ध हुआ, और क्या यह प्रत्यक्ष है या अनुमानित। W3C प्रूवेनेन्स (उत्पत्ति) मॉडल संस्थाओं, गतिविधियों और एजेंटों के संदर्भ में सूचना की उत्पत्ति का वर्णन करता है; यह रिकॉर्ड्स को यह वर्णन करने की भी अनुमति देता है कि एक वस्तु दूसरे से कैसे प्राप्त हुई थी। काल्पनिक रिकॉर्ड्स के लिए यह एक व्यावहारिक ढांचा है, भले ही कोई गेम औपचारिक मॉडल के बजाय सरल लेबलों का उपयोग करता हो। W3C PROV मॉडल प्राइमर
एक संक्षिप्त रिकॉर्ड ऐसा दिख सकता है:
दावा: मारा ने उद्यान के संकेतों को रंगने की योजना बनाई थी; स्रोत: साझा योजना नोट; सहायक को ज्ञात: सोमवार, 10:00 से; प्रकार: प्रत्यक्ष बयान
दावा: संकेतों को घर के अंदर ले जाया गया; स्रोत: समूह-बोर्ड अपडेट; सहायक को ज्ञात: मंगलवार, 16:30 से; प्रकार: प्रत्यक्ष अपडेट
दावा: मारा ने उन्हें शायद इसलिए हटाया क्योंकि बारिश का पूर्वानुमान था; स्रोत: मौसम नोट और अपडेट; सहायक को ज्ञात: मंगलवार, 16:30 से; प्रकार: अनुमान; अपुष्ट
उदाहरण के समय केवल समझाने के लिए हैं। महत्वपूर्ण अंतर इस बात में है कि कोई घटना कब घटी और सहायक को इसके बारे में कब पता चला। यदि सोमवार को बनाया गया नोट मंगलवार को साझा किया जाता है, तो सहायक का ज्ञान मंगलवार से शुरू होता है जब तक कि कहानी स्पष्ट रूप से उसे पहले की पहुँच न दे। अलग होने पर दोनों टाइमस्टैम्प सुरक्षित रखें।
अवलोकन, रिपोर्ट और अनुमान को अलग रखें
एक स्रोत स्वचालित रूप से अपनी सामग्री को निश्चित नहीं बनाता है। कोई पात्र वर्णन कर सकता है कि उसने क्या देखा; एक नोट अधूरा हो सकता है; एक समय-सारणी वास्तव में हुई किसी कार्रवाई के बजाय किसी योजना को दर्ज कर सकती है। रिकॉर्ड के प्रकार को लेबल करने से सहायक को अपनी प्रतिक्रिया सटीक रूप से तैयार करने में मदद मिलती है: "बोर्ड कहता है कि संकेतों को स्थानांतरित कर दिया गया था" यह "मारा ने संकेतों को स्थानांतरित कर दिया" से अलग है, और दोनों "उसने संभवतः मौसम के कारण उन्हें स्थानांतरित किया" से भिन्न हैं।
लगातार एक छोटी शब्दावली का उपयोग करें: प्रत्यक्ष अवलोकन, पात्र की रिपोर्ट, लिखित रिकॉर्ड और अनुमान। एक अनुमान को अपने समर्थक रिकॉर्ड्स की ओर वापस इंगित करना चाहिए और एक अनुमान के रूप में चिह्नित रहना चाहिए। W3C PROV गतिविधियों के लिए एजेंटों की ज़िम्मेदारी और एक इकाई से दूसरी इकाई की व्युत्पत्ति को स्पष्ट रूप से मॉडल करता है; संवाद पर उस अंतर को लागू करने से गेम को यह दिखाने में मदद मिलती है कि कोई निष्कर्ष कहाँ से आया, बजाय इसके कि उसे एक ताज़ा तथ्य के रूप में प्रस्तुत किया जाए। W3C PROV-O
यह एक उपयोगी लेखन परीक्षण भी तैयार करता है: क्या कोई खिलाड़ी सहायक के किसी आश्वस्त बयान को उस रिकॉर्ड तक ट्रैक कर सकता है जिसे एक्सेस करने की उसे अनुमति थी? यदि नहीं, तो उत्तर को संशोधित करें, छूटा हुआ लिखित रिकॉर्ड जोड़ें, या सहायक से कहें कि उसके पास पर्याप्त जानकारी नहीं है।
पहुँच को केवल पात्र द्वारा नहीं, बल्कि कहानी के समय में परिभाषित करें
प्रत्येक रिकॉर्ड के लिए, उस घटना को निर्दिष्ट करें जो सहायक की पहुँच को अनलॉक करती है। एक साझा संदेश भेजे जाते ही उपलब्ध हो सकता है; किसी बोर्ड पर लगाया गया नोटिस तब उपलब्ध हो सकता है जब सहायक बोर्ड की जाँच करता है; कोई बातचीत केवल तभी उपलब्ध हो सकती है जब खिलाड़ी इसके बारे में पूछना चुनता है। "सहायक संग्रह (आर्काइव) में सब कुछ जानता है" जैसे अस्पष्ट लेबलों पर निर्भर रहने से बचें, जब तक कि कहानी यह स्थापित न करे कि उस संग्रह में क्या है और इसे कब अपडेट किया जाता है।
एक व्यावहारिक एक्सेस नियम के तीन भाग होते हैं: रिकॉर्ड के दर्शक, इसकी उपलब्धता का ट्रिगर, और कोई देरी। उदाहरण के लिए: "खिलाड़ी द्वारा बोर्ड खोलने के बाद सहायक समूह-बोर्ड पोस्ट पढ़ सकता है; यह व्यक्तिगत ड्राफ्ट नहीं पढ़ सकता है।" शाखाओं वाली कहानियों में देरी मायने रखती है। यदि किसी खिलाड़ी ने बोर्ड नहीं देखा है, तो सहायक को ऐसा व्यवहार नहीं करना चाहिए जैसे उसने नवीनतम पोस्ट देख ली हो, केवल इसलिए कि वह पोस्ट लेखक की फाइलों में कहीं और मौजूद है।
ट्विन में, स्टोरी वेरिएबल्स अनुच्छेदों में उपलब्ध हो सकते हैं, जबकि अस्थायी वेरिएबल्स हारलोव और शुगरक्यूब में वर्तमान अनुच्छेद तक सीमित होते हैं। यह अंतर दर्शाता है कि लेखकों को जानबूझकर यह तय क्यों करना चाहिए कि कोई तथ्य पूरी कहानी में बना रहता है या केवल किसी विशेष दृश्य से संबंधित है। सटीक कार्यान्वयन कहानी के प्रारूप पर निर्भर करता है, इसलिए नियम को कोड निर्देशों के बजाय एक डिज़ाइन मॉडल के रूप में मानें। ट्विन कुकबुक: वेरिएबल्स
अनिश्चितता को खिलाड़ी के लिए उपयोगी बनाएं
जब कोई रिकॉर्ड गायब, पुराना या अस्पष्ट हो, तो सहायक को ठोस शब्दों में उस कमी का वर्णन करने दें। यह कह सकता है कि उसके पास सोमवार की योजना है लेकिन बाद की कोई पुष्टि नहीं है, या यह कि एक पात्र ने संकेतों को स्थानांतरित करने की सूचना दी है जबकि बोर्ड में कोई अपडेट नहीं है। यह खिलाड़ी को एक सार्थक अगला कदम देता है: किसी अन्य लिखित स्रोत की जाँच करें, किसी पात्र के साथ बातचीत पर दोबारा गौर करें, या यह तय करें कि सुराग अभी भी अनसुलझा है।
यह दृष्टिकोण बिना किसी मनमाने सर्वज्ञता के रहस्य का समर्थन करता है। इंटरएक्टिव कथा पर शोध ने जांच की है कि सीमित ज्ञान खिलाड़ी के व्यवहार को कैसे आकार दे सकता है, जिसमें प्लेयर मॉडल का पता लगाने के लिए इंटरएक्टिव फिक्शन *एंकरहेड* का उपयोग करने वाला एक अध्ययन भी शामिल है। एक लिखित सहायक के लिए, डिज़ाइन का निहितार्थ सामान्य है: खिलाड़ी और सहायक ने जो सीखा है वह उनके अगले विकल्पों को प्रभावित कर सकता है, इसलिए उन ज्ञान स्थितियों को स्पष्ट रूप से ट्रैक करें। रिवेरा-विल्लिकना और अन्य, "इंटरएक्टिव कथा के लिए एक BDI प्लेयर मॉडल को सूचित करना"
सहायक संवाद लिखने से पहले एक त्वरित समीक्षा
प्रतिक्रिया का मसौदा तैयार करने से पहले, प्रत्येक परिणामी दावे के लिए इन बिंदुओं की जाँच करें:
क्या दावा किसी लिखित रिकॉर्ड में मौजूद है, या इसे एक अनुमान के रूप में लेबल किया गया है?
क्या रिकॉर्ड अपने स्रोत का नाम बताता है और किसी योजना, रिपोर्ट, अवलोकन या बाद की पुष्टि के बीच अंतर करता है?
कहानी के किस समय पर सहायक को इस तक पहुँच प्राप्त हुई?
क्या सहायक की काल्पनिक भूमिका उस स्रोत तक पहुँचने की अनुमति देती है?
यदि रिकॉर्ड अधूरा या परस्पर विरोधी है, तो क्या संवाद उस अनिश्चितता को बनाए रखता है?
यदि इनमें से किसी का भी उत्तर अस्पष्ट है, तो सहायक के बयान को तब तक सीमित करें जब तक कि वह उपलब्ध रिकॉर्ड से मेल न खाए। परिणामी पात्र अभी भी मददगार हो सकता है: यह जो कुछ उसने देखा है उसका सारांश दे सकता है, यह पहचान सकता है कि क्या अपुष्ट है, और खिलाड़ी को अगले लिखित सुराग की ओर इंगित कर सकता है। इसकी विश्वसनीयता कहानी के पूर्ण रिकॉर्ड और वास्तव में प्राप्त जानकारी के बीच एक दृश्यमान सीमा से आती है।
