(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.)
Поскольку сетевые взаимодействия могут быть относительно медленными по сравнению с другими аспектами игры, важно уменьшить их до минимума. Следовательно, очень важно решить, каким объемом данных обмениваться и как часто производить этот обмен.
Величина используемого сетевого трафика в значительной мере зависит от того, используете ли вы Unreliable или Reliable Delta Compression режим для синхронизации данных (режим выставляется в компоненте Network View).
В режиме Unreliable, синхронизируемый объект будет целиком передаваться на каждой итерации цикла сетевого обновления. Частота этого обновления определяется величиной Network.sendRate, которая по умолчанию равна 15 обновлениям в секунду. Режим Unreliable гарантирует частые обновления, но любой потерянный или задерживающийся пакет будет просто игнорироваться. Часто это лучший режим синхронизации для объектов, меняющих своё состояние с большой частотой и когда эффект от утерянного обновления будет заметен очень короткое время. Однако, вам следует помнить об объемах данных, которые могут передаваться в каждом обновлении. Например, синхронизация компонента Transform включает передачу девяти переменных типа float (три Vector3 с тремя float в каждом), что равнозначно 36 байтам в каждом обновлении. Если к серверу подключено восемь клиентов и используется частота обновления по умолчанию, то он будет принимать 4.320 Кбайт в секунду (8*36*15) или 34.6 Кбит/с и передавать 30.2 Кбайт/с (8*7*36*15) или 242 Кбит/с. Вы можете значительно уменьшить потребление сетевого трафика, уменьшая частоту обновления, но значение по умолчанию 15 обычно подходит играм с быстрыми действиями.
В режиме Reliable Delta Compressed гарантируется, что данные будут надёжно отправлены и прибудут в правильном порядке. Если пакеты теряются, они отправляются заново, а если они приходят в неправильном порядке, то они будут помещаться в буфер до тех пор, пока не придут все пакеты последовательности. Хотя это гарантирует, что переданные данные будут получены корректно, ожидания и повторные отправления ведут к увеличению использования сетевого трафика. Однако, данные также дельта-компрессированы (сжаты по критерию изменения, delta compressed), что означает, что будут передаваться только отличия по сравнению с прошлым состоянием. Если состояние такое же, ничего не отправляется. Выгоды от дельта-компрессии, таким образом, зависят от того, как сильно изменяется состояние и в каких свойствах.
Существует множество возможностей проявить свои творческие способности при создании игры, так что состояние будет казаться одинаковым на всех клиентах, даже при том, что, строго говоря, может не быть таковым. Например, решение о том, где синхронизировать анимации. Если компонент Animation наблюдается в компоненте Network View, то его свойства будут синхронизироваться буквально одинаково на всех клиентах. Хотя в некоторых случаях это может быть оправдано, обычно персонажу достаточно выглядеть просто шагающим, бегающим, прыгающим и т.д. Так анимации могут грубо синхронизироваться, просто отправляя целочисленное значение, определяющее какую последовательность анимаций проигрывать. Это значительно сэкономит сетевой трафик по сравнению с синхронизацией всего компонента Animation целиком.
Часто нет необходимости поддерживать игру идеально синхронно на всех клиентах, например, в случаях, когда игроки временно в разных областях игры, где они в принципе не могут пересечься друг с другом. Это может уменьшить сетевой трафик, также как и нагрузку на сервер, раз только те, клиенты, что могут взаимодействовать, нуждаются в синхронизации. Иногда такая концепция приводит нас к Relevant Sets (т.е. существуют подмножества внутри всей игры, соответствующие какому-либо конкретному клиенту в какой-то конкретный момент). Синхронизация клиентов в соответствии с их множествами может осуществляться при помощи RPC, поскольку они могут обеспечивать значительный контроль над пунктами назначения обновления состояния state update.
Когда загружаются уровни, редко приходится волноваться о сетевом трафике, поскольку каждый клиент может просто подождать, пока у всех остальных не инициализируется уровень для игры. Загрузка уровня может часто включать передачу довольно больших объёмов данных (таких как картинки или аудиоданные).