توسعه بازی با هوش مصنوعی
Updated 2026-09-05
یک حلقه کوچک و قابلبازی بسازید، ابزارهایی را انتخاب کنید که بازخورد واقعی موتور را نشان دهند و نتیجه را از داراییها و بومیسازی تا خروجی آزمایششده پیش ببرید.
با یک حلقه کامل و کوچک بازی شروع کنید
هدف اولیه مفید، یک فعالیت با شروع و پایان قابل مشاهده است: شروع یک دور، حرکت یا انتخاب، مواجهه با چالش، رسیدن به برد یا باخت و شروع دوباره. پیش از اینکه از عامل بخواهید فایلها را بنویسد، مشخص کنید بازیکن در هر انتقال چه میبیند. صفحه عنوان صیقلخورده ثابت نمیکند که حلقه کار میکند.
یک پلتفرم هدف و مجموعه کوچکی از دستگاههای ورودی انتخاب کنید. مراحل بیشتر، شبکه و محتوای رویهای را به دامنه بعدی موکول کنید. این کار نمونه اولیه ناموفق را قابلتشخیص میکند: میتوانید قانون برخورد خراب را از قابلیت ناتمام جدا کنید، نه اینکه مرتب prompt را بزرگتر کنید.
ابتدا گردشکار و سپس موتور را انتخاب کنید
برای یک پروژه دوبعدی کوچک و اصیل 2D، ابتدا CLI مستند Godot را برای چرخه بررسی، ویرایش و اجرا ارزیابی کنید. Unity زمانی نقطه شروع مناسبی است که پروژه یا تیم موجود از گردشکار ویرایشگر آن استفاده میکند. توانایی نگهداری نتیجه باید به اندازه نمونه اولیه در انتخاب اثر داشته باشد.
کاری را که برای بازتولید خطا روی دستگاه خود لازم است مقایسه کنید. بهترین نقطه شروع، ساختار پروژه، پیشنیازهای ساخت و خطاهای آن است که بتوانید توضیح دهید. عامل مسئولیت ارتقای موتور یا بستههای شخص ثالث را حذف نمیکند.
| مسیر | شرط شروع مفید | نخستین دروازه تصمیم |
|---|---|---|
| پروژه Godot | حلقه 2D کوچک و اصیل | آیا صحنه اعلامشده اجرا و دوباره شروع میشود؟ |
| پروژه Unity | دانش یا وابستگیهای موجود Unity | آیا ویرایشگر انتخابی میتواند بخش را کامپایل و اجرا کند؟ |
| موتور بهعلاوه MCP | نیاز به بازخورد ساختاریافته ویرایشگر | آیا کلاینت میتواند پروژه موردنظر را شناسایی کند؟ |
دسترسی مدل را از ابزارهای موتور جدا کنید
عامل دو اتصال متفاوت دارد: سرویس مدلی که استدلال و ویرایش تولید میکند و ابزارهای محلی که پروژه را بررسی یا اجرا میکنند. Godot MCP و Unity MCP در سمت ابزار قرار دارند. نصب هرکدام، ارائهدهنده مدل را انتخاب نمیکند و یکپارچهسازی gateway را ثابت نمیکند.
اتصال مدل را در کلاینت عامل و اتصال موتور را در تنظیمات ابزار انتخاب کنید. هرکدام را جداگانه با یک عملیات کوچک بررسی کنید. اگر مسیر پروژه محلی اشتباه است، همان مسیر را اصلاح کنید؛ تغییر نقطه پایانی مدل باعث ظاهر شدن صحنه موردنظر نمیشود.
اولین brief را قابلآزمایش کنید
صحنههای لازم، اقدامات بازیکن، انتقالهای وضعیت و رفتار ماندگاری را نام ببرید. کوچکترین پیادهسازی سازگار با این نیازها و فهرست صریح تصمیمهای حلنشده را بخواهید. از brief نمونه زیر بهعنوان نقطه شروع استفاده کنید و دامنه آن را با بازی واقعی خود جایگزین کنید.
Brief اولیه را بدون تغییر ثبت کنید. هر نیاز جدید را تغییر دامنه بنامید. توضیح یک خطا یا ویرایش دستی فایل را مداخله بنامید. این کار تفاوت میان یک prompt اولیه و تکرارهای متعدد بعدی مدل و ابزار را حفظ میکند.
Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.با تغییرات قابلبازبینی کار کنید
پس از اسکلت اولیه، هر بار یک رفتار بخواهید: حرکت، سپس برخورد و بعد انتقال پایان دور. بعد از هر تغییر فایلهای تغییرکرده را بررسی و همان مسیر پذیرش را اجرا کنید. پیش از افزودن بسته خارجی یا تغییر تنظیمات import، یک وضعیت شناختهشده و سالم پروژه را نگه دارید.
عامل باید خطای مربوط، زمینه صحنه و رفتار مشاهدهشده را دریافت کند، نه فقط درخواست تلاش بیشتر. وقتی یک نشانه پس از ویرایشهای تکراری باقی میماند، توقف کنید و مرز خطا را جدا کنید. منبع واردنشده و ارجاع گره اشتباه، حتی اگر هر دو صحنه خالی بسازند، به اصلاحهای متفاوتی نیاز دارند.
داراییها و بومیسازی را ورودی تولید بدانید
مانیفست دارایی را با منبع، مجوز، هویت نویسنده یا ابزار، تغییرات و کاربرد موردنظر نگه دارید. Spriteها را در مقیاس بازی بررسی کنید؛ از شفافیت، همترازی فریم، کنتراست و تناسب برخوردها غافل نشوید. تصویر باورپذیر لزوماً sprite sheet قابلاستفاده نیست.
رشتههای قابلمشاهده بازیکن را با شناسههای پایدار قابلدسترسی نگه دارید. زمینه ترجمه را بدهید و آرگومانهای قالب را محافظت کنید. تصویر، صدا، فونت و متن ترجمهشده پیش از توزیع به بازبینی نیاز دارند. هزینه تولید تصویر را جدا از کار کدنویسی مدل متنی ثبت کنید؛ نه مجوز دارایی و نه مجوز موتور، حقوق تمام فایلهای پروژه را ثابت نمیکند.
هر وضعیت تحویل را جداگانه ثابت کنید
دموی قابلبازی به این نیاز دارد که یک انسان حلقه موردنظر را کامل کند. خروجی گرفتن به یک artifact تولیدشده نیاز دارد. خروجی آزمایششده علاوه بر آن باید روی پلتفرم هدف اجرا شود. ارسال به Steam و انتشار، وضعیتهای بعدی پلتفرم هستند. هنگام گزارش پیشرفت از این برچسبها دقیق استفاده کنید.
هویت build، ورودیهای آزمون، تصاویر بازی واقعی و خطاهای باقیمانده را نگه دارید. تصویر مرورگر باید پس از ورودی، بازی در حال تغییر را نشان دهد، نه صرفاً صفحه بارگذاری. فایل اجرایی Windows که روی سیستمعامل دیگری خروجی گرفته شده، هنوز به بررسی Windows نیاز دارد. راهنمای Steam نیازهای جداگانه حساب و زمانبندی را توضیح میدهد.
مثال Playco درباره گردشکار چه نشان میدهد
داستان مشتری OpenAI در 3 سپتامبر 2026، استفاده Playco از Astra در Playbot، یک IDE متصل به موتورهای بازی، را توصیف میکند. تیم پیش از ساخت نمونههای موضوعی روی یک پایه grey-box تکرار انجام داد. این روایت منتشرشده مشتری از سوی ارائهدهنده است، نه benchmark برای APIsRouter.
نتیجه عملی، شکل گردشکار است: ابتدا مکانیک قابلبازی را تثبیت کنید و سپس ظاهر را تغییر دهید، در حالی که خط پایه مشترک حفظ میشود. ترجیحات خلاقانه را از اصلاح عیب جدا کنید تا نتیجه هر تکرار روشن باشد. برای نتایج گزارششده داستان اصلی را بخوانید و آنها را پیشبینی بازی خود ندانید.
یک نمونه اولیه محلی Godot را بررسی کنید
Switchyard یک معمای مدار کوچک سهاتاقه است که در یک اجرای توسعه محلی Codex ساخته شده است. پروژه منبع شامل حرکت شخصیت، کلیدها، درها، سلولهای قابلجمعآوری، تکمیل اتاق، باخت و شروع دوباره، تنظیمات و پیشرفت ذخیرهشده است. بررسیهای خودکار موتور حلقه بازی را اجرا کردند و فرایند جداگانهای ذخیره را دوباره باز کرد. تصویر زیر یک capture واقعی viewport در Godot است، نه concept art.
اجرای ثبتشده از Godot 4.5.1 استفاده کرد. هویت مدل و صورتحساب API آن قابل مشاهده نبود، بنابراین این مورد benchmark عملکرد یا هزینه Astra نیست. منبع و PCK قابلدانلود پروژه محلی را نشان میدهند؛ PCK به Godot نیاز دارد. build مستقل Windows، خروجی مرورگر، playtest انسانی و انتشار Steam کارهای جداگانه باقی میمانند. این مثال artifactهای مشخصی را نشان میدهد که پیش از ادعای تحویل باید از عامل بخواهید.

راهنمای بعدی را بر اساس گلوگاه انتخاب کنید
اگر محیط شما هنوز مشخص نیست، با انتخاب موتور شروع کنید؛ اگر کشف ابزار شکست میخورد، صفحات تنظیم MCP را بخوانید؛ و اگر پروژه باز میشود اما نادرست رفتار میکند، سراغ راهنمای اشکالزدایی بروید. وقتی تعمیرهای تکراری بیشترین هزینه را دارند، راهنمای هزینه را ببینید؛ کاهش دامنه شاید از تغییر مدل مهمتر باشد.
این راهنماها گردشکارهای مبتنی بر منبع و مثالهای توضیحی ارائه میکنند، نه رتبهبندی اندازهگیریشده موتور. آزمایش Astra شواهد لازم برای مورد مشخص خود را توضیح میدهد. در پروژه خود گامی را انتخاب کنید که یک مانع مشخص را حل کند و نتیجه آن را پیش از گسترش بازی نگه دارید.
پرسشهای پرتکرار
آیا یک prompt میتواند یک بازی کامل بسازد؟
یک brief اولیه میتواند گردشکاری با تماسهای متعدد مدل، عملیات ابزار و اصلاحهای انسانی را شروع کند. کامل بودن را بر اساس معیارهای پذیرش اصلی بسنجید و این تکرارها را اعلام کنید.
آیا برای استفاده از عامل به MCP نیاز دارم؟
نه لزوماً. کلاینتی با ابزار فایل و shell میتواند گردشکار CLI را پشتیبانی کند. MCP یک رابط ابزار دیگر است که هدفگذاری پروژه و مجوزهای آن نیز باید بررسی شود.
اگر بازی باز میشود اما کار نمیکند، از کجا شروع کنم؟
از راهنمای اشکالزدایی برای جدا کردن مشکل شروع، ورودی، وضعیت و render استفاده کنید. یک اقدام قابلبازتولید بازیکن و نخستین خطای مرتبط موتور را به عامل بدهید.
آیا بازیکنان بودجه API توسعه من را مصرف میکنند؟
منطق عادی بازی خروجیگرفتهشده، فقط به این دلیل که AI در نوشتن آن کمک کرده، مدل را فراخوانی نمیکند. قابلیتهای مدل در زمان اجرا، طراحی سرویس و بودجه جداگانهای هستند.
از یک نمونه اولیه ناموفق چه چیزی را نگه دارم؟
Brief اصلی، هویت محیط، آخرین وضعیت قابلبازتولید پروژه، خطاها، مداخلات و شواهد مصرف را حفظ کنید. کار ناموفق بخشی از سابقه تولید است.