गेम्स को फ्री-टेक्स्ट इनपुट में निजी विवरणों को कैसे संभालना चाहिए

यह तय करने से शुरुआत करें कि सुविधा को क्या चाहिए

एक फ्री-टेक्स्ट बॉक्स गेम की आवश्यकता से अधिक जानकारी को आमंत्रित कर सकता है। कोई खिलाड़ी पेस्ट्री चुनने से जुड़े एक दृश्य का अनुरोध करते समय टाइप कर सकता है, “मैं आमतौर पर बस से घर जाता हूँ और बेकरी पर रुकता हूँ।” उस दृश्य को पेस्ट्री या सेटिंग के विकल्प की आवश्यकता हो सकती है; इसे खिलाड़ी के सामान्य मार्ग को सुरक्षित रखने की आवश्यकता नहीं है। पूरे संदेश को उपयोगी गेम डेटा के रूप में मानने से व्यक्तिगत विवरणों का सुविधा की आवश्यकता से अधिक दूर तक पहुंचना आसान हो जाता है।

इनपुट फ़्लो बनाने से पहले, सरल भाषा में इसका उद्देश्य लिखें: उदाहरण के लिए, “इस दृश्य को वैयक्तिकृत करने के लिए खिलाड़ी द्वारा चुनी गई सेटिंग का उपयोग करें।” फिर जानकारी के उस सबसे छोटे हिस्से की पहचान करें जो उस उद्देश्य को पूरा कर सके। यह डेटा न्यूनीकरण (data minimisation) का एक उत्पाद-डिज़ाइन अनुप्रयोग है: यूके सूचना आयुक्त कार्यालय (ICO) डिफ़ॉल्ट डेटा उपयोग को प्रत्येक विशिष्ट उद्देश्य के लिए आवश्यक सीमा तक सीमित बताता है, और डिज़ाइन से लेकर उत्पाद जीवनचक्र तक गोपनीयता पर विचार करने की अनुशंसा करता है (ICO: Data protection by design and by default)।

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

खिलाड़ी के टेक्स्ट को काल्पनिक स्मृति से बाहर रखें

खिलाड़ी द्वारा दर्ज किए गए टेक्स्ट को काल्पनिक दुनिया को परिभाषित करने वाले तथ्यों से अलग करें। किसी गेम को स्थायी कहानी स्थिति की आवश्यकता हो सकती है जैसे कि “पात्र ने बेकरी का दौरा किया” या “अगला दृश्य बाज़ार में है।” वे तथ्य कहानी से संबंधित हैं। खिलाड़ी की वास्तविक दिनचर्या के बारे में एक वाक्य केवल इसलिए काल्पनिक चरित्र की स्मृति नहीं बन जाता क्योंकि वह किसी प्रॉम्प्ट में दिखाई दिया था।

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

यह अलगाव प्राइवेसी-बाय-डिज़ाइन सिद्धांतों से प्राप्त एक वास्तुशिल्प अनुशंसा है, न कि किसी विशिष्ट प्लेटफ़ॉर्म का विवरण। NIST प्राइवेसी फ्रेमवर्क एक स्वैच्छिक उपकरण है जिसे संगठन अपने प्रसंस्करण संदर्भ के अनुसार अनुकूलित कर सकते हैं; इसका मार्गदर्शन डेटा प्रोसेसिंग पारिस्थितिकी तंत्र और लोगों की गोपनीयता आवश्यकताओं के आधार पर प्रासंगिक परिणामों को चुनने पर जोर देता है (NIST: Getting Started with the Privacy Framework)। किसी गेम टीम के लिए, उपयोगी कदम यह मैप करना है कि टेक्स्ट कहाँ प्रवाहित होता है और प्रत्येक गंतव्य को एक स्पष्ट उद्देश्य देना है।

साझाकरण को एक अलग, दृश्यमान विकल्प बनाएं

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

यह महत्वपूर्ण है क्योंकि सामान्य उत्पाद संचालन में गेम टेक्स्ट सीमाओं को पार कर सकता है। उदाहरण के लिए, Ubisoft का गोपनीयता नोटिस सामाजिक सुविधाओं के संबंध में चैट रिकॉर्ड और उपयोगकर्ता-जनित सामग्री को संसाधित करने का वर्णन करता है, और कहता है कि कुछ उपयोगकर्ता नाम और टेक्स्ट लीडरबोर्ड या स्ट्रीमिंग संदर्भों में दिखाई दे सकते हैं (Ubisoft: Privacy Policy)। वह नीति Ubisoft की सेवाओं के बारे में प्रमाण है, गेम्स का सार्वभौमिक विवरण नहीं। यह दिखाता है कि डिज़ाइनरों को यह क्यों पहचानना चाहिए कि कौन सी सुविधा टेक्स्ट प्राप्त करती है और दर्शकों के किसी भी परिवर्तन को स्पष्ट करना चाहिए।

प्रत्येक साझाकरण मार्ग के लिए, उस समय दर्शकों को दिखाएं: इस दृश्य के लिए निजी, चयनित मित्रों के लिए दृश्यमान, या सार्वजनिक। नियंत्रण को उस क्रिया के पास रखें जो दृश्यता को बदलती है। एकमुश्त प्रकाशन विकल्प को समझाने के लिए किसी व्यापक सेटिंग पृष्ठ पर निर्भर रहने से बचें।

बताएं कि इनपुट का क्या होता है

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

कारण व्यावहारिक है: गेम का अपना भंडारण प्रसंस्करण पथ में केवल एक संभावित कदम है। उदाहरण के लिए, OpenAI का API दस्तावेज़ दुरुपयोग-निगरानी लॉग को एप्लिकेशन स्थिति से अलग करता है और एंडपॉइंट व सुविधा के अनुसार प्रतिधारण अंतर का वर्णन करता है। इसके बताए गए नियंत्रण और सीमाएं उस API पर लागू होती हैं, न कि प्रत्येक प्रदाता या गेम पर (OpenAI: Data controls in the OpenAI platform)। एक गेम टीम को जो भी प्रदाता वह उपयोग करती है उसकी वास्तविक सेटिंग्स और शर्तों की जांच करनी चाहिए, फिर परिणामी व्यवहार को सटीक रूप से समझाना चाहिए।

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

खिलाड़ियों को एक निष्कासन नियंत्रण दें जो सहेजी गई प्रतियों तक पहुंचे

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

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

एक साधारण काल्पनिक उदाहरण के साथ हटाने के प्रवाह का परीक्षण करें: बेकरी सेटिंग्स के लिए एक प्राथमिकता सहेजें, पुष्टि करें कि यह बाद के दृश्य को प्रभावित कर सकती है, इसे हटा दें, फिर पुष्टि करें कि यह अब सहेजी गई प्राथमिकताओं के दृश्य में या बाद के दृश्य के लिए प्रदान किए गए संदर्भ में दिखाई नहीं देती है। यह एक प्रस्तावित उत्पाद परीक्षण है, कोई रिपोर्ट किया गया परिणाम नहीं। यदि विलोपन अतुल्यकालिक (asynchronous) है, तो इसकी स्थिति दिखाएं और किसी अधूरे अनुरोध को समाप्त के रूप में प्रस्तुत करने से बचें।

टेक्स्ट सुविधा शिप करने से पहले एक संक्षिप्त समीक्षा का उपयोग करें

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

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

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