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