Відзначимо: коли ви сідаєте грати в настілку з друзями, часто виникає суперечка про правила — чи допустимий такий хід, скільки очок нараховується за комбінацію. У мобільній версії подібних суперечок бути не повинно: кожен хід, кожен підрахунок контролюється кодом. Ми беремо настільну гру і формалізуємо її правила у вигляді скінченного автомата, виключаючи будь-які двозначності. Нижче розповім, як саме ми це робимо і який стек використовуємо.
Скінченний автомат — це абстрактна машина, яка може перебувати в одному зі скінченної множини станів.
Wikipedia
Формалізація правил
Перший крок — написати повну специфікацію правил у вигляді State Machine. Для гри типу «Монополія» або Ludo це кілька десятків станів і переходів. Використовуємо паттерн State або бібліотеку Stateless (портована на Unity). Кожен перехід містить guard conditions та actions. Це гарантує: не можна перейти в невалідний стан, всі правила явно закодовані, тестування — через юніт-тести станів без запуску Unity.
Приклад того, як виглядає ядро логіки на Swift:
enum GameState { case waitingForPlayers case playerTurn(Player) case resolvingMove case gameOver(winner: Player?) } struct Game { var state: GameState mutating func apply(action: Action) -> Bool { switch (state, action) { case (.waitingForPlayers, .startGame): state = .playerTurn(.first) return true // ... решта переходів default: return false } } } AI опонент
Для ігор з повною інформацією (шахи, шашки, абстрактні стратегії) застосовуємо Minimax з Alpha-Beta pruning. Глибина пошуку залежить від branching factor гри. На мобільних пристроях обмежуємо час пошуку: якщо AI не знайшов хід за 500ms — беремо найкращий знайдений. Для ігор з неповною інформацією (карти, приховані ходи) використовуємо Monte Carlo Tree Search (MCTS). MCTS не потребує оціночної функції та моделює випадкові фактори. На iPhone 14 MCTS з 10 000 ітерацій вкладається в 200ms.
Як налаштувати Firebase для мультиплеєра
Для онлайн-режиму використовуємо Firebase Realtime Database. Стан дошки зберігається як JSON, observers на клієнтах синхронізуються через Transaction API для атомарності. Налаштовуємо security rules, щоб кожен гравець міг оновлювати лише свої дані. Детальна документація доступна в офіційному гайді Firebase.Як вибрати AI-опонента для вашої гри?
- Визначте тип інформації: якщо всі дані про стан доступні обом гравцям (шашки, го) — використовуйте Minimax. Якщо є прихована інформація (карти в руці) — MCTS.
- Оцініть середню глибину гри: Minimax ефективний при small branching factor (до 30-40 ходів). Для великої кількості варіантів краще MCTS.
- Перевірте продуктивність на цільових пристроях: протестуйте обидва методи та виберіть кращий за співвідношенням точність/швидкість.
Отримайте консультацію щодо вашого проєкту — ми оцінимо складність і запропонуємо оптимальне рішення.
Чому MCTS кращий за Minimax для ігор з неповною інформацією?
MCTS моделює випадкові фактори без апріорних знань, тоді як Minimax потребує повної оціночної функції. Для карткових ігор MCTS в 3 рази ефективніший за точністю ходів, оскільки враховує ймовірності випадання карт.
Мультиплеєр: local pass-and-play
Найпростіший і найнедооціненіший режим: один телефон, кілька гравців по черзі. Реалізація тривіальна, але конверсія в органічний sharing — висока. Додайте екран «передай телефон» з анімацією перевороту — і local multiplayer готовий.
Для онлайн-режиму в настільних іграх оптимальна Firebase Realtime Database: стан дошки як JSON об'єкт, observers на обох клієнтах. Transaction API гарантує атомарність оновлень — немає race condition при одночасних ходах.
Порівняння AI-методів
| Метод | Повнота інформації | Продуктивність | Застосовність |
|---|---|---|---|
| Minimax | Повна | 4-8 ходів вглиб за 500ms | Шахи, шашки |
| MCTS | Неповна | 10 000 ітерацій за 200ms | Карти, приховані ходи |
Процес роботи
| Етап | Опис | Орієнтовний термін |
|---|---|---|
| Аналітика | Специфікація правил, визначення станів | 1-2 тижні |
| Проєктування | Архітектура, вибір стеку | 1 тиждень |
| Реалізація | Кодинг, AI, мультиплеєр | 2-6 місяців |
| Тестування | Юніт-тести, бета-тест | 2-4 тижні |
| Деплой | Публікація в App Store та Google Play | 1-2 тижні |
Терміни: класична настільна гра без AI — 2–4 місяці; з AI та онлайн-мультиплеєром — 4–7 місяців. Вартість розробки розраховується індивідуально та залежить від обсягу робіт.
Що входить в роботу
- Вихідний код з коментарями та документацією.
- Конфігурації для збірки та публікації (code signing, provisioning profiles).
- Налаштування Firebase, інтеграція аналітики.
- Допомога при проходженні рев'ю в сторах.
Ми спеціалізуємося на мобільній розробці більше 5 років і реалізували 20+ ігрових проєктів. Гарантуємо якість та дотримання термінів. Зв'яжіться з нами для оцінки вашого проєкту — замовте розробку мобільної настільної гри під ключ, і ми запропонуємо оптимальне рішення.
Детальніше про State Machine можна прочитати в Wikipedia, а про MCTS — в Wikipedia.