منوی اصلی از داده تا دکمه

مسئله‌ای که باید حل می‌کردم

بعد از حکم، دلو به یک ورودی مشترک نیاز داشت. من نمی‌خواستم نمایش سکه، بازی‌ها و جایزه‌ها هر کدوم مستقیماً بخشی از ذخیره را با منطق مستقل تفسیر کنن.

پیاده‌سازی در نسخهٔ فعلی

MainMenuPresenter.BuildUiData هدر، بازی‌ها، بسته‌های سکه، زنجیرهٔ هفتگی و دستاوردها را می‌سازد. اطلاعات از MetaCatalog و سرویس‌های اقتصاد و آمار می‌آید، نه از متن دکمه‌ها.

تصمیم و هزینهٔ طراحی

دادهٔ نمایشی اجازه می‌دهد منو را بدون تبدیل presenter به مجموعه‌ای از GameObjectها توضیح بدهم. فیلتر تعریف نامعتبر هم در ساخت فهرست انجام می‌شود.

مرزهای فعلی

خروجی presenter به‌تنهایی صفحه را رسم نمی‌کنه. binder، prefab و مرجع‌های صحنه هنوز لازم‌اند؛ نبود catalog می‌تواند منوی داده‌ای خالی بدهد، نه یک رابط کامل خودکار.

دادهٔ منو و اتصال واقعی صحنه

مثلاً کارت ورود به حکم باید هزینهٔ ورود، تعداد بازی‌ها و بردهای بازیکن را کنار هم نشان دهد. BuildGames این مقادیر را از GameDefinition، StatisticsService و CurrencyService می‌گیرد و در GameCardUiData می‌گذارد. CanAfford به وضعیت سکه وابسته هست، نه متن رنگی روی دکمه. پس تغییر موجودی نیازمند تازه شدن داده و بازتاب آن در رابط هست. این ساختار برای بررسی اختلاف مفید هست: می‌شود پرسید محاسبهٔ توان پرداخت اشتباه بوده یا نمایش مقدار درست به دکمه نرسیده هست. presenter خودِ خرید یا ورود به صحنه را در BuildUiData انجام نمی‌دهدد.

BuildWeeklyStreakRewards برای روزهای یک تا هفت ردیف می‌سازد و نبودن تعریف جایزه می‌تواند Reward برابر null ایجاد کنه. BuildAchievements نیز پیشرفت، هدف، کامل بودن و دریافت‌شدن را کنار تعریف دستاورد قرار می‌دهد. این داده‌ها برای منو مفیدند، اما BuildUiData تضمین نمی‌کنه تمام بخش‌ها در یک binder واحد نمایش داده بشن. در فایل صحنهٔ game.unity، ارجاع اسکریپت StaticMainMenuSceneConnector دیده می‌شود؛ این اتصال از CurrentUiData برای RefreshHeader و RefreshGameCards استفاده می‌کنه. وجود presenter گسترده‌تر را نباید با فعال بودن تمام نماهای ممکن در همین connector یکی دانست.

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

چیزی که از این مرحله یاد گرفتم

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

مثال عملی منوی داده‌محور بازی

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

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

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

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

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

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

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

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

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

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