कॉम्पैक्ट गेम इंटरफ़ेस में पेट कंट्रोल्स और कैरेक्टर को कैसे दृश्यमान रखें

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

कंट्रोल्स को व्यवस्थित करने से पहले कैरेक्टर के लिए एक निश्चित विज़ुअल क्षेत्र निर्धारित करें। इसके सिल्हूट और भाव-भंगिमा के आवश्यक हिस्सों को स्पष्ट रखें, और उनके ऊपर बटन या लेबल लगाने से बचें। यदि किसी कार्रवाई के लिए सीधे पेट को छूने की आवश्यकता है, तो उस इंटरैक्शन क्षेत्र को बाधा रहित छोड़ दें; यदि कंट्रोल्स गेम सीन के ऊपर स्थित हैं, तो सुनिश्चित करें कि वे कैरेक्टर के उस हिस्से को न ढकें जिसे खिलाड़ियों को देखना आवश्यक है। Apple के गेम-कंट्रोल संबंधी दिशानिर्देश वर्चुअल कंट्रोल्स को कम करने की सलाह देते हैं, जहाँ गेम ऑब्जेक्ट्स के साथ सीधा इंटरैक्शन उसकी जगह काम कर सकता है (Game controls)।

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

दृश्यमान आइकन को वास्तविक टच टार्गेट को छोटा किए बिना कॉम्पैक्ट बनाएं। Apple अपने प्लेटफ़ॉर्म पर अक्सर उपयोग किए जाने वाले कंट्रोल्स के लिए न्यूनतम 44 गुणा 44 पॉइंट्स और कम महत्वपूर्ण कंट्रोल्स के लिए 28 गुणा 28 पॉइंट्स की अनुशंसा करता है। Android इंटरैक्टिव टच टार्गेट्स के लिए कम से कम 48 गुणा 48 डेंसिटी-इंडिपेंडेंट पिक्सल की अनुशंसा करता है। ये प्लेटफ़ॉर्म-विशिष्ट माप हैं, इसलिए संख्याओं को एक-दूसरे के समान मानने के बजाय प्रासंगिक प्लेटफ़ॉर्म की इकाइयों और दिशानिर्देशों का उपयोग करें (Apple game controls, Android accessibility guidance)। अनपेक्षित टैप से बचने के लिए पर्याप्त दूरी छोड़ें, विशेष रूप से तब जब दो कार्रवाइयों के परिणाम भिन्न हों।

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

सीन के हल्के और गहरे दोनों हिस्सों पर टेक्स्ट और आइकन की जांच करें। एक बैकग्राउंड पर काम करने वाला कंट्रास्ट पेट के हिलने या सीन बदलने पर गायब हो सकता है। टेक्स्ट के लिए, W3C का WCAG मार्गदर्शन सामान्य आकार के टेक्स्ट के लिए 4.5:1 और बड़े टेक्स्ट के लिए 3:1 का कंट्रास्ट अनुपात निर्धारित करता है। WCAG गेम-विशिष्ट नियम के बजाय वेब-कंटेंट मार्गदर्शन है, लेकिन इसकी कंट्रास्ट सीमाएँ परिवर्तनीय बैकग्राउंड पर इंटरफ़ेस टेक्स्ट के लिए एक उपयोगी जांच के रूप में काम कर सकती हैं (W3C contrast guidance)। किसी अनुपलब्ध कार्रवाई को दर्शाने के लिए केवल रंग पर निर्भर न रहें; इसके लेबल, आकार या स्थिति को भी स्पष्ट रूप से बदलें।

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

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

केवल स्क्रीन के बाहरी आयत के अनुसार नहीं, बल्कि उपयोग योग्य क्षेत्र के अनुसार डिज़ाइन करें। नॉच, कैमरा कटआउट, सिस्टम बार और जेस्चर क्षेत्र किनारे के पास स्थित महत्वपूर्ण कंट्रोल्स के साथ ओवरलैप हो सकते हैं। Apple का लेआउट मार्गदर्शन सेफ़ एरिया को ऐसे क्षेत्रों के रूप में वर्णित करता है जो सामग्री को इंटरफ़ेस तत्वों और डिवाइस सुविधाओं से दूर रखने में मदद करते हैं। Android भी सिस्टम-बार, जेस्चर और डिस्प्ले-कटआउट इनसेट का सम्मान करने की अनुशंसा करता है, जिसमें महत्वपूर्ण कंट्रोल्स को कटआउट से दूर रखा जाता है (Apple layout guidance, Android edge-to-edge guidance)। बैकग्राउंड आर्टवर्क किनारे तक विस्तृत हो सकता है जबकि इंटरैक्टिव तत्व इनसेट में ही बने रहते हैं।

यह मानकर न चलें कि एक ही कॉम्पैक्ट व्यवस्था हर आस्पेक्ट रेशियो में फिट हो जाएगी। कंट्रोल्स को उपयोग योग्य क्षेत्र पर एंकर करें और उपलब्ध चौड़ाई बदलने पर स्पेसिंग या समूहीकरण को अनुकूलित होने दें। Unity के लिए Android का गेम मार्गदर्शन सेफ़-एरिया API का उपयोग करने और विभिन्न डिस्प्ले आकारों और आस्पेक्ट रेशियो का समर्थन करने की अनुशंसा करता है। पोर्ट्रेट या लैंडस्केप लेआउट का परीक्षण केवल तभी करें जब गेम उनका समर्थन करता हो, और रोटेशन, विंडो का आकार बदलने, या डिवाइस को मोड़ने (फोल्ड करने) के बाद पुन: जांच करें यदि वे कॉन्फ़िगरेशन दायरे में हैं (Android guidance for Unity games on large screens)।

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

प्रत्येक समर्थित लेआउट के लिए एक संक्षिप्त पास/फ़ेल चेकलिस्ट का उपयोग करें:

• मुख्य कार्रवाई के दौरान पेट दृश्यमान रहता है, जिसमें उसका चेहरा या अन्य आवश्यक विवरण शामिल हैं।

• प्राथमिक कार्रवाई तक पहुँचना आसान है, इसकी एक स्पष्ट प्रेस्ड स्थिति है, और यह किसी अन्य टार्गेट को ओवरलैप नहीं करती है।

• बदलते सीन बैकग्राउंड के सामने लेबल और महत्वपूर्ण स्थिति संकेत सुपाठ्य बने रहते हैं।

• कोई भी आवश्यक कंट्रोल किसी कटआउट, सिस्टम बार या जेस्चर क्षेत्र के नीचे स्थित नहीं है।

• द्वितीयक कंट्रोल को खोलने से कैरेक्टर का वह हिस्सा या खेल क्षेत्र नहीं छिपता जिसकी अगले चरण के लिए आवश्यकता है।

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

• Apple Developer, Game controls

• Apple Developer, Layout

• Android Developers, Make apps more accessible

• Android Developers, Edge-to-edge design

• Android Developers, Make your Unity game great on all form factors

• W3C Web Accessibility Initiative, Understanding Success Criterion 1.4.3: Contrast (Minimum)