از خود کارت شروع کردم
اولین چیزی که برای دلو ساختم، خودِ حکم یا جوکر نبود؛ پایه‌ای بود که بعداً بتوانم چند بازی کارت را روی آن سوار کنم. از همان اول نمی‌خواستم برای هر بازی دوباره کارت، دسته، دست بازیکن و نوبت‌ها را بنویسم. این بخش‌ها شبیه هم‌اند، حتی وقتی قوانین بازی‌ها خیلی فرق دارن. برای همین کار را از خود کارت شروع کردم: هر کارت باید هویت، خال و ارزش مشخص داشته باشد. عکس کارت فقط راه نمایش آن هست. با این نگاه، حتی کارتی که هنوز تصویر نداره هم می‌تواند در منطق بازی حضور داشته باشد.
دسته و دست، بدون قانون اضافه
بعد از کارت، سراغ دسته و پخش‌کردن رفتم. به‌جای اینکه همه‌جا فرض کنم بازی حتماً یک دستهٔ ثابت داره، تعریف دسته را جدا گذاشتم. سیستم می‌تواند کارت‌ها را نگه داره، بُر بزند، کارت بکشد و دوباره آماده بشه. دست بازیکن هم مسئول کارت‌هایی هست که داره، نه قوانین تمام بازی. این تفکیک شاید از بیرون دیده نشود، اما برای ادامهٔ پروژه خیلی مهم بود. وقتی یک قانون عوض می‌شود، باید بتوانم همان قسمت را تغییر بدهم و مجبور نباشم پخش کارت یا ظاهر دست را از اول بسازم.
هسته چه چیزهایی را نباید بداند؟
جایی که پروژه جان گرفت، اضافه‌شدن بازیکن‌ها، نوبت‌ها و میز بود. دیگر فقط مجموعه‌ای از کارت‌ها نداشتم؛ می‌شد کارت پخش کرد، نوبت را جلو برد و کارت‌های روی میز را دنبال کرد. سخت‌ترین تصمیم این بود که چه چیزهایی را وارد هسته نکنم. مثلاً هسته لازم نیست بداند در حکم چه کسی دست را می‌برد. این تصمیم باید در بخش مخصوص حکم گرفته بشه. همان‌طور که قوانین جوکر نباید به خاطر استفاده از همان کارت‌ها، شبیه حکم بشن. پایهٔ مشترک جریان را نگه می‌دارد و هر بازی معنی حرکت‌ها و نتیجه را مشخص می‌کنه.
پایه‌ای که باید در بازی جواب می‌داد
برای این پایه، بررسی‌هایی برای دسته، نوبت، دست و جریان کامل بازی گذاشتم. بعد نوبت حکم رسید تا ببینم این تقسیم مسئولیت در یک بازی واقعی هم به درد می‌خورد یا فقط روی کاغذ مرتب هست. بعدها جوکر هم از همین پایه استفاده کرد؛ پیاده‌سازی پاسور را هم‌تیمی من نوشت. دوست دارم این سهم‌ها در روایت پروژه روشن بماند، چون دلو نتیجهٔ کنار هم آمدن همین کارهاست. برای بازیکن، خروجی قرار هست یک مجموعهٔ هماهنگ باشد؛ برای من، این هسته راهی شد تا هر بازی تازه را با تمرکز روی قوانین خودش بسازم. داستان بخش‌های بعدی را در صفحهٔ دلو دنبال کن.
مثال عملی هستهٔ مشترک بازی کارتی
یک روش کاربردی برای بررسی هستهٔ مشترک بازی کارتی این است که به جای چند تغییر هم‌زمان، تنها یک مسیر کوتاه بسازی. حکم و جوکر یک نمایش کارت مشترک دارند، اما اعتبار حرکت و شرط پایان جدا تعریف می‌شوند. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازه‌ای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمی‌شود.
خطای رایج و علت آن
کپی کامل صحنه برای هر بازی، اصلاح یک مشکل عمومی را به چند تغییر مستقل تبدیل می‌کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. اشتراک مناسب معمولاً در هویت کارت، دست و نمایش است و مرز قانون باید روشن بماند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
یک تغییر در نمایش کارت باید در همهٔ حالت‌ها بررسی شود، بدون تغییر نتیجهٔ قوانین. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | حکم و جوکر یک نمایش کارت مشترک دارند، اما اعتبار حرکت و شرط پایان جدا تعریف می‌شوند. |
| ریسک اصلی | کپی کامل صحنه برای هر بازی، اصلاح یک مشکل عمومی را به چند تغییر مستقل تبدیل می‌کند. |
| روش بررسی | یک تغییر در نمایش کارت باید در همهٔ حالت‌ها بررسی شود، بدون تغییر نتیجهٔ قوانین. |
| مرز نتیجه‌گیری | اشتراک مناسب معمولاً در هویت کارت، دست و نمایش است و مرز قانون باید روشن بماند. |
پرسش‌های کاربردی دربارهٔ هستهٔ مشترک بازی کارتی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: حکم و جوکر یک نمایش کارت مشترک دارند، اما اعتبار حرکت و شرط پایان جدا تعریف می‌شوند. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. یک تغییر در نمایش کارت باید در همهٔ حالت‌ها بررسی شود، بدون تغییر نتیجهٔ قوانین. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. اشتراک مناسب معمولاً در هویت کارت، دست و نمایش است و مرز قانون باید روشن بماند.
برای ادامهٔ همین موضوع، قانون هر بازی کجا زندگی می‌کند؟ و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
