תהליך נכסים למשחק עם AI

Updated 2026-09-05

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

כתבו חוזה נכס לפני יצירת אמנות

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

עבור sprite sheet הגדירו מספר פריימים, מידות תא, מקור ומצבי אנימציה צפויים. עבור נכס UI זהו את הטקסט והמצב האינטראקטיבי שמסביב. השתמשו ב-placeholder שבבעלותכם עד שהחוזה יתייצב, כדי שאיטרציה אמנותית לא תסתיר אם המשחק עובד.

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

בחרו מקור עם בסיס הרשאה שניתן לבדיקה

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

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

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

הפרידו בין ייחוס קידוד ליצירת תמונות

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

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

השתמשו במניפסט עם לא-ידועים כנים

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

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

{
  "asset_id": "player_idle",
  "source_url": null,
  "permission_record": null,
  "creator_or_tool": null,
  "source_hash": null,
  "final_file_hash": null,
  "transformations": [],
  "image_cost_record": null,
  "review_status": "pending",
  "import_result": null
}

בדקו את ייבוא המנוע, לא רק את קובץ המקור

תיעוד ייבוא התמונות של Godot מתאר אפשרויות דחיסה ו-mipmap שמשפיעות על textures מיובאים. בחרו הגדרות לפי תנאי התצוגה בפועל; pixel art, רקעים מותאמים ו-textures תלת-ממדיים אינם חולקים preset אוניברסלי. שמרו את ההגדרות ששימשו לפלט המאושר.

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

בדקו אנימציה, שמע ו-UI בהקשר

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

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

בדקו את ה-artifact המיוצא ואת רשימת הגילוי

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

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

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

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

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

שאלות נפוצות

האם שימוש הקידוד של Astra כולל את כל עלויות אמנות המשחק?

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

האם אפשר להשתמש בכל תמונה שנראית מתאימה?

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

האם PNG שקוף הוא sprite גמור?

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

מה צריך להיות במניפסט נכסים?

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

מתי לסמן נכס כמאושר?

לאחר שרשומת ההרשאה שלו נפתרה, הקובץ המיובא תואם ל-brief הטכני וההתנהגות הרלוונטית נבדקה ב-build היעד.