לפני שאני פותח Unity או Godot, אני בונה את המנגנון המרכזי ב-Three.js.
לא את כל המשחק. רק את הרעיון המרכזי — הדבר שאני באמת מנסה לאמת. האם הלולאה הזו מרגישה נכון? האם הקצב פגום? האם למנגנון הזה יש רגליים? אני בונה רק מספיק כדי לענות על השאלות האלה בדפדפן באחר הצהריים.
ואז אני שולח את הקישור לאנשים וצופה במה שהם עושים, לא במה שהם אומרים.
ה-workflow הזה שינה את הדרך שבה אני בונה משחקים. הנה למה.
העלות הפסיכולוגית של מנוע "אמיתי"
האינסטינקט המסורתי הוא לפתוח את Unity ו"פשוט להתחיל". אבל לפרויקט Unity יש משקל פסיכולוגי מיידי.
זה לא רק היררכיית הסצנה או ה-render pipeline; זו ההשקעה. עד שחיברתם את ה-Inspector, הגדרתם את ה-Character Controller שלכם, וטיפלתם ב-package manifests, הוצאתם מספיק זמן שהריגת הרעיון כואבת.
ההשקעה הזו משנה את הדרך שבה אתם מעריכים את המנגנון. אתם מתחילים לרציונליזציה של בעיות. אתם אומרים לעצמכם שהקפיצה "תרגיש טוב יותר ברגע שהאנימציות יוכנסו" או שהקרב "פשוט צריך עוד VFX". אתם נלחמים להציל רעיון בינוני כי כבר בניתם את הפיגומים עבורו.
כלי prototyping טוב צריך להיות עם אפס עלות החלפה. אם הרעיון לא עובד, אתם צריכים להיות מסוגלים לעזוב ללא רגשות אשם. Three.js הוא כרטיס האינדקס הדיגיטלי שלי: מהיר, חד-פעמי, וכן.
ה-URL הוא השחרור
Paper prototyping מצוין לבדיקת חוקים, אבל הוא לא יכול לבדוק תחושה. משחק קוביות על נייר אומר לכם אם החשבון נכון; הוא לא יכול להגיד אם ה"קליק" של הזריקה מספק.
כדי לבדוק תחושה, אתם צריכים artifact דיגיטלי. אבל artifact דיגיטלי הוא חסר תועלת אם אף אחד לא משחק בו. כאן הדפדפן מנצח. URL הוא בדיקת משתמש.
כשפרוטוטיפ הוא טאב בדפדפן, אני יכול לשלוח קישור לחמישה אנשים בהודעה ולקבל אות אמיתי תוך שעה. הם לא צריכים להוריד .zip של 200MB או לסמוך על קובץ native לא מוכר. הם פשוט לוחצים.
בעוד שמנועים כמו Unity יכולים לייצא ל-WebGL, "עלות ההחלפה" היא המחסום. סנדבוקס של Three.js הוא נייטיב לאינטרנט משורה ראשונה. השיתוף ללא חיכוך הזה מאפשר לי לעקוב אחר הכלל הזהוב של playtesting: לצפות במה שהם עושים. אני יכול לראות אם הם משתעממים בשלושים שניות. אני יכול לראות אם הם מנסים לתקשר עם העולם בדרך שלא התכוונתי. אי אפשר לקבל סוג כזה של משוב ללא חיכוך מ-build של מנוע נייטיב.
מקרה לדוגמה: Run & Roll
בניתי roguelite קוביות בשם Run & Roll כדי להוכיח את זה.
זמן פיתוח פעיל: כ-4-5 שעות. האילוץ: אף קובץ תמונה אחד. כל אויב ופאה של קובייה צוירו ב-JavaScript באמצעות canvas paths.
לבהירות: אותן "4 שעות" לא מחשבות את הזמן שביליתי במחשבות על המתמטיקה או את ההיכרות הקודמת שלי עם ה-API של Three.js. אבל כיוון שהאומנות הייתה רק קוד, לא היה לי pipeline לנהל. האות היה מיידי: שחקנים המשיכו להתחיל מחדש את הריצה אחרי מוות בלי שנשאלו. הפרוטוטיפ היה כל כך קל והמשוב היה כל כך ברור שהפרוטוטיפ הפך בעצם למוצר. לא העברתי אותו; פשוט ליטשתי אותו ושלחתי אותו.
ההעברה: פאזל המגנט
לפעמים, הפרוטוטיפ נועד למות. לאחרונה בניתי פאזל פיזיקה דו-ממדי שבו אתם מחליפים מגנט בין משיכה לדחייה כדי להנחות כדור.
לפני שמתחייבים לפרודקשן Unity מלא — עם URP, הגדרות ייצוא ל-Android, וארכיטקטורת נתוני שלב — בניתי את חישוב הכוח בסנדבוקס של Three.js.
ה-playtest חשף משהו קריטי: עקומת הכוח הרגישה איטית. כיווננתי עד שמהפך הקוטביות הרגיש זריז ומיידי. ברגע שאנשים אמיתיים אישרו שהלולאה המרכזית "דביקה", פתחתי את Unity. הארכיטקטורה המלאה הייתה ההשקעה הנכונה אחרי שהתחושה הוכחה.
גבולות הסנדבוקס
זה לא כדור כסף. ה-workflow הזה עובד הכי טוב למשחקים שמתמקדים במנגנון שבהם אומנות placeholder היא תחליף כן. הוא נכשל כש:
- המשחק מסתמך על תחושה מונעת-אנימציה (כמו משחקי character-action שבהם ה"תחושה" היא מערכת האנימציה).
- המשחק דורש סימולציות פיזיקה תלת-ממדיות מורכבות או multiplayer מקושר.
- אי אפשר לסמלץ את פלטפורמת היעד בטאב דפדפן (VR הוא הברור).
אבל לרוב הרעיונות העצמאיים, אלה לא הבעיות שאתם צריכים לפתור ביום 1.
אם אתם רוצים לראות איך נראה build Godot מלא אחרי שלב הפרוטוטיפ — בעזרת AI, מקצה לקצה — כתבתי על זה כאן.
הערה על "רצפת ה-Prototyping"
כשהרצתי טיוטה של הפוסט הזה דרך Gemini, הוא עשה משהו לא צפוי: הוא קרא את חשבון המגנט שלי ויצר מיידית סימולציית פיזיקה עובדת של המנגנון ישירות בחלון הצ'אט כדי להוכיח שהוא הבין את ה"תחושה".
זה היה מרשים, אבל זה חיזק את הנקודה שלי. סימולציה בחלון צ'אט מהירה יותר מ-Three.js, אבל היא לולאה סגורה. זה לא קישור שאני יכול לשלוח לזר בהודעה. זה לא artifact שחי בטבע.
רצפת ה-prototyping ממשיכה לרדת, אבל ה-URL נשאר הגשר האולטימטיבי בין "זה עובד על המכונה שלי" ל"זה עובד לשחקן".
אם אתם רוצים להעמיק על איך אני משתמש בכלי AI על פני ה-workflow המלא של הפיתוח — לא רק prototyping — זה כאן.
שחקו ב-Run & Roll: shaharbar2.itch.io/run-and-roll