עיצוב מכניקות משחק למובייל
כל פרויקט מובייל שני נכשל בגלל מכניקות משעממות: השחקן עוזב כבר בדקה השלישית, שימור היום הראשון יורד מתחת ל-20%. הסיבה היא לולאת משוב מעוצבת בצורה גרועה. אנו מעצבים את הלולאה המרכזית כך שכל הקשה מספקת מנת דופמין והלולאה המטא גורמת לשחקנים לחזור מדי יום. לדוגמה, עבור משחק חיתוך היפר-קז'ואל, שימור היום הראשון עלה מ-28% ל-41% לאחר הוספת הסלמת קושי באמצעות AnimationCurve. זמן שנחסך באיזון על ידי הוצאת פרמטרים ל-ScriptableObject: עד 30%. אנו מבטיחים עלייה בשימור ל-41% בהתבסס על ניסיון מעשי. צרו קשר לניתוח פרויקט.
במה שונה הלולאה המרכזית מהלולאה המטא
לולאה מרכזית — פעולה שחוזרת על עצמה כל 30–120 שניות. ב-Tower Defense: הצב מגדל → גל אויבים → תוצאה → משאבים → גל הבא. במשחק איידל: הקשה → מטבעות → שדרוג → יותר מטבעות לשנייה → פחות הקשות. הלולאה חייבת להיות מובנת ללא הדרכה ומספקת בפני עצמה. לולאה מטא — התקדמות על פני מספר סשנים: פתיחת מגדלים חדשים, דמויות, רמות. הלולאה המטא שומרת על השחקן בין סשנים — נותנת סיבה לחזור מחר. טעות נפוצה: עיצוב הלולאה המטא לפני הלולאה המרכזית. אם המשחק הבסיסי משעמם, שום התקדמות לא תציל את השימור. במשחק מובייל, הלולאה המרכזית צריכה להיות קצרה פי 3 מאשר במחשב בגלל הבדלים בטווח הקשב.
כיצד אילוצי המובייל משנים מכניקות
מסך המובייל מכתיב את המכניקות. לחיצה ב-100 אלפיות השנייה במחשב — הקשה ב-200 אלפיות השנייה על מסך מגע. עכבר עם דיוק פיקסלים — אצבע ברוחב 10 dp. אלה אינם חסרונות — הם פרמטרים עיצוביים. כפי ש-Game Design Workshop קובע, עיצוב מכניקות מובייל חייב להתחשב בעיכובים אלה.
עובד היטב במובייל:
- מכניקות החלקה (בסגנון Tinder, match-3, חיתוך)
- הקשה והחזקה (טעינה, כיוון)
- ניהול זמן (Cooking Dash) — זמן מוגבל על מסך קטן יוצר מתח
- צביטה לזום (אסטרטגיות, סימולטורים של עיר)
- גירוסקופ (מבוכים, משחקי מרוצים) — דרך
Input.gyroב-Unity
עובד בצורה גרועה:
- כיוון מדויק (משחקי יריות בעכבר)
- שליטה בו-זמנית במספר אובייקטים
- תגובות מהירות (<100 אלפיות השנייה) — מגבלה פיזיולוגית של מסכי מגע
עיצוב מכניקות עם חשיבה על מונטיזציה
מונטיזציה לא צריכה לשבור את הלולאה המרכזית. מערכת אנרגיה (חיים ב-Candy Crush) — חסימה מלאכותית של הלולאה המרכזית. עובדת מבחינת רכישות בתוך האפליקציה אך פוגעת בחוויית המשתמש. חלופה: מונטיזציה קוסמטית (סקינים, אפקטים) — אינה מגבילה את המשחק, שומרת על חוויית השחקן. אם הפרויקט משתמש במונטיזציה של פרסומות (וידאו מתוגמל דרך Unity Ads, AdMob, IronSource), מכניקות מעוצבות עם "רגעי החלטה" — נקודות שבהן השחקן צופה בפרסומת מרצון: המשך רמה לאחר הפסד, הכפלת פרס. פרסומות כפויות הורסות את הזרימה. הפחתת עלויות איזון באמצעות פרמטריזציה: עד 40%.
כיצד לעצב מכניקה: 5 שלבים
- הגדירו את הז'אנר וקהל היעד. להיפר-קז'ואל, הלולאה המרכזית צריכה להיות 5–30 שניות; ל-RPG, 10–30 דקות.
- ציירו מכונת מצבים של אירוע קלט → מצב → אפקט. ודאו שכל הלולאות נסגרות.
- הוציאו פרמטרים מספריים (מהירות, נזק, טיימרים) ל-
ScriptableObject(Unity) או קובץ JSON — זה מאיץ את האיזון פי 3 בהשוואה לקידוד קשיח. - בנו אב טיפוס עד היום החמישי ובדקו שימור על 20 נבדקים.
- חזרו על התהליך: לאחר שינויי מכניקה, שימור היום הראשון עולה בממוצע ב-10–15%.
// Пример state machine для слайсера (псевдокод)
states: IDLE, SWIPING, CUTTING, COMBO, EXPLOSION
IDLE -> SWIPING (on touch start)
SWIPING -> CUTTING (if collider hit)
CUTTING -> IDLE (if combo timer > threshold)
CUTTING -> COMBO (if combo multiplier active)
IDLE -> EXPLOSION (on bomb touch)
-> GAME_OVERמקרה בוחן: חותך היפר-קז'ואל
משחק היפר-קז'ואל ב-Unity, מכניקה: חיתוך (slicer). לולאה מרכזית: החלקה על אובייקטים → חיתוך → מכפיל קומבו → ניקוד גבוה. בדיקות ראשוניות הראו: שחקנים איבדו עניין עד הדקה השלישית — חוסר בהסלמה. הוספנו עלייה דינמית במהירות האובייקטים וסוגים חדשים ("פצצות" שלא ניתנות לחיתוך) דרך // Пример state machine для слайсера (псевдокод) states: IDLE, SWIPING, CUTTING, COMBO, EXPLOSION IDLE -> SWIPING (on touch start) SWIPING -> CUTTING (if collider hit) CUTTING -> IDLE (if combo timer > threshold) CUTTING -> COMBO (if combo multiplier active) IDLE -> EXPLOSION (on bomb touch) -> GAME_OVER ב-Unity — שימור היום הראשון עלה מ-28% ל-41%.
המרת משלמים ממוצעת לאחר הטמעת וידאו מתוגמל להמשך משחק הגיעה ל-3.5%.
תיעוד מכניקות
כל מכניקה מתועדת ב-GDD עם:
- תיאור פעולת השחקן
- משוב צפוי (מה הם רואים/שומעים)
- פרמטרים (מספרים, טיימרים, מכפילים) — בפורמט עבור
AnimationCurve - מקרי קצה: מה קורה ב-0 נקודות חיים, כשהמלאי מלא, בעת אובדן חיבור
קבועי פרמטרים בקוד הם אויב האיזון. כל הפרמטרים המספריים מועברים ל-ScriptableObject או קובץ JSON. מעצב המשחק יכול לכוונן את האיזון ללא מפתח.
מכניקות אופייניות לפי ז'אנר מובייל
| ז'אנר | לולאה מרכזית | מכניקות מפתח |
|---|---|---|
| היפר-קז'ואל | 5–30 שניות | קלט יחיד, הסלמת קושי |
| Match-3 | 2–5 דקות | מפל, אריחים מיוחדים, מאיצים |
| RPG | 10–30 דקות | קרב, שלל, רמות, משימות |
| Tower Defense | 5–15 דקות | הצבה, ניהול גלים, כלכלה |
| איידל | פסיבי | הקשה, שדרוג, רווחים אופליין |
| ראנר | 1–3 דקות | הימנעות ממכשולים, איסוף |
טעויות אופייניות בעיצוב מכניקות
| טעות | פתרון |
|---|---|
| עיצוב הלולאה המטא לפני הלולאה המרכזית | קודם כל הפכו את הלולאה המרכזית למרתקת |
| פרמטרי איזון מקודדים קשיח | הוציאו ל-ScriptableObject |
| התעלמות מהשהיית מגע | קחו בחשבון עיכוב הקשה של 200 אלפיות השנייה |
| פרסומות כפויות בלולאה המרכזית | השתמשו בוידאו מתוגמל ברגעי החלטה |
מה כלול בעבודה
- ניתוח ז'אנר וקהל יעד
- עיצוב לולאה מרכזית בהתחשב בקלט מובייל
- תיאור כל המכניקות עם פרמטרי איזון
- מכונת מצבים דיאגרמות למערכות מפתח
- תיעוד בפורמט GDD (סעיפי מכניקות)
- המלצות מונטיזציה מבלי לשבור את המשחק
- בדיקת אב טיפוס של המכניקה המרכזית (בהסכמה)
לוח זמנים
3–5 ימי עבודה לעיצוב מכניקות לפרויקט היפר-קז'ואל או קז'ואל. למידקור RPG / אסטרטגיה עם מספר מערכות מחוברות — 5–10 ימים. המחיר מחושב בנפרד לאחר ניתוח קונספט.
צרו קשר להערכת פרויקט. הזמינו עיצוב מכניקות מקצה לקצה וקבלו אב טיפוס לבדיקת שימור תוך שבוע.