खेल इंटरफ़ेस और यह क्या खाता है

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

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

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

और चलिए तुरंत सहमत हैं: नीचे जो लिखा गया है वह किसी भी तरह से अंतिम सत्य नहीं है। मेरा अनुभव सीमित है। अगर आपको लगता है कि कहीं मैंने बकवास लिखा है (या कुछ बेहतर करने के लिए पता है) - कृपया मुझसे संपर्क करें या टिप्पणियों में अपनी दृष्टि का वर्णन करें।

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

1) इंटरफ़ेस की संरचना और मुख्य कार्यात्मक भागों की परिभाषा।
2) आरेख के रूप में मुख्य स्क्रीन को प्रोटोटाइप करना।
3) रीसेट और प्रोटोटाइप परीक्षण। शैली और उपस्थिति के लिए खोजें।
4) स्क्रीन खींचना, UI किट खींचना। प्रलेखन।
5) खेल इंजन, स्वीकृति और गुणवत्ता नियंत्रण का परिचय।
6) इंटरफ़ेस एनिमेशन जोड़ना।
7) परिणामों की विश्लेषिकी।

क्रम में चलते हैं।

पहला कदम। इंटरफ़ेस की संरचना और मुख्य कार्यात्मक भागों की परिभाषा।

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

इन प्राथमिक मॉकअप को फेंकने की प्रक्रिया में, "नियम" उत्प्रेरित होंगे, जिसके अनुसार इस विशेष परियोजना पर इंटरफ़ेस बनाया गया है। नेविगेशन कैसे किया जाता है? बटन कहां स्थित होंगे? पाठ की कितनी आवश्यकता होगी और यह किस आकार का होगा? क्या टूलटिप्स और अन्य पॉप-अप तत्वों की आवश्यकता है, और यदि हां, तो कहां और किस प्रारूप में हैं?

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





मुझे क्या ध्यान देना चाहिए:

• स्क्रीन के बीच संपर्क में।
• कार्यात्मक पर (स्क्रीन के लिए क्या आवश्यक है यह करना सुविधाजनक है)।
• मुख्य तत्वों के आकार और स्थान पर।

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

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

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

चरण दो प्रोटोटाइप की विधानसभा, शैली की खोज।

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





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

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

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

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

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

दूसरे चरण में इंटरफ़ेस के साथ काम करने के परिणाम:

सबसे पहले, आरेख और स्टब विजुअल पर आधारित एक प्रोटोटाइप इंटरफ़ेस की असेंबली बनाई गई है या चल रही है।

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

रेफरी सूची के उदाहरण:





सीमांत नोट: सबसे पहले, अपनी परियोजना के रूप में एक ही बाजार के आला से संदर्भ एकत्र करना बेहतर है। तथ्य यह है कि यदि आप पीसी के लिए एएए गेम से उत्कृष्ट रेफरी लेते हैं, और मोबाइल गेम के विकास में लगे हुए हैं, तो उन्हें समन्वयित करना आसान होगा, लेकिन सीमित मोबाइल प्रारूप में इस सभी सुंदरता का एहसास करना लगभग असंभव होगा। नतीजतन, कुछ बिंदु पर, आप ग्राहक से एक तार्किक सवाल भर में आ जाएंगे: "हमने इस तरह के कूल रिफ को उठाया, इसका परिणाम क्या हुआ?"

एक और पक्ष नोट: इस स्तर पर प्रतियोगियों का अध्ययन करने के लिए अधिक समय और ऊर्जा समर्पित करें। स्क्रीनशॉट देखें, समीक्षा पढ़ें, YouTube पर जाएं, अंत में। जितनी अधिक आप देखते हैं, आपके लिए यह समझना उतना ही आसान होगा कि ऐसी परियोजनाओं में क्या बेहतर काम करता है (या काम नहीं करता है) और आपकी राय पर बहस करना कितना आसान है। पहिया को मजबूत करने के लिए जल्दी मत करो और सादगी से डरो मत।

चरण तीन एक प्रोटोटाइप चलाना, स्क्रीन के पूर्वावलोकन प्रस्तुत करना।

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

Refs के चयन की प्रक्रिया में, पहली पूर्वावलोकन स्क्रीन खींचने के लिए मुख्य निर्देश आमतौर पर स्पष्ट हो जाते हैं: मान लीजिए कि आपके पास एक Sci-Fi सेटिंग है, और ग्राहक द्वारा अनुमोदित refs में Deus Ex और XCOM हैं ... ठीक है, मैं कहूंगा कि आपको कम से कम एक पूर्वावलोकन करना होगा। दो रूपों में:



और अगर refs में शैली के समान कुछ स्क्रीन हैं (समान XCOM और, कहते हैं, मास इफ़ेक्ट) और अधिक समय नहीं है, तो एक के साथ प्राप्त करना बहुत संभव है:



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

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

इस चरण का परिणाम: "ठीक" गुणवत्ता के 3-4 तैयार स्क्रीन, ग्राहक द्वारा अनुमोदित और प्रोटोटाइप में रन-इन इंटरफ़ेस प्रोटोटाइप।

चरण चार यूआई किट, प्रलेखन ड्राइंग स्क्रीन, ड्राइंग।

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

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

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

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

आगे, GUI पैक के बारे में थोड़ा (या, जैसा कि इसे भी कहा जाता है, UI किट या डिज़ाइन केस )। कई बुनियादी स्क्रीन खींचने के बाद, तत्वों का मुख्य सेट जिसमें आपका इंटरफ़ेस शामिल होगा, साथ ही उनकी व्यवस्था के लिए नियम, आमतौर पर स्पष्ट हो जाते हैं। स्क्रीन के साथ भविष्य के काम में, यह लगभग 60-80% होगा जो तैयार किए गए नियमों के अनुसार तैयार तत्वों के पुन: उपयोग से बना होगा। यह एक अलग, संदर्भ फ़ाइल में तत्वों और विवरणों के साथ इस "कंस्ट्रक्टर" को बनाने के लिए समझ में आता है। यह कुछ इस तरह दिखता है:


जॉनी वाटरमैन द्वारा छवि

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

चरण पाँच खेल इंजन का परिचय, गुणवत्ता नियंत्रण।

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

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

चरण छह एनिमेशन चमकाना और जोड़ना।

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

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

सातवाँ चरण। इंटरफ़ेस विश्लेषिकी।

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

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

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

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

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

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

सभी को शुभकामनाएँ!