اشکال‌زدایی بازی‌های تولیدشده با AI

پیش از درخواست اصلاح، شکست را طبقه‌بندی کنید

اولین مرحله شکست‌خورده را مشخص کنید: کشف پروژه، import، parsing یا compilation، شروع صحنه، ورودی بازیکن، وضعیت گیم‌پلی، export یا اجرای target. نشانه‌های بعدی ممکن است پیامد همان شکست اول باشند. نسخه موتور، revision پروژه، target و بازتولید دقیق را کنار هم نگه دارید.

برای نمونه، صحنه‌ای که هرگز شروع نمی‌شود نمی‌تواند نشان دهد دکمه restart کار می‌کند یا نه. مرورگری که package بازی را نمی‌گیرد نمی‌تواند controller را آزمایش کند. پیش از تغییر کد خطا را به مرز درست هدایت کنید؛ این کار از انباشتن patchهای نامرتبط در حلقه تعمیر، درحالی‌که پیش‌نیاز اصلی خراب است، جلوگیری می‌کند.

اولین خطای معنادار موتور را ثبت کنید

در Godot از پنل debugger و خروجی runtime مربوط استفاده کنید. در Unity خطاهای compilation و runtime را جدا بررسی کنید و پیش از تفسیر نتیجه play صبر کنید editor آماده شود. stack یا مکانی را نگه دارید که script شکست‌خورده و عملیات محرک را مشخص می‌کند.

بخش متمرکزی از log را همراه زمینه صحنه یا object مرتبط به agent بدهید. از log عظیم و تفکیک‌نشده که خطای اول را پنهان می‌کند دوری کنید، اما رکورد کامل را محلی نگه دارید. credential و داده شخصی را redacted کنید. گزارش مفید می‌گوید بازیکن چه کرد، چه باید رخ دهد و موتور واقعاً چه گزارشی داد.

بازتولید را بدون تغییر نیازمندی کوچک کنید

از وضعیت پروژه قابل‌بازگشت شروع و کوچک‌ترین صحنه یا عملی را جدا کنید که هنوز عیب را نشان می‌دهد. controller واقعی، قاعده collision یا مرز save درگیر مسئله را نگه دارید. حذف کامل سامانه شکست‌خورده ممکن است اجرای پاکی بسازد و درعین‌حال رفتاری را که باید اصلاح می‌کردید از بین ببرد.

brief زیر قالب اصلی تشخیص است. آن را با جزئیات مشاهده‌شده پر کنید و از مدل نخواهید علت را فرض کند. یک توضیح پیشنهادی و تغییر محدود بخواهید. پس از کامل‌شدن آزمون، مسیر کامل بازیکن را دوباره وصل کنید تا تعمیر محلی انتقال خراب صحنه را پنهان نکند.

Project revision: <record actual revision>
Engine and target: <record actual environment>
Steps: launch -> start round -> perform the failing action
Expected state: <specific result>
Observed state: <specific result>
First engine error: <relevant error and location>
Inspect the referenced scene and script before editing.
Propose one cause, make a scoped fix, then repeat these steps.
Preserve the required behavior and report any remaining failure.

صفحه خالی را لایه‌به‌لایه بررسی کنید

ابتدا مشخص کنید موتور شروع شده و صحنه موردنظر بارگذاری شده است یا نه. سپس انتخاب دوربین، ابعاد viewport، دیده‌شدن object، موقعیت‌ها و هر overlay پوشاننده صحنه را بررسی کنید. وضعیت موتور و capture واقعی را با هم به‌کار ببرید: تصویر به‌تنهایی نشان نمی‌دهد صحنه متوقف، خارج از دوربین یا خالی است.

ورودی را اعمال کنید و ببینید حتی وقتی چیزی ظاهر نمی‌شود وضعیت تغییر می‌کند یا نه. اگر موقعیت تغییر می‌کند اما تصویر نه، روی rendering یا ارجاع‌های صحنه تمرکز کنید. اگر هیچ‌کدام تغییر نمی‌کنند، پیش از تنظیم artwork شروع و ورودی را بررسی کنید. هر فرضیه را به یک مشاهده وصل کنید تا agent بی‌دلیل هر دو سامانه را بازنویسی نکند.

ورودی را در انتقال گیم‌پلی دنبال کنید

action را از focus و mapping تا handler و سپس وضعیت موردتغییر دنبال کنید. پیش از سرزنش محاسبه حرکت، وضعیت pause و interception رابط را بررسی کنید. شکست restart ممکن است handler مفقود، ارجاع قدیمی صحنه یا وضعیتی باشد که هرگز reset نشده است.

پس از تعمیر، action را از چند وضعیت مرتبط آزمایش کنید: شروع اول، پس از برد و در صورت ارتباط پس از باخت. handlerهای تکراری یا objectهای قدیمی را که فقط بعد از roundهای متعدد ظاهر می‌شوند بررسی کنید. miniflow کوچک و کامل می‌تواند این عیب‌های چرخه عمر را بهتر از آزمودن مکرر دکمه در انزوا مشخص کند.

بارگذاری مرورگر را از منطق بازی جدا کنید

برای export وب Godot، پیش از ویرایش کد گیم‌پلی پنل‌های network و console مرورگر را بررسی کنید. بارگذاری HTML، JavaScript، WebAssembly و package بازی را از مکان موردنظر تأیید کنید. تنظیمات میزبانی را با مستندات رسمی export وب، از جمله نیازمندی‌های thread انتخاب‌شده، مقایسه کنید.

نام فایل‌های همراه export را سازگار نگه دارید و artifact را آزمایش کنید، نه ترکیبی از فایل‌های قدیمی و جدید. اگر پروژه اشتباه ظاهر می‌شود، cache service-worker را در مرورگر آزمون بررسی کنید. سپس ورودی را اجرا و محتوای متحرک را تأیید کنید. canvas غیرخالی فقط کنترل اولیه rendering است، نه اثبات کارکرد حلقه بازی.

شکست‌های ویژه export را روی target بررسی کنید

وقتی editor کار می‌کند اما build توزیع‌شده شکست می‌خورد، انتخاب صحنه شروع، منابع واردشده، configuration و logهای target را مقایسه کنید. hash دقیق artifact را نگه دارید تا export دوباره رکورد بازتولید را بی‌اعتبار نکند. پیش از اتکا به saveهای موجود یا cacheهای editor، با وضعیت شروع پاک آزمایش کنید.

برای حل فایل بسته‌بندی‌شده مفقود، مکانیک اصلی را تغییر ندهید. مرز بسته‌بندی را اصلاح کنید و همان مسیر پذیرش را در build target replay کنید. برای artifact دسکتاپ از سیستم‌عامل واقعی و برای artifact مرورگر از مرورگر و میزبانی موردنظر استفاده کنید. صرف cross-export رفتار target را ثابت نمی‌کند.

تعمیر را با نتیجه قبل و بعد ببندید

بازتولید شکست‌خورده، diff محدود و عمل تکرارشده‌ای را که اکنون وضعیت موردنظر را می‌سازد نگه دارید. در مرزی که عیب را ایجاد کرد کنترل رگرسیون اضافه و حلقه اطراف بازی را دوباره اجرا کنید. اصلاحات دستی و درخواست‌های مصرف‌شده در تعمیرهای ناموفق را ثبت کنید.

نمونه‌های اینجا رویه تشخیصی‌اند، نه پرونده منتشرشده شکست و اصلاح. از آن‌ها برای ساخت گزارش مشخص پروژه خود استفاده کنید. وقتی همان نشانه پس از پیشنهادهای تکراری باقی می‌ماند، حلقه خودکار را متوقف و مشاهده مفقود را جمع کنید، نه اینکه بدون شواهد جدید به بازنویسی گسترده بروید.

پرسش‌های پرتکرار