دستاورد از آمار تا دریافت جایزه

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

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

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

AchievementService.GetProgress تعریف را می‌یابد و CalculateCurrentValue را روی معیار آمار اجرا می‌کنه. TryClaim وضعیت معتبر، کامل و دریافت‌نشده را کنترل می‌کنه و پس از grant موفق شناسه را ذخیره می‌کنه.

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

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

مرزهای فعلی

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

سناریوهای بررسی و معنای قرارداد

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

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

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

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

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

مثال عملی دستاورد بازی

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

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

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

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

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

پرسش‌های کاربردی دربارهٔ دستاورد بازی

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

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

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

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