स्पष्ट नियमों, मेमोरी और खिलाड़ी के विकल्पों के साथ एआई बॉट गेम कैसे डिज़ाइन करें

एक ऐसे कोर लूप से शुरुआत करें जिसे आप एआई के बिना खेल सकें

लूप को एक वाक्य में लिखें: स्थिति दिखाएं → क्रिया स्वीकार करें → नियमों की जांच करें → स्थिति अपडेट करें → परिणाम और अगले विकल्प दिखाएं। प्रत्येक बारी (turn) को उस लूप को पूरा करना चाहिए या समझाना चाहिए कि वह आगे क्यों नहीं बढ़ सकती।

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

*फेस्टिवल पार्सल* नामक एक छोटे गेम पर विचार करें। खिलाड़ी के पास पार्सल डिलीवर करने के लिए पांच समय इकाइयां हैं। वे एक सीधा रास्ता या एक बगीचे का रास्ता चुन सकते हैं और जाने से पहले वैकल्पिक रूप से एक सजावटी रिबन एकत्र कर सकते हैं। एक बॉट उत्सव के कूरियर की भूमिका निभाता है जो रास्तों के बारे में बताता है और डिलीवरी पर टिप्पणी करता है।

प्रस्तावित नियम जानबूझकर संक्षिप्त रखे गए हैं:

पहले विकल्प से पहले ये नियम दिखाएं। बताएं कि डिलीवरी क्रियाएं सत्र को समाप्त करती हैं, इसलिए खिलाड़ियों को पहले से ही रिबन एकत्र करना होगा। एक डिलीवरी जो अंतिम समय इकाई खर्च करती है वह भी सफल होती है क्योंकि सफलता की जांच पहले होती है।

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

स्पष्ट स्थिति (explicit state) को परिणामों का प्राधिकार बनाएं

स्थिति (state) को इस बात का गेम रिकॉर्ड मानें कि क्या सत्य है। बातचीत का टेक्स्ट उस रिकॉर्ड की व्याख्या कर सकता है, लेकिन उसे चुपचाप इसे बदलना नहीं चाहिए।

रॉबर्ट न्यस्ट्रॉम का *Game Programming Patterns* (https://gameprogrammingpatterns.com/state.html) में स्टेट अध्याय, स्टेट्स, इनपुट्स और अनुमत बदलावों (transitions) के माध्यम से परिमित अवस्था मशीनों (finite state machines) का वर्णन करता है। यह यह भी प्रदर्शित करता है कि कैसे ढीले ढंग से संयुक्त बूलियन फ़्लैग अमान्य संयोजन उत्पन्न कर सकते हैं। उस सिद्धांत को अपने गेम के जीवनचक्र पर लागू करें: परिभाषित बदलावों के साथ एक सत्र स्थिति (session status) का उपयोग करें, जैसे सक्रिय, डिलीवर किया गया, या छूटा हुआ।

डिलीवरी प्रोटोटाइप के लिए, एक छोटा स्थिति विनिर्देश पर्याप्त है:

दूसरा मान संग्रहीत करने के बजाय, जो इसका खंडन कर सकता है, चुने गए मार्ग से गार्डन पोस्टकार्ड प्राप्त करें। इसी तरह, स्थिति और नियमों से वर्तमान में उपलब्ध क्रियाओं की गणना करें।

एक निश्चित प्रसंस्करण क्रम का उपयोग करें: अनुरोध की व्याख्या करें, उसकी क्रिया और मापदंडों को मान्य करें, परिणाम की गणना करें, स्थिति परिवर्तन को प्रतिबद्ध (commit) करें, फिर इसका वर्णन करें। सूत्रधार को प्रतिबद्ध परिणाम और अनुमत अगली क्रियाएं दें। उसे दूसरी गणना का आविष्कार नहीं करना चाहिए।

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

आप किसी मौजूदा कथा उपकरण (narrative tool) के साथ इन स्थितियों का प्रोटोटाइप बना सकते हैं। इंकल का आधिकारिक इंटरैक्टिव-फिक्शन ट्यूटोरियल (https://www.inklestudios.com/ink/web-tutorial/) सशर्त विकल्पों, पहले देखी गई सामग्री को ट्रैक करने, वेरिएबल्स और स्पष्ट अंत की व्याख्या करता है। वे विशेषताएं एआई वर्णन जोड़ने से पहले रचित गेम का परीक्षण करने के लिए एक उपयोगी आधार प्रदान करती हैं।

खिलाड़ियों को ऐसे विकल्प दें जिन्हें वे समझ सकें और प्रभावित कर सकें

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

*फेस्टिवल पार्सल* में, मार्ग का निर्णय खिलाड़ियों की विभिन्न प्राथमिकताओं का समर्थन करता है:

ये बताए गए नियमों से की गई उदाहरणात्मक गणनाएं हैं। वे एक सरल निर्णय सहायता प्रदान करते हैं: पहले समाप्त करने के लिए सीधी डिलीवरी चुनें, सजावट के लिए रिबन एकत्र करें, या पोस्टकार्ड के लिए बगीचे का रास्ता चुनें। शेष समय यहाँ केवल अंत का एक विवरण है; यह गुप्त रूप से अंक प्रदान नहीं करता है।

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

दृश्यमान क्रियाओं के साथ-साथ मुक्त टेक्स्ट (free text) का समर्थन करें। “आइए दर्शनीय मार्ग लें” बगीचे की डिलीवरी से मैप हो सकता है। “इसे विशेष बनाएं” अस्पष्ट है: इसका अर्थ रिबन एकत्र करना, बगीचे का रास्ता लेना, या दोनों हो सकता है। समय खर्च किए बिना एक संक्षिप्त स्पष्टीकरण मांगें।

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

असमर्थित अनुरोधों को सूचनात्मक रखें। यदि खिलाड़ी उड़ने के लिए कहता है, तो समझाएं कि उपलब्ध मार्ग सीधे और बगीचे के हैं, उनकी लागतों के साथ। मुक्त टेक्स्ट अभिव्यक्ति का विस्तार कर सकता है जबकि क्रिया प्रणाली क्षमताओं का एक पूर्वानुमेय सेट बनाए रखती है।

परिभाषित करें कि बॉट क्या याद रखता है और वह क्या जान सकता है

मेमोरी को तीन स्तरों में विभाजित करें, प्रत्येक का एक अलग उद्देश्य हो।

आधिकारिक सत्र स्थिति (authoritative session state) संसाधनों, प्रगति, चयनित मार्गों और अंत को संग्रहीत करती है। यह सहेजने (save) और पुनः लोड करने (reload) पर भी बनी रहती है और केवल मान्य क्रियाओं के माध्यम से बदलती है।

एक सत्र इवेंट लॉग प्रतिबद्ध क्रियाओं और उनके परिणामों को रिकॉर्ड करता है। एक प्रविष्टि कह सकती है कि क्रिया 2 ने रिबन एकत्र किया और समय को पांच से घटाकर चार कर दिया। यह डिबगिंग और सटीक रीकैप का समर्थन करता है। क्रिया पहचानकर्ता (action identifiers) बनाए रखें ताकि एक दोहराया गया अनुरोध एक ही इवेंट को दो बार लागू न कर सके।

कथा संदर्भ (narrative context) में हालिया संवाद और एक संक्षिप्त रीकैप शामिल होता है जिसका उपयोग टोन और निरंतरता बनाए रखने के लिए किया जाता है। वास्तविक गेम स्थिति को हटाए बिना इसे छोटा किया जा सकता है।

प्रभावी संदर्भ इंजीनियरिंग के लिए एंथ्रोपिक का गाइड (https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) बातचीत के इतिहास को सारांशित करने और संदर्भ विंडो के बाहर स्थायी नोट्स रखने दोनों पर चर्चा करता है। यह यह भी चेतावनी देता है कि अत्यधिक सारांशीकरण से महत्वपूर्ण विवरण खो सकते हैं। यहाँ डिज़ाइन का निहितार्थ यह है कि सटीक यांत्रिक तथ्यों को संरचित भंडारण में रखा जाए और संवादी निरंतरता के लिए सारांश का उपयोग किया जाए।

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

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

एक ठोस क्रम के साथ मेमोरी का परीक्षण करें: रिबन एकत्र करें, सहेजें, पुनः लोड करें, स्थिति के लिए पूछें, और बगीचे की डिलीवरी का चयन करें। रिबन एकत्र ही रहना चाहिए, डिलीवरी से पहले चार समय इकाइयां शेष रहनी चाहिए, और अंतिम समय शून्य होना चाहिए।

गेम की विफलता और सिस्टम की विफलता के लिए अलग-अलग प्रतिक्रियाएं डिज़ाइन करें

एक छूटा हुआ उद्देश्य खेल का हिस्सा है। एक असफल जनरेशन अनुरोध कार्यान्वयन की समस्या है। उन्हें अलग-अलग परिणाम दें।

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

कार्यान्वयन विफलताओं के लिए, विस्तृत वर्णन जोड़ने से पहले पुनर्प्राप्ति व्यवहार को परिभाषित करें:

न पढ़े जा सकने वाले सेव को चुपचाप नए गेम से न बदलें। इससे खोई हुई प्रगति छिप जाती है और अगली प्रतिक्रिया भ्रामक हो जाती है।

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

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

पहले नियमों का, फिर बॉट की व्याख्या का प्लेटेस्ट करें

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

प्रतिनिधि खिलाड़ियों को बिना कोचिंग के डिलीवरी पूरी करने के लिए आमंत्रित करें। उनसे पूछें कि चुनने से पहले वे क्या उम्मीद करते हैं और उनका क्या मानना है कि बाद में क्या बदला। नील्सन नॉर्मन ग्रुप की थिंकिंग-अलाउड प्रयोज्यता परीक्षण गाइड (https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/) प्रतिभागियों को बोलने देने के साथ-साथ प्रतिनिधि प्रतिभागियों और कार्यों की सिफारिश करती है; यह यह भी चेतावनी देती है कि सूत्रधार के संकेत व्यवहार को प्रभावित कर सकते हैं।

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

संक्षिप्त प्लेटेस्ट चेकलिस्ट। दुनिया का विस्तार करने से पहले नियमों और स्थिति से निपटने में विफलताओं को ठीक करें। यदि खिलाड़ी विकल्पों को समझते हैं लेकिन उन्हें दिलचस्प नहीं पाते हैं, तो ट्रेडऑफ़ बदलें। यदि वे निर्णयों का आनंद लेते हैं लेकिन लागतों का अनुमान नहीं लगा सकते हैं, तो प्रस्तुति में सुधार करें। जब इसके मौजूदा विकल्प अलग-अलग शब्दों, सहेजे गए सत्रों और विफलता पथों में समझने योग्य बने रहें, तो प्रोटोटाइप का विस्तार करें।

इस विषय को आगे पढ़ें