مسئله‌ای که باید حل می‌کردم
برد هفت‌صفر با یک برد عادی یکسان نیست و تیم حاکم هم در تشخیص نوع برد اهمیت داره. من نمی‌خواستم این استثنا در چند نقطهٔ امتیاز و متن رابط تکرار بشه.
پیاده‌سازی در نسخهٔ فعلی
HokmKotRuleResolver.Resolve ابتدا KotEnabled را بررسی می‌کنه. فقط نتیجهٔ هفت‌صفر وارد مسیر کوت می‌شود؛ برد تیم حاکم Kot و برد تیم مقابل HakemKot می‌دهد.
تصمیم و هزینهٔ طراحی
نوع برد در HokmHandWinType و نتیجهٔ مستقل باقی می‌ماند. امتیازهای قابل تنظیم از config می‌آیند و لایهٔ بازخورد می‌تواند نام مناسب نتیجه را نمایش بدهد.
مرزهای فعلی
کوت بودن به یک نتیجهٔ معتبر پایان دست وابسته هست. صرف مشاهدهٔ عدد بزرگ در HUD کافی نیست؛ همچنین خاموش‌بودن گزینهٔ کوت باید نتیجهٔ عادی برگرداند.
همان نتیجهٔ صفر، دو معنای متفاوت
دو دست را تصور کن که در هر دو، تیم بازنده هیچ دوری نبرده هست. اگر برنده تیم حاکم باشد، Resolve نتیجهٔ Kot می‌سازد؛ اگر برنده طرف مقابل حاکم باشد، HakemKot برمی‌گرداند. بنابراین تنها دیدن عدد صفر برای انتخاب عنوان کافی نیست. ورودی hakemTeamId بخش ضروری زمینهٔ تصمیم هست و سرویس آن را در محدودهٔ دو تیم معتبر بررسی می‌کنه. این مدل باعث می‌شود پیام جشن، مقدار امتیاز و ثبت نتیجه بتوانند به یک طبقه‌بندی مشخص تکیه کنن، به جای اینکه هر شنونده از روی اعداد خودش نام نتیجه را حدس بزند.
در نسخهٔ کد، شرطی که متغیرهای teamAWonSevenZero و teamBWonSevenZero را می‌سازد، امتیاز برنده را با config.HandTargetTricks مقایسه می‌کنه. پس نام هفت‌صفر با رفتار پیکربندی‌شده باید دقیق خوانده بشه: کد در آن شرط عدد هفت را ثابت نکرده هست. در تنظیم معمول حکم این آستانه معنای آشنا داره، اما اگر پیکربندی تغییر کنه، بررسی طبقه‌بندی نیز همراه همان آستانه تغییر می‌کنه. این نکته دلیل خوبی برای روشن کردن قرارداد تنظیمات هست؛ نام متغیر یا متن محصول به‌تنهایی تضمین نمی‌کنه تمام ترکیب‌های تنظیمات معنای مورد نظر بازی را حفظ کنن.
KotEnabled پیش از طبقه‌بندی ویژه بررسی می‌شود و در حالت خاموش، NormalHandPoints بازمی‌گردد. همچنین اگر نتیجهٔ دست به آستانهٔ برنده در برابر صفر نرسیده باشد، خروجی عادی هست. KotPoints و HakemKotPoints از پیکربندی می‌آیند و resolver خودش امتیاز وضعیت مسابقه را تغییر نمی‌دهدد. این تقسیم مسئولیت برای تغییر قانون امتیاز مفید هست، اما به فراخواننده نیاز داره تا نتیجه را در سرویس مسابقه درست اعمال کنه. این کلاس نیز تاریخچهٔ دست‌ها را بازسازی نمی‌کنه؛ معتبر بودن رخداد پایان دست را نمی‌توان با دیدن یک نتیجهٔ طبقه‌بندی‌شده جایگزین کرد.
چیزی که از این مرحله یاد گرفتم
برای من، این مثال نشان داد که استثنا را می‌شود به یک قانون کوچک و روشن تبدیل کرد. به این ترتیب تغییر امتیاز کوت مجبور نیست هم‌زمان منطق دست و انیمیشن تبریک را تغییر بدهد.
مثال عملی کوت و حاکم‌کوت
برای فهم عملی کوت و حاکم‌کوت، یک مثال آموزشی را قدم‌به‌قدم دنبال کنیم. نتیجهٔ یک دست بدون برد دور برای تیم مقابل را با نتیجهٔ عادی مقایسه کن. پیش از اجرا، وضعیت آغاز را روی کاغذ بنویس؛ مشخص کن چه چیزی می‌تواند تغییر کند و چه چیزی باید ثابت بماند. بعد فقط همین مسیر را اجرا کن. این مثال گزارشی از آمار کاربران یا قابلیت تازهٔ منتشرشدهٔ دلو نیست؛ تمرینی برای روشن کردن تصمیم طراحی همین مطلب است.
خطای رایج و علت آن
استفاده از امتیاز عادی برای همهٔ حالت‌ها، استثناهای قانون انتخاب‌شده را حذف می‌کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. امتیاز این حالت‌ها را باید با قانون دقیق پروژه توضیح داد، نه یک عدد عمومی برای همهٔ بازی‌ها. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
چند نمونهٔ مرزی از برد معمولی، کوت و حاکم‌کوت را طبق قرارداد همان نسخه ثبت کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | نتیجهٔ یک دست بدون برد دور برای تیم مقابل را با نتیجهٔ عادی مقایسه کن. |
| ریسک اصلی | استفاده از امتیاز عادی برای همهٔ حالت‌ها، استثناهای قانون انتخاب‌شده را حذف می‌کند. |
| روش بررسی | چند نمونهٔ مرزی از برد معمولی، کوت و حاکم‌کوت را طبق قرارداد همان نسخه ثبت کن. |
| مرز نتیجه‌گیری | امتیاز این حالت‌ها را باید با قانون دقیق پروژه توضیح داد، نه یک عدد عمومی برای همهٔ بازی‌ها. |
پرسش‌های کاربردی دربارهٔ کوت و حاکم‌کوت
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: نتیجهٔ یک دست بدون برد دور برای تیم مقابل را با نتیجهٔ عادی مقایسه کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. چند نمونهٔ مرزی از برد معمولی، کوت و حاکم‌کوت را طبق قرارداد همان نسخه ثبت کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. امتیاز این حالت‌ها را باید با قانون دقیق پروژه توضیح داد، نه یک عدد عمومی برای همهٔ بازی‌ها.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
