تصویر آموزشی طراحی منوی دلو؛ مرتبط با موضوع نوشته

منوی دلو؛ راه کوتاه‌تر تا میز بازی

بعد از میز بازی، نوبت ورود بود

وقتی حکم قابل بازی شد، دلو هنوز برای ورود به بازی به یک مسیر روشن نیاز داشت. تا آن موقع بیشتر حواسم به کارت‌ها، قوانین و بات‌ها بود. بعد سراغ منوی اصلی رفتم تا بخش‌های پروژه کنار هم قرار بگیرند: انتخاب بازی، تنظیمات، فروشگاه و مسیر برگشت. در گزارش توسعهٔ دهم، چیدمان اولیهٔ منو و بخش‌های مختلف را نشان دادم. آن مرحله برای من بیشتر ساختن اسکلت رابط بود؛ باید معلوم می‌شد هر صفحه کجا قرار می‌گیرد و بازیکن از کدوم مسیر به میز بازی می‌رسه، قبل از اینکه وارد جزئیات دیگر شوم.

ظاهر ساده برای انتخاب مشخص

برای ظاهر منو، می‌خواستم حال‌وهوای بازی کارت حفظ بشه و انتخاب‌ها ساده بمانند. کسی که برنامه را باز می‌کنه، احتمالاً می‌خواهد یک بازی انتخاب کنه؛ لازم نیست همان لحظه تمام بخش‌های پروژه جلوی او باشند. انتخاب بازی، دیدن تنظیمات و سرزدن به فروشگاه هر کدوم دلیل خودشان را دارن. من سعی کردم این دلیل‌ها در چیدمان گم نشوند. برای تبدیل ایده‌های بصری به طرح اولیه هم از GPT کمک گرفتم. تمرکزم در آن زمان برنامه‌نویسی و وصل‌کردن قسمت‌ها بود، پس نمی‌خواستم ساخت تصویرها تمام زمان مرحله را بگیرد.

منو به سیستم‌های بعدی وصل شد

منو برایم فقط تصویر شروع نبود؛ نقطهٔ اتصال سیستم‌هایی شد که بعداً ساختم. بعد از نسخهٔ اولیهٔ رابط، سراغ اقتصاد سکه رفتم و بعد اسکین‌ها و پس‌زمینه‌ها را اضافه کردم. این یعنی فروشگاه و صفحهٔ شخصی‌سازی باید به داده‌های واقعی همان سیستم‌ها وصل می‌شدند. دیدن یک آیتم، داشتن آن و انتخاب‌کردنش سه حالت متفاوت‌اند. اگر این تفاوت در صفحه معلوم نباشد، حتی یک سیستم درست هم برای بازیکن گیج‌کننده می‌شود. برای همین پس از ساخت بخش‌های زیرساختی، برگشتم تا ببینم این حالت‌ها در تجربهٔ واقعی منو چطور کنار هم قرار می‌گیرندد.

از «کار می‌کنه» تا «کجا بروم؟»

چیزی که در این مرحله برایم تغییر کرد، زاویهٔ نگاه به دلو بود. قبلاً بیشتر می‌پرسیدم آیا یک دست از ابتدا تا انتها کار می‌کنه؛ حالا سؤال این بود که بازیکن چطور به آن دست می‌رسه و بعد از آن کجا می‌رود. صفحهٔ زیبا وقتی مفید هست که انتخاب بعدی روشن باشد. همین نگاه در بخش‌های بعدی، از شخصی‌سازی تا متن‌های فارسی و انگلیسی، همراه پروژه ماند. این مطلب روایت ساخت منوست و قرار نیست ادعا کنه با یک چیدمان، همهٔ مسئله‌های رابط حل شده‌اند. برای دیدن اینکه منو به چه مجموعه‌ای وصل شد، به صفحهٔ دلو سر بزنید؛ هر کدوم از بازی‌ها و سیستم‌هایش یک مرحله از همین مسیر بودند.

مثال عملی طراحی منوی دلو

اگر بخواهی طراحی منوی دلو را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. بازیکن تازه‌وارد می‌خواهد با کمترین ابهام به حکم، جوکر یا پاسور برسد. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.

خطای رایج و علت آن

تعداد زیاد دکمه‌های هم‌وزن، مقصد اصلی بازی را میان فروشگاه و پاداش‌ها پنهان می‌کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. مسیر کوتاه باید اطلاعات ضروری را حفظ کند و فقط تعداد لمس را کم نکند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.

چطور نتیجه را بررسی کنیم؟

با مشاهدهٔ نخستین انتخاب، بفهم بازیکن مقصد و هزینهٔ ورود را درست فهمیده یا نه. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.

بخش بررسیآنچه باید ثبت شود
موقعیت آزمایشیبازیکن تازه‌وارد می‌خواهد با کمترین ابهام به حکم، جوکر یا پاسور برسد.
ریسک اصلیتعداد زیاد دکمه‌های هم‌وزن، مقصد اصلی بازی را میان فروشگاه و پاداش‌ها پنهان می‌کند.
روش بررسیبا مشاهدهٔ نخستین انتخاب، بفهم بازیکن مقصد و هزینهٔ ورود را درست فهمیده یا نه.
مرز نتیجه‌گیریمسیر کوتاه باید اطلاعات ضروری را حفظ کند و فقط تعداد لمس را کم نکند.

پرسش‌های کاربردی دربارهٔ طراحی منوی دلو

از کجا شروع کنم؟

از همان موقعیت محدود این مطلب شروع کن: بازیکن تازه‌وارد می‌خواهد با کمترین ابهام به حکم، جوکر یا پاسور برسد. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.

چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟

زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. با مشاهدهٔ نخستین انتخاب، بفهم بازیکن مقصد و هزینهٔ ورود را درست فهمیده یا نه. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. مسیر کوتاه باید اطلاعات ضروری را حفظ کند و فقط تعداد لمس را کم نکند.

برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.

آخرین مطالب بلاگ

تصویر مفهومی مستقل دربارهٔ مقایسه موتورهای بازی

مقایسه یونیتی، گودوت و آنریل؛ انتخاب براساس خروجی پروژه

مقایسهٔ یونیتی، گودوت و آنریل وقتی مفید است که خروجی پروژه معلوم باشد. برای یک بازی کارتی موبایل، یک پازل وب و یک اکشن سه‌بعدی نیازهای

ادامهٔ مطلب
تصویر مفهومی درباره BoomBo

BoomBo؛ مسیر طراحی شخصیت‌های عنصری

مسیر بصری اولیه BoomBo شخصیت‌های عنصری بامزه و کمی ترسناک را بررسی می‌کند: کدو، آتش، یخ، باد و سایه. هدف این است که شخصیت‌ها در آرنای کوچک از بالا قابل.

ادامهٔ مطلب
تصویر آموزشی بودجهٔ حافظهٔ بازی؛ مرتبط با موضوع نوشته

بودجهٔ حافظه؛ دارایی‌ها هم هزینه دارند

تصویر، صدا و آبجکت اجرایی حافظه می‌گیرند، حتی اگر فایل روی دیسک کوچک دیده شود. میز موبایلی بودجهٔ بصری متناسب با دستگاه هدف می‌خواهد.

ادامهٔ مطلب
Dalo