На мой взгляд, лучшая стратегия для подхода к пошаговой игре, подобной этой, - это выбрать некоторые базовые архитектурные подходы. Изобразите составные части и некоторые основные игровые схемы.
Вы должны поместить большую часть логики игрового движка в серверный компонент. Клиенты должны быть максимально тонкими, ориентируясь в первую очередь на
- Связь с игровым движком
- Принятие пользовательских данных
- Интерпретация ответов игрового движка
- Рисование экранов
Ваш сервер / игровой движок должен быть относительно не сохраняющим состояния, но вести список текущих игровых сессий в игре. Веб-службы SOAP с отслеживанием состояния или даже сервлеты HTTP были бы хорошим выбором, поскольку они поддерживают сессию для вас, размещая и читая сессионные cookie-файлы в запросе.
Вся сеть работает по запросу запроса, поэтому она по своей природе не имеет состояния, но некоторые технологии, такие как Java-сервлеты, помогут вам поддерживать сеансы, так что вам это не нужно. Нет необходимости физически создавать отдельные потоки, каждый запрос приводит к тому, что сервер приложений создает новый поток выполнения, в то время как сеанс по своей природе является изменчивым.
На стороне сервера я бы сохранил все данные для конкретной активной игры в сеансе. Таким образом, ваш игровой движок будет поддерживать упорядоченную связь между двумя игроками.
- Игрок 1 отправляет запрос на окончание хода со всей информацией об изменении состояния игры.
- Движок игры интерпретирует запрос, вносит необходимые изменения в состояние игры.
- Игрок 2 посылает частые запросы, чтобы проверить и посмотреть, не настал ли еще ход игрока 2 *. 1026 *
- Игровой движок подтверждает запрос Игрока 2 на его ход и отправляет новое игровое состояние в ответ.
- Игрок 2 получает ответ, обновляет свою копию состояния игры, отмечая изменения с момента его последнего хода.
- Сполосните и повторите.