Вам нужно всего около 30 обновлений (или даже меньше, может быть, 10 или 20) в секунду. интерполировать позиции движущихся объектов на стороне клиента. Как правило, вы должны отправлять данные только тогда, когда они действительно необходимы. В WoW вы можете получать больше обновлений от игроков, с которыми вы находитесь в группе, чем от игроков, которые находятся в том же месте. Кроме того, если другой игрок находится далеко от вас, вы не получаете столько обновлений в секунду о нем.
Затем отправляйте только один полный снимок каждому игроку, когда он подключается. После этого отправляйте только изменения игровых объектов. Если никаких изменений не произошло, не отправляйте их.
Затем интенсивно используйте BitVectors или как бы вы их ни называли, чтобы уменьшить количество ненужных данных! Пример: Вы также можете попытаться записать число с плавающей запятой, используя только один байт (в диапазоне от 0 до 1 или от -1 до 1), поэтому у вас есть только 256 или 128 различных значений. Но игрок не заметит никаких резких движений благодаря интерполяциям.
Посмотрите на это для примера с LidgrenLibrary о том, как сжимать данные: http://code.google.com/p/lidgren-network-gen3/wiki/Optimization
Далее: постарайтесь уменьшить радиус обзора игроков по мере их движения и передавать только важную информацию за это время. Затем, когда они перестают, снова увеличивают радиус обзора. Вы можете использовать систему пространственного хеширования или дерево bsp, чтобы уменьшить накладные расходы при поиске объектов, находящихся «в зоне действия». Это хорошая статья по теме: http://en.wikipedia.org/wiki/Collision_detection
Также сжимайте данные, СЕБЕ СЕБЯ знаете только о структуре данных и временной согласованности в данных (которые можно и нужно использовать). Общий алгоритм, такой как Bzip2, Deflate, как угодно, должен использоваться, но только как финальная стадия сжатия!
Кроме того, для информации, не важной для игры, вы также можете использовать дополнительные методы P2P. Пример: игрок воспроизводит анимацию «привет» (просто графический эффект). Игрок отправляет эту информацию на сервер, но сервер не передает информацию другим игрокам. Вместо этого этот некритический эффект посылается самим игроком другим клиентам в радиусе действия.
РЕДАКТИРОВАТЬ (из-за комментария):
Дополнительные методы для уменьшения среднего количества бит в секунду для каждого игрока:
Вы написали, что отправляете «Объект не изменился». Нет причин делать это. Если вы беспокоитесь о потере пакета (и из-за этого не можете синхронизировать моделирование), учтите следующее: На каждом фиксированном временном шаге (например, 100, 200, 300, 400 ...) хешируйте состояние моделирования и отправляйте его на сервер. , сервер подтверждает или отправляет полный снимок всех данных обратно.
Для таких вещей, как ракеты или даже игроки, вы можете использовать не только интерполяцию, но и экстраполяцию, чтобы сделать симуляцию более реалистичной. Пример «Ракета»: вместо обновления с такими сообщениями, как «Сейчас в позиции х», просто отправьте сообщение один раз, содержащее следующее: «Ракета порождена: позиция (вектор), время (на каком этапе моделирования порождается ракета), скорость ( вектор)". Таким образом, вам даже не нужно включать вращение, потому что наконечник всегда будет в направлении «скорости».
Объедините несколько команд в одном сообщении и никогда не отправляйте сообщения размером менее 16-20 байт, потому что заголовок udp будет больше, чем само сообщение. Также не отправляйте пакеты, размер которых превышает MTU вашего протокола, потому что фрагментация замедлит скорость передачи.