اول رفتار خراب را بنویس
دیباگ با مشاهدهٔ قابل تکرار شروع می‌شود. عمل‌ها، نتیجهٔ مورد انتظار و نتیجهٔ واقعی را پیش از تغییر کد ثبت کن. یونیتی دیباگ کد مدیریت‌شده را پشتیبانی می‌کنه، اما نقطهٔ توقف وقتی مفیدتر هست که سؤال آن محل را بدانید.
اگر امتیاز به جای یک بار، دوبار بالا می‌رود، فعلاً همهٔ اسکریپت‌ها را تغییر نده. بنویس از کدوم صفحه شروع کردی، چه چیزی را چند بار لمس کردی و انتظار عدد چند بود. سپس مسیر را دوباره برا تا معلوم بشه اتفاق تکرارپذیر هست یا به شرایط دیگری وابسته هست. تفاوت «گاهی خراب هست» با «بعد از بازگشت به منو هر انتخاب دو امتیاز می‌دهد» بسیار زیاد هست. جملهٔ دوم محل بررسی را محدود می‌کنه و به هم‌تیمی هم امکان می‌دهد مسئله را بدون توضیح طولانی تو ببیند.
یک توقف در جای درست
یک شکست امتیاز را به ترتیب کمینه تبدیل کن: بازی را باز کن، حرکت مشخص بزنید و عدد را ببین. عدد مورد انتظار را جدا بنویس. جایی که ورودی پذیرفته‌شده نتیجه می‌شود توقف یا تشخیص موقت بذار. مقدار را دنبال کن، نه حدس از صفحهٔ نهایی. پس از روشن شدن علت و اصلاح، شلوغی تشخیصی موقت را بردارید.
در محل اعمال امتیاز توقف بگذار و بپرس چرا این کد دو بار اجرا شده. مقدار قبلی، مقدار جدید و مسیر فراخوانی را ببین؛ شاید قانون اشتباه هست یا شاید یک listener دوبار وصل شده. اضافه کردن پیام در Console هم برای سؤال محدود مفید هست، اما صدها پیام بدون نام رویداد و زمینه خواندن را سخت می‌کنند. از پیام به عنوان مشاهده استفاده کن، نه درمان؛ چاپ اینکه امتیاز عوض شد، دلیل تغییر را اصلاح نمی‌کنه. مستند دیباگ مدیریت‌شدهٔ یونیتی دربارهٔ اتصال ابزار و breakpoint راهنمای دقیق‌تر ارائه می‌دهد.
اصلاح را با همان مسیر بررسی کن
پس از اصلاح، همان مسیر اولیه را تکرار کن و یک مسیر نزدیک را هم ببین: ورود مستقیم، بازگشت از منو و شروع دوباره. اگر فقط مورد گزارش‌شده درست شد ولی مسیر عادی خراب شد، اصلاح هنوز کامل نیست. یادداشت کوتاهی از علت نگه دار تا دفعهٔ بعد به جای حدس، از تجربه استفاده کنی. هر خطای عجیب به بازنویسی بزرگ نیاز نداره. گاهی حذف یک اتصال تکراری کافی هست؛ اندازهٔ اصلاح باید با علت پیدا‌شده هماهنگ باشد و تست آن باید رفتار بازیکن را بررسی کنه، نه فقط ناپدید شدن یک پیام قرمز.
مطالعهٔ بیشتر: Unity: Managed-code debugging
برای یک مثال مرتبط، حکم دلو؛ وقتی حریف باید تصمیم بگیرد را هم بخون.
مثال عملی دیباگ بازی یونیتی
یک روش کاربردی برای بررسی دیباگ بازی یونیتی این است که به جای چند تغییر هم‌زمان، تنها یک مسیر کوتاه بسازی. یک خطا را با ورودی مشخص و مراحل کوتاه دوباره اجرا کن. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازه‌ای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمی‌شود.
خطای رایج و علت آن
تغییر هم‌زمان چند بخش ممکن است خطا را پنهان کند، بدون اینکه علت پیدا شود. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. لاگ مفید باید به سؤال روشن جواب بدهد و اطلاعات خصوصی را بی‌دلیل ثبت نکند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
یک فرضیه را در هر بار آزمایش کن و وضعیت قبل از خطا را ثبت کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | یک خطا را با ورودی مشخص و مراحل کوتاه دوباره اجرا کن. |
| ریسک اصلی | تغییر هم‌زمان چند بخش ممکن است خطا را پنهان کند، بدون اینکه علت پیدا شود. |
| روش بررسی | یک فرضیه را در هر بار آزمایش کن و وضعیت قبل از خطا را ثبت کن. |
| مرز نتیجه‌گیری | لاگ مفید باید به سؤال روشن جواب بدهد و اطلاعات خصوصی را بی‌دلیل ثبت نکند. |
پرسش‌های کاربردی دربارهٔ دیباگ بازی یونیتی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: یک خطا را با ورودی مشخص و مراحل کوتاه دوباره اجرا کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. یک فرضیه را در هر بار آزمایش کن و وضعیت قبل از خطا را ثبت کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. لاگ مفید باید به سؤال روشن جواب بدهد و اطلاعات خصوصی را بی‌دلیل ثبت نکند.
برای ادامهٔ همین موضوع، نمونهٔ اولیهٔ بازی؛ چه چیزی را باید زود امتحان کنیم؟ را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
