Многопользовательская игра в реальном времени (концептуальный вопрос)

Question

Я читал эту статью от Valve, которая, кажется, объясняет архитектуру их многопользовательской системы. Кажется, что они задерживают рендеринг с помощью пары тиков на клиенте, чтобы они могли обрабатывать отброшенные пакеты, но они также отправляют пакеты как «дельта-снимки» (разница между двумя соседними состояниями).

Предположим, у нас есть времена A, B, C, и клиент правильный в момент A, но отбрасывает пакет в B, а затем получает пакет в C. Как он может правильно определить состояние в момент C? Пакет в C сообщает (я думаю) только дельту между состояниями B и C, а клиент знает только состояние в A. Что мне здесь не хватает?

Answer 1

Дельты не должны быть относительно предыдущего сообщения, которое было отправлено (дельтой или снимком). Вместо этого они будут относиться к последнему подтвержденному состоянию. Таким образом, в приведенном выше примере обновление в C может быть дельтой относительно A. Потеря сообщения B, следовательно, становится неудобством, поскольку дельты становятся больше (и потенциально может накапливаться ошибка), но в конечном итоге сообщение будет проходить и подтверждаться, и сервер может начать отправлять дельты относительно этого обновленного состояния.

Answer 2

Полное состояние синхронизируется периодически или по запросу клиента. Интерполяция / экстраполяция может использоваться для компенсации потери пакетов при ожидании полного обновления позиции. Некоторые события требуют надежной доставки и могут быть добавлены средства подтверждения получения.

У Гленна Фидлера есть отличных статей о сетевых играх в его блоге .

Эта старая статья о сети Quake 3 звучит похоже. Дельта-состояния представляют собой изменения от последнего подтвержденного состояния клиента, которое было получено. Итак, если сервер видит, что клиент позади, то будет создана следующая дельта из разницы между состоянием клиента и текущим состоянием сервера.

Answer 3

Сервер, вероятно, периодически отправляет полную синхронизацию (т.е. не дельты), но реже. По крайней мере, так я и делаю.

Answer 4

Из связанной статьи:

Обычно полные (не дельта) снимки отправляются только тогда, когда игра начинается или клиент страдает от сильной потери пакетов в течение пары секунд. Клиенты могут запросить полный снимок вручную с помощью команды cl_fullupdate.

Answer 5

Не глядя на реализацию, я бы предположил, что пакет C также содержит идентификатор пакета, от которого он является дельтой (в данном случае, пакета B).

Когда клиент получает пакет C после пакета A, он будет знать, что он еще не видел пакет B, и, следовательно, может запросить полное обновление с сервера.

Answer 6

Я предполагаю, что время от времени они посылают полный снимок. Вот почему в запаздывающих играх участвуют люди, работающие с неправильной скоростью, когда отбрасываются дельта-кадры, а затем «телепортируются» в правильное положение при получении полного снимка.