मानविकी के लिए गेमिंग इंटरफेस को संरक्षित करना

सभी को नमस्कार! मैं गेमिंग इंटरफेस में विशेषज्ञता वाला एक यूआई / यूएक्स डिजाइनर हूं। मैं एक मानवतावादी भी हूं: कोड से जुड़ी हर चीज जन्मजात भय और अविश्वास को जन्म देती है, जिसे मैं दूर नहीं कर सकता। एक "ब्लैक मैजिक" से डरने के लिए एक डिजाइनर के लिए सामान्य है। लेकिन एक समस्या है जो जीवन को बहुत जटिल करती है।

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

हमारे इस मानवीय विशेषता को जानने के बाद, अनुकंपा प्रोग्रामर (अन्य अच्छे लोगों के साथ) ने एक डिज़ाइन बनाने और कोड की एक पंक्ति लिखे बिना वास्तविक उपकरणों पर परीक्षण करने के लिए पर्याप्त संख्या में उपकरण बनाए। इन उपकरणों को "इंटरफ़ेस प्रोटोटाइप प्रोग्राम" प्रकार के अनुरोध के द्वारा आसानी से जाना जाता है। ये स्केच, Adobe XD, Figma, Principle, InVision, Marvel, आदि हैं। वे कमाल के हैं। वे लाखों तंत्रिका डिजाइनर कोशिकाओं (और संभवतः कुछ जीवन) को बचाते हैं। उनके बारे में सैकड़ों लेख लिखे गए हैं, वे दुनिया भर में यूआई / यूएक्स डिजाइनरों द्वारा प्रशंसा के पात्र हैं।

हालांकि, ये उपकरण मुख्य रूप से वेब और मोबाइल एप्लिकेशन डेवलपर्स के लिए अनुकूल हैं। खेल देव के लिए (और हम यहाँ विशेष रूप से खेल देव के बारे में हैं) वे खराब रूप से अनुकूल हैं।

"एक मिनट रुको, क्या अंतर है?" आप पूछते हैं। खेल भी आवेदन कर रहे हैं, है ना? वास्तव में नहीं। गेम की बारीकियां उत्पादन प्रक्रिया में महत्वपूर्ण सुधार लाती हैं।

चलो ठीक है।

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

बैंक, मेरी तरह, जितनी जल्दी हो सके उपयोगकर्ता कार्यों को बंद करने में रुचि रखता है। वह विशेष रूप से उन्हें नहीं बनाता है। योजनाबद्ध रूप से, यह कुछ इस तरह दिखता है:



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

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



इस तरह की संरचना पहले से ही प्रोटोटाइप के लिए बहुत अधिक कठिन है। इस गेम फीचर को घात नंबर 1 कहें । और भी हैं।

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

घात नंबर 3 खेलों में बहुत ही गैर-मानक तत्व और / या एनिमेशन हैं। वेबसाइटों पर या कार्यालय अनुप्रयोगों में पाया जा सकता है की तुलना में तत्वों का पैलेट बहुत व्यापक है। प्रत्येक प्रोटोटाइप कार्यक्रम उन्हें बिल्कुल भी नहीं बना सकते हैं।

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

हाँ, वैसे। सीमांत नोट। मैंने केवल फ़्लैश या यूनिटी पर बने खेलों के साथ काम किया। फ्लैश पहले ही मर चुका है, इसलिए यह मुख्य रूप से एकता के बारे में होगा। मेरा मानना ​​है कि अन्य लोकप्रिय गेम इंजनों के संबंध में कहा गया प्लस या माइनस सही है, लेकिन यह सही नहीं है।

काम के ऐसे दोहराव से क्या होता है? जाहिर है, तथ्य यह है कि कम या ज्यादा जटिल इंटरफ़ेस प्रोटोटाइप विकसित करने और समर्थन करने का प्रयास आसमान छू रहा है। इसे अपेक्षाकृत सस्ते डिजाइनर मानव घड़ियों (माफ करना), लेकिन फिर भी दें।

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

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

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

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

तीसरे, पहले से वर्णित कारणों के लिए, सिद्धांत में किए गए ओम के प्रोटोटाइप में कोई गेमप्ले नहीं है और न ही हो सकता है। 3 डी भी ऐसा नहीं है! वे केवल खेल से अलगाव में, सपाट यूआई / यूएक्स के बारे में हैं। मेरी राय में, यह उनके मूल्य को कम करता है। हालांकि ओम का दावा है कि इस तरह के समाधान लगभग 80% खेल शैलियों का अनुकरण करने के लिए उपयुक्त हैं।

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

मेरे अनुभव में, एक विषम चित्र के रूप में स्क्रीन का सबसे सरल गैर-संवादात्मक मानचित्र स्क्रीन के बीच बातचीत और कनेक्शन पर अधिकांश मुद्दों को हल करता है। यह तस्वीर आधे घंटे में एकत्र की जाती है और इसके लिए फ़ोटोशॉप (इलस्ट्रेटर) में तैयार किए गए मॉकअप के अलावा कुछ भी नहीं चाहिए। इसे रोकना सबसे अधिक संभव है।

किन मामलों में एक संवादात्मक और अत्यधिक विस्तृत (ओह्म इस उच्च निष्ठा ) प्रोटोटाइप को आगे बढ़ने के लिए समझ में आता है? Nuuu ... उदाहरण के लिए, यदि आपके ग्राहक को काम स्वीकार करने के लिए सबसे अधिक दृश्य सामग्री की आवश्यकता है, और बीडब्ल्यू योजना की नहीं। ऐसा होता है।

या अगर आपको एक सुंदर डेमो बिल्ड बनाने की आवश्यकता है जो आप निवेशकों को दिखा सकते हैं और फोन पर ड्राइव कर सकते हैं।

या अगर प्रोजेक्ट या उसके अलग-अलग हिस्से का गेमप्ले इतना नया है कि आम तौर पर यह स्पष्ट नहीं है कि इसके साथ बातचीत कैसे करें, और परिकल्पना परीक्षण के निरंतर चक्रों की आवश्यकता होती है।

या यदि आप इंटरफेस में परीक्षण और त्रुटि प्रक्रिया को गति देना चाहते हैं, तो प्रोग्रामर को रास्ते से उतार दें।

या यदि आपको प्रयोज्य परीक्षण के लिए एक नकली उत्पाद की आवश्यकता है।

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

तो फिर, संक्षेप में। मैं खेल इंटरफ़ेस को प्रोटोटाइप करने के तीन मुख्य तरीके देखता हूं:

1) स्क्रीन के एक नक्शे तक सीमित। इंटरएक्टिव प्रोटोटाइप के साथ परेशान न करें यदि आप यह नहीं समझते हैं कि आप उन्हें क्या और कैसे परीक्षण करना चाहते हैं।

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

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

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

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



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

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

एक बार फिर, एकता में खेल के लिए प्रोटोटाइप इंटरफेस के लाभ क्या है:

वे "गेमप्ले" प्रोटोटाइप में एकीकृत करना आसान है और भविष्य के उत्पाद की बहुत अधिक समग्र और प्रभावशाली तस्वीर प्राप्त करते हैं।

एकता में बने प्रोटोटाइप के हिस्सों को सीधे "फिनिश" प्रोजेक्ट में पुन: उपयोग किया जा सकता है। यह पूरी तरह से काम नहीं करेगा - प्रोग्रामर सबसे अधिक संभावना है कि आपके डिजाइन एक्सटेंशन को एकता के लिए कहीं गहरे में चिपकाने की पेशकश करेंगे, लेकिन कुछ हिस्सों और अलग-अलग स्क्रीन में यह बहुत संभव है।

इस तरह के प्रोटोटाइप डिवाइसों पर ठीक उसी तरह काम करेंगे जैसे आप उन्हें चाहते हैं। ठीक से बढ़ाया और बढ़ाया जाएगा। बैंग्स और सुरक्षित क्षेत्रों पर विचार करेंगे। अंतिम परिणाम, सौंदर्य के साथ कोई विसंगतियां नहीं!

इस तरह के प्रोटोटाइप आसानी से और जल्दी से "मक्खी पर" संपादित करते हैं। पहले सिद्धांत में, फिर एकता में उसी काम को दोहराना आवश्यक नहीं है। आप फोटोशॉप से ​​गुजरे बिना भी कुछ कर सकते हैं।

ओविंग यूनिटी डिजाइनर को त्रि-आयामी इंटरफेस तक पहुंच प्रदान करता है और इंजन के अंदर से इंटरफ़ेस को नियंत्रित करता है।

प्रत्यक्ष बोनस के अलावा, साथ वाले भी हैं: इंजन को जानना सामान्य रूप से जीवन को बहुत सुविधाजनक बनाता है, और श्रम बाजार में एक विशेषज्ञ के रूप में आपके मूल्य को भी बढ़ाता है।

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

और इसके लिए यह आवश्यक नहीं है कि एक तकनीकी विशेषज्ञ हो।