התשובה הקצרה
אין מודל AI אחד שהוא הטוב ביותר ליצירת משחקי וידאו, כי יצירת משחק היא לא משימה אחת. היא הרבה משימות: כתיבת לוגיקת המשחק, תיקון באגים, עיצוב שלבים, יצירת גרפיקה, הפקת סאונד וחיבור של הכול יחד כדי שהמשחק ירוץ. מודלים שונים חזקים בחלקים שונים, והדירוגים משתנים כל כמה חודשים עם יציאת גרסאות חדשות.
במקום לרדוף אחרי מנצח שיתיישן במהירות, התמקדו במה שקובע את האיכות. ברגע שתבינו זאת, תוכלו לשפוט כל כלי או מודל בעצמכם.
מדוע המודל הוא רק חלק מהתמונה
מודל גולמי מנבא טקסט. כדי להפוך פרומפט למשחק שרץ, המערכת שסביב המודל צריכה לתכנן, לערוך קבצים, לאמת קוד ולתקן כשלים. המערכת הזו קובעת אם תקבלו משהו שאפשר לשחק בו או קיר של קוד שבור.
מערכת כזו לרוב כוללת:
- סט ברור של כללים שמסביר למודל איך לבנות משחק, ולא רק פרומפט חשוף.
- תבניות וקוד בסיס כך שהמודל לא יצטרך להמציא מחדש את התשתית המשעממת בכל פעם.
- דרך להריץ את הקוד שנוצר, לזהות שגיאות ולהעביר אותן בחזרה למודל לניסיון תיקון.
- יצירת גרפיקה משולבת וסאונד מהספרייה, כך שהנכסים נטענים במשחק.
- בדיקות קוד לצד בדיקת משחק בדפדפן, ותוצאות שלא נבדקו מסומנות כלא מאומתות.
שני מוצרים יכולים להשתמש באותו מודל בסיסי ולהפיק תוצאות שונות לחלוטין, פשוט כי לאחד יש מערכת חזקה סביבו ולאחר אין. זו הסיבה שמדד ביצועים של מודל גולמי לא מעיד הרבה על איכות הכלי ליצירת משחקים.
כיצד יכולות המודל משתנות בהתאם למשימה
הנה מפה גסה של המקומות שבהם מודלים עוזרים, כללית בכוונה, כי פרטים מתיישנים מהר:
- יצירת קוד: מודלים גדולים ומסוגלים יותר לרוב טובים יותר בייצור לוגיקת משחק רצה ובתיקון באגים כשמשהו משתבש. זה המקום שבו תשלום עבור מודל חזק יותר משתלם לרוב.
- איטרציה חסכונית: מודל זול יותר יכול להתאים לשינוי קטן ומוגדר היטב. זמן התגובה שלו תלוי במשימה, בכלים, בהיקף החשיבה ובעומס אצל הספק, כך שקטן יותר לא תמיד אומר מהיר יותר.
- גרפיקה ותמונות: מודלי תמונה הם משפחה נפרדת ממודלי טקסט. המודל שכותב את לוגיקת המשחק הוא לא זה שמצייר את הספרייטים.
- סאונד ומוזיקה: שוב, מדובר במודלים מיוחדים ונפרדים, אבל סאונד ומוזיקה מגיעים מספרייה של הקלטות אמיתיות.
המסקנה המעשית היא שאף מודל יחיד לא עושה את כל זה בצורה מושלמת, ולכן כלי משחקים רציני מחבר כמה מודלים יחד במקום להמר על אחד בלבד.
למה להמר על מודל אחד זו מלכודת
כל מאמר שבוחר מנצח אחד קבוע יתיישן מהר. גרסאות חדשות יוצאות לעיתים קרובות, ומודל שמוביל ברבעון אחד עלול להישאר מאחור ברבעון הבא. רדיפה אחרי טבלאות הדירוג היא דרך לא יעילה לבחירת כלי ליצירת משחקים.
עמיד יותר לשאול שאלות טובות יותר. האם הכלי מריץ ובודק את הקוד שהוא כותב? האם הוא מתאושש מהשגיאות של עצמו? האם הוא מפיק משהו שאפשר לשחק בו, ולא קטע קוד שצריך להרכיב לבד? התכונות האלה מחזיקות מעמד יותר מכל גרסת מודל.
איך זה עובד ב-OddShed
OddShed בנוי סביב הרעיון הזה. במקום לבקש מכם לבחור מודל של ספק, הוא נותן לכל חשבון את אותו צוות סוכנים: בונה כותב את הקוד, אמן מצייר את הגרפיקה, מעצב סאונד בוחר אפקטים קוליים ומוזיקה, ובודק QA מנסה כל גרסה בדפדפן כשאפשר. את המודלים שמאחורי כל אחד מהם OddShed בוחר בשבילכם.
OddShed בונה משחקי דפדפן עם Phaser לדו־ממד ו-Three.js לתלת־ממד, וכל תור מציג בדיוק כמה עלה ברגע שהוא מסתיים. במרכז עומדת המערכת, לא שם של מודל.
סיכום
- אין מודל אחד שהוא הטוב ביותר. התשובה תלויה במשימה ומשתנה במהירות.
- המערכת סביב המודל חשובה יותר משם המודל עצמו כדי לקבל משחק שניתן לשחק בו.
- מודלים חזקים עוזרים בעיקר ביצירת קוד ותיקון באגים; מודלים קלים יותר מספיקים לשינויים קטנים.
- שפטו כלי לפי היכולת שלו להריץ, לבדוק ולתקן את הפלט של עצמו, ולא לפי המודל שהוא טוען להשתמש בו.