אני עושה "vibe coding" של משחקים שלמים ב-Unity כבר זמן מה — אני בעצם מלמד מאסטרקלאס שלם על איך לעשות את זה. אבל לאחרונה, מצאתי את עצמי שואל שאלה חדשה: עד כמה ה-workflow AI מבוסס-טרמינל שלי מתורגם למנוע משחק שונה לחלוטין?
כדי לבדוק את זה, החלטתי להריץ ניסוי: לבנות קלון מלא של Flappy Bird ב-Godot 4.4 עם AI כשותף התכנות היחיד שלי.
לא רציתי דמו פיזיקה פשוט. רציתי טיפול מובייל מודרני מלא — מטא-פרוגרסיה, כלכלת מטבעות, חנות עם קוסמטיקה, סקיילינג קושי, ורקעים פרלקסיים.
בעוד שסטאק תזמור ה-AI שלי הוא בדוק-קרב לעבודה המקצועית שלי ב-Unity, לתת לו לנהוג ב-Godot מאפס היה גבול חדש לגמרי עבורי. במהלך שני סשנים אינטנסיביים, דחפתי את הגבולות של ההגדרות האלה כדי לראות עד כמה רחוק אפשר להגיע לפני שהדברים מתפרקים.
הנה בדיוק איך נראו ההגדרות, מה עבד, מה נשבר, ולמה הניסוי הזה באמת שינה את האופן שבו אני רואה מנועי משחק שונים.
1. ההגדרות: סטודיו וירטואלי בטרמינל
לפני שכתבתי שורת GDScript אחת, הקמתי את סביבת התזמור שלי. השתמשתי ב-CLI של Claude Code של Anthropic, אבל הנשק הסודי היה התוסף oh-my-claudecode.
למי שלא השתמש בו, התוסף הזה פועל כשכבת תזמור. במקום להסתמך על חלון צ'אט AI אחד שינחש את דרכו דרך פרויקט, הוא מאפשר לכם לנתב משימות שונות ל"עובדי" AI מתמחים. בעצם יצרתי סטודיו וירטואלי זעיר.
פירקנו את המשחק ל-20 משימות נפרדות — מבניית SaveManager ב-JSON, ועד חיווט כלכלת המטבעות, ועד קידוד טוסטים של הישגים שמחליקים פנימה. כל משימה עברה מחזור מחמיר:
- Spec Agent: מעצב את ה-API ואת הארכיטקטורה.
- Implementation Agent: כותב את ה-GDScript בפועל ואת קבצי הסצנה.
- Review Agent: מבקר את הקוד לבאגים לפני שממשיכים.
באמצע הדרך, גם חיברתי את Godot MCP Server (באמצעות Model Context Protocol של Anthropic) כך שה-AI יוכל ממש להריץ את הפרויקט ללא ראש ולקרוא את פלט הקונסול.
2. מה שעבד: ה-AI כארכיטקט בכיר
ציפיתי שהפרויקט יקרוס תחת המשקל שלו עצמו סביב משימה 10. באופן מפתיע, ה-AI הצליח להרבה מערכות מורכבות מהניסיון הראשון.
- הארכיטקטורה החזיקה: ה-AI בנה autoload singleton יחיד של
GameManager, השתמש בניתוק מבוסס-signal בין ה-UI ל-gameplay, ושמר על מבנה קפדני של סצנה-לכל-ישות. הוא שרד את כל 20 הפיצ'רים בלי צורך ב-refactor. - עיצוב מודע-פלטפורמה: מכיוון שציינתי שאנחנו מכוונים ל-HTML5 Web Export, ה-AI עשה בחירות מבריקות ספציפיות למנוע. במקום לכתוב ל-IndexedDB של האינטרנט בכל לקיחת מטבע (מה שגורם לסערות כתיבה מסיביות ולפיגור), הוא בנה באופן יזום מערכת שמירה עם בופרינג שרק התרוקנה במסך Game Over.
- מחזור הביקורת: קיום סוכן AI נפרד שמבקר את הקוד תפס באגים אמיתיים. הוא שם לב כשחוזה ה-API של החנות הופר וסימן race condition שבו אנימציית Tween יכלה לחפוף לקריאת
kill().
3. הנקודות העיוורות: איפה ש-Vibe Coding נשבר
בעוד שקוד המערכות היה מדהים, ה-AI נתקל בקיר ברגע שהיה צריך להתמודד עם מצבי runtime. הוא נכשל בשתי דרכים שונות מאוד:
- עריכת סצנה עיוורת (כשל מרחבי): סוכני ה-AI ערכו קבצי
.tscnשל Godot ביד בטרמינל. כיוון שחסרה להם כל מודעות מרחבית של ה-viewport, הם הגדירו את ספרייט המדליה ותווית הניקוד לאותה מיקום Y בדיוק, מה שגרם לבאגי UI חופפים. - מלכודת ה-"Variant" Inference (כשל ניתוח סטטי): זה היה סוג שונה לגמרי של נקודה עיוורת. הטיפוס הסטטי הקפדני של Godot תפס 8 באגים שונים שהמבקר ה-AI החמיץ. ה-AI לא הבין ששיטות כמו
JSON.parse_string()מחזירותVariantב-Godot 4.4. כיוון שה-AI עשה ביקורת קוד סטטית במקום בדיקת runtime, האזהרות-כשגיאות הקפדניות האלה הקריסו את המשחק עד שהשתמשתי ב-Godot MCP כדי לאפשר ל-AI לקרוא את לוגי ה-runtime. - כשל האינטגרציה: ה-AI בנה
DifficultyManagerיפהפה שסיקלל את פער הצינורות בצורה מושלמת ככל שהניקוד שלכם גדל. הבעיה? סצנת הצינור בפועל הייתה עם פער של 200 פיקסל מקובע. ה-AI ביקר את הקוד באופן מושלם אבל נכשל לחלוטין באימות שצורות ההתנגשות הפיזיות באמת השתמשו בנתונים.
4. ליטוש ויזואלי ו-CI/CD Pipeline
אתם יכולים לקבל את מערכת ההישגים המתוחכמת ביותר בעולם, אבל אם המשחק שלכם נראה כמו חלום קדחת של אומנות פרוגרמרים, ה"ויב" נהרס לחלוטין. איכות ויזואלית היא לא nice-to-have; היא נושאת עומס.
ברגע שהמערכות נבנו, ביקשתי מ-Claude לכתוב סקריפטי Python (במיוחד באמצעות ספריית התמונות Pillow) כדי לייצר ספרייטים פשוטים אבל מגובשים של אומנות פיקסל — חשבו על צורות גיאומטריות נקיות, טקסטורות צינור ברורות, וצללית ציפור ניכרת — ולחווט אותם לתוך nodes של הסצנה.
תנו לי להיות ברור מאוד, בכל זאת: בעוד שהפלט היה צעד מסיבי קדימה ממלבני placeholder, האומנות עדיין חסרת לחלוטין סגנון או נשמה ייחודיים. אם הניסוי הזה לימד אותי משהו על אסתטיקה של משחקים, זה שכרגע אין שום תחליף לאיש אומנות ייעודי שעובד לצד ה-AI כדי לתת למשחק אופי וחזון אמיתיים.
הרגל CI/CD מועיל: עשיתי אוטומציה מלאה של הדפלוימנט. לימדתי את ה-AI להפעיל ייצוא Godot ללא ראש ישירות מה-CLI ולהשתמש ב-butler push כדי לשלוח את ה-.pck (קבצי המשחק הארוזים של Godot) ובינארי WASM ישירות ל-itch.io. המשחק עבר מפרומפט טרמינל ל-משחק ווב חי וניתן לשחק תוך דקות.
הפסיקה הכנה: Godot מול Unity
אחרי שבניתי את זה מא' עד ת', הגעתי למסקנה מפתיעה: Godot הוא כרגע מנוע המשחק הטוב ביותר לעבודה עם AI. כיוון שקבצי הסצנה .tscn של Godot הם טקסטואליים בלבד והאקוסיסטם שלו משולב עמוקות עם סקריפטינג קל (GDScript), LLMs יכולים לקרוא, להבין, ולתמרן פרויקטי Godot ברמת שטף נייטיב שקשה מאוד להשיג במקומות אחרים. זה מנוע ה-"vibe coding" האולטימטיבי כרגע.
עם זאת... אני עדיין מעדיף בחזקה את Unity לפיתוח המשחקים המקצועי שלי. בעוד ש-Godot מדהים ל-prototyping מהיר עם AI, האקוסיסטם הבוגר של Unity, חנות הנכסים המסיבית, עומק ה-middleware של צד שלישי, וצינורות ה-deployment המוכחים עדיין חסרי השוואה לסקיילינג של מוצר מקצועי ומסחרי.
AI הוא בעצם מפתח ג'וניור מהיר מאוד ומלא ידע מאוד שלא יכול לראות את המסך. הוא מכפיל כוח מסיבי עבור boilerplate וקוד מערכות, אבל הוא לא מחליף ארכיטקטורת מנוע יציבה או עין של מעצב אנושי.
קוד המקור המלא לפרויקט הזה זמין ב-GitHub.
הניסוי הזה נבנה על אותם יסודות workflow בדיוק שאנחנו מלמדים בקורס ה-vibe coding שלנו. אם אתם רוצים לצאת מהדפדפן וללמוד איך לבנות את הצינורות האוטומטיים האלה בעצמכם, בדקו את המאסטרקלאס של Itay.
