Самое главное здесь: это пошаговая игра?
Для пошаговых игр вы можете просто использовать TCP-сокеты и передавать полное игровое состояние (или дельтуна основе предыдущего состояния игры) через сокет.На самом деле не имеет значения, как оно кодируется.
Для игр реального времени важно, чтобы вы пытались обновлять состояние как можно чаще.Это не важно, если пакет потерян;возможно другой пакет все еще находится в пути, который переопределяет предыдущий пакетВот почему вы должны использовать UDP-сокеты вместо TCP.
Учитывая, что вы говорите об играх на основе тайлов, подумайте, какую информацию вам нужно сообщить своим клиентам.Может быть, движутся только игроки, а остальные статичны?
Это сложный вопрос, который не позволяет дать однозначный ответ.Есть много проектных решений, которые нужно принять во внимание, касаясь дизайна основного цикла симуляции игры, мошенничества, тестов сетевой архитектуры и т. Д. Небольшой пример проблем, с которыми вы сталкиваетесь, см. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking.
Самое простое решение, которое я могу вам дать:
- Используйте сокеты TCP, чтобы вам не приходилось обрабатывать потерю пакетов.
- Когда состояние игры изменяется на сервере,распространять информацию о состоянии всех клиентов.Делайте это в чем-то, что не занимает много места.Примером может быть передача небольших пакетов следующим образом
ENTITY NUMBER - NEW POSITION
.(т.е. два 32-разрядных целых числа).Когда вам нужно одновременно передать несколько обновлений, убедитесь, что они содержатся в одном и том же TCP-пакете, и что буфер отправки TCP немедленно сбрасывается с обоих концов. - Забудьте все проблемы синхронизации, с которыми вы столкнетесь при работес клиентами со временем туда-обратно (пинг)
400ms
и выше.При необходимости вы можете преобразовать пакет следующим образом: ENTITY NUMBER - NEW POSITION - CURRENT SPEED VECTOR
, что позволит клиенту оценить положение объекта, включая задержку задержки.