توسعه بازی Godot با AI

پیش از ویرایش مرز پروژه را تعریف کنید

از پوشه پروژه متعلق به خود و فهرست مکتوب تغییرات مجاز شروع کنید. صحنه‌ها، scriptها، assetها و pluginهای موجود را فهرست کنید تا agent ساختار فعلی را گسترش دهد، نه اینکه پیاده‌سازی دومی بسازد. وضعیت اولیه پروژه را قابل‌بازگشت نگه دارید و binary موتوری را که آن را باز می‌کند ثبت کنید.

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

executable و آرگومان‌های پشتیبانی‌شده را مشخص کنید

مستندات پایدار CLI Godot فرمان‌های زیر را فراهم می‌کند. GODOT_BIN و PROJECT متغیرهای shell انتخاب‌شده برای این نمونه‌اند، نه تنظیمات Godot؛ مسیرهای placeholder را با executable و پروژه موجود خود جایگزین کنید. مسیر پروژه باید project.godot را در خود داشته باشد.

پیش از scriptکردن flagهای بیشتر، خروجی version و help را ثبت کنید. این کار از فرض وجود فرمانی در build نصب‌شده جلوگیری می‌کند که فقط در مستندات آنلاین جاری است. هویت binary را با نتیجه‌های آزمون بعدی نگه دارید و هنگام بررسی شکست ثابت بمانید. این فرمان‌های نمونه از شکل‌های مستند CLI استفاده می‌کنند.

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

import، parsing و play واقعی را جدا کنید

import بدون رابط، مرز پردازش asset را بررسی می‌کند. کنترل parser یک script را می‌سنجد. راه‌اندازی عادی به بازی می‌رسد و می‌تواند سیم‌کشی صحنه و مشکل runtime را آشکار کند. این نتیجه‌ها را در رکورد بازبینی جدا نگه دارید و هر سه را tests passed خلاصه نکنید.

مسیر script نمونه زیر باید از قبل در پروژه شما وجود داشته باشد. کنترل parser عمداً محدود است و collision، ورودی responsive یا persistence درست را ثابت نمی‌کند. پس از ویرایش رفتار تغییرکرده و انتقال بلافاصله قبل و بعد آن را دوباره اجرا کنید. این کار اغلب از ساخت کنترل‌های جداگانه بسیار برای helperهای تولیدشده اطلاعاتی‌تر است.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

ابزارهای CLI یا MCP را آگاهانه انتخاب کنید

agent دارای دسترسی shell می‌تواند دنباله CLI بازبینی‌شده را اجرا کند. Godot MCP رابط ابزار دیگری است که پروژه نگه می‌دارد و setup آن در صفحه ویژه خودش پوشش داده شده است. در هر دو حالت، اپراتور باید پیش از تأیید نوشتن یا اجرای فرایند بداند کدام پروژه هدف است.

تنظیمات ارائه‌دهنده مدل agent را از ابزار موتور جدا کنید. اتصال محلی سالم در دسترس‌بودن مدل خاص یا پشتیبانی agent از همه قابلیت‌های gateway سازگار را ثابت نمی‌کند. ابتدا کوچک‌ترین read مجاز را برقرار، بعد تغییر صحنه قابل‌بازگشت و تنها سپس چرخه کامل گیم‌پلی را در آزمایش مجاز اجرا کنید.

به شکست‌ها زمینه کافی صحنه بدهید

وقتی تعامل شکست می‌خورد، درخت صحنه مرتبط، script، action ورودی و اولین خطای معنادار runtime را ثبت کنید. انتقال مورد انتظار و وضعیت مشاهده‌شده را توضیح دهید. گزارش اینکه بازیکن حرکت نمی‌کند باید بگوید بازی focus دارد یا نه، ورودی تشخیص داده می‌شود یا نه و موقعیت بازیکن تغییر می‌کند یا نه.

اصلاح کوچکی با توضیح متکی بر آن شواهد بخواهید. پس از اعمال، همان action را تکرار و رگرسیون restart و انتقال‌های صحنه را بررسی کنید. تعمیر را فقط چون خطا ناپدید شده قبول نکنید؛ غیرفعال‌کردن قابلیت می‌تواند خطا را حذف و نیاز اصلی را حل‌نشده بگذارد.

پیش‌نیازهای export را صریح آماده کنید

export به preset سازگار و export templateهای نصب‌شده نیاز دارد. export_presets.cfg و گنجاندن منابع را پیش از build بررسی کنید. credentialهای export را خصوصی نگه دارید. نام preset در نمونه صرفاً نمایشی است و باید با پروژه شما مطابقت کند؛ پوشه خروجی باید از قبل وجود داشته باشد.

template یا preset مفقود را مشکل محیط بدانید، نه شواهد غلط‌بودن منطق بازی تولیدشده. logهای export و hash artifact را نگه دارید تا یافته‌های پلتفرم هدف به build مشخصی اشاره کنند. export موفق checkpoint مهمی است، اما شروع یا تکمیل round توسط player تحویل‌شده را ثابت نمی‌کند.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

یک miniflow تحویل را روی target اجرا کنید

بازی exportشده را روی سیستم‌عاملی که قصد پشتیبانی دارید اجرا کنید. شروع، ورودی، round کامل، restart، تنظیمات و persistence پس از راه‌اندازی دوباره را آزمایش کنید. برای هر نتیجه، هویت artifact، زمینه دستگاه و outcome مشاهده‌شده را نگه دارید. export ساخته‌شده در macOS به‌خودی‌خود رفتار Windows را تأیید نمی‌کند.

برای target وب، بارگذاری مرورگر و خطاهای runtime را هم بررسی و canvas را با ورودی واقعی اجرا کنید. قابل‌مشاهده‌بودن و حرکت محتوا را در صورت انتظار تأیید کنید. پیکربندی میزبانی موردنظر را آزمایش کنید و فرض نکنید اجرای editor بارگذاری منابع مرورگر و محدودیت پلتفرم را پوشش می‌دهد.

یک پروژه منبع و capture بومی برای بررسی

نمونه محلی Switchyard یک معمای Godot سه‌اتاقه، کنترل‌های خودکار گیم‌پلی، کنترل‌های save-reopen، log خام، source ZIP و Godot PCK فراهم می‌کند. captureهای بومی آن پروژه در حال اجرا را در دو اندازه viewport نشان می‌دهند. تکرار فرمان‌های مستند کنترل قوی‌تری از قضاوت پروژه فقط از روی screenshot است.

پروژه از Godot 4.5.1 در اجرای Codex استفاده کرده که مدل دقیق تولید آن تأیید نشده است. بنابراین گردش‌کار موتور محلی را نشان می‌دهد، نه benchmark Astra. export مرورگر به‌خاطر export templateهای مفقود مسدود بود و PCK فایل اجرایی مستقل Windows نیست. این مرزها کنار منبع ثبت شده‌اند تا توسعه‌دهنده بعدی بداند چه چیزی باید آزموده شود.

حلقه را با handoff قابل‌بازبینی ببندید

handoff باید دامنه قابل‌بازی، هویت منبع، نسخه موتور و template، دستورهای build، نتایج پذیرفته‌شده و عیب‌های حل‌نشده را نام ببرد. captureهای اصیل artifact آزموده‌شده و منشأ assetهای تحویل‌شده را اضافه کنید. تلاش‌های تعمیر و مداخله‌های دستی را نگه دارید و فقط dump کد تولیدشده نهایی ارائه نکنید.

وقتی حلقه پایه پذیرفته شد، asset و بومی‌سازی را پیش از فکرکردن به ارسال پلتفرم با کنترل‌های import و گیم‌پلی خودشان اضافه کنید. این walkthrough بر مستندات موتور بنا شده است؛ آن را روی نسخه نصب‌شده خود اعمال و نتیجه واقعی را حفظ کنید. فهرست کوتاه مسائل حل‌نشده را با مراحل بازتولید نگه دارید تا جلسه توسعه بعدی از همان وضعیت معلوم آغاز شود.

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