Мобильная словесная игра: где ломается подбор слов
Подбор слов в игре выходит из строя раньше, чем интерфейс. Словарь не покрывает словоформы — игрок выкладывает допустимое существительное во множественном числе, а проверка хода его отклоняет. Партия после этого не рассыпается, но доверие к правилам теряется: дальше человек играет осторожно либо уходит в приложение, где принимают больше слов.
Вторая точка отказа — отзывчивость на длинных цепочках. Логика игрового поля должна за доли секунды проверить слово, пересечения, бонусные клетки и начисление очков, а перебор по списку слов на каждой букве даёт заметную задержку на длинных выкладках. Префиксное дерево и правила словоизменения снимают проблему: поиск идёт по ветвям, а не по всему массиву, и подсветка вариантов остаётся мгновенной.
Третий источник — связь. Проверка хода игрока, отправленная на сервер, при обрыве теряется, и партия расходится: у одного слово принято, у другого нет. Спасают ходы с номером и полным состоянием позиции — приложение после переподключения досылает неподтверждённый ход и получает актуальное поле.
Узкие места словаря обычно лежат вне кода поиска: нет правил словоизменения для языка, нет отдельного набора имён собственных, нет фильтра лексики. Всё это вскрывается на живых игроках, а не в тестах, и закрывается набором словарей, которые обновляются без выпуска новой версии приложения.
Мобильная словесная игра держится на трёх вещах: полноте словаря, скорости подбора слов и целостности партии при обрыве связи. Разбираем, как каждое из этих мест закрывается в нашей работе.
Словарь и отклик в игре: что меняется после переработки
Словарь перестал быть монолитом, который целиком держится в памяти устройства. Мы разложили его на префиксное дерево частотного ядра и подгружаемые слои редких слов: проверка хода идёт по локальной структуре, поэтому отклик не зависит от качества связи. Размер словаря при этом вырос кратно.
Слабым местом было распознавание словоформ: игрок вводил «бегу», «бежит», «побежал», а принималась только одна форма, и ход сгорал. Теперь ввод приводится к лемме по морфологической модели, выверенной по данным корпуса Национальный корпус русского языка, — доля корректно распознанных слов выросла с двух третей почти до полной.
Скорость отклика на ход изменилась радикально: раньше каждое слово уходило на сервер и ждало проверки, теперь решение принимается на устройстве. Ход подтверждается в момент касания, а сеть нужна только для синхронизации итога партии.
Стабильность партии держится на журнале ходов: он пишется пошагово, и при обрыве связи в метро или лифте сессия восстанавливается с последнего подтверждённого хода. Время восстановления — единицы секунд вместо пересоздания партии и потери прогресса.
Отдельно закрыли класс отказов, который давал больше всего обращений в поддержку: рассинхрон словарей между версиями приложения и двойные засчитанные ходы. Версия словаря и правила проверки фиксируются в самой партии, сервер сверяет только результат, — доля доигранных партий заметно выросла.
Варианты сборки словаря и проверки ходов: сравнение подходов
Проверку хода игрок ощущает как отзывчивость интерфейса: если ответ запаздывает, буква «не встаёт» и человек считает, что приложение сломалось. Поэтому режим проверки выбирают до старта разработки — переезд со словаря в сборке на серверную проверку означает переписать слой правил и заново собрать сам словарь.
Технические альтернативы
| Вариант | Когда подходит | Ограничения подхода |
|---|---|---|
| Локальный словарь в приложении | Одиночная игра, офлайн-режим, ранний прототип | Вес сборки растёт вместе со словарём; набор слов доступен на устройстве, обновление — только с новой версией приложения |
| Серверная проверка ходов | Мультиплеер, рейтинг, турниры, защита от подмены правил | Каждый ход зависит от канала связи; при слабой сети интерфейс ждёт ответа, сервер держит нагрузку на всех партиях |
| Гибридная схема | Мультиплеер и офлайн в одном приложении | Два источника правил синхронизируют по версиям; расхождение словарей ломает партию, поддержка дороже |
| Готовый игровой модуль | Типовые правила, запуск в короткий срок | Правила и словарь ограничены возможностями поставщика; свой режим и своя разметка очков почти не расширяются |
Как выбирают на практике
Выбор сводится к трём вопросам: есть ли сетевая игра и рейтинг, нужен ли офлайн, насколько язык игры отличается от типового. Для одиночных партий хватает словаря в сборке — это самый простой в поддержке путь. Как только появляется соперник и общий счёт, проверка уходит на сервер, а локальный словарь остаётся резервным для офлайна.
Этапы работы: от разбора словаря до передачи сборки
Порядок этапов здесь не формальность: словарь и правила ходов определяют структуру состояния и то, сколько одновременных партий выдержит сервер. Поэтому модель игры сначала фиксируем в схемах и только потом пишем код. Каждый шаг заканчивается сборкой, которую можно поставить на устройство и сыграть партию.
-
Аудит игровой логики. Разбираем прототип или чужой код: как строится поле, проверяются слова, начисляются очки. На выходе — перечень узких мест и решение, что переиспользуем, а что переписываем.
-
Схема данных словаря. Словарь раскладываем в префиксное дерево: проверка слова и подсказки идут без полного перебора. Отдельно описываем языковые наборы, веса букв и обновление словаря без пересборки приложения.
-
Настройка правил ходов. Фиксируем валидацию хода, тайминги, замену букв и условия завершения партии. Отдельно — разрешение конфликтов, когда игроки ходят одновременно.
-
Синхронизация партий и мультиплеер. Состояние считает сервер: клиент отправляет ход и получает подтверждение с обновлённым полем. Продумываем разрыв связи и возврат в партию с тем же счётом.
-
Тестирование партий. Прогоняем словарь автотестами, играем партии ботами, проверяем редкие случаи — смешанные языки, спорные комбинации, одновременные ходы. Нагрузочный прогон показывает, сколько сессий держит узел.
-
Передача проекта. Отдаём репозиторий с историей, сборки, схемы данных, описание правил и порядок выпуска обновлений. Обучаем команду: от локального запуска до разбора сбоев в партиях.
Состав поставки: схемы данных, правила ходов, документация
Поставка — это не только собранное приложение. На приёмке мы передаём набор артефактов, по которым игру можно развивать без нас: описания структур, регламенты, доступы и документацию. Ниже — что именно оказывается на руках у заказчика.
- Схема данных игрового ядра — словарь, уровни, профили, прогресс, история партий: поля, типы, индексы, связи между таблицами. Плюс миграции, чтобы расширять структуру без потери пользовательских данных.
- Правила ходов и подсчёта очков — что считается допустимым словом, как разрешаются спорные комбинации, как ведёт себя партия при обрыве связи и повторной отправке хода.
- Регламент обновления словаря — формат файла пополнения, порядок проверки новых слов и версионирование наборов, при котором уже начатые партии не ломаются.
- Правила модерации контента — фильтры имён и чата, список стоп-слов, порядок действий модератора и журнал решений по каждому случаю.
- Схема сервисов и окружений — где развёрнуты игровой сервер, хранилище и очереди, как выдаются доступы и хранятся секреты.
- Документация проекта — архитектурное описание, локальный запуск и сборка, порядок выпуска обновлений и откат на предыдущую версию.
- Доступы и права — репозитории, панели управления, аналитика и аккаунты в магазинах приложений оформлены на заказчика.
Состав поставки фиксируем до старта работ и сверяем на приёмке по пунктам — без «допишем потом».
Кейс: метрики до и после переработки ядра
Что показывали метрики до переработки
Ядро собирали под быстрый прототип: словарь грузился целиком, а проверка хода каждый раз пересчитывала доступные варианты заново. На устройствах среднего класса отклик растягивался до полутора секунд, доля корректно распознанных слов держалась на 71%, и примерно каждая девятая партия заканчивалась обращением в поддержку — чаще всего с жалобой на «зависший» ход.
Игроки уходили раньше финала: доля завершённых партий не поднималась выше 46%, удержание второго дня — 21%. Для словесной игры это критично: партия короткая, и один подвисший ход стоит всего матча.
Что изменили и что получилось
Словарь разложили по префиксному дереву и держим горячую часть в памяти, проверку хода считаем инкрементально — только по изменившимся клеткам. Состояние партий мультиплеера вынесли в Redis с коротким временем жизни ключа: ход соперника приходит по событию, а не вытягивается опросом раз в секунду. Те же правила проверки слов работают в офлайне, поэтому локальная игра не расходится с серверной логикой.
После переработки: распознавание слов — 99%, отклик на ход — десятые доли секунды, доля завершённых партий — 78%, удержание второго дня — 34%. Обращений в поддержку стало меньше в шесть раз на тысячу партий, а нагрузка на серверы при том же числе игроков упала вдвое.
Чем отличается серверная проверка ходов от локальной?
Локальная проверка выполняет валидацию хода на устройстве: слово сверяется со словарём в памяти приложения, ответ приходит мгновенно. Серверная проверка ходов делает то же самое на стороне сервиса — устройство отправляет ход и ждёт вердикт. От этого выбора зависит не только отзывчивость интерфейса, но и то, кому принадлежит истина в партии.
Клиент — недоверенная среда: всё, что лежит в сборке, рано или поздно извлекается — словарь, стоимость букв, правила комбинаций. Если проверка слов живёт только на устройстве, защита от подсказок держится на запутывании кода. Серверный арбитр отдаёт наружу лишь вердикт по конкретному ходу, и по нему не восстановить ни словарь, ни редкие слова.
У серверного варианта своя цена: круг до сервиса добавляется к каждому ходу, и на слабой связи партия «залипает». Растёт и сложность поддержки — резервирование, лимиты запросов, отдельная ёмкость под нагрузку турниров. Работа без подключения требует офлайн-режима с очередью ходов и последующей синхронизацией состояния, где конфликты разрешаются по правилам, а не по тому, чей ход пришёл позже.
На практике берут гибрид. Локальная проверка обслуживает одиночную игру и подсветку в интерфейсе — ход ощущается мгновенным, а сервер остаётся арбитром в мультиплеере и рейтинге. Синхронизация состояния строится на нумерованных ходах: сервер принимает ход, отвергает конфликтующий и рассылает подтверждённое состояние всем участникам. Правила при этом держат в одном общем модуле с тестами, иначе клиент и сервер расходятся в трактовке слов и игроки получают разные ответы на один и тот же ход.
Технические сомнения: словарь, задержки, обновления
Перед стартом заказчик проверяет не механику игры, а решения, которые дорого менять потом: как обновляется словарь, что с откликом на слабых устройствах, сколько работы добавляет второй язык и как игра переносится на вторую платформу. Это архитектурные развилки — они задают структуру данных и правила подсчёта очков.
Ниже — ответы на то, что чаще всего спрашивают на этапе оценки.
Словарь придётся обновлять вместе с приложением?
Нет. Словарь — отдельный набор данных со своей версией: игра подтягивает актуальный и хранит его локально, поэтому пополнение выходит без новой сборки приложения. Игрок без сети пользуется последним загруженным набором, а откат на предыдущий делается в один шаг.
Что с задержкой отклика на слабом устройстве?
Проверка хода идёт на самом устройстве: словарь поднимается в память при запуске, поиск слова не ждёт сеть, поэтому подсветка и реакция на касание не зависят от качества связи. Сервер участвует только в сверке результатов партии.
Сколько работы добавляет второй язык в игре?
Словарь и правила вынесены в отдельные конфигурации и не трогают логику подсчёта очков. Добавить язык — значит подключить набор слов и перевод интерфейса, а не переписать игру; следующий язык идёт по той же схеме.
Как проходит перенос на вторую платформу?
Основная логика — общий модуль, отдельно реализуются только ввод, оплата и уведомления. Вторая платформа не превращается во второй проект: переносится ядро игры, а не пишется заново.
Кто отвечает за модерацию слов?
Ход, которого нет в словаре, не принимается, а недопустимые сочетания отсекает отдельный фильтр — он обновляется без выпуска сборки. Спорные ходы попадают в журнал, поэтому правила модерации уточняются по реальным случаям.
Обсуждение задачи: что понадобится от вас и как пойдёт работа
Чтобы оценка проекта опиралась на факты, а не на догадки, достаточно одного разговора по делу и небольшого набора вводных. Готовить техническое задание заранее не нужно — опишите идею и покажите то, что уже есть: прототип, макеты, старый код. Мы разберём механику, предложим разумный объём первой версии и вернёмся с оценкой и планом работ.
Что понадобится от вас:
- Механика игры: какие режимы нужны (одиночная партия против словаря, дуэль на одном устройстве, сетевые матчи) и как считаются очки.
- Словарная база: языки, объём набора слов, что делать со спорными и редкими словами, нужна ли серверная проверка ходов.
- Платформы и аудитория: телефоны и планшеты, обязателен ли офлайн-режим, нужна ли синхронизация прогресса между устройствами.
- Доступы и материалы: аккаунты магазинов приложений, существующие макеты, домен для серверной части, текущий код или прототип, если он есть.
- Ограничения: желаемые сроки, требования магазинов к контенту и возрастным рейтингам, интеграции с аналитикой и платежами.
- Кто принимает решения: человек, который будет согласовывать спорные места по правилам игры и интерфейсу.
Первый шаг — разбор задачи и обратный план работ: что делаем на каждой неделе, где точки согласования и что попадает в первую сборку. Опишите задачу в удобной форме — вернёмся с оценкой и планом.
