یک بازی استراتژی ممکن است در Godot اجرا شود، اما هنوز برای تحویل به دیگران آماده نباشد. بازیکن باید بتواند بازی تازه‌ای شروع کند، چند روز در آن دوام بیاورد، ذخیره‌اش را دوباره باز کند و بدون دسترسی به پروژهٔ تو آن را اجرا کند. در این آموزش، نمونه‌ای با اقتصاد غذا، چرخهٔ شب‌وروز، حمله، اکتشاف و کاروان را از همین زاویه بررسی می‌کنیم: اول مسیر بازی بازیکن را تست می‌کنی، بعد خطاهای قابل‌بازتولید را جدا می‌کنی و در پایان، پروژه یا خروجی قابل‌اجرایی می‌سازی که واقعاً می‌شود به شخص دیگری سپرد.

۱. از منوی شروع، یک مسیر تکرارپذیر بساز

پیش‌نیاز این مرحله، پروژه‌ای است که فایل project.godot در ریشهٔ پوشه‌اش باشد و در Godot باز شود. بازی را از داخل ویرایشگر اجرا کن. پیش از آنکه سراغ ساختمان‌ها بروی، منوی شروع را امتحان کن: موسیقی پخش می‌شود؟ «بازی جدید» وارد صحنهٔ بازی می‌شود؟ فهرست ذخیره‌ها قابل‌خواندن است؟ اگر ذخیرهٔ قبلی داری، آن را باز کن و ببین دوربین، زمان و وضعیت منابع با چیزی که انتظار داری سازگارند یا نه.

برای تست اصلی، بازی جدید را انتخاب کن تا نتیجه به وضعیت ذخیرهٔ قدیمی وابسته نباشد. در نمونهٔ موردبحث، رابط بازی نام و سلامت افراد، زمان، منابع و وضعیت‌های جمعیت را نشان می‌دهد. این‌ها فقط تزئین نیستند؛ ابزار مشاهدهٔ تست‌اند. اگر بعداً فردی را به شغلی اختصاص دادی، باید بتوانی تغییر جای خالی شغل و وضعیت همان فرد را در رابط ببینی.

نتیجهٔ موردانتظار این مرحله یک «نقطهٔ شروع شناخته‌شده» است، نه صرفاً بازشدن پنجره. زمان شروع، تعداد افراد و مقدار اولیهٔ غذا و چوب را در یادداشت تست ثبت کن. اگر بارگذاری ذخیره رفتار متفاوتی دارد، آن را جداگانه گزارش کن؛ قاطی‌کردن تست بازی تازه با تست ذخیره، پیدا کردن منشأ خطا را سخت می‌کند.

۲. اقتصاد اولیه را با ساختمان و شغل امتحان کن

در بازی استراتژی، ساختن ساختمان زمانی معنی پیدا می‌کند که زنجیرهٔ منابع و نیروی انسانی آن کار کند. نزدیک درخت‌ها مسیر تأمین چوب را بررسی کن و برای غذا، محل مجاز ساخت مزرعه را پیدا کن. در این نمونه نمی‌شود هر ساختمانی را در هر نقطه گذاشت؛ ارتفاع زمین و محدودهٔ ساخت مهم‌اند. اگر نشانگر ساخت روی نقطه‌ای نامعتبر قرار گرفت، آن را با خرابی کنترل‌ها اشتباه نگیر. همان ساختمان را روی زمین مناسب و داخل مرز امتحان کن.

بعد از ساخت، جایگاه‌های شغلی را بررسی و چند نفر را به کار اختصاص بده. نتیجهٔ موردانتظار این است که تعداد جایگاه‌های خالی کم شود، افراد به محل کار بروند و شاخص‌های تولید یا ذخیره در گذر زمان تغییر کنند. عدد مثبتِ تولید غذا به‌تنهایی نشانهٔ امنیت نیست: ذخیرهٔ فعلی، مصرف جمعیت و وقفه‌های احتمالی تولید را هم کنار هم بخوان. با ساخت خانه ظرفیت جمعیت بیشتر می‌شود، اما جمعیت بیشتر غذا هم مصرف می‌کند.

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

۳. شب اول را به آزمون فشار تبدیل کن

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

در مسیر دفاعی، اول چوب و سایر منابع لازم را کنار بگذار، برج را در محل مفید قرار بده و فرد یا نیروی مناسب را به آن اختصاص بده. در نمونه، کماندار می‌تواند در برج مستقر شود و درِ ورودیِ روی مسیر دسترسی هنگام حمله بسته می‌شود. بعد از ساخت، فقط به ظاهر برج اکتفا نکن: ظرفیت و اشغال آن، راه رسیدن مهاجم و تغییر ترس جمعیت را هم نگاه کن. نتیجهٔ موردانتظار این است که دفاع واقعاً در جریان حمله نقش داشته باشد، نه اینکه ساختمان صرفاً روی نقشه دیده شود.

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

۴. مسیر حرکت، آب‌وهوا و جابه‌جایی شغل را بسنج

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

جاده هزینهٔ منابع دارد. بنابراین پرسش تست فقط «سریع‌تر شد؟» نیست؛ آیا به مسیری وصل شده که افراد واقعاً از آن استفاده می‌کنند؟ اگر کسی مسیر دیگری می‌رود، پیوستگی جاده، مانع‌های نقشه و مقصد واقعی دستورش را بررسی کن. با اضافه‌شدن دیوار یا پله نیز باید دوباره دسترسی به مقصد را امتحان کنی؛ دفاع خوب نباید راه فعالیت‌های خودت را ببندد.

حالا فردی را که مشغول شغلی است برای ساخت خانه انتخاب کن. در این نمونه، دستور جدید می‌تواند او را از کار قبلی جدا کند. بعد از پایان ساخت، جایگاه شغلی سابقش را دوباره بررسی کن؛ ممکن است لازم باشد فردی را به آن اختصاص بدهی. این تستِ کوچک جلوی یک خطای تفسیری رایج را می‌گیرد: افت تولید پس از ساخت خانه شاید از تغییر مأموریت فرد آمده باشد، نه از خود خانه.

۵. اکتشاف و کاروان را از ابتدا تا رسیدن بار دنبال کن

برای دیدن بخش‌های ناشناختهٔ نقشه، نیرویی را به اکتشاف بفرست. در این نمونه، رقیب هم پایگاهش را توسعه می‌دهد و برای پیدا‌کردن تو جست‌وجو می‌کند؛ کشفِ قبلیِ قلعهٔ او نیز به معنی دید زنده به سربازانش پس از ترک منطقه نیست. «پیداکردن پایگاه دشمن»، «دیدن نیروهای حاضر» و «واکنش دشمن پس از کشف پایگاه تو» را جداگانه بررسی کن. اگر سربازها وارد نبرد شدند، تغییر تجربه و قدرتشان را ثبت کن؛ درمان زخمی‌ها با بیمارستان و پزشک را هم، اگر در نسخهٔ موردآزمایش فعال است، جدا بسنج. وقتی یک سکونتگاه بیرونی پیدا شد، گرفتن آن را از انتقال منابعش جدا در نظر بگیر: تصرف، داشتن کاروان و سالم‌رسیدن بار سه مرحلهٔ متفاوت‌اند. در نمونه، پس از تصرف سکونتگاه می‌توان مقدار منبع ارسالی را تعیین کرد؛ گاری به مقصد می‌رود، بار می‌گیرد و برمی‌گردد. وجود راهزن در مسیر، همراهی نیروی محافظ را به تصمیمی عملی تبدیل می‌کند.

برای آزمون، مقدار مشخصی غذا سفارش بده و چهار چیز را ثبت کن: موجودی مبدأ پیش از بارگیری، محتوای گاری هنگام بازگشت، خطرهای مسیر و موجودی مقصد پس از رسیدن. نتیجهٔ موردانتظار فقط حرکت‌کردن گاری نیست؛ منبع باید طبق قواعد بازی از مبدأ کم و در مقصد اضافه شود. اگر بار نمی‌رسد، بررسی کن کاروان ساخته و مسیر فعال شده باشد، گاری واقعاً بار گرفته باشد و در میانهٔ راه نابود یا متوقف نشده باشد.

اگر تاجر و بازار مرکزی را پیدا کردی، معامله را آزمونی جدا از انتقال منابع میان سکونتگاه‌ها بدان: ارسال کالا، دریافت عوض آن و خطر حمله به کاروان در هر دو مسیر را پیگیری کن. سناریوی انتقال بار نیز جای خوبی برای تست ذخیره است. پیش از سفارش یک ذخیره بساز؛ پس از رسیدن بار نیز ذخیره کن، به منو برگرد و دوباره آن را بارگذاری کن. اگر موجودی یا وضعیت مسیر پس از بارگذاری با وضعیت پیش از خروج سازگار نیست، مشکل را با همین دنبالهٔ کوتاه گزارش کن، نه با جملهٔ مبهم «سیو خراب است».

۶. لگ را در صحنهٔ شلوغ بازتولید کن، نه نقشهٔ خالی

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

اگر لگ دیدی، نقطهٔ وقوع را بنویس: هنگام زوم؟ هم‌زمان با حرکت گروهی؟ فقط زیر باران؟ هنگام حمله؟ یک ذخیرهٔ قابل‌بازتولید و شرح همین شرایط، از درخواست کلی «بازی را سریع‌تر کن» مفیدتر است. اگر از دستیار کدنویسی کمک می‌گیری، پیش از پذیرفتن تغییر بخواه علت احتمالی را مشخص کند و تغییراتش را محدود نگه دارد:

بازنویسی آموزشی پرامپت — برای دستیار کدنویسی:

در پروژهٔ Godot، کاهش روانی حرکت را در یک صحنهٔ شلوغ بررسی کن: چند گروه هم‌زمان حرکت می‌کنند، سربازها حضور دارند و هوا بارانی است. ابتدا روش بازتولید و بخش‌های احتمالیِ پرهزینه را گزارش کن. سپس فقط تغییرات مرتبط و قابل‌برگشت پیشنهاد بده. رفتار مسیر‌یابی، سرعت بازی و ذخیره/بارگذاری نباید ناخواسته تغییر کند. برای هر تغییر بگو چگونه قبل و بعد از آن را در همان شرایط مقایسه کنم.

این متن دستور به ابزار AI است، نه فرمان ترمینال. حتی اگر دستیار کد را تغییر داد، همان ذخیره و همان شرایط را دوباره آزمایش کن؛ رفع لگ وقتی ارزش دارد که رفتار بازی را خراب نکرده باشد.

۷. برای بازی یک برگهٔ آزمون پذیرش بنویس

آزمون پذیرش یعنی مجموعه‌ای از کارها که اگر شخص دیگری انجامشان داد، بتواند دربارهٔ آماده‌بودن نسخه تصمیم بگیرد. در ریشهٔ پروژه، کنار project.godot، فایلی به نام TEST_PLAN.md بساز. این فایل به Godot وابسته نیست؛ یک سند متنی برای توسعه‌دهنده و آزمایش‌کننده است. متن کوتاه زیر مثال تکمیلی آموزشی است و می‌توانی آن را با نام دکمه‌ها و قواعد واقعی بازی خودت هماهنگ کنی:

# آزمون پذیرش نسخه

- بازی تازه: از منو شروع می‌شود؛ زمان، جمعیت و منابع نمایش داده می‌شوند.
- ساخت‌وساز: ساختمان در جای مجاز ساخته می‌شود و در جای نامجاز نه.
- اقتصاد: پس از اختصاص افراد، تولید و مصرف در گذر زمان قابل‌پیگیری‌اند.
- شب و دفاع: استراحت، حمله و واکنش برج یا نیرو مشاهده می‌شود.
- رضایت و سلامت: اثر مالیات و بی‌خوابی بر رضایت، خستگی و بیماری بررسی می‌شود.
- اکتشاف و نبرد: دیدِ منطقه پس از ترک آن، واکنش دشمن پس از کشف پایگاه و تغییر تجربهٔ سرباز پس از نبرد بررسی می‌شود؛ درمان زخمی‌ها، اگر فعال است، جدا ثبت می‌شود.
- مأموریت: تغییر کار یک فرد، شغل قبلی او را به‌درستی به‌روز می‌کند.
- کاروان: بار از مبدأ دریافت می‌شود و پس از رسیدن، موجودی مقصد تغییر می‌کند.
- تجارت، اگر در نسخه فعال است: کالای ارسالی و عوض دریافتی پس از طی مسیر ثبت می‌شوند.
- ذخیره: خروج به منو و بارگذاری، وضعیت مهم بازی را حفظ می‌کند.
- اجرا: نسخهٔ خروجی روی دستگاه آزمایش، بدون ویرایشگر Godot باز می‌شود.

برای هر مورد ثبت کن: نتیجه، مراحل بازتولید، و در صورت خطا تصویر یا گزارش مناسب.

پس از نوشتن فایل، آن را واقعاً اجرا کن. کنار هر مورد «قبول»، «رد» یا «هنوز تست نشده» بگذار. اگر حمله در یک اجرای کوتاه رخ نداد، مورد دفاع را قبول اعلام نکن؛ یا شرایط مناسبش را فراهم کن یا وضعیتش را تست‌نشده نگه دار. این صداقت برای نسخه‌ای که دیگران قرار است دانلود کنند مهم‌تر از پرکردن همهٔ خانه‌ها با علامت تأیید است.

۸. انتشار سورس را از ساخت نسخهٔ قابل‌اجرا جدا کن

قرار دادن پروژه در مخزن عمومی به دیگران اجازه می‌دهد سورس را بگیرند و با Godot باز کنند؛ به معنی داشتن فایل نصب یا اجرای مستقل نیست. پیش از انتشار، مطمئن شو project.godot، صحنه‌ها، اسکریپت‌ها و فایل‌های تصویری یا صوتیِ واقعاً موردنیاز در پوشهٔ پروژه هستند. پیش از عمومی‌کردن مخزن، تغییرات را برای کلیدها، توکن‌ها، داده‌های خصوصی و فایل‌های موقت بازبینی کن؛ حق بازنشر دارایی‌های دانلودشده یا تولیدشده با AI را هم جداگانه بررسی کن. خروجی‌های ساخته‌شده را با سورس اشتباه نگیر. حذف کورکورانهٔ تصاویرِ ظاهراً اضافی هم خطرناک است: ممکن است یک صحنه هنوز به آن‌ها ارجاع بدهد.

بعد یک README.md در ریشهٔ پروژه بنویس: نسخهٔ سازگار Godot را پس از بررسی پروژه و آزمون واقعی ثبت کن، نه از روی حدس. روش دریافت پروژه، بازکردن پوشهٔ دارای project.godot، صبرکردن برای واردسازی فایل‌ها، اجرای بازی از ویرایشگر و وضعیت فعلی خروجی‌ها را هم توضیح بده. برای Git، ابتدا فقط فایل‌های بازبینی‌شده را برای ثبت انتخاب کن؛ اگر از رابط VS Code استفاده می‌کنی، فهرست فایل‌ها و محتوای تغییرات را پیش از commit بخوان. سپس مخزن عمومی تازه را در سرویس میزبانی بساز، نشانی واقعی آن را به‌عنوان remote تنظیم کن و شاخهٔ ثبت‌شده را push کن. اگر پروژه از قبل remote دارد، بدون بررسی آن را جایگزین نکن؛ برای جزئیات از مستندات رسمی Git کمک بگیر.

نتیجهٔ موردانتظار این مرحله را با یک آزمایش مستقل بسنج: پروژه را در پوشه‌ای تازه دریافت کن و فقط با کمک README در Godot سازگار باز و اجرا کن. سپس آموزش را جدا از خود بازی بیازما: آیا خواننده‌ای دیگر با همین توضیحات و پیش‌نیازهای اعلام‌شده می‌تواند خروجی آزمایشی بسازد؟ نتیجهٔ این آزمونِ آموزش را جدا از قبولی مکانیک‌های بازی در TEST_PLAN.md ثبت کن. اگر فایل یا توضیحی کم است، هنوز مسیر «دریافت سورس و اجرا در Godot» آماده نیست. نشانی مخزن را هم فقط وقتی منتشر کن که واقعاً ساخته و آزمایش شده باشد؛ در این آموزش هیچ لینک دانلودی برای خود بازی فرض نمی‌کنیم.

۹. خروجی قابل‌دانلود بساز و روی پلتفرم مقصد امتحان کن

برای کسی که Godot نصب ندارد، باید از پروژه خروجی مناسب پلتفرمش بگیری. در Godot از Project > Export پیش‌تنظیم مقصد را اضافه کن، قالب خروجیِ سازگار با نسخهٔ ویرایشگر را نصب یا بررسی کن و از همان پنجره گزینهٔ صدور پروژه را برای آن مقصد اجرا کن. جزئیات و پیش‌نیازها بسته به نسخه و پلتفرم فرق دارند؛ اگر گزینه‌ای غیرفعال است، پیام همان پنجره و مستندات رسمی Godot را بخوان. همهٔ فایل‌های همراهِ خروجی را با هم تحویل بده، نه لزوماً فقط فایل اجرایی را. بستهٔ تحویلی را بیرون از ویرایشگر و روی دستگاه مقصد باز کن و شروع بازی، حرکت، صدا و ذخیره/بارگذاری را تکرار کن. اگر ذخیره فقط در ویرایشگر کار می‌کند، بررسی کن بازی برای نوشتن از مسیر قابل‌نوشتنی مانند user:// استفاده کند، نه فایل‌های بسته‌بندی‌شدهٔ res://.

خروجی دسکتاپ برای یک سیستم‌عامل را به‌جای خروجی همهٔ سیستم‌ها معرفی نکن. خروجی وب را از طریق سرور محلی یا میزبان وب در مرورگر آزمایش کن؛ بازکردن مستقیم فایل HTML از مسیر file:// آزمون انتشار نیست و صرف ساخته‌شدن فایل‌ها هم تجربه‌ای یکسان با دسکتاپ را تضمین نمی‌کند. برای Android علاوه بر پیش‌تنظیم، ابزارهای ساخت سازگار و تنظیمات امضای متناسب با نوع انتشار لازم است؛ پیش از وعدهٔ فایل نصب، راهنمای رسمی خروجی Android را با محیط خودت تطبیق بده و نتیجه را روی دستگاه مقصد تست کن.

ساخت خودکار خروجی و انتشار آن در صفحهٔ release می‌تواند مرحلهٔ بعد از تثبیت همین روند دستی باشد، نه جایگزین آن. اول باید بدانی خروجی سالم چه فایلی است و چگونه آزمایش می‌شود. تحویل نهایی تو یک پوشهٔ پروژه با README.md و TEST_PLAN.md تکمیل‌شده، به‌همراه فقط خروجی‌هایی است که واقعاً ساخته و روی پلتفرم مقصد اجرا کرده‌ای. در توضیح نسخه، پلتفرم‌های آزمایش‌شده و ایرادهای باقی‌مانده را روشن بنویس؛ این‌طور بازیکن می‌داند دقیقاً چه چیزی دریافت می‌کند.

مطالعهٔ مرتبط

ساخت نمونهٔ اولیهٔ بازی استراتژیک در Godot با کمک هوش مصنوعی

ویدیوی کامل

اگر می‌خواهی روند کار و آزمون‌ها را هم ببینی، ویدیوی کامل این آموزش اینجاست:

تماشای ویدیو در یوتیوب · گروه گفت‌وگو و پرسش‌های آموزشی