Game Engines in the Age of AI-Based Game Development

AI משנה את הדרך שבה אנחנו צריכים לחשוב על מנועי משחק.

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

במשחקי מובייל, התשובה הייתה ברורה: Unity.

Unity עדיין שולטת בפיתוח מסחרי של משחקי מובייל. יש לה את ה־SDKs, רשתות הפרסום, כלי האנליטיקה, אינטגרציות IAP, כלי attribution, פלאגינים, Asset Store, מדריכים וניסיון הפקה. במשך שנים היא הייתה ברירת המחדל.

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

אבל זה הופך להרבה פחות רלוונטי ברגע שהעבודה עוברת מפיתוח שמונע על ידי בני אדם לפיתוח שמונע על ידי AI.

כש־AI agents עושים חלק גדול מעבודת הפיתוח, השאלה האמיתית הופכת להיות:

עם איזה מנוע AI יכול לעבוד בצורה נקייה, מהירה ואוטונומית?

מהזווית הזאת, התמונה משתנה.

Unity: אקוסיסטם חזק, התאמה חלשה ל־AI

היתרון הכי גדול של Unity הוא האקוסיסטם שלה.

החולשה הכי גדולה שלה היא שאף אחד לא תכנן אותה לפיתוח AI אוטונומי. זה מנוע שמבוסס על Editor-state.

הבעיות העיקריות הן:

• Unity היא מנוע שמבוסס על Editor-state חלק גדול מהמצב האמיתי של הפרויקט חי בתוך Unity Editor, ה־Inspector, קבצים מסוריאלים, metadata של assets, GUIDs ורפרנסים שנוצרים על ידי ה־Editor. AI עובד הכי טוב כשהוא יכול לבדוק ולערוך קבצים ברורים. Unity נשענת מאוד על התנהגות של ה־Editor, ש־LLM לא תמיד יכול לראות או לשנות ישירות בצורה בטוחה.
• הserialized formats של Unity שבירים Unity לא הופכת לידידותית ל־AI רק בגלל שחלק מהקבצים שלה הם טקסטואליים. ה־serialized YAML שלה הוא פורמט ייחודי ל־Unity, שביר, קשור להתנהגות של ה־Editor ושל תהליך ה־import, והוא משטח עריכה גרוע ל־LLMs. זה לא פשוט כמו JSON, XML או קבצי config רגילים. טעות קטנה יכולה לשבור scenes, prefabs או assets.
• רפרנסים ל־assets יוצרים סיכון הרבה שינויים ב־assets, scenes, prefabs, import ורפרנסים תלויים בקבצי .meta, ב־GUIDs וב־import pipeline של Unity. אם ה־AI מטפל בהם לא נכון, הוא יכול לשבור את הפרויקט בדרכים שקשה לאבחן ולתקן.
• ה־Editor עדיין יושב באמצע גם עם כלי MCP, Unity Editor עדיין צריך לעיתים קרובות להישאר פתוח ורץ. ה־MCP מגשר בין ה־AI agent לבין Unity, אבל הוא לא מסיר את התלות של Unity ב־Editor. ב־MCP workflows אמיתיים שמונעים על ידי Editor, Unity עדיין יכולה להיתקע בגלל editor state, בעיות scripting thread, reloads, דיאלוגים, אינטראקציות שתלויות בפוקוס, או התנהגות של פלאגינים. אם זה נגרם על ידי Unity או על ידי שכבת ה־MCP זה כמעט לא משנה: התוצאה המעשית היא לולאת AI שבירה.
• Headless, server ו־parallel workflows עדיין חלשים Unity טכנית יכולה לרוץ במצב batch ו־headless/no-graphics. טכנית, כן. מעשית, לא באמת. בהשוואה ל־Godot, Unity נשארת יעד אוטומציה כבד, איטי, מנופח, מרוכז סביב Editor, ורגיש לרישוי. היא לא רצה באופן טבעי בהרבה אינסטנסים headless קלים, מקומית או על שרת. Server builds בדרך כלל דורשים מכונות חזקות יותר ותשומת לב גדולה יותר לרישוי. להריץ כמה אינסטנסים של Unity במקביל זה כמעט בלתי אפשרי בפועל: אינסטנס אחד כבר איטי וכבד, ולהריץ יותר מאחד במקביל יביא את הפרודוקטיביות שלך קרוב לאפס. במיוחד כשמנועים אחרים כמו Godot עושים את זה בלי מאמץ.
• Unity איטית יותר Unity נטענת לאט, עושה reload להכול כל פעם, מרעננת לאט, מקמפלת לאט ורצה לאט. הזכרתי את המילה “לאט”? לא מספיק. פיתוח עם AI הוא ממילא לא הדבר הכי מהיר כשעובדים עם frontier models, אז Unity מוסיפה עוד חיכוך לכל איטרציה. אם Unity לא מרגישה לך איטית, או שאתה עובד על מחשב סופר־חזק, או שלא ראית מנוע משחק אחר כבר שנים.

זאת הסיבה ש־Unity מרגישה כל כך רע לפיתוח AI אוטונומי.

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

זאת הלולאה הבסיסית כשעובדים בפיתוח עם AI:

Human-AI Feedback → plan → generate files → run in engine → test → errors → fix bugs/params → (repeat)

Unity הופכת את הלולאה הזאת לכבדה ואיטית יותר.

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

בלי שינוי ארכיטקטוני גדול, אני לא חושב שזה ישתפר מספיק. Unity תצטרך להפוך לפחות תלויה ב־Editor, יותר שקופה טקסטואלית, קלה יותר להרצה headless, קלה יותר לאוטומציה, פחות תלויה ב־hidden state, בטוחה יותר לעריכה ישירה על ידי LLMs, ומהירה יותר בטעינה, רענון ובנייה.

העתיד כנראה אינו רק “AI assistant בתוך Unity”. העתיד הוא לולאת פיתוח AI סביב כל הפרויקט, עם כלי CLI שמובילים את האוטומציה.

זה לא feature update קטן. זה שינוי ארכיטקטוני עמוק.

Godot: אקוסיסטם חלש יותר, התאמה הרבה יותר טובה ל־AI

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

אבל ל־Godot יש יתרונות גדולים לפיתוח מבוסס AI:

• היא פתוחה, קלה ושקופה יותר. Godot היא open source. קבצי הפרויקט שלה טקסטואליים ומובנים יותר, ומודלי AI יכולים לבדוק ולשנות אותם בקלות רבה יותר.
• הרבה יותר קל לעשות לה אוטומציה. Godot רצה headless בקלות רבה יותר, עובדת טוב יותר על שרתים, ומתמודדת הרבה יותר טוב עם כמה אינסטנסים במקביל.
• האיטרציה מהירה יותר. עם אותו מודל AI, workflows ב־Godot זזים הרבה יותר מהר מאשר workflows ב־Unity. ה־agent יכול לערוך קבצים, להריץ את הפרויקט, לבדוק התנהגות ולהמשיך לעשות איטרציות בלי להילחם כל הזמן ב־Editor.

מהניסיון שלי, במשחקים פשוטים יכול להיות אפילו מהיר יותר לבנות את הגרסה הראשונה ב־Godot ואז לבקש מה־AI להמיר אותה ל־Unity, במקום לפתח ישירות ב־Unity מההתחלה.

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

Godot הופכת את הלולאה הזאת להרבה יותר נקייה.

החולשה הכי גדולה של Godot היא עדיין האקוסיסטם המסחרי. עדיין אין לה את הרמה של Unity ב־mobile ads SDKs, אינטגרציות IAP, אנליטיקה, attribution, mediation, כלי צד שלישי production-ready, ידע מסחרי במובייל, או עומק של Asset Store.

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

Web engines: מעולים ל־AI, חלשים כפלטפורמה עסקית

Three.js, Phaser ומנועי web אחרים היו בעבר די נישתיים לפיתוח משחקים רציני. אנשים השתמשו בהם למשחקי web, פרוטוטייפים, creative coding, דמואים אינטראקטיביים וניסויים ויזואליים, אבל לעיתים רחוקות התייחסו אליהם כאל אלטרנטיבה רצינית ל־Unity עבור משחקי מובייל מסחריים.

AI הופך אותם להרבה יותר מעניינים.

Web engines מתאימים מאוד ל־AI workflows כי הפרויקטים ברובם טקסטואליים, קלים, מהירים להרצה, קלים לפריסה, וקלים להבנה עבור LLMs. JavaScript, TypeScript, JSON, HTML, CSS ו־browser workflows כולם מאוד נגישים למודלי AI. לא צריך Editor ענק או build pipeline כבד. אפשר להריץ את המשחק בדפדפן, לבדוק אותו, לשנות אותו, לעשות reload ולהמשיך להתקדם.

זאת הסיבה שאנחנו רואים עכשיו התפוצצות של משחקי web, אנימציות וחוויות אינטראקטיביות שנוצרו עם AI ונראים מרשימים. Game Jam עם 1000 כניסות, רבות מהן מרשימות ויזואלית. ה־workflow נקי ומהיר.

אבל ל־web engines יש בעיה אחרת:

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

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

לכן web engines עובדים מצוין לפרוטוטייפים, דמואים, ניסויים מהירים, playable concepts, ויזואליות שנוצרת עם AI, שיתוף מיידי וחוויות web-first. אבל למשחק מסחרי רציני, במיוחד משחק מובייל, web לבדו בדרך כלל לא מספיק.

אם היעד הוא web פלוס מובייל, או web פלוס פלטפורמות אחרות, זה נהיה מעניין יותר. אבל בשלב הזה עדיין צריך production pipeline אמיתי, וכנראה גם אסטרטגיית מנוע נכונה סביב Unity, Godot, או web-to-mobile stack שבאמת מוכן לפרודקשן. בפועל, הרבה יותר טוב לפתח על מנוע מתאים ולהפיק גם build למובייל וגם build ל־web, מאשר להכין גרסת Three.js/Phaser של המשחק עבור web.

היום מול מחר

AI משנה את התמונה כשמסתכלים קדימה על פיתוח משחקים.

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

על הציר הזה, Godot נמצאת במצב הרבה יותר טוב מ־Unity.

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

Godot בעיקר עדיין צריכה להגדיל את האקוסיסטם שלה.

Unity צריכה לשנות את הארכיטקטורה שלה.

אני חושב של־Godot יש את הבעיה הקלה יותר.

---

הערות נוספות:

כדי לתת קצת קונטקסט, זה המקום שממנו מגיע הניסיון שלי:

כמו רבים אחרים, אני מפתח ומשתמש ב־Claude Code/Codex harness לבניית משחקים מסחריים, לשימוש פנימי בלבד. הוא מכסה גם Unity וגם Godot, ואני משתמש ב־web engines כמו Three.js, עם או בלי Rapier, וגם ב־Phaser, כדי לעשות פרוטוטייפים מהירים להרבה רעיונות חדשים.

ה־Unity stack כולל את ה־harness שלי, את Ivan Murzak’s Unity MCP, ואת Unity 6. עד עכשיו, ה־MCP של Ivan Murzak הוא ה־Unity MCP הכי טוב שבדקתי, ואני ממשיך לבדוק אחרים. פיתחתי גם wrapper סביב ה־MCP כדי להפוך את ה־CLI לחזק ומהיר יותר. אני משתמש גם ב־Figma MCP וב־Unity ו־Figma skills שלי כדי לנהל UI/gameplay במשחקים עם הרבה מסכים ופופאפים.

ה־Godot setup שלי כולל knowledge base משלי ל־Godot עבור קוד ואפקטים, עם מיקוד ב־Godot 4+, מכיוון ש־LLMs בדרך כלל מאומנים על קוד של Godot 3. אני משתמש גם ב־GoPeak Godot MCP כדי לעבוד בצורה יעילה עם המנוע. ההבדל בין Unity ל־Godot מאוד ברור בפועל: אני כמעט לא פותח את ה־Godot editor ידנית.

אני לא עובד עם Unreal Engine, ומעולם לא עבדתי איתו, ולכן אני בכוונה לא מתייחס אליו במאמר הזה.

קריאה נוספת

• AI Coding Tools for Video Game Development: A First-Principles Analysis of What Actually Works — Chier Hu
• Why AI Writes Better Game Code in Godot Than in Unity — DEV Community
• Unity AI’s Open Beta Now Live for Unity 6 — Unity Discussions
• Request for Official Clarification: Unity MCP Access, Subscription Requirements, and Future Policy — Unity Discussions