مسئله‌ای که باید حل می‌کردم
چهار کارت روی صفحه کافی نیست تا حکم درست کار کنه. باید بدانم هر صندلی در کدوم تیم هست و شریک یا نفر بعد آن کیست، بدون اینکه منطق به مختصات تصویر وابسته بشه.
پیاده‌سازی در نسخهٔ فعلی
HokmSeatResolver.GetTeam از HokmGameConfig می‌خواند. GetPartnerSeat هم‌تیمی دیگر را پیدا می‌کنه و ArePartners یک صندلی را شریک خودش حساب نمی‌کنه.
تصمیم و هزینهٔ طراحی
BuildTurnOrderFrom ترتیب را از یک صندلی می‌سازد و اندیس‌ها دور می‌زنند. قرارداد جهت حکم را صریح گذاشتم؛ معنای چرخش آن را نباید صرفاً از علامت اندیس در TurnManager حدس زد.
مرزهای فعلی
پیکربندی ناقص شریک پیدا نمی‌کنه و سرویس خطا می‌دهد. جای آواتار یا مختصات UI در این کلاس بررسی نمی‌شود، بنابراین سیم‌کشی اشتباه صفحه هنوز مسئلهٔ مستقلی هست.
جهت منطقی میز و جابه‌جایی ظاهر
اگر میز برای نمایش روی گوشی بچرخد و بازیکن انسانی همیشه پایین قرار بگیرد، مفهوم هم‌تیمی نباید با جابه‌جایی آواتارها تغییر کنه. GetTeam اطلاعات را از HokmGameConfig می‌خواند و GetPartnerSeat در همان پیکربندی به دنبال صندلی دیگر با TeamId برابر می‌گردد. بنابراین راست و چپ ظاهری مرجع امتیازدهی نیستند. این جداسازی هنگام ساخت بات نیز اهمیت داره: حمایت از هم‌تیمی باید به هویت صندلی وابسته باشد، نه اینکه کدوم کارت در Canvas نزدیک‌تر یا روبه‌روی بازیکن نمایش داده می‌شود.
GetNextSeat در این کلاس برای CounterClockwise اندیس صندلی را زیاد می‌کنه و برای Clockwise آن را کم می‌کنه. این قرارداد را نباید از روی علامت عدد جهت در مدیر نوبت عمومی حدس زد. FromSeatIndex نتیجه را با تعداد چهار صندلی دور می‌زند و اندیس منفی را نیز اصلاح می‌کنه. BuildTurnOrderFrom چهار عضو را با همین مسیر تولید می‌کنه و آغاز را همان صندلی ورودی می‌گذارد. در مرحلهٔ تقسیم یا انتخاب حاکم، دادن فهرست ساخته‌شده به سرویس بعدی کمک می‌کنه ترتیب واقعی از یک تعریف مشخص پیروی کنه.
ArePartners شرط نابرابر بودن دو صندلی را داره، در حالی که GetTeam تنها عضویت تیم را پاسخ می‌دهد. اگر صندلی را با خودش مقایسه کنیم، هم‌تیم بودن در سطح TeamId درست هست، اما شریک بودن در معنای بازی درست نیست. این تفاوت کوچک می‌تواند در انتخاب بات جلوی منطق اشتباه حمایت از خود را بگیرد. با این حال، resolver فقط محدودهٔ شناسهٔ صندلی را بررسی می‌کنه؛ پیکربندی ناقص یا اتصال بصری اشتباه را درمان نمی‌کنه. اگر شریک در داده پیدا نشود، خطا می‌دهد و آن خطا باید به اصلاح داده منجر بشه، نه ساختن شریک فرضی.
چیزی که از این مرحله یاد گرفتم
وقتی ربات یا امتیاز دربارهٔ تیم سؤال می‌پرسد، بهتر هست یک پاسخ مرکزی داشته باشد. این مرز کمک کرد مفهوم شریک از چپ و راستِ ظاهری میز جدا بماند.
مثال عملی صندلی و تیم در حکم
یک روش کاربردی برای بررسی صندلی و تیم در حکم این است که به جای چند تغییر هم‌زمان، تنها یک مسیر کوتاه بسازی. چهار صندلی ثابت را نمایش بده و سپس محل نشستن بازیکن محلی را در رابط بچرخان. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازه‌ای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمی‌شود.
خطای رایج و علت آن
اگر تیم از موقعیت ظاهری استخراج شود، چرخاندن رابط ممکن است هم‌تیمی را تغییر دهد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. شناسهٔ صندلی منطقی از جایگاه بصری روی صفحه جدا است. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
صندلی روبه‌رو باید در همهٔ جهت‌های نمایش همان هم‌تیمی باقی بماند. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | چهار صندلی ثابت را نمایش بده و سپس محل نشستن بازیکن محلی را در رابط بچرخان. |
| ریسک اصلی | اگر تیم از موقعیت ظاهری استخراج شود، چرخاندن رابط ممکن است هم‌تیمی را تغییر دهد. |
| روش بررسی | صندلی روبه‌رو باید در همهٔ جهت‌های نمایش همان هم‌تیمی باقی بماند. |
| مرز نتیجه‌گیری | شناسهٔ صندلی منطقی از جایگاه بصری روی صفحه جدا است. |
پرسش‌های کاربردی دربارهٔ صندلی و تیم در حکم
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: چهار صندلی ثابت را نمایش بده و سپس محل نشستن بازیکن محلی را در رابط بچرخان. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. صندلی روبه‌رو باید در همهٔ جهت‌های نمایش همان هم‌تیمی باقی بماند. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. شناسهٔ صندلی منطقی از جایگاه بصری روی صفحه جدا است.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
