Архітектура системи крафтингу для мобільної гри

Архітектура системи крафтингу для мобільної гри

Проєктуємо систему крафтингу з нуля. Типові помилки: зберігати рецепти в коді, довіряти клієнтській валідації, ігнорувати офлайн-прогресію. За довгі роки ми реалізували крафтинг для ігор із сукупною аудиторією понад 10 млн встановлень. Ділимося архітектурними рішеннями, які економлять до 40% часу при інтеграції.

Система крафтингу — механіка комбінування ресурсів для отримання предметів. У мобільних іграх вона варіюється від простої (5 каменів → 1 алмаз) до складної (ланцюжок із 10 рецептів з різними станціями та ймовірностями). Від правильної схеми даних залежить продуктивність і захист від зламу. Наприклад, у RPG з 50 рецептами та 4 станціями без серверного контролю читерство сягає 90%.

Замість зберігання рецептів у коді виносимо їх у конфіги — Remote Config або Addressables. Це змінює баланс без оновлення застосунку: збільшити час крафту рідкісного меча з 10 до 15 секунд за пару кліків. А серверна перевірка знижує ризик читерства в 10 разів для ігор з монетизацією. Вартість розробки системи крафтингу починається від $1500 для базового варіанту, а економія бюджету завдяки грамотній архітектурі може сягати $2000 на складних проектах. Нижче розберемо ключові компоненти на прикладах з Unity та PlayFab.

PlayFab Cloud Script використовується для серверної валідації, що дозволяє зменшити кількість порушень у 10 разів порівняно з клієнтською логікою.

Чому рецепти варто зберігати як дані?

Рецепти зручно зберігати як дані, а не як логіку. Це дозволяє додавати рецепти без оновлення застосунку — через Remote Config або Addressables. Використовуємо структуру:

[Serializable] public class CraftingRecipe { public string recipeId; public string resultItemId; public int resultQuantity; public List<Ingredient> ingredients; public float craftingTime; // секунди, 0 = миттєво public float successRate; // 0.0-1.0, 1.0 = завжди public string requiredStation; // "forge", "alchemy_table", null = скрізь public int requiredLevel; } [Serializable] public class Ingredient { public string itemId; public int quantity; public bool consumed; // false = інструмент, не витрачається } 

Список рецептів завантажується при старті з ScriptableObject або через Addressables.LoadAssetAsync<CraftingDatabase>. Для балансування без оновлення — Remote Config зберігає JSON з overrides. Приклад: збільшили час крафту меча з 10 до 15 секунд, якщо баланс змістився.

Реалізація перевірки інгредієнтів та серверного контролю

Перевірка двостороння: на клієнті для UX (миттєва помилка), на сервері для захисту від зламу. Клієнтська логіка в CraftingManager:

public class CraftingManager : MonoBehaviour { public static CraftingManager Instance { get; private set; } private CraftingDatabase _database; private InventoryManager _inventory; public CraftingResult TryCraft(string recipeId, string stationId = null) { var recipe = _database.GetRecipe(recipeId); if (recipe == null) return CraftingResult.InvalidRecipe; // Перевірка станції if (!string.IsNullOrEmpty(recipe.requiredStation) && recipe.requiredStation != stationId) return CraftingResult.WrongStation; // Перевірка рівня if (PlayerData.Level < recipe.requiredLevel) return CraftingResult.LevelTooLow; // Перевірка наявності інгредієнтів foreach (var ingredient in recipe.ingredients) { if (_inventory.GetCount(ingredient.itemId) < ingredient.quantity) return CraftingResult.MissingIngredients; } // Ймовірність успіху bool success = Random.value <= recipe.successRate; // Списуємо лише витратні інгредієнти foreach (var ingredient in recipe.ingredients.Where(i => i.consumed)) _inventory.Remove(ingredient.itemId, ingredient.quantity); if (success) _inventory.Add(recipe.resultItemId, recipe.resultQuantity); // Аналітика GameAnalytics.NewDesignEvent($"Crafting:Result:{recipeId}", success ? 1 : 0); return success ? CraftingResult.Success : CraftingResult.Failed; } } 

Для ігор з монетизацією обов'язкова серверна валідація через PlayFab Cloud Script:

// PlayFab Cloud Script handlers.CraftItem = function(args) { var recipeId = args.recipeId; var recipe = getRecipeFromCatalog(recipeId); // Перевіряємо інвентар на сервері var inventory = server.GetUserInventory({ PlayFabId: currentPlayerId }); for (var ingredient of recipe.ingredients) { var count = countItem(inventory, ingredient.itemId); if (count < ingredient.quantity) { return { success: false, error: "insufficient_items" }; } } // Списуємо та нараховуємо на сервері for (var ingredient of recipe.ingredients.filter(i => i.consumed)) { server.RevokeInventoryItems({ ... }); } server.GrantItemsToUser({ itemIds: [recipe.resultItemId], ... }); return { success: true, resultItemId: recipe.resultItemId }; }; 

Серверна перевірка запобігає читерству: клієнт може зламати, сервер — ні.

Як організувати крафтинг з таймером та офлайн-прогресію?

Для механіки «запустив і повернись через годину» використовуємо об'єкт слоту:

public class CraftingSlot { public string recipeId; public DateTime completionTime; public bool isComplete => DateTime.UtcNow >= completionTime; } public void StartCrafting(string recipeId, int slotIndex) { var recipe = _database.GetRecipe(recipeId); _craftingSlots[slotIndex] = new CraftingSlot { recipeId = recipeId, completionTime = DateTime.UtcNow.AddSeconds(recipe.craftingTime) }; // Зберігаємо в PlayerPrefs або Cloud Save SaveCraftingState(); // Плануємо локальний пуш NotificationManager.ScheduleLocal( $"Крафтинг завершено: {recipe.resultItemId}", recipe.craftingTime ); } 

Стан слотів потрібно персистити. При повторному вході DateTime.UtcNow порівнюється з completionTime: якщо минуло — крафт завершено. Так таймер працює в офлайні.

Типи крафту

Категорія крафту обирається під жанр. Для RPG підходять багаторівневі та таймерні, для казуальних — миттєві та ймовірнісні.

Етапи розробки системи крафтингу

1. Аналіз — визначаємо механіки, будуємо прототип.
2. Проєктування даних — рецепти, інвентар, слоти, серверні правила.
3. Реалізація — пишемо CraftingManager, валідацію, таймери, UI.
4. Інтеграція сервера — PlayFab Cloud Script для валідації.
5. Тестування — навантаження, читерство, офлайн-сценарії.
6. Деплой — публікація з дотриманням Store Review Guidelines.

Що входить у роботу

• Проєктування схеми даних рецептів та інвентарю.
• Реалізація CraftingManager з перевірками та ймовірностями.
• Система крафтингу з таймерами та офлайн-прогресією.
• Локальні пуш-сповіщення про завершення крафту.
• Серверна валідація через PlayFab / GameSparks.
• UI: рецептбук, слоти крафтингу, прогрес-бар.
• Аналітичні події для балансування популярності рецептів.
• Документація архітектури та інтеграції.
• Надання доступів до серверних конфігів.
• Навчання команди замовника роботі з системою.
• Технічна підтримка на етапі впровадження.

Терміни розробки

Базовий крафтинг (миттєвий, без таймерів): 3–5 днів. Повна система з таймерами, слотами, серверною валідацією та UI: 1,5–3 тижні. Вартість розраховується індивідуально після оцінки обсягу інвентарю та кількості рецептів. Гарантуємо стабільну роботу та дотримання Store Review Guidelines.

Наші спеціалісти мають 10+ років досвіду в мобільній розробці — врахуємо нюанси код-сайнінгу та сертифікатів для публікації. Оцінимо проєкт і запропонуємо оптимальне рішення. Замовте систему крафтингу під ключ – виконаємо за 3-5 днів базовий варіант. Пишіть для обговорення – отримайте надійну архітектуру.