Разработка мобильного приложения для онлайн-шахмат
Создаёте шахматное приложение и столкнулись с рассинхроном ходов, спорами по таймеру или интеграцией AI? Мы решаем эти задачи на iOS, Android и Flutter с 2015 года. Главная техническая сложность — синхронизация состояния партии между двумя клиентами в реальном времени с минимальной задержкой и корректной обработкой таймера. Без продуманной архитектуры игроки столкнутся с рассинхроном, «залипанием» ходов и несправедливым таймингом. WebSocket — единственный подходящий протокол для обмена ходами; HTTP polling даёт задержки и лишний трафик. На iOS используем URLSessionWebSocketTask, на Android — OkHttp WebSocket, на Flutter — web_socket_channel. Клиент отправляет ход в UCI-нотации (e2e4), сервер валидирует позицию и рассылает обновление обоим игрокам. Вся проверка легальности — на сервере.
Как синхронизировать ходы в реальном времени?
WebSocket — единственный подходящий протокол. HTTP polling даёт задержки и лишний трафик. На iOS используем URLSessionWebSocketTask (нативный), на Android — OkHttp WebSocket, на Flutter — web_socket_channel. Протокол обмена: клиент отправляет ход в UCI-нотации (e2e4), сервер валидирует позицию и рассылает обновление обоим игрокам. Клиент не доверяет себе в легальности хода — всю проверку делает сервер. Иначе модифицированное приложение может делать нелегальные ходы.
// Android — отправка хода webSocket.send(Json.encodeToString(MoveMessage( gameId = currentGameId, move = "e2e4", remainingTimeMs = timerViewModel.whiteTimeMs ))) При разрыве соединения клиент переходит на HTTP polling каждые 2 секунды и пытается реконнект с exponential backoff. Партия продолжается — игрок с плохим соединением не теряет время автоматически.
Почему таймер должен быть на сервере?
Таймер — источник споров в онлайн-шахматах. Если держать его только на клиенте, недобросовестный игрок может замедлить свой таймер. Правильная схема: сервер хранит white_remaining_ms и black_remaining_ms, обновляет при каждом ходе и отправляет актуальные значения клиентам. Клиент отображает таймер (анимация убывания), но не является источником истины. При реконнекте клиент запрашивает текущее состояние и синхронизирует отображение.
Технологии рендера доски
Для нативных приложений используем Canvas API (Android) или CAShapeLayer + CALayer (iOS). Анимация хода — перемещение ImageView/UIImageView через ValueAnimator / UIView.animate. В Flutter — кастомный CustomPainter с Canvas.drawImage для фигур. Фигуры в формате SVG конвертируются в растровые изображения под разные разрешения — это позволяет перекрашивать их для разных тем.
Шахматный движок для игры с AI
Stockfish — стандарт индустрии, открытый, сильнейший. Компилируется как C++ библиотека для iOS, через JNI для Android или через пакет stockfish для Flutter. Глубина поиска управляется UCI-командами: setoption name Skill Level value 10 (0–20), go movetime 1000. Анализ позиции выполняется в отдельном потоке, чтобы не блокировать UI. Настройки движка позволяют адаптировать сложность: на уровне 0 он допускает грубые ошибки, на 20 — играет на уровне гроссмейстера.
Рейтинг Эло и матчмейкинг
Формула Эло: newRating = oldRating + K * (score - expectedScore). K = 32 для новых игроков, 16 для опытных. Матчмейкинг ищет соперника в диапазоне ±100 Эло с таймаутом расширения каждые 10 секунд. Очередь хранится в Redis Sorted Set, score = timestamp постановки. При поиске выбирается ближайший по рейтингу участник. Алгоритм гарантирует, что время ожидания редко превышает 30 секунд при 500 одновременных игроках.
Сравнение платформ: производительность и задержки
| Компонент | iOS (Swift) | Android (Kotlin) | Flutter (Dart) |
|---|---|---|---|
| WebSocket | URLSessionWebSocketTask | OkHttp WebSocket | web_socket_channel |
| Таймер | Server-sync | Server-sync | Server-sync |
| Движок | Stockfish (C++) | Stockfish (JNI) | Stockfish (native plugin) |
| Рендер | CAShapeLayer | Canvas | CustomPainter |
| Задержка (p95) | < 50 ms | < 60 ms | < 80 ms (на старых устройствах) |
Нативное приложение на Swift/Kotlin даёт на 20% меньше задержек по сравнению с Flutter на устройствах 5-летней давности. Для современных флагманов разница несущественна. Это подтверждают наши тесты на iPhone 8 и Samsung Galaxy S9.
Как масштабировать приложение под тысячи игроков?
Архитектура построена на микросервисах: матчмейкинг, синхронизация и рейтинг вынесены в отдельные сервисы. База данных на PostgreSQL с шардингом по games.id. Redis используется для очередей и кэша. WebSocket-сервер на Node.js с кластеризацией — для горизонтального масштабирования. Это позволяет выдерживать тысячи одновременных партий без потери производительности. Детали архитектуры
Мы используем Kubernetes для оркестрации сервисов. Каждый сервис имеет отдельный балансировщик. WebSocket-сервер работает на нескольких подах с общим Redis pub/sub для рассылки ходов. Это даёт отказоустойчивость и линейное масштабирование.
Что входит в работу
- Архитектурная документация (диаграммы потоков, схемы БД).
- Исходный код с Unit-тестами.
- Интеграция с App Store Connect / Google Play Console.
- Инструкция по деплою и мониторингу.
- Обучение команды заказчика (1-2 дня).
- Техническая поддержка 3 месяца после релиза.
Ориентировочные сроки
| Функционал | Сроки |
|---|---|
| Игра против AI (Stockfish) | 4–5 недель |
| Онлайн-игра + таймер | 6–8 недель |
| Матчмейкинг + рейтинг | 2–3 недели |
| Полное приложение | 8–12 недель |
Почему стоит заказать у нас
Наша команда имеет 8+ лет опыта в мобильной разработке и более 15 реализованных проектов в сфере онлайн-игр. Используем только проверенные технологии: WebSocket, Stockfish, нативные API. Оптимизация затрат — до 30% экономии по сравнению с разработкой собственного движка. Мы предлагаем разработку под ключ: от прототипа до публикации в сторах. App Store Review Guidelines (Section 4.2, 5.1) — наши инженеры знают их наизусть.
Свяжитесь с нами, чтобы обсудить ваш проект. Получите консультацию по архитектуре и оценку стоимости. Мы гарантируем прозрачность на каждом этапе. Закажите демонстрацию нашего подхода на реальном проекте.