نمذجة واجهات الألعاب للإنسانيات

مرحبا بالجميع! أنا مصمم UI / UX متخصص في واجهات الألعاب. أنا أيضًا إنساني: كل ما يتعلق بالشفرة يثير الخوف الفطري وعدم الثقة ، وهو أمر لا يمكنني التغلب عليه. أن تكون خائفًا من "السحر الأسود" للمخرج أمر طبيعي بالنسبة إلى المصمم. ولكن هناك مشكلة تعقد الحياة بشكل كبير.

والحقيقة هي أنه في عملنا ، يتعين علينا ، نحن مصممي الواجهة ، غالبًا الاقتراب من المواقع والتطبيقات الداخلية وحتى الدخول فيها قليلاً. هذه الحاجة وثيقة الصلة بشكل خاص في مرحلة النماذج الأولية والسريعة ، عندما ترغب في جمع شيء ما على ركبتك يمكن أن يعطي فكرة عن المنتج النهائي ، سيكون لها الحد الأدنى من الوظائف الضرورية وتبدو مناسبة أيضًا. ومع ذلك ، فإن معظم المصممين (بمن فيهم أنا) ليس لديهم حتى الحد الأدنى من المعرفة لإنشاء وتحرير جزء واجهة النموذج الخاص بهم ، من خلال الكود. وهذا أمر طبيعي بالنسبة لهذه الصناعة.

بمعرفة هذه الميزة الإنسانية الخاصة بنا ، قام المبرمجون الوجدون (إلى جانب الأشخاص الآخرين الطيبين) بإنشاء عدد كاف من الأدوات لإنشاء تصميم واختباره على أجهزة حقيقية دون كتابة سطر واحد من التعليمات البرمجية. يتم غوغل هذه الأدوات بسهولة بناءً على طلب من "برنامج النماذج الأولية للواجهة". هذه هي Sketch و Adobe XD و Figma و Principle و InVision و Marvel وغيرها. إنها رائعة. إنهم ينقذون الملايين من خلايا مصمم الأعصاب (وربما زوجين من الأرواح). المئات من المقالات قد كتبت عنهم ، وقد أثنى عليها مصممو UI / UX بجدارة في جميع أنحاء العالم.

ومع ذلك ، تم تصميم هذه الأدوات بشكل أساسي لمطوري تطبيقات الويب والجوال. بالنسبة إلى dev dev (ونحن هنا حصريًا حول dev dev) ، فهي مناسبة بشكل سيء.

"انتظر لحظة ، ما هو الفرق؟" الألعاب هي تطبيقات أيضًا ، أليس كذلك؟ ليس حقا تجعل تفاصيل اللعبة تصحيحًا مهمًا لعملية الإنتاج.

هيا بنا

أولاً ، غالباً ما يتم بناء التطبيقات "العادية" التي لا تستخدم الألعاب على مبدأ الحلول المباشرة لمشاكل المستخدم. على سبيل المثال ، أريد حل مشكلة معينة - تحويل الأموال إلى بطاقة Serege - ولهذا ، افتح تطبيقًا مصرفيًا. مدى سرعة حل سؤالي يحدد درجة رضائي عن هذا التفاعل. بعد النقل ، أغلق التطبيق وأنساه لفترة من الوقت. أنا مرتاح ، البنك راضي ، سيريوجا راضي. هذا مسار خطي مفهوم من النقطة أ إلى النقطة ب.

البنك ، مثلي ، مهتم بإغلاق مهام المستخدم في أسرع وقت ممكن. انه لا يخلق لهم على وجه التحديد. بشكل تخطيطي ، يبدو مثل هذا:



في قطاع الترفيه (حيث يأتي الدخل الرئيسي من الإعلانات) ، كلما زاد الوقت الذي يقضيه المستخدم في إحدى الخدمات ، يمكن تحقيق المزيد من الأرباح منه. لذلك ، يوتيوب نفسه ، دون أن يطلب ، يطلق الفيديو التالي ويسرق الخوارزميات التي تختار هذا الفيديو لمصالحك. في ألعاب المحمول نفسه. الرغبة في الحصول على المتعة والحصول على جرعة من الدوبامين بمعنى ما هي مهمة يحددها المستخدم. لكنها لا تملك حلاً نهائيًا محددًا ، وهو ما يستخدمه منتجو المحتوى. نريد منك ألا تنفصل عن ألعابنا. عموما.

لذلك ، تستخدم الألعاب دورات تلقي اللاعبين بمهام جديدة وتنقلهم بمهارة من نشاط إلى آخر. يبدو شيء مثل هذا:



مثل هذا الهيكل بالفعل أصعب بكثير من النموذج الأولي. استدعاء هذه اللعبة ميزة الكمين رقم 1 . هناك آخرون.

كمين رقم 2 اللعبة هي في المقام الأول اللعب. الواجهة مجرد ربط وإطار للماس (على الرغم من أن الواجهة = gameplay في بعض الألعاب ، ولكن دعونا لا نتحدث عن أشياء حزينة). بدون هذه الأحجار الكريمة في المنتصف ، يكون من الصعب في كثير من الأحيان تقييم مدى جودة أو سوء واجهة المستخدم الخاصة بك (والآن لا أتحدث عن المظهر). المشكلة هي أنه لا يمكن دمج طريقة اللعب في أدوات النماذج الأولية ؛ فهي موجودة في برامج مختلفة ، في عوالم مختلفة. وإذا لم تكن هناك طريقة لعب ، فلا توجد لعبة بحد ذاتها. لا يوجد سياق مطلوب.

الكمين رقم 3 في الألعاب هناك عناصر و / أو رسوم متحركة غير قياسية للغاية. لوحة العناصر أوسع بكثير مما يمكن العثور عليه على مواقع الويب أو في التطبيقات المكتبية. ليس كل برنامج النماذج الأولية يمكن إعادة إنشائها على الإطلاق.

مصنوعة 4 كمين ألعاب على محركات اللعبة. تتم مزامنة أدوات النماذج الأولية معهم حول ... لا شيء. فهي ببساطة ليست مصممة لهذا الغرض. كل ما تم القيام به في * اسم البرنامج للنماذج الأولية * ، ستعيد أنت (أو زميلك الفقير) مرة أخرى في المحرك. من الصفر. وليست حقيقة أنه في نفس الوقت سيكون من الممكن تكرار كل شيء على الأقل بالقرب من ما كان عليه في النموذج الأولي: قدرات البرنامج مختلفة. هذا هو السبب في أن اللاعبين الكبار مثل Game Insight ( فيديو ) أو Pixonic ( مقالة ) يتدفقون على الأدوات الداخلية التي تقوم بمزامنة فوتوشوب بطريقة ما ، وتقطيع العفاريت ، وتجميعها في المحرك ، وإدارة الأنماط ، إلخ.

نعم ، بالمناسبة. ملاحظة هامشية. لقد عملت فقط مع الألعاب المصنوعة على Flash أو Unity. لقد توفي Flash بالفعل ، لذلك سيكون حول الوحدة بشكل أساسي. أفترض أن كل ما هو زائد أو ناقص هو الصحيح بالنسبة لمحركات الألعاب الشائعة الأخرى ، لكن هذا غير دقيق.

ماذا يؤدي هذا الازدواجية في العمل؟ من الواضح أن الحقيقة المتمثلة في أن الجهود المبذولة لتطوير ودعم نماذج واجهة أكثر أو أقل تعقيدًا هي زيادة صارخة. فليكن الساعات البشرية الرخيصة نسبيا مصمم (الرجال آسف) ، ولكن مع ذلك.

لا أريد أن أقول أن واجهات اللعبة النموذجية بالأدوات القياسية غبية. بالطبع لا: أي عمل تحضيري في إنتاج الواجهة أفضل من غيابها. إنها فقط الطريقة المألوفة لنا ، المصممين ، لها قيود ومشاكل يمكن تجنبها. المزيد عن هذا في وقت لاحق.

هناك مثل هذا الرجل ، أم تاندون . لقد نشر العديد من المقالات حول ألعاب UI / UX ، وبشكل عام يبدو أنه نوع من التحسس في هذه المسألة. على الأقل ، يكتب بثقة كبيرة (بالمناسبة ، كان من منه أنني سحبت الصور وبعض الأفكار لهذا المقال). أنصح المهتمين بقراءة الدورة المقابلة لمقالاته على LinkedIn (لا تنسوا VPN): الأجزاء الأولى والثانية والثالثة . يمكنك أيضا مشاهدة الفيديو الخاص به من مؤتمر في لندن. من الأفضل التوقف والقيام بذلك الآن قبل متابعة قراءة هذه المقالة ، لأن سأعتمد في أماكن على مادته.

على الرغم من حقيقة أن فكرة أوم بشكل عام - لجعل النماذج الأولية قريبة قدر الإمكان من المنتجات النهائية بأسرع ما يمكن وبأسعار رخيصة ، أود ، ولا سيما أنني لا أتفق معه. على سبيل المثال ، يدعي أنه من أجل تحقيق نفس النتيجة في النموذج الأولي للعبة (يُطلق عليه أوم النموذج الأولي dev) ، مقارنةً بالنموذج "المصمم" ، فإنه يستغرق وقتًا وجهدًا عدة مرات. يتم تقديم أشكال محددة: يستغرق إنشاء هذا النموذج الأولي من 5 إلى 7 أيام باستخدام Principle (أحد أدوات النماذج الأولية الشائعة) ، وسيستغرق الفريق من 20 إلى 30 يومًا لتنفيذ نفس الوظيفة في المحرك ، وفقًا لأهم. ولا يتعلق الأمر "بالقيام بكل شيء وفقًا للجمال" ، بل يتعلق فقط بالحصول على نتيجة مماثلة في المخرجات. في رأيي ، الرقم مبالغ فيه إلى حد كبير.

ثانياً ، لا تزال أمثلة النموذج الأولي التي ذكرها Om خطية في الغالب. هذا هو إما برامج تعليمية مع سلسلة من الإجراءات الحقيقية الوحيدة ، أو سلسلة من الشاشات التي يمكنك من خلالها السفر في الاتجاهين "هناك" و "هنا" ، أو تقليد التفاعل الجزئي المحلي. نعم ، إنها تبدو لذيذة ، لكنني لم أر أي دورات ألعاب أو منطق معقد هناك.

ثالثًا ، في نماذج أوم المقدمة في Principle ، للأسباب التي سبق وصفها ، لا توجد طريقة اللعب نفسها ولا يمكن أن تكون كذلك. ليس هناك حتى 3D على هذا النحو! إنهم فقط حول UI / UX المسطح ، بمعزل عن اللعبة نفسها. في رأيي ، هذا يقلل من قيمتها. على الرغم من أن Om تدعي أن هذه الحلول مناسبة لمحاكاة ما يقرب من 80 ٪ من أنواع الألعاب.

رابعًا ، أحد الأسباب الرئيسية لتطوير نموذج أولي للواجهة هو استخدامه اللاحق في أبحاث قابلية الاستخدام. هذا شيء عظيم وصحيح ، ولكن كم مرة صادفتك دراسات قابلية للاستخدام (أوه ، على الأقل) في مجال تطوير اللعبة المحلية؟ هل هناك حاجة إلى مثل هذه النماذج الأولية للفرق الصغيرة والاستوديوهات التي لا تجري هذه الدراسات نفسها؟ إذا كان النموذج الأولي للعبة جزءًا واضحًا وإلزاميًا من تطوير أي لعبة (بشرط ألا تكون ورقة تتبع من مشروع آخر) ، فهل هناك أي نقطة في الإزعاج باستخدام نماذج "المصمم" - هذا سؤال مفتوح.

في تجربتي ، أبسط خريطة غير تفاعلية للشاشات في صورة واحدة ضخمة يحل الغالبية العظمى من القضايا على التفاعل والاتصال بين الشاشات. يتم جمع هذه الصورة في غضون نصف ساعة ولن تحتاج سوى الصور بالحجم الطبيعي المرسومة في Photoshop (الرسام). هذا هو في معظم الأحيان ممكن أن تتوقف.

في أي الحالات يكون من المنطقي الانتقال إلى نموذج أولي تفاعلي ومفصل للغاية (يطلق أوم على هذا النموذج عالي الدقة )؟ Nuuu ... على سبيل المثال ، إذا كان عميلك يحتاج إلى معظم المواد المرئية ، وليس إلى مخطط BW ، لقبول العمل. هذا يحدث.

أو إذا كنت بحاجة إلى إنشاء عرض توضيحي جميل يمكنك إظهاره للمستثمرين والقيادة على الهاتف.

أو إذا كانت طريقة لعب المشروع أو جزء منه جديدًا إلى درجة أنه من غير الواضح عمومًا كيفية بناء التفاعل معه ، ويلزم إجراء دورات مستمرة لاختبار الفرضيات.

أو إذا كنت ترغب في تسريع عملية التجربة والخطأ في الواجهات ، فقم بإفراغ المبرمجين على طول الطريق.

أو إذا كنت بحاجة إلى منتج محاكاة لاختبار قابلية الاستخدام.

باختصار ، لا أوصي بإنشاء نموذج تفصيلي للعبة مع واجهة بشكل افتراضي ، ولكن هناك حالات عندما تكون هناك حاجة إليها حقًا. فقط قرر لماذا تنفق مواردك على هذا ونوع العادم الذي تخطط لاستلامه.

لذلك مرة أخرى ، لفترة وجيزة. أرى ثلاث طرق رئيسية لنموذج واجهة اللعبة:

1) تقتصر على خريطة الشاشات. لا تهتم بالنماذج الأولية التفاعلية إذا كنت لا تفهم ماذا وكيف تريد اختبارها.

2) اجعل بدائية (صور الشرائح حرفيًا مع انتقالات) نموذجًا تفاعليًا في البرنامج الذي سيتم تشغيله بشكل أسرع. هذا هو البديل لأولئك الذين يفهمون ماذا وكيف يريدون التحقق ، والذين لا يحتاجون إلى تفاصيل خاصة أو لربط الواجهة مع هذه اللعبة (على سبيل المثال ، أنت مهتم فقط بالجزء ميتا من اللعبة). يمكن مشاهدته على الجهاز.

ولكن إذا كنت بحاجة موضوعيًا إلى شيء أكثر قربًا من المنتج الحقيقي ، فهذا هو الخيار الثالث ، ودعونا نتناوله بمزيد من التفاصيل. للقيام بذلك ، النموذج الأولي للواجهة مباشرة في الوحدة ، عزيزي صديق مصمم. إنه أسهل مما تعتقد.

الحقيقة هي أن الوحدة هي نظام بيئي كامل ، تجمع ضخم. مخيف إلى حد ما ، وحشية في بعض الأحيان وغير مريحة ، ولكن بالتأكيد مع إيجابياته. على سبيل المثال ، بغض النظر عن الميزة الإضافية التي ترغب في تثبيتها على المحرك ، فعلى الأرجح أنها متاحة بالفعل للتنزيل في متجر الأصول . في بعض الأحيان حتى من نوعية لائقة. أدوات التصميم ليست استثناء.

على سبيل المثال ، أنا شخصياً أحب DoozyUI ، والذي يسمح لك بإنشاء شاشات منفصلة دون الكثير من المتاعب ، وإضافة الروابط والتحولات بينهما ، وربط الرسوم المتحركة للواجهة بسرعة. نظرًا لأنهم لا يدفعون رسومًا إضافية مقابل الإعلانات ، فسأقولها كما يلي: هذا بعيد عن الأداة الوحيدة المتاحة في السوق. وربما ليس الأفضل. قام برشوة لي بعدد كبير من البرامج التعليمية وتاريخ غني ونظامه الخاص لعرض الروابط بين الشاشات. مجرد إلقاء نظرة على هذا الجمال!



ومع ذلك ، هناك حلول أخرى رائعة لإنشاء أنظمة شاشة معقدة في Unity دون معرفة رمز عميقة. كل ما عليك فعله هو استثمار القليل من وقتك في عمليات البحث الخاصة بهم وحفر أعمق في متجر الأصول.

من حيث المبدأ ، يمكنك الاستغناء عن الامتدادات على الإطلاق ، واستخدام ما تقدمه Unity خارج الصندوق. فقط للنفسية الإنسانية ، سيكون الأمر أكثر إيلامًا. يجب أن تفهم أنه في أي موقف في البداية ، سيتعين على متحدِّث الوحدة أن يشاهد ساعات تدريب NN (أو يسحب المبرمجين باستمرار ، كما في حالتي). ومع ذلك ، فإن المحرك غير مصمم للمصممين ؛ إنه بيئة كانت معادية في البداية لأخينا. لذلك ، لا يعتبر العديد من مصممي UI / UX للعبة ميزات Unity كأداة لعملهم. لكنك لست واحداً من هؤلاء ، أليس كذلك؟

مرة أخرى ، ما هو ربح النماذج الأولية للألعاب فورًا في Unity:

من السهل دمجها في النموذج الأولي "gameplay" والحصول على صورة أكثر شمولية وإثارة للإعجاب عن المنتج المستقبلي.

يمكن إعادة استخدام أجزاء من النماذج الأولية المصنوعة في الوحدة مباشرة في مشروع "إنهاء". لن ينجح الأمر تمامًا - على الأرجح سيعرض المبرمجون التمسك بملحقات التصميم لـ Unity في مكان ما بشكل أعمق ، ولكن في الأجزاء والشاشات المنفصلة ، يكون ذلك ممكنًا للغاية.

ستعمل هذه النماذج الأولية على الأجهزة بالطريقة التي تريدها بالضبط. سيتم امتدت بشكل صحيح وتحجيمها. سوف تنظر الانفجارات والمناطق الآمنة. لا تناقضات مع النتيجة النهائية ، الجمال!

مثل هذه النماذج بسهولة وبسرعة تحرير "على الطاير". ليس من الضروري تكرار نفس العمل أولاً في المبدأ ، ثم في الوحدة. يمكنك أن تفعل شيئا حتى دون الذهاب من خلال فوتوشوب.

يمنح Owning Unity المصمم إمكانية الوصول إلى واجهات ثلاثية الأبعاد والتحكم في الواجهة من داخل المحرك.

بالإضافة إلى المكافآت المباشرة ، هناك ما يرافقها: التعرف على المحرك يسهل إلى حد كبير الحياة بشكل عام ، ويزيد من قيمتك كمتخصص في سوق العمل.

بشكل عام ، أردت أن أقول كل هذا. الزملاء ، لا تخافوا للتجربة! ألق نظرة فاحصة على المحركات التي تعمل بها وقدراتها. بذل المزيد من الجهد ، عناء ، تكون مهتمة. يؤتي ثماره.

ولهذا ليس من الضروري أن يكون فني.