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

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Архітектура системи крафтингу для мобільної гри
Середній
~3-5 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    562

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

Проєктуємо систему крафтингу з нуля. Типові помилки: зберігати рецепти в коді, довіряти клієнтській валідації, ігнорувати офлайн-прогресію. За довгі роки ми реалізували крафтинг для ігор із сукупною аудиторією понад 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 = інструмент, не витрачається
}
Параметр Опис
recipeId Унікальний ідентифікатор рецепту
resultItemId ID предмету-результату
ingredients Список інгредієнтів з кількістю та прапорцем витрати
craftingTime Час крафту в секундах (0 — миттєвий)
successRate Ймовірність успіху від 0 до 1

Список рецептів завантажується при старті з 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: якщо минуло — крафт завершено. Так таймер працює в офлайні.

Типи крафту

Тип крафту Опис Складність Приклад
Миттєвий Інгредієнти одразу конвертуються в результат Низька 5 каменів → 1 алмаз
З таймером Запуск крафту, очікування завершення Середня Створення зілля 30 хв
Ймовірнісний Результат залежить від шансу Середня Перетворення руди з шансом 70%
Багаторівневий Ланцюжок крафтів із проміжних предметів Висока Сталь із руди та вугілля → меч

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

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

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

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

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

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

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

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

Аналітика мобільних застосунків: Firebase, Amplitude, AppsFlyer та атрибуція

Наша команда регулярно стикається з проектами, де аналітика вже «налаштована», але реальних інсайтів немає. Типовий приклад — стартап з 50k DAU: трекінг десятків подій без жодної відповіді на питання «чому користувачі не доходять до оплати». За два тижні ми побудували базову воронку і з'ясували, що 70% аудиторії відвалюється на екрані верифікації номера телефону. Після локалізації бага retention зріс на 12%. Висновок: аналітика повинна починатися з конкретних питань, а не з трекінгу всього підряд.

Чому таксономія подій — основа аналітики мобільних застосунків?

Firebase Analytics, Amplitude, Mixpanel — технічно схожі. Різниця в тому, що ви в них кладете. Типова помилка: події screen_view, button_tap_1, button_tap_2 без контексту. Через місяць ніхто не пам'ятає, що таке button_tap_2.

Правильна таксономія: об'єкт + дія + контекст. product_viewed, checkout_started, payment_completed з параметрами product_id, category, price, source. Це дозволяє будувати воронки, когортний аналіз та retention без додаткового трекінгу.

Ми фіксуємо naming convention у tracking plan — документі (Google Sheet або Amplitude Data Catalog), де описано кожну подію, її параметри та умови спрацьовування. Tracking plan синхронізується з командою аналітиків до початку розробки, а не після. Такий підхід гарантує, що через місяць дані залишаться інтерпретованими, а не перетворяться на звалище. Досвід впровадження на 50+ проектах підтверджує: при відсутності tracking plan вартість підтримки аналітики зростає у 2-3 рази за рахунок переробок.

Що обрати для аналітики мобільних застосунків: Firebase, Amplitude чи Mixpanel?

Таблиця нижче показує ключові відмінності трьох популярних платформ. Вибір залежить від бюджету, трафіку та завдань.

Критерій Firebase Analytics Amplitude Mixpanel
Безкоштовний ліміт Безліміт (в рамках Spark-плану) До 10 млн events/міс До 1 тис. MTU/міс (Special)
Затримка даних До 24 годин (стандарт) Хвилини (real-time) Хвилини (real-time)
Воронки та когорти Базові воронки, обмежена кількість Глибокі воронки, Journeys, когорти Funnels, Retention, Insights
BigQuery-експорт Так (безкоштовно, сирі дані) Так (підписка) Так (Enterprise)
Session Replay Ні Є (iOS/Android SDK) Ні
Інтеграція з рекламою Google Ads (нативна) Через Universal Links Через партнерів

Firebase Analytics — безкоштовно, глибока інтеграція з Google Ads, BigQuery-експорт для сирих даних. Обмеження: затримка даних до 24 годин, обмежені воронки. Для стартапів з Google Ads трафіком — перший вибір.

Amplitude — продуктова аналітика з акцентом на когорти та шляхи користувача. Journeys (колишній Pathfinder) показує реальні шляхи між подіями — не передбачувані воронки, а фактичні маршрути. Session Replay — запис сесій для UX-аналізу. Безкоштовний тир до 10 млн events/місяць достатній для більшості продуктів на старті.

Mixpanel — ближче до Amplitude, сильніший у сегментації в реальному часі. Insights, Funnels, Retention — базові інструменти, які закривають 90% аналітичних завдань продакта.

Більш формальні визначення цих платформ можна знайти у Wikipedia (Firebase) та Wikipedia (Amplitude).

Як вирішити проблему мультиканальної атрибуції з AppsFlyer?

Знати звідки прийшов користувач — окреме завдання. Firebase Attribution працює лише всередині Google-екосистеми. Для мультиканальної атрибуції (Facebook Ads, TikTok, Apple Search Ads, programmatic) потрібен MMP — Mobile Measurement Partner.

AppsFlyer — лідер ринку. OneLink — universal deep link, який працює на iOS та Android і коректно атрибутує встановлення з будь-якого каналу. Protect360 — вбудований захист від fraud (фейкові встановлення, click injection на Android). Adjust та Branch — конкуренти з подібним функціоналом. Branch сильний у deep linking; Adjust популярний у gaming.

Згідно з Apple, з iOS 14.5 застосунки повинні отримувати дозвіл користувача через ATT перед збором IDFA для відстеження. AppsFlyer використовує probabilistic matching (IP + user agent + timing) для цих користувачів — точність нижча, але краще ніж нічого. SKAdNetwork та Privacy Preserving Attribution надають агреговані дані від Apple із затримкою 24-72 години.

Як налаштувати crash-аналітику, щоб не пропускати баги?

Firebase Crashlytics — стандарт для crash reporting. Автоматично групує креші за стектрейсом, показує affected users %, velocity alerts при зростанні crash rate більш ніж на 10% за годину.

Важливо: символікація. На iOS .dSYM файли повинні автоматично завантажуватися при кожній збірці — через Fastlane upload_symbols_to_crashlytics або Xcode Cloud built-in. Без символів креш у Crashlytics виглядає як набір адрес пам'яті. Це трапляється частіше, ніж здається при переході на новий CI — в одному проекті з аудиторією 500k користувачів ми виявили, що 40% крешів залишалися несимволізованими через пропущений етап у CI/CD. Після автоматизації час реакції на баги скоротився з 3 годин до 15 хвилин.

Для React Native та Flutter — @sentry/react-native та sentry_flutter дають додатковий контекст: breadcrumbs, мережеві запити перед крешем, стан Redux/Provider.

Нижче — порівняння популярних інструментів crash-аналітики для вибору під свої завдання.

Критерій Firebase Crashlytics Sentry Instabug
Безкоштовний ліміт Безліміт (в рамках Spark) 5k events/міс 250 MAU
Групування За стектрейсом + параметри За fingerprint За стектрейсом + метадані
Символікація Автоматична (через файл) Автоматична (через CLI) Автоматична
Velocity alerts Так (за % зміни) Так (за кількістю) Так (за порогом)
Дод. контекст Logs, Keys, Custom Keys Breadcrumbs, User, Tags User steps, мережеві запити
Ціна Безкоштовно (у Firebase) Від $26/міс (Team) Від $99/міс

Налаштування оточення

Три оточення з окремими Firebase проектами: dev, staging, production. Змішувати аналітику з тестових сесій і production — поширена помилка, яка спотворює всі метрики. На iOS через GoogleService-Info.plist для кожної схеми, на Android через google-services.json у папці кожного flavor.

Терміни: базова аналітика з Firebase + Crashlytics — 3-5 днів. Повноцінний tracking plan + Amplitude/Mixpanel з воронками та когортами — 2-3 тижні. Атрибуція через AppsFlyer з deep linking та fraud protection — 1-2 тижні. Вартість розраховується індивідуально залежно від складності інтеграцій.

Що входить у нашу роботу

В рамках впровадження аналітики ми надаємо:

  • Розробку та узгодження tracking plan з командами продукту та маркетингу.
  • Інтеграцію SDK (Firebase, Amplitude, Mixpanel, AppsFlyer) з урахуванням вашого стеку (Swift/Kotlin/Flutter/React Native).
  • Налаштування воронок, когорт, дашбордів та алертів.
  • Автоматизацію символікації та завантаження .dSYM через Fastlane.
  • Документацію щодо подій та параметрів.
  • Навчання команди роботі з аналітичною платформою.
  • Два тижні пост-релізної підтримки та коригування трекінгу.

Наш досвід — 7 років впровадження аналітики та понад 80 успішних проектів у сфері мобільної розробки. Ми гарантуємо коректність даних і прозорість кожного етапу.

Зв'яжіться з нами, щоб отримати консультацію з налаштування аналітики вашого застосунку. Замовте аудит поточної аналітики — і ми покажемо, які метрики ви втрачаєте.