אנו מפתחים מערכות מלאי (Inventory) מוכנות לשימוש למשחקים — מרשימת פריטים בסיסית ועד מערכות יצירה (Crafting) מורכבות וסנכרון רשת. ב-5 שנות עבודה, השלמנו מעל 20 פרויקטים עבור Unity ו-Unreal. קבלו ייעוץ למשימה שלכם — נעריך את הארכיטקטורה ואת לוחות הזמנים תוך יום אחד.
מערכת מלאי היא אחד הרכיבים שבשלבים מוקדמים נראית פשוטה ("רק רשימת פריטים"), אבל עד אמצע הפרויקט הופכת לצומת שהכל מתחבר אליו: כלכלה, התקדמות, יצירה, מסחר, שמירה. עיצוב מחדש של ארכיטקטורת המלאי בשלב ייצור התוכן הוא אחת הפעולות הכואבות ביותר בפיתוח משחקים.
שגיאות ארכיטקטוניות טיפוסיות שמונחות מההתחלה
פריט כ-MonoBehaviour על הסצנה. טעות נפוצה בקרב מתחילים: ItemComponent על GameObject, Inventory כ-List<ItemComponent>. משמעות הדבר היא שכל פריט במלאי קיים כאובייקט Unity — בלתי אפשרי לסריאליזציה ללא פריצות, קשה לשכפל, ולא ניתן להעברה ברשת. הדרך הנכונה: פריט במלאי הוא נתונים, לא אובייקט סצנה.
למה הפרדה בין ItemDefinition ל-ItemInstance היא קריטית?
ItemDefinition הוא ScriptableObject המתאר את סוג הפריט: שם, אייקון, סטטיסטיקות בסיס, האם הוא ניתן לערימה או לא, גודל ערימה מקסימלי. ItemInstance הוא מבנה או מחלקה עם נתוני ריצה: כמות, עמידות, תוספות אקראיות (Affixes), שיפורים (Enchantments). ItemDefinition אחד יכול לייצר אלפי ItemInstance שונים. ללא הפרדה זו, אי אפשר ליישם כראוי משני פריטים או את הייצור שלהם.
צימוד הדוק של ממשק המשתמש לנתוני המלאי. אם InventorySlot קורא ישירות את Item.name ומעדכן את Text.text, אז כל שינוי בנתונים שובר את ממשק המשתמש. המלאי צריך לעבוד ללא ממשק משתמש כלל — אירועים (OnItemAdded, OnItemRemoved, OnItemChanged) מתפרסמים דרך אירועי C# או UnityEvent, וממשק המשתמש נרשם אליהם מבחוץ.
איך לבנות ארכיטקטורה חזקה
ליבה — InventoryContainer: מחלקה עם List<ItemSlot> שבה ItemSlot מאחסן ItemDefinition reference + ItemInstance data + int quantity. המיכל לא יודע של מי הוא — של שחקן, של תיבה, של חנות. זה מאפשר שימוש במערכת אחת לכל דבר.
ItemDatabase — ScriptableObject או נכס כתובת (Addressable) עם Dictionary<string, ItemDefinition> לפי GUID. מזהה פריט הוא מחרוזת, לא int-ID: זה מפשט מיזוג בעבודה צוותית ולא נשבר כשמוסיפים פריטים חדשים.
פעולות על המלאי — מתודות מיכל: TryAdd(ItemDefinition, quantity), TryRemove(ItemDefinition, quantity), TryMove(fromSlot, toContainer, toSlot). כל מתודה מחזירה bool או InventoryOperationResult עם קוד שגיאה (אין מספיק מקום, פריט לא נמצא, משבצת חסומה). אין מתודות void לפעולות נתונים.
ערימה ופריטים ייחודיים
משאבים הניתנים לערימה (עץ, זהב, תחמושת) ופריטים ייחודיים עם תוספות דורשים לוגיקת הוספה שונה. TryAdd בודק itemDef.isStackable — אם כן, מחפש משבצת קיימת עם אותו ItemDefinition וממלא עד maxStackSize, והשאר נכנס למשבצת חדשה. אם !isStackable — כל מופע תופס משבצת נפרדת עם ItemInstance משלו.
מיון מלאי — אלגוריתם שמסדר משבצות לפי קטגוריה ובתוך קטגוריה לפי שם. מיושם דרך List.Sort() עם IComparer<ItemSlot> מותאם אישית ומונפש דרך קורוטין עם החלפת מיקומים רציפה — אחרת מבחינה ויזואלית אי אפשר להבין מה קרה.
שמירת מצב המלאי
סריאליזציה היא משימה נפרדת. ItemInstance חייב לעבור סריאליזציה למבנה ידידותי ל-JSON: { "defGuid": "abc123", "quantity": 5, "durability": 87, "affixes": [...] }. JsonUtility של Unity עובד בצורה גרועה עם פולימורפיזם — עבור ItemInstance מורכבים עם ירושה, עדיף להשתמש ב-Newtonsoft.Json (דרך com.unity.nuget.newtonsoft-json) עם ממירים מותאמים אישית.לפי התיעוד הרשמי של Unity, JsonUtility לא תומך בירושה — השתמשו בספריות צד שלישי למודלים מורכבים.
בטעינת שמירה: בצעו דה-סריאליזציה של רשימת המשבצות, מצאו את ItemDefinition ב-ItemDatabase לפי GUID, שחזרו את ItemInstance. אם ItemDefinition עם GUID זה לא נמצא (תוכן הוסר), המשבצת מסומנת כ-orphaned ואינה גורמת לקריסה.
מקרה בוחן: מלאי ל-MMO Shooter
פרויקט עם 200+ פריטים ייחודיים וייצור תוספות פרוצדורלי. ללא הפרדת Definition/Instance, היה צורך ב-200 ScriptableObjects, וכל פריט עם תוספות היה מופע נפרד. פתרון: 40 הגדרות, מופעים נוצרים תוך כדי ריצה. שמירה — 5 אלפיות שנייה עבור 10,000 פריטים. עדכוני ממשק משתמש דרך אירועים, מיון — 0.2 אלפיות שנייה.טבלת לוחות זמנים משוערים
| היקף | תחום | משך |
|---|---|---|
| מינימלי | רשימת פריטים, הוספה/הסרה, משבצות ממשק משתמש | 3–7 ימים |
| בסיסי | ערימה, ItemDefinition/Instance, שמירה | 1–2 שבועות |
| בינוני | יצירה, ציוד, ממשק גרירה ושחרור, מסננים | 3–5 שבועות |
| מלא | ייצור תוספות, מסחר, סנכרון רשת | 2–3 חודשים |
ניהול משאבים: כשהמלאי הוא יותר מפריטים
במשחקי אסטרטגיה והישרדות, משאבים (עץ, אוכל, חשמל) חיים לא במשבצות מלאי, אלא ב-ResourceSystem — רישום גלובלי או קשור למבנה עם Dictionary<ResourceType, float>. עדכונים מתרחשים דרך Tick כל N שניות של זמן משחק, לא ב-Update() כל פריים.
יצרנים וצרכנים של משאבים נרשמים ב-ResourceSystem דרך ממשק IResourceProducer / IResourceConsumer. זה מאפשר הוספת מבנים חדשים ללא שינוי במערכת הליבה. איזון זרימת המשאבים נבדק בכלי עריכה עוד לפני הריצה — טבלה עם ייצור וצריכה נוכחיים לפי סוג מתעדכנת בחלון עריכה מותאם אישית דרך EditorApplication.update.
מה כלול בפיתוח מערכת מלאי
- ארכיטקטורה:
ItemDefinition/ItemInstance,InventoryContainer,ResourceSystem - יישום פעולות: הוספה, הסרה, הזזה, מיון, ערימה
- סריאליזציה ושמירה: JSON, אפשרות בינארית, דחיסה
- ממשק משתמש: משבצות מותאמות אישית, גרירה ושחרור, מסננים, קטגוריות (במידת הצורך — לשליטה בג'ויסטיק או במובייל)
- אופטימיזציה: מיחזור אובייקטים (Object Pooling), כתובות נכסים, טעינה אסינכרונית
- אינטגרציה עם יצירה, מסחר, ציוד, סנכרון רשת
- בדיקות יחידה: כיסוי כל הפעולות, כולל מקרי קצה
- תיעוד: תיאור ארכיטקטורה, מדריך הגדרה, מדריך ליוצרי תוכן
- פריסה ותמיכה: סיוע באינטגרציה לפרויקט קיים
תהליך עבודה
העיצוב מתחיל בטבלה של כל סוגי הפריטים והמאפיינים שלהם — לפני כתיבת קוד. כמה פריטים ייחודיים מתוכננים? האם יש פריטים שנוצרים? האם יש צורך ביצירה? זה קובע את עומק הארכיטקטורה. אב טיפוס InventoryContainer ללא ממשק משתמש נכתב תחילה ומכוסה בבדיקות יחידה ב-Unity Test Runner — הוספה, הסרה, גלישה, שמירה/טעינה. ממשק המשתמש מחובר אחרון.
צרו קשר כדי לדון בפרויקט שלכם. קבלו הערכת ארכיטקטורה ולוח זמנים תוך יום עסקים אחד.