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

התחילו בחוזה הפרויקט הקיים

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

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

התייחסו לאוטומציית עורך כחיבור נפרד

פרויקט Unity MCP של CoplayDev חושף פעולות עורך ללקוחות תואמים. מדריך ההתקנה שלו מתאר חבילת עורך וחיבור שרת. שירות המודל של הסוכן נפרד: שינוי פרטי גישה למודל לא יתקן מופע עורך שאינו זמין.

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

בקשו שינויים מוגבלים עם תוצאות נראות

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

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

Inspect the selected project and its existing input and controller code.
Add one restart transition to the owned gameplay scene.
Keep package versions and rendering settings unchanged.
Report changed scripts, scene references, and the verification performed.
Stop before package downloads, purchases, external uploads, or publishing.

המתינו לקומפילציה לפני פרשנות תוצאות המשחק

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

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

השתמשו ב-test framework של הפרויקט בכוונה

Unity Test Framework מתעד בחירת בדיקות משורת הפקודה ופלט תוצאות. הדוגמה מניחה שה-framework כבר מוגדר ושספריית תוצאות הבדיקה קיימת. UNITY_BIN ו-PROJECT הם משתני shell להמחשה שמצביעים לעורך ולפרויקט הקיימים. התאימו את תיעוד הייחוס לחבילה המותקנת שלכם.

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

UNITY_BIN="/absolute/path/to/Unity"
PROJECT="/absolute/path/to/project"
"$UNITY_BIN" -batchmode -projectPath "$PROJECT" \
  -runTests -testPlatform EditMode \
  -testResults "/absolute/existing-results-dir/editmode.xml" \
  -logFile "/absolute/existing-results-dir/editmode.log"

בדקו קלטי build לפני יצירת player

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

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

אמתו משחק מחוץ לעורך

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

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

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

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

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

שאלות נפוצות