مسئلهای که باید حل میکردم
وقتی یک دور چهارکارتی تمام میشود، هنوز یک دست حکم تمام نشده. من باید تعداد دورهای بردهشدهٔ تیم را از امتیاز دستها در مسابقه جدا نگه میداشتم.
پیادهسازی در نسخهٔ فعلی
HokmHandTrickScoringService نتیجهٔ دور را به وضعیت دست اعمال میکنه. HokmMatchScoringService.ApplyHandEnded نتیجهٔ پایان دست را میگیرد و رسیدن به هدف مسابقه را بررسی میکنه.
تصمیم و هزینهٔ طراحی
پایان دست یک رویداد مشخص داره و میتواند نتیجهٔ کوت را هم دریافت کنه. این جدایی کمک میکنه صفحهٔ امتیاز دو عدد با معنای متفاوت را اشتباهی جای هم نگذارد.
مرزهای فعلی
سرویس مسابقه ورودی تهی، شروعنشدن مسابقه و پایان قبلی را رد میکنه. این کنترلها ادعای تضمین تراکنش شبکه یا ذخیرهٔ سروری نیستند؛ مدل فعلی محلی هست.
پایان دست و ثبت امتیاز مسابقه
یک سناریوی رایج در طراحی HUD این هست که تیم یک دور میبرد و عدد کنار نامش بالا میرود؛ اما آن عدد ممکنه امتیاز دورهای دست باشد، نه امتیاز مسابقه. ApplyTrickWinner ابتدا AddTrickPoint را در HokmHandState اجرا میکنه و TrickScoreChanged را با شمارش دو تیم منتشر میکنه. اگر تیم به HandTargetTricks رسیده باشد، MarkHandEnded و HandEnded نیز رخ میدهند. این ترتیب روشن میکنه پایان دست نتیجهٔ عبور از یک آستانه هست، نه نتیجهٔ هر دور برنده. رابط باید این دو نوع عدد را با قرارداد درست دریافت کنه.
ApplyHandEnded در سرویس مسابقه دو مسیر عمومی داره. مسیر دارای hakemTeamId از HokmKotRuleResolver نتیجهٔ کوت را میگیرد؛ مسیر بدون آن یک نتیجهٔ عادی میسازد. سپس WithWinType اطلاعات مؤثر پایان دست را آماده میکنه و AddHandPoints مقدار MatchPointsToAdd را به تیم برنده میافزاید. این تفاوت برای اتصال سرویسها مهم هست: اگر فراخواننده برای سناریوی کوت overload ساده را انتخاب کنه، نمیتوان انتظار داشت سرویس از اطلاعاتی که دریافت نکرده تیم حاکم را حدس بزند. انتخاب امضای متد بخشی از صحت جریان امتیازدهی هست.
هر دو سرویس وضعیت شروع و پایان را بررسی میکنند، ولی این را نباید تضمین عمومی جلوگیری از همهٔ ثبتهای تکراری دانست. تا وقتی مسابقه پایان نیافته، سرویس مسابقه فهرستی از شناسهٔ دستهای قبلاً امتیازگرفته نداره. پس هماهنگکننده باید پایان هر دست را در مسیر مشخص و کنترلشده اعمال کنه. رخداد MatchScoreChanged پیش از بررسی رسیدن به MatchTargetHands منتشر میشود و در صورت رسیدن، MatchEnded هم میآید. شنوندهها باید تغییر عدد را از پایان چرخه تشخیص دهند؛ شنیدن یک افزایش امتیاز الزاماً مجوز نمایش پایان کل مسابقه نیست.
چیزی که از این مرحله یاد گرفتم
برای من، امتیاز فقط یک متغیر عددی نبود. هر عدد به یک چرخه تعلق داشت و هر تغییر باید روشن کنه از کارت، دور، دست یا کل مسابقه حرف میزنیم.
مثال عملی امتیازدهی حکم
یک روش کاربردی برای بررسی امتیازدهی حکم این است که به جای چند تغییر همزمان، تنها یک مسیر کوتاه بسازی. یک تیم چند دور را میبرد و سپس امتیاز دست نهایی به جدول مسابقه اضافه میشود. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازهای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمیشود.
خطای رایج و علت آن
ثبت نتیجه در پایان هر انیمیشن ممکن است امتیاز یک دست را چند بار افزایش دهد. این خطا معمولاً وقتی پنهان میماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. بازنشانی دست تازه نباید امتیاز کل مسابقه را پاک کند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
امتیاز دور را از امتیاز دست جدا کن و ثبت نتیجهٔ دست را تنها یک بار بپذیر. اجرای یکباره برای نتیجهگیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار میآید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | یک تیم چند دور را میبرد و سپس امتیاز دست نهایی به جدول مسابقه اضافه میشود. |
| ریسک اصلی | ثبت نتیجه در پایان هر انیمیشن ممکن است امتیاز یک دست را چند بار افزایش دهد. |
| روش بررسی | امتیاز دور را از امتیاز دست جدا کن و ثبت نتیجهٔ دست را تنها یک بار بپذیر. |
| مرز نتیجهگیری | بازنشانی دست تازه نباید امتیاز کل مسابقه را پاک کند. |
پرسشهای کاربردی دربارهٔ امتیازدهی حکم
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: یک تیم چند دور را میبرد و سپس امتیاز دست نهایی به جدول مسابقه اضافه میشود. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیادهسازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، میتوان حالتهای بیشتری اضافه کرد. ساخت همهٔ حالتها از ابتدا، فهم علت خطا را سختتر میکند.
چه زمانی میتوانم بگویم این بخش درست کار میکند؟
زمانی که رفتار در موقعیت تعریفشده با قرارداد سازگار باشد و محدودیتهای آن روشن بمانند. امتیاز دور را از امتیاز دست جدا کن و ثبت نتیجهٔ دست را تنها یک بار بپذیر. موفقیت در این آزمون دربارهٔ همان سناریو شاهد میدهد؛ از آن نمیتوان بدون بررسی دربارهٔ همهٔ دستگاهها، همهٔ قوانین محلی یا همهٔ حجمهای داده نتیجه گرفت. بازنشانی دست تازه نباید امتیاز کل مسابقه را پاک کند.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژهها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.




