مسئله‌ای که باید حل می‌کردم
شروع مسابقه باید بعد از روشن‌شدن هزینهٔ ورود باشد. اگر اول صحنه را باز کنم و بعد سکه را بررسی کنم، رابط وارد حالتی می‌شود که نباید از ابتدا ممکن بوده باشد.
پیاده‌سازی در نسخهٔ فعلی
MatchEntryService.TryEnterMatch بازی را از MetaCatalog پیدا می‌کنه و TrySpendCoins را با دلیل MatchEntry می‌زند. نتیجه شامل وضعیت، شناسهٔ بازی، نام صحنه و هزینه هست.
تصمیم و هزینهٔ طراحی
Success و NotEnoughCoins و InvalidGame مسیرهای متفاوت‌اند. Finish رویداد درخواست و تله‌متری موجودی پیش و پس از تلاش را می‌دهد؛ مصرف‌کننده بر اساس نتیجه تصمیم به جابه‌جایی صحنه می‌گیرد.
مرزهای فعلی
این سرویس خودش SceneManager را اجرا نمی‌کنه و rollback بارگذاری ناموفق صحنه داخل آن وجود نداره. پرداخت موفق و ورود موفق به صحنه دو مرحله‌اند که نباید در گزارش یکی بشن.
سناریوهای بررسی و معنای قرارداد
سناریوی اصلی دو نتیجهٔ متفاوت داره: بازی در کاتالوگ وجود داره ولی بازیکن سکهٔ کافی نداره، یا شناسه اصلاً به بازی معتبر اشاره نمی‌کنه. در حالت اول پیام دربارهٔ موجودی هست؛ در حالت دوم باید تعریف یا اتصال منو بررسی بشه. یک نتیجهٔ عمومی شکست این تفاوت را از رابط و گزارش پنهان می‌کرد. نگه داشتن شناسه، نام صحنه و هزینه در نتیجه کمک می‌کنه مصرف‌کننده پس از تصمیم سرویس بداند دقیقاً چه مقصدی را می‌تواند باز کنه. نمونهٔ موفق نیز به این معناست که هزینه پذیرفته شده، نه اینکه موتور حتماً صحنه را بارگذاری کرده هست.
این جداسازی یک فاصلهٔ واقعی بین پرداخت و ورود می‌سازد. اگر بارگذاری مقصد به هر دلیل متوقف بشه، سرویس فعلی خودش بازپرداخت انجام نمی‌دهدد. بنابراین طراحی تجربه باید برای چنین وضعیت‌هایی پیام و سیاست مشخص داشته باشد؛ از این سورس نمی‌توان وجود آن سیاست را نتیجه گرفت. در بررسی تله‌متری نیز شمار درخواست موفق را با شمار مسابقهٔ آغازشده یکی نمی‌گیرم. رویداد مرحلهٔ بعد می‌تواند روشن کنه بازیکن واقعاً وارد شده یا فقط هزینه پرداخت کرده هست. این تفکیک برای یافتن خطای اتصال صحنه مفیدتر از اضافه کردن یک نام کلی مانند شروع به همهٔ مراحل هست.
در بازبینی مسیر ورود، تکرار سریع لمس هم پرسش مستقلی هست. این سرویس به تنهایی قفل رابط در برابر دو درخواست پیاپی معرفی نمی‌کنه؛ مصرف‌کننده باید بداند چه زمانی دکمه را ببندد و چه زمانی دوباره اجازه بدهد. من درخواست ورود، پرداخت سکه و رسیدن به runner را سه نشانهٔ جدا می‌بینم تا خطای مسیر به اشتباه مشکل قوانین مسابقه تفسیر نشود.
چیزی که از این مرحله یاد گرفتم
برای من، قرارداد ورود کمک کرد یک لمس را به تصمیم قابل توضیح تبدیل کنم. بازی معتبر، توان پرداخت و مقصد مشخص باید پیش از شروع وجود داشته باشند؛ پیام کمبود سکه پیامد همان تصمیم هست.
مثال عملی هزینهٔ ورود مسابقه
برای فهم عملی هزینهٔ ورود مسابقه، یک مثال آموزشی را قدم‌به‌قدم دنبال کنیم. بازیکن با موجودی مرزی ورود را می‌زند و سپس بارگذاری مسابقه شکست می‌خورد. پیش از اجرا، وضعیت آغاز را روی کاغذ بنویس؛ مشخص کن چه چیزی می‌تواند تغییر کند و چه چیزی باید ثابت بماند. بعد فقط همین مسیر را اجرا کن. این مثال گزارشی از آمار کاربران یا قابلیت تازهٔ منتشرشدهٔ دلو نیست؛ تمرینی برای روشن کردن تصمیم طراحی همین مطلب است.
خطای رایج و علت آن
کسر قبل از آماده شدن مسیر، بدون تعریف لغو، می‌تواند سکه را بدون مسابقه مصرف کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. لحظهٔ رزرو، قطعی شدن ورود و سیاست بازگرداندن هزینه باید روشن باشند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
موجودی ناکافی، دوبار کلیک و شکست ورود را جدا بررسی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | بازیکن با موجودی مرزی ورود را می‌زند و سپس بارگذاری مسابقه شکست می‌خورد. |
| ریسک اصلی | کسر قبل از آماده شدن مسیر، بدون تعریف لغو، می‌تواند سکه را بدون مسابقه مصرف کند. |
| روش بررسی | موجودی ناکافی، دوبار کلیک و شکست ورود را جدا بررسی کن. |
| مرز نتیجه‌گیری | لحظهٔ رزرو، قطعی شدن ورود و سیاست بازگرداندن هزینه باید روشن باشند. |
پرسش‌های کاربردی دربارهٔ هزینهٔ ورود مسابقه
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: بازیکن با موجودی مرزی ورود را می‌زند و سپس بارگذاری مسابقه شکست می‌خورد. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. موجودی ناکافی، دوبار کلیک و شکست ورود را جدا بررسی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. لحظهٔ رزرو، قطعی شدن ورود و سیاست بازگرداندن هزینه باید روشن باشند.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
