مسئله‌ای که باید حل می‌کردم
پاداش سکه ممکنه اول به شکل انیمیشن دیده بشه و بعد به هدر برسد. من باید روشن می‌کردم موفقیت درخواست با تغییر فوری موجودی همیشه یک لحظه نیست.
پیاده‌سازی در نسخهٔ فعلی
RewardDistributionService.GiveCoins می‌تواند CoinRewardPresentationRequested را ارسال کنه و یک PendingCoinGrant نگه داره. CompletePendingCoinGrant آن را حذف می‌کنه و فقط بعد سکه را به CurrencyService می‌دهد.
تصمیم و هزینهٔ طراحی
بدون handler، افزایش فوری انجام می‌شود. GiveReward بین Coins و StaticItem مسیر انتخاب می‌کنه؛ پاداش تبلیغاتی هم از RewardSource مشخص می‌شود و قرارداد ارائه‌دهندهٔ تبلیغ جداست.
مرزهای فعلی
pendingها در حافظه‌اند، نه ذخیرهٔ پایدار. اگر برنامه وسط نمایش بسته بشه، وجود نتیجهٔ Success به‌تنهایی اثبات اضافه‌شدن سکه نیست؛ دوام این مرحله یک محدودیت قابل بررسی هست.
سناریوهای بررسی و معنای قرارداد
عنوان پاداش تبلیغاتی ممکنه توجه را به شبکهٔ تبلیغ ببرد، اما مسئلهٔ این مرحله زمان تحویل سکه هست. یک ارائه‌دهنده می‌تواند خبر موفقیت نمایش را بدهد و سرویس توزیع درخواست حرکت سکه را بسازد؛ هیچ‌کدام به تنهایی همان تغییر نهایی موجودی نیستند. شناسهٔ درخواست این فاصله را قابل دنبال کردن می‌کنه. CompletePendingCoinGrant ابتدا درخواست را از مجموعه حذف می‌کنه و سپس افزودن سکه را انجام می‌دهد، بنابراین تکرار همان شناسه مسیر عادی دریافت دوباره نیست. CancelPendingCoinGrant نیز حذف درخواست هست و نباید با تحویل موفق پاداش اشتباه بشه.
سخت‌ترین سناریو بسته شدن برنامه هنگام پرواز سکه‌هاست. درخواست معوق در Dictionary حافظه قرار داره و قرارداد فعلی آن را برای اجرای بعدی ذخیره نمی‌کنه. از طرف دیگر، بعضی سرویس‌های دریافت می‌توانند نتیجهٔ موفق را ثبت کرده باشند. این ترکیب نیاز به تصمیم صریح دربارهٔ ثبت پایدار، جبران یا زمان تأیید داره؛ در این یادداشت اجرای یکی از این راهکارها را ادعا نمی‌کنم. وجود مسیر فوری وقتی هیچ ارائه‌دهنده‌ای نمایش را قبول نمی‌کنه، رفتار دیگری هست که باید جدا بررسی بشه. مرز اصلی برای من این هست که جذابیت نمایش نباید تعریف حسابداری را مبهم کنه و رویداد درخواست با رویداد تحویل نهایی یکی شمرده نشود.
تمایز Coins و StaticItem نشان می‌دهد همهٔ پاداش‌ها به حرکت سکه نیاز ندارند. درخواست مالکیت یک آیتم مسیر دیگری داره و درستی شناسه و دستهٔ آن اهمیت پیدا می‌کنه. یک نمایش عمومی پاداش باید نتیجهٔ همین قرارداد را توضیح بدهد و از روی تصویر جایزه نوع تحویل را حدس نزند. این جداسازی برای افزودن پاداش تازه مفید هست، ولی اعتبار هر تعریف همچنان باید بررسی بشه.
چیزی که از این مرحله یاد گرفتم
برای من، جلوهٔ سکه نباید حسابداری را مبهم کنه. شناسهٔ درخواست اجازه می‌دهد پایان نمایش یک بار به grant وصل بشه، ولی مسئلهٔ بازیابی قطع برنامه را باید جدا و صریح حل کرد.
مثال عملی قرارداد تبلیغ پاداشی
اگر بخواهی قرارداد تبلیغ پاداشی را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. در مثال آموزشی درخواست تبلیغ باز می‌شود، ولی بازیکن پیش از پایان آن برمی‌گردد. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
اعطای جایزه هنگام باز شدن تبلیغ، دریافت واقعی نتیجه را با شروع نمایش اشتباه می‌گیرد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. وضعیت تبلیغ و سیاست پاداش باید از نمایش دکمه مستقل باشند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
لغو، خطا و نتیجهٔ موفق را جدا بررسی کن و جایزه را برای یک نتیجه دوباره نده. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | در مثال آموزشی درخواست تبلیغ باز می‌شود، ولی بازیکن پیش از پایان آن برمی‌گردد. |
| ریسک اصلی | اعطای جایزه هنگام باز شدن تبلیغ، دریافت واقعی نتیجه را با شروع نمایش اشتباه می‌گیرد. |
| روش بررسی | لغو، خطا و نتیجهٔ موفق را جدا بررسی کن و جایزه را برای یک نتیجه دوباره نده. |
| مرز نتیجه‌گیری | وضعیت تبلیغ و سیاست پاداش باید از نمایش دکمه مستقل باشند. |
پرسش‌های کاربردی دربارهٔ قرارداد تبلیغ پاداشی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: در مثال آموزشی درخواست تبلیغ باز می‌شود، ولی بازیکن پیش از پایان آن برمی‌گردد. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. لغو، خطا و نتیجهٔ موفق را جدا بررسی کن و جایزه را برای یک نتیجه دوباره نده. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. وضعیت تبلیغ و سیاست پاداش باید از نمایش دکمه مستقل باشند.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
