פיתוח משחקים עם AI ב-Godot

הגדירו את גבול הפרויקט לפני עריכות

התחילו מספריית פרויקט בבעלותכם ומרשימה כתובה של שינויים מותרים. ערכו מלאי של סצנות, סקריפטים, נכסים ותוספים קיימים כדי שהסוכן יוכל להרחיב את המבנה הנוכחי במקום ליצור מימוש שני. שמרו את מצב הפרויקט הראשוני ניתן לשחזור ותעדו איזה בינארי של המנוע פותח אותו.

בחרו מקטע משחק מתון עם מעברים מפורשים. לדוגמה, מסך כותרת שמוביל לחדר אחד וחוזר דרך ניצחון או הפסד מספק בדיקה חוזרת. החליטו מי בודק קומפוזיציה חזותית ופקדים, מפני שלא מנתח מוצלח ולא הודעת השלמה של מודל מוכיחים שהחוויה קוהרנטית.

זהו את קובץ ההפעלה ואת הארגומנטים הנתמכים

תיעוד ה-CLI היציב של Godot מספק את הפקודות שלהלן. GODOT_BIN ו-PROJECT הם משתני shell שנבחרו לדוגמה, לא הגדרות Godot; החליפו את נתיבי הדוגמה בקובץ ההפעלה ובפרויקט הקיימים שלכם. נתיב הפרויקט חייב להכיל project.godot.

לכדו את פלט הגרסה וה-help לפני תסרוט דגלים נוספים. כך לא תניחו שפקודה שמופיעה בתיעוד מקוון עדכני קיימת ב-build המותקן שלכם. תעדו את זהות הבינארי יחד עם תוצאות בדיקה מאוחרות יותר ושמרו עליה יציבה בזמן חקירת כשל. הפקודות להמחשה משתמשות בצורות CLI מתועדות.

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

הפרידו ייבוא, פענוח ומשחק בפועל

ייבוא headless בודק גבול של עיבוד נכסים. בדיקת parser בוחנת סקריפט. הפעלה רגילה מגיעה למשחק ויכולה לחשוף חיבורי סצנה ובעיות ריצה. שמרו את התוצאות האלה נפרדות ברשומת הבדיקה במקום לסכם את שלושתן כבדיקות שעברו.

נתיב הסקריפט להמחשה שלהלן חייב כבר להתקיים בפרויקט שלכם. בדיקת parser היא צרה בכוונה: היא אינה יכולה לבסס התנגשות עובדת, קלט מגיב או התמדה נכונה. לאחר עריכה הריצו מחדש את ההתנהגות שהיא משנה ואת המעבר שמיד לפניה ואחריה. לרוב זה אינפורמטיבי יותר מיצירת בדיקות מבודדות רבות לפונקציות עזר שנוצרו.

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

בחרו בכלי CLI או MCP בכוונה

סוכן שמסוגל לעבוד עם shell יכול להפעיל רצף CLI שנבדק. Godot MCP הוא ממשק כלי נוסף שמתוחזק בפרויקט, וההגדרה שלו מכוסה בדף הייעודי. בכל מקרה, המפעיל צריך לדעת איזה פרויקט מיועד לפני אישור כתיבה או הפעלת תהליך.

שמרו את הגדרות ספק המודל של הסוכן נפרדות מכלי המנוע. חיבור מקומי עובד אינו מוכיח שמודל מסוים זמין או שהסוכן תומך בכל תכונה של gateway תואם. קבעו תחילה קריאת read קטנה ומותרת, לאחר מכן שינוי סצנה הפיך, ורק אז מחזור משחק מלא בניסוי מורשה.

תנו לכשלים מספיק הקשר סצנה

כאשר אינטראקציה נכשלת, לכדו את עץ הסצנה הרלוונטי, הסקריפט, פעולת הקלט ושגיאת הריצה המשמעותית הראשונה. הסבירו את המעבר הצפוי ואת המצב שנצפה. דוח שלפיו השחקן אינו יכול לזוז צריך לומר אם למשחק יש focus, אם קלט מזוהה ואם מיקום השחקן משתנה.

דרשו תיקון מוצע קטן עם הסבר הקשור לראיה הזו. לאחר החלתו חזרו על אותה פעולה ובדקו רגרסיות בהתחלה מחדש ובמעברי סצנה. הימנעו מקבלת תיקון רק מפני שהשגיאה נעלמה; השבתת התכונה המושפעת יכולה להסיר שגיאה תוך השארת הדרישה המקורית ללא מענה.

הכינו מראש את דרישות הקדם לייצוא

ייצוא דורש preset תואם ותבניות ייצוא מותקנות. בדקו את export_presets.cfg ואת הכללת המשאבים לפני הבנייה. שמרו פרטי גישה לייצוא פרטיים. שם ה-preset בדוגמה הוא המחשה וחייב להתאים לפרויקט שלכם; תיקיית הפלט חייבת כבר להתקיים.

התייחסו לתבנית או preset חסרים כאל בעיית סביבה, לא כראיה שלוגיקת המשחק שנוצרה שגויה. שמרו יומני ייצוא ואת ה-hash של ה-artifact כדי שממצאי יעד יתייחסו ל-build מסוים. ייצוא שהצליח הוא נקודת בדיקה חשובה אך אינו מוכיח שהמשחק שנמסר מתחיל או משלים סיבוב.

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

הריצו miniflow מסירה ביעד

הפעילו את המשחק המיוצא במערכת ההפעלה שבה אתם מתכוונים לתמוך. בדקו התחלה, קלט, סיבוב מלא, התחלה מחדש, הגדרות והתמדה לאחר הפעלה מחדש. עבור כל תוצאה שמרו זהות artifact, הקשר מכשיר ותוצאה שנצפתה. ייצוא שנוצר ב-macOS אינו מאמת בעצמו התנהגות ב-Windows.

עבור יעד web בדקו גם טעינת דפדפן ושגיאות ריצה והפעילו את ה-canvas בקלט אמיתי. ודאו שהתוכן נראה וזז כשמתאים. בדקו את תצורת האירוח המיועדת במקום להניח שהרצת עורך מקומית מכסה טעינת משאבי דפדפן ומגבלות פלטפורמה.

פרויקט מקור ולכידה טבעית למנוע לבדיקה

דוגמת Switchyard המקומית מספקת פאזל Godot עם שלושה חדרים, בדיקות משחק אוטומטיות, בדיקות שמירה ופתיחה מחדש, יומנים גולמיים, ZIP מקור ו-PCK של Godot. הלכידות הטבעיות שלה מציגות את הפרויקט הפועל בפועל בשני גדלי viewport. חזרה על הפקודות המתועדות היא בדיקה חזקה יותר משיפוט הפרויקט לפי צילום מסך בלבד.

הפרויקט השתמש ב-Godot 4.5.1 בהרצת Codex שזהות מודל היצירה המדויקת שלה לא אומתה. לכן הוא מדגים תהליך מנוע מקומי, לא benchmark של Astra. ייצוא לדפדפן נחסם בגלל תבניות ייצוא חסרות, וה-PCK אינו קובץ הפעלה עצמאי ל-Windows. הגבולות האלה מתועדים עם המקור כדי שהמפתח הבא ידע מה עדיין צריך לבדוק.

סגרו את הלולאה במסירה שניתנת לבדיקה

המסירה צריכה לציין את היקף המשחק, זהות המקור, גרסאות המנוע והתבניות, הוראות build, תוצאות שהתקבלו ופגמים שלא נפתרו. כללו לכידות אותנטיות מה-artifact שנבדק ואת המקור של נכסים שנשלחו. שמרו ניסיונות תיקון והתערבויות ידניות במקום להציג רק dump קוד שנוצר.

כאשר הלולאה הבסיסית מתקבלת, הוסיפו נכסים ולוקליזציה באמצעות בדיקות ייבוא ומשחק משלהם לפני ששוקלים שליחת פלטפורמה. ההדרכה הזו מבוססת על תיעוד מנוע; הפעילו אותה בגרסה המותקנת שלכם ושמרו תוצאות אמיתיות. שמרו רשימה קצרה של בעיות שלא נפתרו עם שלבי שחזור כדי שסשן הפיתוח הבא יתחיל מאותו מצב ידוע.

שאלות נפוצות