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

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

Проєктуємо систему крафтингу з нуля. Типові помилки: зберігати рецепти в коді, довіряти клієнтській валідації, ігнорувати офлайн-прогресію. За довгі роки ми реалізували крафтинг для ігор із сукупною аудиторією понад 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 днів базовий варіант. Пишіть для обговорення – отримайте надійну архітектуру.