مسئله‌ای که باید حل می‌کردم
انتخاب حاکم باید قابل مشاهده باشد، ولی کارت‌های موقت آن نباید با دست نهایی قاطی بشن. من این مرحله را پیش از پخش اصلی به عنوان یک تصمیم مستقل نگه داشتم.
پیاده‌سازی در نسخهٔ فعلی
HokmHakemSelectionService.SelectHakem کارت‌ها را به ترتیب صندلی‌ها آشکار می‌کنه و اولین آس حاکم را مشخص می‌کنه. کارت‌های آشکارشده در HokmRevealedHakemCard برای نمایش نگه داشته می‌شوند.
تصمیم و هزینهٔ طراحی
خروجی انتخاب، صندلی حاکم و اطلاعات مرحله را به لایهٔ جریان می‌دهد. این امکان می‌دهد نمایش آس از پیدا کردن آن جدا باشد و انیمیشن خودش قانون انتخاب را ننویسد.
مرزهای فعلی
سرویس شکستِ پیدا نشدن آس را هم گزارش می‌کنه. آن مسیر برای دادهٔ نامعتبر مهم هست؛ داشتن یک DeckDefinition با نام استاندارد به‌تنهایی اثبات وجود آس مناسب نیست.
نمایش آس بدون نگه داشتن دست موقت
SelectHakem ابتدا دسته را Reset می‌کنه و در صورت فعال بودن shuffleBeforeSelection آن را بر می‌زند. سپس از startingSeatId پیش می‌رود و هر کارت را با revealIndex، صندلی، تیم و نمونهٔ کارت ثبت می‌کنه. این دادهٔ مرحله‌ای برای نمایش روند انتخاب مهم هست: رابط می‌تواند ترتیب واقعی آشکار شدن کارت‌ها را نشان دهد، نه اینکه صرفاً نام حاکم را بعد از یک حرکت نمایشی اعلام کنه. البته زمان‌بندی نمایش در این سرویس نیست؛ فراخوانی منطقی تمام انتخاب را انجام می‌دهد و لایهٔ ارائه تصمیم می‌گیرد نتیجه چگونه دیده بشه.
وقتی اولین Ace پیدا می‌شود، سرویس از temporaryRevealedCards یک فهرست کپی می‌سازد و مجموعهٔ داخلی را خالی می‌کنه. همان snapshot هم در HakemSelected و هم در نتیجهٔ Selected قرار می‌گیرد. به این ترتیب پاک‌سازی بافر داخلی، دادهٔ نمایشی نتیجه را از بین نمی‌برد. این کپی عمیق کارت‌ها نیست؛ نمونه‌های CardInstance همچنان همان ارجاع‌های برداشت‌شده‌اند. برای تفسیر گزارش باید میان استقلال فهرست و استقلال کامل تمام اشیای داخل آن تفاوت گذاشت. این دقت از نسبت دادن تضمین ذخیره‌سازی به یک کپی ساده جلوگیری می‌کنه.
بعد از موفقیت، دسته در نقطهٔ پس از برداشت آس باقی می‌ماند؛ این متد در انتها آن را برای تقسیم اصلی بازنشانی نمی‌کنه. پس مسیر بازی باید مرحلهٔ انتخاب و مرحلهٔ تقسیم را آگاهانه به هم وصل کنه و کارت‌های موقت را دست نهایی فرض نکند. در حالت شکست نیز FailAndClear snapshot را حفظ می‌کنه تا بتوان نبودن آس یا دادهٔ نامعتبر را توضیح داد. حتی نام استاندارد برای دارایی دسته کافی نیست: اگر محتوای واقعی آس نداشته باشد، حلقه می‌تواند تا پایان دسته پیش برود و نتیجهٔ ناموفق برگرداند.
چیزی که از این مرحله یاد گرفتم
برای من، یک مرحلهٔ کوچک هم نیاز به قرارداد واضح داشت. نتیجهٔ منطقی باید قبل از نمایش معتبر باشد و نمایش فقط همان روند واقعی را برای بازیکن قابل دیدن کنه.
مثال عملی انتخاب حاکم حکم
برای فهم عملی انتخاب حاکم حکم، یک مثال آموزشی را قدم‌به‌قدم دنبال کنیم. در مثال آموزشی کارت‌ها یکی‌یکی آشکار می‌شوند تا آس و حاکم مشخص شود. پیش از اجرا، وضعیت آغاز را روی کاغذ بنویس؛ مشخص کن چه چیزی می‌تواند تغییر کند و چه چیزی باید ثابت بماند. بعد فقط همین مسیر را اجرا کن. این مثال گزارشی از آمار کاربران یا قابلیت تازهٔ منتشرشدهٔ دلو نیست؛ تمرینی برای روشن کردن تصمیم طراحی همین مطلب است.
خطای رایج و علت آن
اگر انیمیشن کند باشد و ورودی ادامه داشته باشد، فرایند تعیین حاکم ممکن است دوباره اجرا شود. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. این روند مربوط به قانون انتخاب‌شدهٔ پروژه است؛ گونه‌های محلی ممکن است متفاوت باشند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
پس از یافتن آس، توقف جریان و ثبت تنها یک حاکم را بررسی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | در مثال آموزشی کارت‌ها یکی‌یکی آشکار می‌شوند تا آس و حاکم مشخص شود. |
| ریسک اصلی | اگر انیمیشن کند باشد و ورودی ادامه داشته باشد، فرایند تعیین حاکم ممکن است دوباره اجرا شود. |
| روش بررسی | پس از یافتن آس، توقف جریان و ثبت تنها یک حاکم را بررسی کن. |
| مرز نتیجه‌گیری | این روند مربوط به قانون انتخاب‌شدهٔ پروژه است؛ گونه‌های محلی ممکن است متفاوت باشند. |
پرسش‌های کاربردی دربارهٔ انتخاب حاکم حکم
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: در مثال آموزشی کارت‌ها یکی‌یکی آشکار می‌شوند تا آس و حاکم مشخص شود. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. پس از یافتن آس، توقف جریان و ثبت تنها یک حاکم را بررسی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. این روند مربوط به قانون انتخاب‌شدهٔ پروژه است؛ گونه‌های محلی ممکن است متفاوت باشند.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
