From a Phone Video to Working Game Code

TL;DR

פיתחתי כלי ותהליך עבודה שהופכים וידאו של גיימפליי, דו־ממדי ותלת־ממדי כאחד, לקוד משחק אמיתי, בעזרת AI ומנוע משחק. תהליך העבודה שלי הצליח לייצר את קוד המשחק של Smash Fest, משחק מובייל תלת־ממדי קז'ואל, מתוך כ־8 דקות (בסך הכול) של וידאו, בערך בלילה אחד + בוקר מוקדם. זה כולל את עיצוב השלבים ואת כל מסכי המטא־משחק שהופיעו בסרטונים. לא ניסיתי לשחזר את האמנות והטקסטורות, רק את הקוד, והתוצאה הייתה משחק עובד.

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

רקע

לפני שאתחיל, כדאי שאזכיר שאני משתמש ב־harness אישי לפיתוח משחקים שאני קורא לו PlayDreams. הוא מאפשר לי ולכמה חברים לפתח משחקים מהר יותר ובאופן אמין יותר על פני Unity, Godot ו־web, והוא מכסה גם יצירת אמנות ופרסום לחנויות המובייל. חלק מהתהליכים שאתאר כאן מבוססים על כלים ומערכות שכבר יש לי שם, אבל תהליך ה־video-to-game עצמו שאני מתאר כאן אמור להיות ברור למדי, ומפתח שעובד עם Claude או Codex אמור להיות מסוגל לשחזר את אותו תהליך עבודה כללי בסביבה שלו.

לאחרונה הוספתי ל־PlayDreams, ה־harness שלי לפיתוח משחקים, כלי שהופך וידאו של דמות ל־sprite דו־ממדי. את הכלי פיתח במקור חבר, וככל ששיחקתי איתו התחלתי לתהות אם אפשר להפוך אותו לתהליך עבודה מלא של video-to-game-code. אז ניסיתי.

המרת המשחק שאפרט עליה בהמשך היא הפיכת וידאו של Smash Fest לגיימפליי אמיתי (ולכמה שלבים), אבל למען ההגינות – פיתחתי את המערכת קודם על משחק דו־ממדי: משחק המהג'ונג הדו־ממדי שלי.

זה חשוב, כי אימנתי את המערכת קודם על משחק שאני מחזיק בקוד שלו – ל־orchestrator הייתה גישה לקוד המקור האמיתי, והוא יכול היה לכוון את הניסיון הראשון להפוך וידאו לקוד משחק בצורה די עצמאית, ולתקן את הטעויות של עצמו באופן עצמאי. אני מאמין שהתהליך ההתחלתי הזה היה קריטי כדי לקבל בסיס קוד נכון, במיוחד מכיוון שרציתי שהתהליך יהיה מבוסס־קוד (ולא מבוסס־LLM) ככל האפשר. גם כשהשתמשתי במודלים חזיתיים (Opus ו־Fable של Claude, עם ביקורות של Terra ו־Sol של OpenAI), הם עדיין עשו לא מעט טעויות (אבל בביטחון מלא!) שרק ההשוואה לקוד האמיתי הציפה.

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

למה עשיתי את זה ב־Godot

בחרתי לעשות את התהליך עם Godot. מחזורי הפיתוח מהירים בהרבה מ־Unity, המנוע יותר מיכולת ויציב מספיק כדי לטפל בכל מה שהמשחק צריך, ויש לו scenes ו־assets מובנים. בנוסף, ל־harness שלי, PlayDreams, יש setup חזק מאוד לפיתוח ב־Godot, מה שהפך את הפיתוח לקל ומהיר יותר.

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

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

שלב 1 – להבין מה לצלם. ואז לצלם שוב.

כדי לבצע ניתוח כמו שצריך הייתי צריך וידאו טוב (או יותר מאחד, בשלבים מאוחרים יותר). הוא היה צריך לכסות את כל מה שרציתי לפתח – כלומר את כל התפריטים, את כל מצבי המשחק – כישלון שלב, ניצחון בשלב, שימוש ב־booster לפני השלב, מה קורה כשנגמרים הלבבות וכו'. עבור כל ממד של המשחק (מצלמה, פיזיקה, מבנה שלב, התקדמות, UI).

שלב 2 – לכתוב מה הווידאו לא יכול לספר לך

זה שלב חשוב.

לפני שום קוד, אני מייצר רשימת היעדרים (absence list): מלאי מסך־אחר־מסך שבו כל פער מסווג לאחת מארבע קטגוריות.

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

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

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

דוגמה נוספת, ספציפית ל־Smash Fest – השלבים בנויים משכבות (שורות) של אובייקטים תלת־ממדיים שמונחים זה על זה, אחד מאחורי השני. אף פעם אי אפשר לראות את השכבות האחוריות, אלא אם כן מוצאים דרך להפיל את השכבה הקדמית לבד, או שכל המבנה יושב על שולחן מסתובב (יש שלבים כאלה). זו בעיה שצריך לטפל בה.

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

שלב 3 – להפוך וידאו לראיות

עכשיו אני מחלץ פריימים.

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

אבל אתה לא צריך כל פריים באותה צפיפות. דברים שונים דורשים דגימה שונה לחלוטין:

• תפריט או פריסת מסך – פריים אחד. זה סטטי. פריים שני לא מוסיף שום מידע.
• מבנה ופריסה של שלב – בערך פריים אחד לכל חצי שנייה. מספיק כדי לראות שינוי, ולא כל כך הרבה שתטבע בפרטים (ותבזבז טוקנים וזמן).
• VFX, פגיעות, רעידות מצלמה, תחושה – קצב פריימים מלא. במיוחד אם יש אפקטים שכוללים חלקיקים מהירים, ירי, מחזורי צבעים וכו'.

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

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

הערה חשובה אחת – השלב הזה יכול לצרוך המון מקום בדיסק. השתמשתי בווידאו שצולם ב־iPhone שלי, והוא היה ברזולוציה גבוהה ב־60fps. כמה דקות של זה. בסוף היו לי מעל 20 ג'יגה של פריימים על הדיסק. אבל זה המחיר של ניתוח וידאו (ושל מתן אפשרות לסוכנים להריץ לולאות באופן עצמאי).

ניתוח שלבים – בעיה מיוחדת

נקודת כשל פוטנציאלית חשובה נוספת – ניתוח שלבים.

ל־LLMs יש נטייה להסתכל על הפריים הראשון של השלב ולהסיק שזה מידע השלב. זה כמעט תמיד שגוי. ברוב המשחקים שלב הוא אובייקט זמני, לא מרחבי. אי אפשר להסתכל על הפריים הראשון של שלב ולדעת ממה השלב מורכב. פריים הפתיחה לא מספר לך מה נופל, מה מופיע, מה תנאי הניצחון, או איך זה נגמר. כמעט בכל ז'אנר משחקים, אלמנטים מופיעים ככל שהשלב מתקדם – גלילת מסך חושפת עוד אויבים, עוד פלטפורמות, עוד power ups, ארכיטקטורת שלב וכו'. במשחקי match 3 הלוח משתנה עם תגובות שרשרת ואלמנטים שנוספים. במהג'ונג פני האריחים נחשפים רק כשהאריחים שמעליהם נלקחים. אתה חייב לצפות בשלב שלם משוחק (לפעמים יותר מפעם אחת) כדי להבין באמת מה יש בו.

כפי שציינתי, בחרתי משחקים "קלים" כדי לאמן את המערכת שלי. גם במהג'ונג וגם ב־Smash Fest, גם אם חלק מהאלמנטים מוסתרים בהתחלה – כולם נמצאים שם מתחילת השלב.

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

שלב 4 – ערוץ הקלט השני: מחקר ז'אנר

הצילומים הם ערוץ אחד. המחקר הוא הערוץ השני, וזה צד חשוב.

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

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

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

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

במקרה של Smash Fest, למשל, תת־הז'אנר לא היה בבסיס הידע שלי, אז הכול היה חייב להגיע מהווידאו ומחיפוש ברשת.

שלב 5 – לנתח את ז'אנר המשחק ולכתוב מסמכים

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

מכיוון שרציתי שהפיתוח ירוץ בלולאה עד סיום בלי שאני אהיה בלולאה – החלק הזה היה קריטי לעשות נכון. קראתי את תדריך העיצוב (הייתי VP Product בסטודיו משחקים במשך רוב העשור האחרון, סקירת עיצובים היא אזור הנוחות שלי...) והכנסתי תיקונים, ואחרי שהתוכנית הטכנית הייתה מוכנה קראתי, תיקנתי ואישרתי גם אותה. זה כנראה החלק שבו הייתה לי הכי הרבה עבודה בכל תהליך ה־video to game הזה.

שלב 6 – הנחיות אמנות: לעשות פחות, במכוון

ההנחיה הבסיסית שלי בניסוי הזה הייתה אל תשקיע מאמץ בחילוץ האמנות.

האמנות המקורית מוגנת בזכויות יוצרים. כל asset שמגיע מהפריימים האלה הוא placeholder שייזרק לפני שאפשר יהיה להשיק משהו. ליטוש שלו הוא בזבוז מוחלט של זמן וטוקנים.

אז הכלל הוא: קח מה שקל לחלץ, והשקע את המאמץ שלך בבניית משחק שקל להחליף בו assets פנימה והחוצה. asset מול asset. המבנה היה חשוב יותר ממה שהטקסטורה או התמונה בפועל היו (כי אי אפשר להשתמש בשום דבר מהאמנות המקורית).

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

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

באופן אישי, יש לי גם את כל חבילות ה־CC0 של Kenney (ששילמתי עליהן בשמחה) ב־MCP אישי שאני משתמש בו לאמנות placeholder. גם הקדשתי מזמן זמן לקטלג ולתאר כל אלמנט וכל חבילה, כך שבנק ה־assets ניתן לחיפוש בקלות.

אז יש לי סולם עלויות למילוי slots – חילוץ, פרוצדורלי, בנק assets, מיוצר – וכל slot שמולא חייב לציין איזה שלב בסולם מילא אותו. במקרה הזה אסרתי לייצר אמנות – המערכת הייתה מחלצת, מייצרת אמנות פרוצדורלית או מוצאת asset CC0 מתאים בבנק ה־assets.

שלב 7 – מימוש באמצעות לולאת השוואה

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

עכשיו מתחילה לולאת הפיתוח המרכזית:

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

נתתי ל־orchestrator agent מטרה ברורה – אני רוצה לראות משחק מתפקד וניתן למשחק (מינוס האמנות המדויקת) שבו כל שלב משוחק בדיוק כמו בווידאו. אז הוא צריך ללולאה שוב ושוב עד שהשלב זהה, האלמנטים מתנהגים אותו דבר ובתזמון הנכון. כלומר עד חצי שנייה למעלה או למטה בתזמון זה בסדר, אבל מעבר לזה זה אומר שמשהו לא בסדר. המימוש, פרמטר, מה שזה לא יהיה. תמשיך בלולאה עד שזה מתנהג אותו דבר. פיתוח בלולאה בלי מטרות ראויות לא יביא אותך לשום מקום. או שהוא ייעצר מוקדם מדי ויכריז שסיים, או שהוא ימשיך אחרי שסיים ויהרוס את הקוד (או ישרוף כל טוקן שיש לך).

שתי השוואות שונות רצות, ושתיהן נחוצות כי הן תופסות דברים שונים:

• השוואת ייחוס מדרגת את הצילום שלי מול פריימים מקובעים מהצילומים, על פי אינווריאנטים מוצהרים וניתנים למדידה – פריסה, גיאומטריה, פלטה גסה, והאם האייקון הנכון מקושר לתפקיד הנכון.
• ביקורת per-asset מדרגת את ה־assets עצמם מבחינת תוכן.

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

שתי מגבלות על הלולאה שחשובות:

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

שלב 8 – השערים שתופסים את השקרים הנוחים

שני שערים נוספים שהוספתי במסלול הזה.

חובה לבדוק את המשחק מנקודת המבט של השחקן. הפעל את ה־scene האמיתי, אל תשלח שום קלט, וכשל אם התמונה משתנה מעצמה באופן קבוע ורחב. הקביעות היא המבחן, לא התנועה – אנימציית idle ולולאות חלקיקים עוברות בסדר גמור. זה קיים כי לחיצה אחת על Play נתנה לי test harness שמריץ את עצמו במקום משחק. לחיצה על Play חייבת למסור לשחקן את המשחק.

אף slot של asset לא יכול להחזיק greybox. כל slot של תמונה מציין את השלב בסולם שמילא אותו, וכל טענה נבדקת מול הפיקסלים בפועל של הקובץ, כך שקופסה אפורה לא יכולה לענוד חותמת מקור. המערכת גם קוראת את ה־scenes של הפרויקט כדי לבדוק שהאמנות באמת נגישה – slot ששום scene לא מפנה אליו הוא יתום, ו־slot שה־scene שלו טוען קובץ שטוח אחר נתפס בנפרד.

גם זה הגיע מבעיות שהיו לי בהמרת וידאו המהג'ונג לקוד משחק – פעם אחת זה העביר כל slot בודד על build שמעולם לא הושווה לפריים ייחוס כלשהו. מניפסט assets נקי הוא לא משחק נראה. הוא רק מספר לך שקובץ אמיתי מגיע לכל slot דרך נתיב שהמנוע טוען. הוא לא דמיון ויזואלי והוא לא ביקורת אמנות.

שלב 9 – ה־GDD. מסמך עיצוב המשחק נכתב אחרון

זה נשמע הפוך, אבל ככה בחרתי לעשות את זה.

ה־GDD נכתב ב_סוף_ התהליך, ומיושב מול המשחק שבאמת קיים. כל טענה מכניקה בו נושאת את המקור שלה: [observed] מהצילומים, [inferred], [user-specified], או [unknown-unfilmed]. checker פוסל את המסמך אם טענה כלשהי חשופה.

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

מי עושה מה: קוד מול LLM

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

קוד רגיל, אפס LLM:

• חילוץ פריימים, נרמול קצב פריימים, hashing וקיבוע של קליפים
• זיהוי מקטעים, זיהוי חיתוכי סצנה, סיווג תנועת מצלמה לכל מקטע
• סגמנטציית מסכים וסריקות של פאות לא מוסתרות
• רשומת המדידה – מזהים, ציטוטים, מעברי קואורדינטות הלוך־ושוב
• ולידציה של רשימת ההיעדרים וטיעוני הכיסוי
• הגדרות slot, ייצור greybox, ולידציית התאמה ל־slot
• צילום מסך ובדיקת עשן של boot
• השוואת הייחוס וביקורות ה־per-asset
• השערים של הבדיקה מנקודת מבט השחקן ושל חיווט האמנות
• ה־leakage canary
• בדיקת מקור על תדריך העיצוב
• מאמת המסלול – מניפסט אחד, ריצה אחת, תוצאה אחת, ובכוונה אין שום דרך להקליד פסק דין ביד

דורש LLM:

• להסתכל על פריימים ולומר מה יש על המסך – והוא מדווח בחזרה בטקסט בלבד, עם רמת ביטחון וציטוט פריים לכל טענה, אף פעם לא על ידי הדבקת תמונות במעלה הזרם
• להחליט מה כנראה חוקי המשחק, מתוך מה שנצפה
• מחקר ז'אנר וריכוז המוסכמות
• כתיבת תדריך העיצוב, כיוון האמנות, ומסמך עיצוב המשחק בסוף
• כתיבת קוד המשחק בפועל (Godot)
• שיפוט האם הבדל ויזואלי משנה או לא
• החלטה אילו מהפגמים שסומנו לתקן קודם

התבנית: ה־LLM קורא, שופט וכותב. הקוד מודד, מסרב ומתעד. בכל פעם שתפסתי את המודל טועה שוב ושוב, הפתרון אף פעם לא היה לנסח את ההוראה בתקיפות רבה יותר – הוא היה להפוך את הכלל לסקריפט שנכשל.

המסקנות שלי

• אל תתייחס לפריימים כאל ערימה אחת. מסכים צריכים פריים אחד. מבנה שלב צריך בערך פריים לכל חצי שנייה (תלוי בז'אנר המשחק). VFX צריך קצב פריימים מלא. דגימה של שלושתם באותה דרך אומרת שאתה או טובע בנתונים או מפספס לגמרי את האפקטים.
• שלב הוא ישות זמנית ודינמית. ל־LLMs יש לפעמים נטייה להסיק את עיצוב השלב מתוך פריים פתיחה. ברוב המשחקים השלבים כוללים אלמנטים רבים שנחשפים רק תוך כדי משחק. צריך לנתח וידאו של שלב מתחילתו ועד סופו כדי לקבל את המידע הדרוש כדי לבנות אותו.
• אל תעבוד יותר מדי על האמנות. היא מוגנת בזכויות יוצרים, היא זמנית, היא הולכת להימחק. קח מה שזול לחלץ והמשך הלאה.
• השקע את המאמץ הזה ביכולת החלפה במקום. slots עם גדלים ותפקידים מוצהרים, ו־validator שבודק שתחליף באמת מתאים. החלפת asset מול asset היא התוצר.
• תגיד מה אתה לא יכול לדעת, לפני שאתה בונה. רשימת ההיעדרים היא השעה בעלת הערך הגבוה ביותר בכל התהליך. פערים שאתה נותן להם שם הופכים למשימות צילום; פערים שאתה לא נותן להם שם הופכים להמצאות.
• שתי השוואות, לא אחת. בדיקות ברמת המבנה מעבירות assets מזוהמים ישר הלאה. כל קופסה במקום הנכון, פיקסלים לא נכונים בתוכה.
• סדר את הבדיקות שלך כך ששום דבר לא מדרג את עצמו. צלם לפני שהפילטר קיים.
• שער שעובר הוא לא טענת דמיון ויזואלי. כתוב מה כל בדיקה לא אומרת, בפלט של הבדיקה עצמה. אחרת "כל ה־slots עברו" עלול להתפרש על ידי ה־LLM כ"המשחק נראה נכון".
• חסום את הלולאות שלך. שלושה ניסיונות, ואז הסלמה. למודל טוב יותר (שגם אותו אתה חוסם) או ישירות לבן אדם. לולאת "שפר עד שטוב" בלי חסם פשוט שורפת כסף בתרומה מזערית.
• כתוב את מסמך העיצוב המלא אחרון, עם מקור לכל שורה. כך יש לך נקודת מוצא מוצקה להתחיל לאיטרציות.

כל התהליך בתמונה אחת

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

flowchart TD
    A["Reference game<br/>name, developer, store links, phone video"]:::human --> B["Step 1 - Capture brief<br/>what to film and what each clip should reveal"]:::code

    B --> C["Step 2 - ABSENCE LIST<br/>coverage / resolution / unfilmed / observability"]:::code

    C -->|coverage or unfilmed gap| D["Film more"]:::human
    D --> B

    C -->|covered enough to proceed| E["Step 3 - Video processing<br/>extract, sample, timestamp, segment"]:::code

    E --> E1["Screens<br/>~1 frame each"]:::code
    E --> E2["Level structure<br/>~1 frame / 0.5 s"]:::code
    E --> E3["VFX / impacts / feel<br/>full frame rate"]:::code

    E1 --> F["Build evidence<br/>spans, camera regime, temporal level data,<br/>measurements with frame citations"]:::code
    E2 --> F
    E3 --> F

    F --> G["Read and interpret frames<br/>what is visible, with confidence + citation"]:::llm

    C -->|observability gap| H["Step 4 - Genre / game research<br/>knowledge base + web<br/>tag claims as research"]:::llm
    G --> H

    G --> I["Combine observed evidence<br/>with research / inference"]:::llm
    H --> I

    I --> J["Step 5 - Write design brief"]:::llm

    J --> K{"Human approves<br/>design brief?"}:::gate
    K -->|no| J
    K -->|yes| L["Write technical implementation plan"]:::llm

    L --> M{"Human approves<br/>technical plan?"}:::gate
    M -->|no| L

    M -->|yes| N["Step 6 - Define art guidelines + SLOTS<br/>declared size and role<br/>extract / procedural / CC0 / generated"]:::code

    N --> O["Step 7 - Build initial game implementation"]:::llm

    O --> P["Boot smoke test<br/>zero runtime errors"]:::code
    P --> Q["Capture constructed game state"]:::code

    Q --> R1["Reference comparison<br/>layout, geometry, palette, role binding"]:::code
    Q --> R2["Per-asset audit<br/>asset content"]:::code

    R1 --> S{"Defects?"}:::gate
    R2 --> S

    S -->|yes, attempts remain| T["Judge what matters and fix<br/>bounded retry loop"]:::llm
    T --> P

    S -->|retry budget exhausted| U["Escalate<br/>stronger model, then human"]:::gate

    S -->|clean| V["Step 8 - Final deterministic gates<br/>player-driven test<br/>no slot holds greybox<br/>art reachable from scenes"]:::code

    V --> W["Route verifier<br/>one manifest, one run, one result"]:::code

    W --> X["Step 9 - Write GDD LAST<br/>reconcile against implemented game<br/>tag every claim:<br/>observed / inferred / user-specified / unknown-unfilmed"]:::llm

    classDef code fill:#1e3a5f,stroke:#4a9eff,color:#e8f0fe
    classDef llm fill:#4a3b1a,stroke:#e0a83c,color:#fdf6e3
    classDef gate fill:#4a1f1f,stroke:#ff6b6b,color:#ffe8e8
    classDef human fill:#2a2a2a,stroke:#999,color:#eee

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

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