Розробка мобільної словесної гри: від Trie до мультиплеєра

Мобільна словесна гра: де ламається добір слів

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

Партія після цього не розсипається, але довіра до правил втрачається: далі людина грає обережно або йде в застосунок, де приймають більше слів.

Друга точка відмови — відгук на довгих ланцюжках. Логіка ігрового поля має за частки секунди перевірити слово, перетини, бонусні клітинки та нарахування очок, а перебір за списком слів на кожній літері дає помітну затримку на довгих викладках.

Префіксне дерево та правила словозміни знімають проблему: пошук іде за гілками, а не за всім масивом, і підсвічування варіантів залишається миттєвим.

Третє джерело — зв'язок. Перевірка ходу гравця, надіслана на сервер, під час обриву губиться, і партія розходиться: в одного слово прийнято, в іншого — ні.

Рятують ходи з номером і повним станом позиції — застосунок після повторного підключення досилає непідтверджений хід і отримує актуальне поле.

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

Усе це виявляється на живих гравцях, а не в тестах, і закривається набором словників, які оновлюються без випуску нової версії застосунку.

Мобільна словесна гра тримається на трьох речах: повноті словника, швидкості добору слів і цілісності партії під час обриву зв'язку. Розбираємо, як кожне з цих місць закривається в нашій роботі.

Словник і відгук у грі: що змінюється після переробки

Словник перестав бути монолітом, який повністю тримається в пам'яті пристрою. Ми розклали його на префіксне дерево частотного ядра та підвантажувані шари рідкісних слів: перевірка ходу йде за локальною структурою, тому відгук не залежить від якості зв'язку. Розмір словника при цьому зріс кратно.

Слабким місцем було розпізнавання словоформ: гравець вводив «біжу», «біжить», «побіг», а приймалася лише одна форма, і хід згорав.

Тепер введення приводиться до леми за морфологічною моделлю, вивіреною за даними корпусу Національний корпус російської мови, — частка коректно розпізнаних слів зросла з двох третин майже до повної.

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

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

Окремо закрили клас відмов, який давав найбільше звернень до підтримки: розсинхрон словників між версіями застосунку та подвійні зараховані ходи. Версія словника та правила перевірки фіксуються в самій партії, сервер звіряє лише результат, — частка дограних партій помітно зросла.

Варіанти збірки словника та перевірки ходів: порівняння підходів

Перевірку ходу гравець відчуває як відгук інтерфейсу: якщо відповідь запізнюється, літера «не стає» й людина вважає, що застосунок зламався.

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

Технічні альтернативи

Як обирають на практиці

Вибір зводиться до трьох питань: чи є мережева гра та рейтинг, чи потрібен офлайн, наскільки мова гри відрізняється від типової. Для одиночних партій вистачає словника у збірці — це найпростіший у підтримці шлях.

Як тільки з'являється суперник і спільний рахунок, перевірка йде на сервер, а локальний словник залишається резервним для офлайну.

Етапи роботи: від розбору словника до передачі збірки

Порядок етапів тут не формальність: словник і правила ходів визначають структуру стану та те, скільки одночасних партій витримає сервер. Тому модель гри спочатку фіксуємо в схемах і лише потім пишемо код. Кожен крок закінчується збіркою, яку можна поставити на пристрій і зіграти партію.

1. Аудит ігрової логіки. Розбираємо прототип або чужий код: як будується поле, перевіряються слова, нараховуються очки. На виході — перелік вузьких місць і рішення, що перевикористаємо, а що переписуємо.

2. Схема даних словника. Словник розкладаємо в префіксне дерево: перевірка слова та підказки йдуть без повного перебору. Окремо описуємо мовні набори, ваги літер і оновлення словника без перезбирання застосунку.

3. Налаштування правил ходів. Фіксуємо валідацію ходу, таймінги, заміну літер і умови завершення партії. Окремо — розв'язання конфліктів, коли гравці ходять одночасно.

4. Синхронізація партій і мультиплеєр. Стан рахує сервер: клієнт надсилає хід і отримує підтвердження з оновленим полем. Продумуємо розрив зв'язку та повернення в партію з тим самим рахунком.

5. Тестування партій. Проганяємо словник автотестами, граємо партії ботами, перевіряємо рідкісні випадки — змішані мови, спірні комбінації, одночасні ходи. Навантажувальний прогін показує, скільки сесій тримає вузол.

6. Передача проєкту. Віддаємо репозиторій з історією, збірки, схеми даних, опис правил і порядок випуску оновлень. Навчаємо команду: від локального запуску до розбору збоїв у партіях.

Склад поставки: схеми даних, правила ходів, документація

Поставка — це не лише зібраний застосунок. На прийманні ми передаємо набір артефактів, за якими гру можна розвивати без нас: описи структур, регламенти, доступи та документацію. Нижче — що саме опиняється в руках у замовника.

• Схема даних ігрового ядра — словник, рівні, профілі, прогрес, історія партій: поля, типи, індекси, зв'язки між таблицями. Плюс міграції, щоб розширювати структуру без втрати користувацьких даних.
• Правила ходів і підрахунку очок — що вважається припустимим словом, як розв'язуються спірні комбінації, як поводиться партія під час обриву зв'язку та повторного надсилання ходу.
• Регламент оновлення словника — формат файлу поповнення, порядок перевірки нових слів і версіонування наборів, за якого вже розпочаті партії не ламаються.
• Правила модерації контенту — фільтри імен і чату, список стоп-слів, порядок дій модератора та журнал рішень щодо кожного випадку.
• Схема сервісів і середовищ — де розгорнуті ігровий сервер, сховище та черги, як видаються доступи й зберігаються секрети.
• Документація проєкту — архітектурний опис, локальний запуск і збірка, порядок випуску оновлень і відкат на попередню версію.
• Доступи та права — репозиторії, панелі управління, аналітика й акаунти в магазинах застосунків оформлені на замовника.

Склад поставки фіксуємо до старту робіт і звіряємо на прийманні за пунктами — без «допишемо потім».

Кейс: метрики до та після переробки ядра

Що показували метрики до переробки

Ядро збирали під швидкий прототип: словник завантажувався повністю, а перевірка ходу щоразу перераховувала доступні варіанти заново.

На пристроях середнього класу відгук розтягувався до півтори секунди, частка коректно розпізнаних слів трималася на 71%, і приблизно кожна дев'ята партія закінчувалася зверненням до підтримки — найчастіше зі скаргою на «завислий» хід.

Гравці йшли раніше фіналу: частка завершених партій не піднімалася вище за 46%, утримання другого дня — 21%. Для словесної гри це критично: партія коротка, і один підвислий хід коштує всього матчу.

Що змінили і що вийшло

Словник розклали за префіксним деревом і тримаємо гарячу частину в пам'яті, перевірку ходу рахуємо інкрементально — лише за зміненими клітинками.

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

Після переробки: розпізнавання слів — 99%, відгук на хід — десяті частки секунди, частка завершених партій — 78%, утримання другого дня — 34%. Звернень до підтримки стало менше в шість разів на тисячу партій, а навантаження на сервери за тієї ж кількості гравців упало вдвічі.

Чим відрізняється серверна перевірка ходів від локальної?

Локальна перевірка виконує валідацію ходу на пристрої: слово звіряється зі словником у пам'яті застосунку, відповідь надходить миттєво. Серверна перевірка ходів робить те саме на боці сервісу — пристрій надсилає хід і чекає вердикту. Від цього вибору залежить не лише відгук інтерфейсу, а й те, кому належить істина в партії.

Клієнт — недовірене середовище: усе, що лежить у збірці, рано чи пізно витягується — словник, вартість літер, правила комбінацій. Якщо перевірка слів живе лише на пристрої, захист від підказок тримається на заплутуванні коду.

Серверний арбітр віддає назовні лише вердикт щодо конкретного ходу, і за ним не відновити ні словник, ні рідкісні слова.

У серверного варіанта своя ціна: коло до сервісу додається до кожного ходу, і на слабкому зв'язку партія «залипає». Зростає й складність підтримки — резервування, ліміти запитів, окрема ємність під навантаження турнірів.

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

На практиці беруть гібрид. Локальна перевірка обслуговує одиночну гру та підсвічування в інтерфейсі — хід відчувається миттєвим, а сервер залишається арбітром у мультиплеєрі та рейтингу.

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

Правила при цьому тримають в одному спільному модулі з тестами, інакше клієнт і сервер розходяться в трактуванні слів і гравці отримують різні відповіді на той самий хід.

Технічні сумніви: словник, затримки, оновлення

Перед стартом замовник перевіряє не механіку гри, а рішення, які дорого змінювати потім: як оновлюється словник, що з відгуком на слабких пристроях, скільки роботи додає друга мова та як гра переноситься на другу платформу. Це архітектурні розвилки — вони задають структуру даних і правила підрахунку очок.

Нижче — відповіді на те, що найчастіше запитують на етапі оцінки.

Що із затримкою відгуку на слабкому пристрої?

Перевірка ходу йде на самому пристрої: словник піднімається в пам'ять під час запуску, пошук слова не чекає мережу, тому підсвічування та реакція на дотик не залежать від якості зв'язку. Сервер бере участь лише в звірянні результатів партії.

Скільки роботи додає друга мова у грі?

Словник і правила винесені в окремі конфігурації та не зачіпають логіку підрахунку очок. Додати мову — означає підключити набір слів і переклад інтерфейсу, а не переписати гру; наступна мова йде за тією ж схемою.

Як відбувається перенесення на другу платформу?

Основна логіка — спільний модуль, окремо реалізуються лише введення, оплата та сповіщення. Друга платформа не перетворюється на другий проєкт: переноситься ядро гри, а не пишеться заново.

Хто відповідає за модерацію слів?

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

Обговорення задачі: що знадобиться від вас і як піде робота

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

Ми розберемо механіку, запропонуємо розумний обсяг першої версії та повернемося з оцінкою і планом робіт.

Що знадобиться від вас:

• Механіка гри: які режими потрібні (одиночна партія проти словника, дуель на одному пристрої, мережеві матчі) і як рахуються очки.
• Словникова база: мови, обсяг набору слів, що робити зі спірними та рідкісними словами, чи потрібна серверна перевірка ходів.
• Платформи й аудиторія: телефони та планшети, чи обов'язковий офлайн-режим, чи потрібна синхронізація прогресу між пристроями.
• Доступи та матеріали: акаунти магазинів застосунків, наявні макети, домен для серверної частини, поточний код або прототип, якщо він є.
• Обмеження: бажані строки, вимоги магазинів до контенту та вікових рейтингів, інтеграції з аналітикою та платежами.
• Хто ухвалює рішення: людина, яка буде погоджувати спірні місця щодо правил гри та інтерфейсу.

Перший крок — розбір задачі та зворотний план робіт: що робимо на кожному тижні, де точки погодження і що потрапляє в першу збірку. Опишіть задачу в зручній формі — повернемося з оцінкою і планом.