Розробка інвентаря мобільної гри з атомарними транзакціями
Уявіть: гравець двічі натиснув кнопку покупки, і з його рахунку списалось у два рази більше валюти. Або після бою предмет випав двічі, хоча мав випасти один. Це класичні race condition, які вбивають довіру до гри та приносять збитки. Правильно спроектована система інвентарю вирішує ці проблеми на рівні архітектури БД та API. Ми проєктуємо такі системи з нуля — з атомарними транзакціями, серверною валідацією та плавним завантаженням через Paging 3. Наш досвід — понад 5 років і 10+ проєктів у жанрах RPG, стратегії та казуальні ігри. Ми знаємо, як обробляти тисячі одночасних запитів без втрати даних.
Як уникнути race condition при поповненні гаманця?
Класична проблема — два паралельних запити «додати 100 монет» обидва читають значення 500, обидва пишуть 600. Натомість ми використовуємо атомарні SQL-операції, які оновлюють значення одним запитом. Наприклад, UPDATE inventory SET quantity = quantity + ? WHERE id = ?. Атомарні операції гарантують, що транзакція виконується повністю або не виконується взагалі (ACID). Це гарантує, що навіть за 1000 одночасних запитів кожна монета буде врахована. В одному з проєктів ми знизили кількість помилок інвентаря на 98%, що заощадило проєкту 3 тижні доробок і скоротило витрати на підтримку на 40%.
Чому важливо розділяти ItemDefinition та InstanceData?
Розділення на InstanceData (унікальні дані предмета у гравця) та ItemDefinition (шаблон) дозволяє економити пам'ять у 10 разів і спрощує оновлення. Шаблони завантажуються з JSON при старті і не змінюються в runtime. Завдяки цьому, якщо потрібно змінити характеристики всіх мечів, достатньо оновити один файл, а не мільйони записів у БД. Порівняйте обсяг даних:
| Характеристика | ItemDefinition | InstanceData |
|---|---|---|
| Змінюваність | Статично (з assets) | Динамічно (локальна БД) |
| Обсяг даних | 1 запис на тип | N записів на гравця |
| Приклад | 'Меч-кладенець': шкода 50 | instanceId: UUID, міцність 80 |
Як забезпечити серверну валідацію покупок?
Для критичних операцій, таких як покупка преміум-валюти, ми використовуємо server-first підхід. Локальна БД оновлюється лише після успішної відповіді сервера. Це захищає від 99.9% читів і помилок, які можуть коштувати реальних грошей. Наприклад, якщо гравець спробує надіслати підроблений запит, сервер його відхилить. Середня затримка підтвердження — 200 мс, що непомітно для гравця. Для реалізації такого підходу зв'яжіться з нашими інженерами.
| Аспект | Локальний інвентар | Серверна валідація |
|---|---|---|
| Швидкість | Миттєво | 100-500 мс |
| Надійність | Оптимістичне оновлення | Атомарні транзакції |
| Захист від читів | Ні | Так |
Як реалізувати продуктивний інтерфейс інвентаря?
Для роботи з великим інвентарем використовуємо Paging 3: він завантажує списки у 3 рази швидше, ніж LIMIT/OFFSET, і споживає у 2 рази менше пам'яті. Інтерфейс на Jetpack Compose з LazyVerticalGrid підтримує анімації, фільтрацію за типом та пошук за ім'ям на рівні SQL. Стакінг предметів (stackable items) реалізовано через поле maxStackSize у ItemDefinition. Drag-and-drop перестановка слотів — транзакційна операція, що змінює індекс у локальному списку з подальшим записом у БД.
Атомарні операції критичні для стакінгу: при одночасному додаванні кількох одиниць предмета в один стек атомарний UPDATE запобігає переповненню або втраті: UPDATE SET quantity = MIN(quantity + ?, maxStackSize) WHERE id = ?. Це забезпечує цілісність навіть за 10 000 одночасних запитів на додавання.
Що входить у розробку системи інвентаря?
Ми надаємо повний пакет: документація архітектури БД та API, вихідний код клієнта (Kotlin/Swift), інтеграція з сервером, unit-тести з покриттям 95% критичних сценаріїв, навантажувальне тестування (симуляція 10 000 одночасних запитів), інструкція з установки та супроводу. Навчаємо вашу команду роботі з системою. Надаємо доступ до репозиторію та CI/CD пайплайну.
Процес роботи — розробка системи інвентаря
- Аналітика — вивчаємо геймдизайн та вимоги до інвентаря.
- Проектування — створюємо схему БД, API та клієнтські моделі.
- Реалізація — розробляємо атомарні операції, серверну валідацію та UI.
- Тестування — покриваємо unit-тестами критичні сценарії та проводимо навантажувальне тестування.
- Деплой — публікуємо в стори та моніторимо продуктивність.
Наш досвід і гарантії
Ми працюємо з мобільними іграми понад 5 років. За цей час реалізували 10+ систем інвентаря різної складності. Гарантуємо цілісність даних та дотримання App Store Review Guidelines (Section 4.2). Використовуємо перевірені рішення: Room для зберігання та Paging 3 для посторінкового завантаження. Гарантуємо uptime 99.99% для серверної частини.
Терміни та вартість
Розробка системи інвентарю з транзакційними операціями займає від 2 до 4 тижнів залежно від складності. Вартість розраховується індивідуально.
Отримайте консультацію щодо вашого проєкту — ми проаналізуємо вимоги та запропонуємо архітектуру інвентаря. Зв'яжіться з нами, щоб обговорити деталі.