(For new projects, you should use the new networking system introduced in 5.1. This information is for legacy projects using the old networking system.)
При заданном компоненте Network View Вы можете включить синхронизацию состояний State Synchronization, выбрав Reliable Delta Compressed или Unreliable из раскрывающегося меню State Synchronization. После этого, при помощи свойства Observed (предмет наблюдений) вы должны выбрать тип данных, которые будут синхронизироваться.
Юнити может синхронизировать компоненты Transform, Animation, Rigidbody и MonoBehaviour.
Transforms сериализуются, сохраняя position (позицию), rotation (вращение) и scale (масштаб). Информация о наследовании не передаётся по сети.
Animation сериализует состояние каждой запущенной анимации, такие как time (время), weight (вес), speed (скорость) и включенные свойства.
Rigidbody сериализует position (позицию), rotation (вращение), velocity (скорость) и angular velocity (угловую скорость).
Скрипты (MonoBehaviours) вызывают функцию OnSerializeNetworkView().
Компоненты Network View на данный момент поддерживают два способа передачи данных с разными уровнями надежности: Reliable Delta Compressed и Unreliable.
У обоих есть свои плюсы и минусы, и характерные особенности игры будут определять, какой из них лучше использовать.
Для большей информации о минимизации сетевого трафика, изучите Minimizing Bandwidth page.
Режим Reliable Delta Compressed (надежная сжатая передача изменений) автоматически будет сравнивать последние полученные клиентом данные с текущим состоянием. Если никаких изменений данных с последнего обновления не было, никаких данных передаваться не будет. Однако, данные будут сравниваться по каждому свойству. Например, если position (позиция) Transform изменилась, а rotation (вращение) - нет, то только position будет передан по сети. Передавая только изменяющиеся данные, вы сохраняете сетевой трафик.
Юнити также обеспечит, чтобы каждый UDP пакет надежно дошел, пересылая его до тех пор, пока принимающая сторона не определится. Это значит, что если пакет потеряется, любой последующий переданный пакет не будет обрабатываться до тех пор, пока потерянный пакет не будет передан заново и не примется. До тех пор, все более поздние пакеты будут продолжать ждать в буфере.
В режиме Unreliable (ненадёжный), Юнити будет отправлять пакеты, не проверяя, что они были получены. Это означает, что неизвестно какая информация была получена, так что не безопасно отправлять только измененные данные - будут отправляться все состояния целиком при каждом обновлении.
Протокол сетевого уровня использует UDP, обычно ненадежный, неупорядоченный протокол, но который можно использовать и для надёжной отправки упорядоченных пакетов, подобно тому, как это делает TCP. Чтобы это сделать, Юнити внутренне использует протокольные сообщения ACK и NACK, чтобы контролировать передачу пакетов, гарантируя тем самым, что ни один пакет не потеряется. У такого использования надёжно упорядоченных пакетов есть и обратная сторона: если пакет потеряется или задерживается, всё остановится до тех пор, пока этот пакет не придёт целиком. Это может вызывать запаздывание передач, если сеть работает со значительными задержками (лагами).
Ненадежные передачи данных можно использовать в тех случаях, когда вы знаете, что данные хоть как будут меняться каждый кадр. Например, в гоночных играх, на практике вы можете полагать, что автомобиль игрока всегда двигается, так что эффекты от потери пакета вскоре будут исправлены следующим пришедшим пакетом.
В общем, вам следует использовать ненадежную Unreliable отправку пакетов, когда быстрые частые обновления важнее пропущенных пакетов. Если же данные, напротив, меняются нечасто, вы можете использовать Reliable Delta Compression, чтобы сохранить пропускную способность.
В случаях, когда сервер обладает полной властью full authority над состоянием мира, клиенты изменяют состояние игры только в соответствии с обновлениями, которые они получают от сервера. Одна из проблем такого подхода в том, что задержка, обусловленная ожиданием ответа от сервера, может оказывать влияние на ход игры (геймплей). Например, если игрок нажмёт кнопку, чтобы пойти вперёд, в действительности он не сдвинется с места, пока не получит от сервера обновленное состояние. Задержки зависят от задержек соединения, так что чем хуже связь, тем менее отзывчивой становится система управления.
Одним из возможных решений этой проблемы является прогнозирование на стороне клиента Client-side Prediction, означающее, что клиент прогнозирует ожидаемое обновление движения от сервера, используя приблизительно такую же внутреннюю модель. Так что игрок незамедлительно реагирует на ввод, но сервер видит его позицию из последнего обновления. Когда, наконец-то, обновление состояния приходит от сервера, клиент сравнивает свой прогноз с тем, что в действительности произошло. Они могут различаться, так как сервер может знать больше о том, что происходит вокруг игрока, а клиент знает только то, что ему положено знать. Ошибки в прогнозах исправляются, как только случаются и если проводится постоянная корректировка, то результат будет более гладким и менее заметным.
Возможно применение базовых принципов прогнозирования на стороне клиента по отношению к оппонентам игрока. Экстраполяция Extrapolation это процесс сохранения нескольких последних известных значений position (позиции), velocity (скорость) и направления оппонента, после чего эти данные используются для прогнозирования, где он появится в ближайшем будущем. Когда придёт следующее обновление состояния с корректировкой позиции, состояние клиента будет обновлено с этой точной информацией, что может привести к внезапным скачкам персонажа, если прогнозирование было неудачным. В FPS играх поведение игроков может быть весьма непредсказуемым, следовательно описанный тип прогнозирования имеет ограниченную область применения. Если сетевые задержки становятся достаточно большими, оппонент будет совершать сильные скачки в соответствии с накоплением ошибки прогнозирования.
Интерполяция Interpolation может использоваться, когда пакеты теряются по пути к клиенту. Обычно это вызывает остановку движения NPC, после чего прыжок на новое место, как только пакет в конце концов приходит. Задерживая состояние мира на некое значение времени (примерно 100 мс) и интерполируя между последней известной позицией и новой, можно сделать движение между этими двумя точками гладким, даже если пакет потеряется.