مسئله‌ای که باید حل می‌کردم
برای جوکر، اسم فایل دسته کافی نبود. باید ترکیب واقعی کارت‌ها مشخص باشد، چون تعداد نسخهٔ هر رتبه مستقیماً روی جفت‌شدن و پایان بازی اثر می‌گذارد.
پیاده‌سازی در نسخهٔ فعلی
JokerGame.ValidateDeck دستهٔ ۳۳ کارتی را می‌خواهد: یک جوکر، چهار نسخه از آس و بی‌بی و شاه، و دو نسخه از رتبه‌های دیگر. هویت suit و rank عادی باید متمایز باشد.
تصمیم و هزینهٔ طراحی
صحنهٔ فعلی Joker_Mixed_33_Deck را استفاده می‌کنه. انتخاب خال‌های دو نسخه در validator انعطاف داره، اما Asset فعلی برای آن‌ها دل و پیک داره.
مرزهای فعلی
وجود فایل‌های قدیمی با نام ۳۳ یا ۴۱ نشان نمی‌دهدد همان‌ها به صحنه وصل‌اند. مسیر reference واقعی و اعتبارسنجی باید با هم دیده بشن؛ عدد نام فایل قرارداد اجرایی نیست.
سناریوهای بررسی و معنای قرارداد
در یک بازی جفت‌سازی، خطای ترکیب دسته مستقیماً به پایان بازی منتقل می‌شود. اگر یک رتبه تعداد نامناسب داشته باشد یا جوکر تکرار بشه، حتی رابط کاملاً سالم نمی‌تواند نتیجهٔ درست ایجاد کنه. اعتبارسنجی دسته پیش از جریان اصلی، این مسئله را در همان مرز داده آشکار می‌کنه. چهار آس، چهار بی‌بی و چهار شاه با رتبه‌های دو نسخه‌ای و یک جوکر جمعاً سی‌وسه کارت می‌سازند. شرط یکتا بودن هویت خال و رتبه نیز جلوی این را می‌گیرد که دو ارجاع به یک کارت معمولی به عنوان دو کارت معتبر پذیرفته بشن. این محدودیت‌ها جزئی از قانون همین نسخه‌اند.
برای بررسی دارایی، هم ترکیب داخلی را می‌خوانم و هم ارجاع واقعی صحنه را دنبال می‌کنم. وجود یک فایل قدیمی با عدد دیگر در نام، دلیل فعال بودن آن نیست. برعکس، نام مناسب هم اگر محتوای نامعتبر داشته باشد چیزی را تضمین نمی‌کنه. آزادی در انتخاب دو خال برای رتبه‌های دو نسخه‌ای نشان می‌دهد قانون روی تعداد و هویت استوار هست، نه رنگ‌آمیزی یک دارایی خاص. این تفکیک می‌تواند تغییر محتوای تصویری را ساده کنه، اما هر ترکیب جدید باید همچنان همان قواعد اعتبارسنجی را بگذراند. از این ساختار دربارهٔ همهٔ گونه‌های محلی جوکر یا قوانین متفاوت آن‌ها نتیجهٔ عمومی نمی‌گیرم.
اشتراک RuntimeDeck به معنای اشتراک همهٔ محدودیت‌ها نیست. حکم و جوکر می‌توانند ظرف دادهٔ مشابه داشته باشند و اعتبارسنجی متفاوت بخواهند. این نمونه به من نشان می‌دهد بازاستفادهٔ سالم در سطح نمایش و هویت کارت اتفاق می‌افتد، در حالی که قانون ترکیب نزدیک همان بازی باقی می‌ماند. افزودن بازی بعدی نیز باید تعریف معتبر خودش را داشته باشد، نه اینکه عدد کارت از یک بازی دیگر کپی بشه.
چیزی که از این مرحله یاد گرفتم
برای من، این مرحله آغاز اثبات انعطاف هسته بود. کارت و دست همان ساختار مشترک ماندند، ولی تعریف دسته دیگر استاندارد حکم نبود و قانون خودش ترکیب معتبر را تعیین کرد.
مثال عملی ترکیب دستهٔ جوکر
اگر بخواهی ترکیب دستهٔ جوکر را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. ۳۲ کارت معمولی و یک جوکر را بشمار و فراوانی رتبه‌ها را جدا ثبت کن. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
نام دارایی دسته تضمین نمی‌کند تعداد کارت و ترکیب رتبه‌های داخل آن درست باشد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. این قرارداد مخصوص گونهٔ جوکر توضیح‌داده‌شده در این پروژه است. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
چهار آس، چهار بی‌بی، چهار شاه، رتبه‌های دو نسخه‌ای و یک جوکر را اعتبارسنجی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | ۳۲ کارت معمولی و یک جوکر را بشمار و فراوانی رتبه‌ها را جدا ثبت کن. |
| ریسک اصلی | نام دارایی دسته تضمین نمی‌کند تعداد کارت و ترکیب رتبه‌های داخل آن درست باشد. |
| روش بررسی | چهار آس، چهار بی‌بی، چهار شاه، رتبه‌های دو نسخه‌ای و یک جوکر را اعتبارسنجی کن. |
| مرز نتیجه‌گیری | این قرارداد مخصوص گونهٔ جوکر توضیح‌داده‌شده در این پروژه است. |
پرسش‌های کاربردی دربارهٔ ترکیب دستهٔ جوکر
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: ۳۲ کارت معمولی و یک جوکر را بشمار و فراوانی رتبه‌ها را جدا ثبت کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. چهار آس، چهار بی‌بی، چهار شاه، رتبه‌های دو نسخه‌ای و یک جوکر را اعتبارسنجی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. این قرارداد مخصوص گونهٔ جوکر توضیح‌داده‌شده در این پروژه است.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
