Розробка мобільних ігор: де проєкт ламається на старті
Більшість проєктів у розробці мобільних ігор ламається не на ігровій механіці, а на зв'язці клієнта з мережею.
Поки в партії двоє за одним пристроєм, усе передбачувано; щойно учасників більшає, а канал нестабільний, синхронізація стану партії перестає сходитися — один уже зробив хід, другий його не бачить, третій бачить попередній.
Друга точка відмови — подвійна логіка під дві платформи. Правила, підрахунок очок і порядок ходів дублюються в нативному шарі та в спільному коді: гілки розходяться вже через кілька релізів, а дефект відтворюється лише на одній із них.
Єдине ядро правил плюс кросплатформна збірка з одного джерела прибирають розходження — правиться одна реалізація замість двох.
Третя — продуктивність під навантаженням. Мультиплеєр у мобільній грі рівно тримає двох, а на восьмому учаснику втрачає чутливість: клієнт пересилає повний стан партії замість змін, передбачення власного ходу не реалізовано, і затримка каналу стає видимою гравцеві.
Усі три збої архітектурні, а не «оптимізуємо потім». Авторитетний сервер, обмін лише змінами й одна модель стану для всіх учасників знімають їх на етапі проєктування архітектури ігрового клієнта — поки правка коштує одного рішення, а не переписування мережевого шару.
Далі розбираємо, як це закривається: які режими синхронізації обираємо під жанр, що перевіряємо навантаженням і як переносимо логіку без втрати прогресу гравців.
Що змінюється після перенесення логіки на спільне ядро
Поки логіка партії живе у двох гілках під кожну платформу, будь-яке правило доводиться писати двічі. Підрахунок очок, таймери, порядок ходів і умови перемоги розходяться в дрібницях — і це випливає не в тестах, а на живих гравцях, коли учасники бачать різний стан однієї партії.
Перенесення логіки в спільне ігрове ядро прибирає саме джерело розходжень. Ядро — детермінована модель партії: однаковий вхід дає один і той самий набір ходів і переходів стану на будь-якому пристрої.
Платформний шар залишається тонким — введення, відрисовка, сповіщення, а правила й синхронізація живуть в одному місці.
Єдина кодова база замість двох дає один набір перевірок на правила: сценарій, що пройшов на одному пристрої, гарантовано проходить і на другому.
Збірка релізу стає передбачуваною — один конвеєр збирає обидві платформи з одного коміту, тому час збірки релізу перестає залежати від того, чи підтягнула друга гілка чужу правку.
Окремо усувається клас відмов «розходження стану в учасників»: мережевий шар передає дії гравців, а не готові стани, і партія сходиться в усіх за однією послідовністю кроків. Це дає відтворювані партії для розбору спірних ситуацій і відкат до збереженої точки без ручної звірки.
Ціна рішення — дисципліна в ядрі: правка проходить рев'ю та перевірку до потрапляння в збірку. Окупається тим, що підтримка двох платформ перестає бути подвійною роботою, а інструментарій беремо зрілий — Unity, де спільний шар і збірка під мобільні платформи відпрацьовані.
Формати мультиплеєра: порівняння підходів і обмежень
Схема синхронізації визначає не картинку, а клас відмов: що станеться при обриві зв'язку в одного з гравців, хто вирішує, чий постріл влучив, чи можна підробити результат на пристрої.
Тому режими мультиплеєра обирають до того, як написана ігрова логіка — перенесення на іншу схему пізніше означає переписування бойової частини й перезбирання балансу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Авторитетний сервер | Змагальні та рейтингові режими, де важливий рівний результат | Потрібна постійна інфраструктура, затримка залежить від близькості вузла до гравця |
| Пряме з'єднання між пристроями | Кооператив на 2–4 особи, ранній доступ без інфраструктури | Пристрій-хост стає точкою відмови; його власник бачить стан повністю |
| Локальний хост в одній мережі | Турніри та вечірки в одному приміщенні, показові матчі | Працює лише всередині спільної мережі, за її межами режим розпадається |
| Гібридна мережева схема | Масові режими, де потрібні і чутливий ввід, і спільний рейтинг | Складніше в налагодженні: розсинхрон проявляється рідко й на довгих сесіях |
На практиці вибір такий: рейтингові матчі — авторитетний сервер, кооператив — пряме з'єднання між пристроями, турніри на майданчику — локальний хост.
Гібридна мережева схема бере компроміс: незворотні події та підсумок матчу підтверджує сервер, а відгук на натискання пристрій рахує одразу й гасить розходження звіркою стану.
Ціна — окремий набір перевірок зі штучною втратою зв'язку, затримкою та перепідключенням, інакше розсинхрон випливе вже у гравців.
Етапи робіт: від аудиту прототипу до передачі команді
Ігровий прототип зазвичай збирають як перевірку механіки: логіка живе на пристрої, стан матчу пересилається як вийде. Щойно з'являється мультиплеєр та ІІ-супротивники, вузьким місцем стає синхронізація — розходження між гравцями, спірні влучання, розвал матчу при втраті зв'язку. Роботу ведемо етапами, і кожен закривається артефактом, який команда приймає.
- Аудит прототипу. Дивимося, де рахується ігрова логіка, як зберігається стан матчу, що можна перевикористати. На виході — карта вузьких місць і рішення: доопрацьовуємо поточну основу чи переносимо логіку на сервер.
- Схема мережевої взаємодії. Фіксуємо, що рахується авторитетно на сервері, що передбачається на пристрої, як розв'язуються конфлікти й відновлюється матч після обриву. Схему узгоджуємо до першого рядка коду.
- Реалізація. Збираємо матчмейкінг, кімнати та синхронізацію стану; поведінку ІІ-супротивників виносимо в налаштування, щоб складність змінювалася без перезбирання збірки.
- Навантажувальні перевірки. Ганяємо матчі на нестабільному каналі та з різною якістю зв'язку, шукаємо поріг, на якому стани розходяться, а сервер упирається в межу.
- Приймання на пристроях. Прогін на слабких і топових моделях, різних версіях системи, з перериванням матчу вхідним викликом і перемиканням між мережами.
- Передача проєкту. Репозиторії, стенди, схеми, регламент випуску версій і навчання вашої команди — щоб розвиток ішов без нас.
Кожен етап дає перевірюваний результат: звіт аудиту, узгоджену схему, протокол навантажувальних перевірок, список дефектів із пріоритетами. За цією послідовністю видно, де проєкт перебуває і що залишилося до релізу.
Що передаємо на руки: схеми, конфігурації, регламенти
Передаємо не «доступ до репозиторію», а комплект, за яким ваша команда або інший підрядник продовжить роботу без зворотного проєктування.
Кожен артефакт версіонується разом із кодом і оновлюється в міру змін — інакше через два релізи документація розходиться з реальністю й перестає бути джерелом правди.
- Опис архітектури — шари клієнта, стан ігрової сесії, серверна логіка та точки розширення. Схема модулів із явними межами: де додається новий режим, не зачіпаючи мережевий шар і балансну математику.
- Схеми мережевих потоків — послідовності handshake, синхронізації стану та реконекту при обриві зв'язку. Окремо — що бачить клієнт при розсинхроні й як розв'язуються конфлікти між гравцями.
- Конфігурації оточень — dev, staging, production з переліком змінних, лімітів і зовнішніх залежностей. Підняття стенда повторюється з нуля за інструкцією, без «спитати в того, хто налаштовував».
- Політики доступу та секретів — ролі в репозиторії та хмарі, принцип мінімальних прав, ротація ключів платіжних і аналітичних інтеграцій, заборона секретів у коді.
- Регламент випуску оновлень — гілкування, обов'язкові перевірки, порядок викату на тестові групи, критерії відкату й строки розбору збоїв із фіксацією причини.
- Інструменти збірки та релізу — відтворювана збірка, автоматичне вивантаження в магазини, версіонування та зберігання карт коду для розбору падінь у проді.
- Документація щодо даних — схема зберігання прогресу, метрик і профілів, правила міграції при зміні формату, щоб оновлення не обнуляло прогрес гравців.
- План передачі — спільні розбори з вашою командою, доступи, порядок супроводу перших релізів і контакт для термінових питань.
Комплект перевірюваний: якщо за ним не можна підняти стенд і випустити оновлення без нас — це не передача, а залежність.
Кейс: синхронізація партій та ІІ-супротивники в бою
Проєкт — покрокові бої, де живі гравці ходять у парі з ІІ-напарниками. Партію рахував пристрій кожного учасника, і на реальних мережах виникав розсинхрон партії: один гравець бачив влучання, другий — промах за тим самим ходом.
Кожен п'ятий матч закінчувався зривом, а на слабких пристроях застосунок грівся й вилітав у середині бою.
Що змінили
Розрахунок партії переїхав на сервер: клієнт надсилає лише ввід, сервер тримає єдиний правильний стан і розсилає підтверджені знімки бою.
Клієнт став тонким — йому більше не потрібно утримувати в пам'яті всю історію ходів, а обрив зв'язку лікується перепідключенням до останнього підтвердженого кроку замість перезапуску матчу.
Поведінка ІІ-супротивника теж перейшла на сервер і стала однаковою в усіх учасників: те саме рішення на тому самому стані, прорахунок заздалегідь обмежений у часі та не конкурує з графікою за ресурси пристрою.
Результат
Частка зірваних партій знизилася з 18% до 2%, час підключення до матчу — з 6–9 секунд до 1,5–2 секунд завдяки легкому клієнту та короткому стартовому знімку.
На пристроях нижнього цінового сегмента падіння в бою скоротилися в рази, а реліз у Google Play пройшов без хвилі відгуків про зависання — стабільність на слабких пристроях стала окремим критерієм приймання.
Що робити, якщо гра вже випущена на своєму сервері?
Випущена гра — це не лише код, а живі матчі, рейтинг, прогрес гравців і покупки. Тому логіку переносять не за принципом «зупинити й переписати», а шарами: спочатку визначається межа авторитетного стану й те, що саме клієнт вважає джерелом правди. Далі новий контур вмикається поряд зі старим, а не замість нього.
Перший етап — паралельна робота двох схем. Запити на читання йдуть у нову схему, її відповіді звіряються з відповідями старої, розходження пишуться в окремий журнал, але гравцеві, як і раніше, відповідає стара.
Так коректність перевіряється на реальному трафіку, включно з годинами пік, а не на тестовому стенді, і жоден матч не залежить від ще не перевіреного коду.
Винесення логіки йде від некритичного до критичного: спочатку підбір суперників та агрегована статистика, потім ігрові сесії всередині матчу, останніми — акаунти, покупки й нарахування. Кожен шар перемикається окремо та незалежно, тому збій в одному не тягне за собою інші. Стан гравців переноситься у фоні, матчі продовжують іти.
План відкату будується на рівні маршрутизації: один перемикач повертає трафік у стару схему, а формати даних сумісні в обидва боки — нова пише те, що стара вміє читати.
Відкат займає секунди й не перериває активні матчі, тому застосовується як штатний інструмент, а не як аварійний захід.
Оновлення випущеної гри при цьому не потребує примусового релізу клієнта: контракт між клієнтом і сервером не змінюється, змінюється лише місце виконання логіки.
Ми ведемо метрики розходжень і частку перерваних матчів — поки вони в нормі, крок вважається пройденим і починається наступний.
Технічні сумніви: відкати, чити, навантаження, приватність
Обрив зв'язку в матчі, підміна результату, пікове навантаження та зберігання даних гравців — не абстрактні ризики, а конкретні місця в архітектурі, де рішення або є, або його немає. Нижче — відповіді на питання, які найчастіше ставлять перед стартом розробки.
Принцип один: станом матчу володіє сервер, а клієнт лише надсилає наміри. Тоді перепідключення, перевірка результату та масштабування вирішуються одним шаром, а не трьома різними латками.
Що відбувається при обриві зв'язку в матчі?
Сесія живе на сервері ще 30–60 секунд: стан фіксується знімком, гравець бачить паузу або керованого бота, а при поверненні підключається за ключем сесії й продовжує з тієї ж секунди. Матч не перестворюється.
Як захищаються результати матчів?
Результат рахує сервер за своїми правилами, а не пристрій гравця: правка локальних даних або підміна пакетів нічого не змінює. Додатково зберігається запис дій — аномальна точність і повторювані послідовності йдуть на розбір.
Як рахується пікове навантаження?
Рахуємо не за встановленнями, а за одночасними матчами в годину пік, із запасом на сплеск події. Навантажувальний прогін іде з перевищенням прогнозу, щоб стеля з'єднань і черга перевірялися до релізу.
Як зберігаються дані гравців і як проходить відкат версії?
Зберігаємо мінімум: ідентифікатор, прогрес, факти покупок — із шифруванням і обмеженим строком, як вимагає Google Play. Ігрові правила винесено в конфігурацію на сервері: невдалий баланс відкочується перемикачем без випуску нової збірки в магазин.
Обговоримо задачу: що додати до запиту на оцінку
Щоб повернутися з оцінкою та планом робіт, а не із загальними словами, потрібні вхідні дані щодо проєкту. Ми розбираємо матеріали до початку розмови: тоді оцінка спирається на механіку, мережеву модель і цільові платформи, а не на здогадки. Нижче — що додати до запиту, щоб ми обговорили задачу предметно.
- Опис механік: правила раунду, умови перемоги, внутрішньоігрова економіка, як поводиться ІІ-суперник при різній кількості гравців.
- Прототип або напрацювання: грабельна збірка, чернетки екранів, начерки рівнів — покажемо, що перевикористаємо, а що переписуємо.
- Поточна схема мережі: як синхронізується стан між гравцями, де живе серверна логіка, як обробляються розриви зв'язку та перепідключення.
- Цільові платформи: мобільні системи та планшети, чи потрібне перетинання з настільними версіями й єдиний акаунт між ними.
- Навантаження: очікуване число одночасних гравців, середня довжина матчу, вимоги до чутливості керування.
- Обмеження за строками та етапами: прив'язка до запуску, що критично в першій версії, що переносимо в другу.
- Склад робіт і доступи: чи потрібні дизайн, аналітика та публікація в магазинах, до яких сховищ і сервісів даєте доступ.
Із цими вхідними даними ми повертаємося з оцінкою та планом робіт із розробки мобільної гри: етапи, порядок, ризики й те, що потрібно буде від вас на кожному кроці.
