Синхронизация состояния игры клиент-сервер

Я делаю клиент-серверную игру в стиле MMO. Пока что у меня настроена структура так, что сервер и клиенты взаимодействуют друг с другом для предоставления обновлений состояния. Сервер поддерживает состояние игры и периодически вычисляет следующее состояние, а затем время от времени (каждые n миллисекунд) отправляет новое состояние всем клиентам. Пользователь может просматривать это новое состояние и реагировать на него на стороне клиента. Эти действия затем отправляются обратно на сервер для обработки и отправки для следующего обновления.

Очевидная проблема заключается в том, что для передачи этих обновлений между сервером и клиентами требуется время. Если клиент атакует врага, то к тому времени, когда это обновление вернется на сервер, вполне возможно, что сервер настолько продвинулся в игровом состоянии, что враг больше не находится в том же месте и вне досягаемости.

Для решения этой проблемы я пытался найти хорошее решение. Я просмотрел следующее, и это помогло некоторым, но не полностью: Синхронизация игры Mutli Player . Я уже пришел к выводу, что вместо того, чтобы просто передавать текущее состояние игры, я могу передавать другую информацию, такую ​​как направление (или целевое положение для движения ИИ) и скорость. Исходя из этого, у меня есть часть того, что необходимо, чтобы «угадать» на стороне клиента, каково фактическое состояние (как его видит сервер), продвигая состояние игры на n миллисекунд в будущее.

Проблема заключается в определении время, необходимое для перехода к состоянию, поскольку оно будет зависеть от времени задержки между сервером и клиентом, которое может значительно различаться. Кроме того, следует ли мне улучшить состояние игры до того, каким оно было в настоящее время, когда клиент его просматривает (т.е. учитывать только время, которое потребовалось обновлению, чтобы добраться до клиента), или я должен продвинуть его достаточно далеко, чтобы, когда его ответ будет отправлен обратно на сервер, к тому времени это будет правильное состояние (учет как для пути, так и из поездки ).

Есть предложения?

Повторим:

1) Как лучше всего рассчитать время между отправкой и получением?

2) Должен ли я продвигать состояние на стороне клиента настолько, чтобы считать для всего пути туда и обратно, или просто времени, необходимого для передачи данных с сервера клиенту?

РЕДАКТИРОВАТЬ: То, что я придумал до сих пор

Поскольку у меня уже есть много пакетов, идущих туда и обратно между клиентами и сервером, я не хочу добавлять к этому трафику, если мне нужно. В настоящее время клиенты отправляют на сервер пакеты обновления статуса (UDP) ~ 150 миллисекунд (только если что-то изменилось), а затем они принимаются и обрабатываются сервером. В настоящее время сервер не отправляет ответа на эти пакеты.

Для начала я попрошу клиентов попытаться оценить время задержки. Я буду использовать значение по умолчанию от 50 до 100 миллисекунд. Я предлагаю, чтобы примерно каждые 2 секунды (для каждого клиента) сервер немедленно отвечал на один из этих пакетов, отправляя обратно индекс пакета в специальном пакете обновления времени. Если клиент получает пакет синхронизации, он будет использовать индекс, чтобы вычислить, как давно этот пакет был отправлен, а затем использовать время между пакетами в качестве нового времени задержки.

Это должно держать клиентов в разумной степени в курсе их задержка, без слишком большого избыточного сетевого трафика.

Звук приемлемый, или есть лучший способ? Это все еще не отвечает на второй вопрос.