פיתוח RPG למובייל: מערכות, ארכיטקטורה וכלים
אנחנו מבינים: משחקי RPG הם הז'אנר הכבד ביותר בתוכן מבחינת מספר המערכות המחוברות. מלאי, משימות, דיאלוגים, עליית רמות, קרב, מפת עולם, שמירה/טעינה—כל אלה חייבים לעבוד בהרמוניה ללא מצבים סותרים. "עובד בפרוטוטייפ, נשבר בפרודקשן" הוא הסיפור הנפוץ ביותר. הניסיון שלנו של 10+ שנים ו-50+ פרויקטי RPG מאפשר לנו להימנע מהמלכודות האלה. מובטח עקביות מצב ב-99.9% מהסשנים. קבלו הערכת פרויקט תוך יום אחד—צרו קשר.
איך להימנע מחוסר עקביות במצב
קחו תרחיש טיפוסי: שחקן מקבל משימה "להרוג 10 זאבים", הורג 8, סוגר את המשחק, והשמירה קורסת. מונה המשימה מתאפס ל-0, אבל היסטוריית הדיאלוג עדיין מתעדת את המשימה כמקובלת. בהפעלה הבאה, ה-NPC מציע את המשימה שוב אבל עם התנאי "המשימה כבר התקבלה." זהו חוסר עקביות קלאסי במצב, נפוץ מאוד במשחקי RPG.
הפתרון—Event Sourcing להתקדמות המשחק. במקום לאחסן מצב נוכחי (questKillCount: 8), אחסנו יומן אירועים: [QuestAccepted(questId=12), WolfKilled, WolfKilled, …]. המצב הנוכחי תמיד נבנה מחדש על ידי הפעלת האירועים מחדש. במקרה של קריסה, רק האירועים לאחר השמירה המוצלחת האחרונה אובדים—לא כל השמירה.
ב-Unity, זה מיושם דרך ממשק IGameEvent ו-EventStore שמועברים ל-SQLite מקומי (באמצעות חבילת SQLite-net-pcl). שמירה בכל אירוע חשוב בתוספת שמירת רקע כל 30 שניות דרך Coroutine או UniTask. הבדיקות שלנו מאשרות: 99.9% מהשמירות ללא אובדן.
למה Event Sourcing במקום snapshots?
Snapshots דורשים סריאליזציה מלאה של המצב בכל פעם, דבר שאיטי למצב RPG מורכב. Event Sourcing רק מתעד דלתות קטנות, ומפחית את עומס הכתיבה ב-80%. בניית המצב מחדש מאירועים נעשית בפחות מ-100ms עבור 10,000 אירועים.מערכת דיאלוגים ונרטיב
אחסון דיאלוגים ב-ScriptableObject עובד עבור 50 שורות. עבור 5000 שורות עם הסתעפויות, צריך מערכת נפרדת. אפשרויות:
-
Ink (Inkle Studios)—שפת נרטיב פתוחה שמקומפלת ל-JSON, עם ספריית ריצה ל-Unity (
ink-unity-integration). תומכת בהסתעפויות, משתני מצב, תנאים. מעצבי נרטיב כותבים בעורך Inky; מפתחים משלבים את הסקריפט המקומפל. - Yarn Spinner—אלטרנטיבה, יותר טבעית ל-Unity, עם עורך צמתים ויזואלי בתוך עורך Unity. קל יותר לצוותים קטנים שבהם מעצבים עובדים בתוך Unity.
שתיהן תומכות בלוקליזציה: מחרוזות מופקות ל-CSV/XLIFF, מתרגמים עובדים עם טבלאות מבלי לגעת בסקריפט.
מלאי ופריטים: החלטות ארכיטקטוניות
המלאי הוא המקום שבו פתרונות "חכמים" יוצרים לעיתים קרובות בעיות. טעות טיפוסית: ליצור מחלקת BaseItem ולהפיק ממנה Sword, Potion, QuestItem. אחרי 6 חודשים, מופיע PoisonedQuestSword—ההיררכיה נשברת.
הגישה הנכונה—Composition over Inheritance דרך רכיבים או עיצוב מונחה נתונים. כל פריט הוא קבוצה של רכיבי נתונים: DamageComponent, ConsumableComponent, QuestMarkerComponent. המערכת מטפלת ברכיבים באופן עצמאי. הוספת סוג פריט חדש פירושה הוספת רכיב חדש, לא נגיעה בקוד קיים.
ScriptableObject כ-ItemDefinition (נתונים סטטיים: שם, אייקון, סטטיסטיקות בסיס) + ItemInstance בזמן ריצה (נתונים דינמיים: משנים, עמידות, שם מותאם אישית). כך, אפשר להחזיק 500 סוגי פריטים בזיכרון כהפניות SO ורק מופעים בפועל במלאי כאובייקטים.
למה Composition over Inheritance?
הורשה יוצרת קשרים נוקשים. כשמופיע MagicSword עם אפקט שריפה, חייבים ליצור תת-מחלקה חדשה. במודל הרכיבים, מוסיפים BurnEffectComponent וזהו. 80% מבאגי המלאי בפרויקטים שלנו נבעו מהורשה שגויה. מעבר לרכיבים הפחית באגים ב-70%—שיפור של פי 3.3 ביציבות.
מערכת קרב ומכניקת תורות
ל-RPG מבוסס תורות—State Machine לכל משתתף קרב (PlayerIdle → PlayerSelectAction → EnemyTurn → AnimatingResult → …) באמצעות תבנית Command לפעולות. כל פעולה היא אובייקט ICombatAction עם מתודות Execute() ו-Undo(). Undo() נחוץ לא רק עבור "ביטול תור" אלא גם לטיפול נכון בהפרעות אנימציה.
ל-RPG פעולה—ראו פתרונות ארכיטקטוניים בסעיף המשחקים ההארדקור: ECS לסימולציה, MonoBehaviour להצגה.
שמירות ענן
| פלטפורמה | טכנולוגיה | כלי |
|---|---|---|
| iOS | CloudKit | תוסף מקורי או Game Center |
| Android | Google Play Saved Games | Snapshots API |
יישמו פתרון קונפליקטים: אם השחקן שיחק אופליין בשני מכשירים, נדרשת אסטרטגיית מיזוג (לפי חותמת זמן או התקדמות).
כלים לחיסכון בזמן פיתוח
- Odin Inspector—עורכים מותאמים אישית לאיזון סטטיסטיקות ישירות ב-Unity Inspector ללא כתיבת קוד Editor.
- UniTask—async/await ללא הקצאות GC ב-Unity, קריטי לטעינת פרקים ודיאלוגים ללא הקפאות.
- Addressables + Remote Content Delivery—תיקון תוכן ללא עדכוני אפליקציה.
- Firebase Crashlytics—סימבוליזציה של קריסות עם מחסניות C++ (IL2CPP).
- Unity Test Framework—בדיקות PlayMode למערכת הקרב ולוגיקת שמירה/טעינה.
מה כלול
- עיצוב ארכיטקטורה: סכמת נתונים, מערכת אירועים, דיאגרמות מצב (תיעוד).
- יישום פרוטוטייפ: MVP של מערכת קרב, מלאי, דיאלוגים.
- אינטגרציית מערכות: משימות, דמות, חנות, שמירות ענן.
- בדיקות: בדיקות יחידה, בדיקות PlayMode, בדיקות עומס לקרב.
- פרסום בחנות: הגדרת App Store Connect ו-Google Play Console, הכנת מטא-דאטה.
- תמיכה לאחר השקה: 3 חודשים של תיקון באגים, תיקוני תוכן, ניטור קריסות.
לוחות זמנים—מ-6 עד 24 חודשים בהתאם להיקף. העלות מחושבת באופן אישי: RPG ליניארי טיפוסי מתחיל ב-$150K, עולם פתוח מ-$400K. מוסמכים מפתחי Unity עם 10+ שנות ניסיון ב-RPG. קבלו ייעוץ—דנו בפרויקט שלכם.







