مسئله‌ای که باید حل می‌کردم
خرید پس‌زمینه وقتی معنی داره که انتخاب بازیکن در صحنهٔ بازی هم دیده بشه. من بین مالکیت آیتم، مجهزکردن آن و اعمال واقعی تصویر سه مرحلهٔ جدا دیدم.
پیاده‌سازی در نسخهٔ فعلی
CustomizationRuntimeApplier.ApplyToScene ذخیره و CustomizationCatalog را بارگذاری می‌کنه، شناسهٔ مجهز را می‌یابد و skin و background را اعمال می‌کنه. فقط componentهای همان صحنه پیمایش می‌شوند.
تصمیم و هزینهٔ طراحی
GameVisualConfig override روی کارت می‌گیرد و HokmBoardBackgroundView پس‌زمینه را دریافت می‌کنه. نبود داده مسیر پاک‌کردن override داره تا انتخاب قبلی بی‌دلیل باقی نماند.
مرزهای فعلی
نام ApplyToActiveHokmScene نباید باعث بشه استفادهٔ مشترک را محدود فرض کنم؛ ApplyToScene عمومی‌تر هست. با این حال همهٔ viewها باید با این مسیر سازگار باشند و cache کاتالوگ هم عمر مشخص داره.
سناریوهای بررسی و معنای قرارداد
برای دنبال کردن تجربه، سه پرسش را پشت سر هم می‌پرسم: آیا بازیکن میز را داره، آیا همان میز انتخاب شده و آیا مقصد آن انتخاب را نشان می‌دهد؟ پاسخ مثبت به خرید به تنهایی پاسخ مثبت به دو پرسش بعدی نیست. اعمال تنظیم پس از ورود به صحنه، انتخاب ذخیره‌شده را به اجزای بصری وصل می‌کنه. محدود کردن جست‌وجو به صحنهٔ مشخص نیز در پروژه‌ای با چند صحنه یا اشیای باقی‌مانده اهمیت داره؛ قرار نیست یک تغییر پس‌زمینه هر شیء مشابه در حافظه را بی‌قاعده تغییر دهد. در این مسیر، شناسهٔ انتخاب‌شده باید در کاتالوگ قابل پیدا کردن باشد.
اگر دادهٔ انتخاب معتبر نباشد، پاک کردن override از باقی ماندن ظاهر قبلی جلوگیری می‌کنه. این تصمیم برای حالت تغییر کاتالوگ یا نبودن یک دارایی قابل توضیح هست، اما نتیجهٔ بصری پیش‌فرض همچنان باید در مقصد مناسب باشد. بررسی فقط در فروشگاه انجام نمی‌شود: ورود به بازی، تغییر انتخاب و ورود دوباره، و انتخابی با دادهٔ حذف‌شده هر کدوم بخش دیگری از مسیر را می‌سنجند. نام تاریخی تابع مربوط به حکم نباید دامنهٔ واقعی ApplyToScene را محدود جلوه دهد؛ در عین حال تعمیم نام نیز به معنای پشتیبانی خودکار هر نمای تازه نیست. اجزای مقصد باید قرارداد اعمال پوست و پس‌زمینه را واقعاً مصرف کنن.
کاتالوگِ یافتن انتخاب و نمای دریافت‌کننده دو طرف این مسیر هستند. افزودن یک دارایی به کاتالوگ بدون وجود مصرف‌کنندهٔ مناسب در صحنه، خودکار به نمایش منجر نمی‌شود. این یادداشت برای من یادآور یک معیار ساده هست: انتخاب را در مقصد واقعی ببینم. آزمایش فقط روی تصویر پیش‌نمایش فروشگاه، ارتباط ذخیره، شناسه و جزء صحنه را به طور کامل نشان نمی‌دهدد.
چیزی که از این مرحله یاد گرفتم
برای من، شخصی‌سازی باید تا مقصد ادامه پیدا کنه. فروشگاه فقط مالکیت را توضیح می‌دهد؛ تجربهٔ واقعی وقتی کامل‌تر می‌شود که تصویر کارت، پشت حریف و میز هم همان انتخاب را منعکس کنن.
مثال عملی شخصی‌سازی میز
برای فهم عملی شخصی‌سازی میز، یک مثال آموزشی را قدم‌به‌قدم دنبال کنیم. بازیکن یک پس‌زمینهٔ تازه می‌خرد، انتخاب می‌کند و به صحنهٔ بازی می‌رود. پیش از اجرا، وضعیت آغاز را روی کاغذ بنویس؛ مشخص کن چه چیزی می‌تواند تغییر کند و چه چیزی باید ثابت بماند. بعد فقط همین مسیر را اجرا کن. این مثال گزارشی از آمار کاربران یا قابلیت تازهٔ منتشرشدهٔ دلو نیست؛ تمرینی برای روشن کردن تصمیم طراحی همین مطلب است.
خطای رایج و علت آن
داشتن آیتم در مجموعه با اعمال شدن همان آیتم در صحنه یکسان نیست. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. کنتراست کارت با میز از جذابیت بصری تنها مهم‌تر است. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
مالکیت، انتخاب فعال و تصویر واقعی صحنه را به صورت سه وضعیت بررسی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | بازیکن یک پس‌زمینهٔ تازه می‌خرد، انتخاب می‌کند و به صحنهٔ بازی می‌رود. |
| ریسک اصلی | داشتن آیتم در مجموعه با اعمال شدن همان آیتم در صحنه یکسان نیست. |
| روش بررسی | مالکیت، انتخاب فعال و تصویر واقعی صحنه را به صورت سه وضعیت بررسی کن. |
| مرز نتیجه‌گیری | کنتراست کارت با میز از جذابیت بصری تنها مهم‌تر است. |
پرسش‌های کاربردی دربارهٔ شخصی‌سازی میز
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: بازیکن یک پس‌زمینهٔ تازه می‌خرد، انتخاب می‌کند و به صحنهٔ بازی می‌رود. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. مالکیت، انتخاب فعال و تصویر واقعی صحنه را به صورت سه وضعیت بررسی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. کنتراست کارت با میز از جذابیت بصری تنها مهم‌تر است.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
