ММО методы, алгоритмы и ресурсы для поддержания низкой пропускной способности?


9

Существуют ли какие-либо ресурсы и документация о том, как текущие MMO обрабатывают данные о действиях и перемещениях от сжатия до обработки на клиенте? Любые ресурсы для алгоритмов прогнозирования движения?

Меня особенно интересуют те, которые имеют движение wsad и сосредоточены на поддержании низкой задержки. Какова скорость и размер пакета для различных типов MMO (в сети)?

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

Ответы:


9

Что ж, есть эта книга - она ​​немного устарела, и я никогда ее не читал, но она от авторитетного издателя. Я также нашел этот , который новее, но я никогда не слышал раньше. Оба утверждают, что охватывают вопросы разработки игр для MMO (или, по крайней мере, онлайн); При этом прогноз на стороне клиента более или менее одинаков, независимо от масштаба вашей базы одновременных игроков, и у Google есть много информации об этом .

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

Есть две основные классификации вещей, которые вы можете сделать:

  • Будьте агрессивны в отношении отправки только минимального объема данных минимальному набору клиентов, которым это необходимо.
  • Создайте игру, которая не дает игрокам стимула слишком много собирать деньги, помогая вам в целом сократить количество «нужных клиентов».

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

Для первого варианта вы могли бы рассмотреть возможность рассылки многоуровневых сообщений - есть некоторые вещи о других игроках, которые всегда важно знать, такие как позиции. Но другие вещи, такие как здоровье, могут быть не столь важны для объектов, которые текущий игрок пока не может видеть, поэтому вы выбираете то, что отправляете этому игроку, исходя из относительного расстояния всех других объектов, находящихся рядом с ним - это, по сути, душит данные, которые вы отправляете, как вы упомянули в последнем бите вашего вопроса, а также их фильтрация.

Очень масштабные многопользовательские архитектуры также буферизуют отчеты, которые не требуют немедленных действий. Сообщения о сохранении символов, отправленные на сервер, могут быть выполнены в дельтах, с полными обновлениями только в критических точках, и эти обновления могут быть помещены в буфер на сервере регулирования, чтобы они отправлялись на сервер, который фактически содержит символьные данные в устойчивом состоянии, периодическая мода - по мере масштабирования базы проигрывателя вы должны заботиться об оптимизации дискового ввода-вывода, а также сетевого трафика. Вы не хотите, чтобы ваша база данных персонажей трэшлась.

Скорость и размер пакета сильно различаются от игры к игре, так же, как и для игр без MMO. Это действительно очень специфичная вещь, и нет общих стандартов.


1
Существует также продолжение первой книги (Massively Multiplayer Game Development 2). На мой взгляд, это не очень полезная серия книг (это определенно не книга «Сделай ММО за час», как в большинстве книг для разработчиков игр), но в ней обсуждаются некоторые теоретические проблемы. спросил в этом вопросе. И, возможно, это было бы более полезно для тех, у кого уже есть частично разработанная MMO.
Ricket

5

В дополнение к ответу, приведенному выше, прочтите TCP_NODELAY и узнайте, как работает масштабирование окна. Понимание деталей TCP (и да, вы хотите использовать TCP, а не UDP, если перспектива обработки разностных обновлений, поступающих не по порядку, звучит для вас забавно) и повторная передача важна для контроля задержки.


4
Я повторю, что если вы используете дифференциальные обновления (обычно бинарные различия в игровых структурах) и используете что-то с доставкой не по порядку (надежной или нет), вы об этом пожалеете. Люди, которые не любят TCP в играх, обычно просто не знают об этом (например, знают, что делает NODELAY). UDP имеет смысл для таких вещей, как голосовые данные, где пакеты с неправильным порядком можно просто отбросить, это редко бывает в игре.
Coderanger

1
"редко бывает в игре"? При условии, что сервер выдает мне авторитетные игровые состояния каждый кадр, мне все равно, что происходило в прошлом. Простой монотонно увеличивающийся номер кадра из пакетов UDP идеально подходит для этого. Сколько данных вам действительно нужно для надежной передачи?
ChrisE

2
«При условии, что сервер дает мне авторитетные игровые состояния каждый кадр» Конечно, если вы рассматриваете это как данность. Обратите внимание, что я сказал «если вы используете дифференциальные обновления», что будет противоположно стробированию полного состояния каждого кадра. В ММО с любым уровнем сложности в мире быстро станет невозможным поставлять полные обновления, которые часто.
Coderanger

1
Даже если вы отправляете полное состояние вещей, которые меняются, вы сталкиваетесь с проблемами неупорядоченной доставки, когда объединение вещей может стать невозможным. Подумайте об обновлениях «x = 1, y = 2», а затем «y = 1, z = 2». Если они приходят в обратном направлении, вы хотите отбросить «первый», чтобы значение y было правильным, но затем вы потеряете изменение в x.
Coderanger

1
@ Adam Вот почему я сказал, что вы должны прочитать спецификацию TCP и понять, как работает масштабирование окон и как оно взаимодействует с ретрансляцией ;-) Переписывание TCP в основном всегда неправильно, шансы испортить его близки к 100%. Если вы хотите надежной доставки заказа, не используйте UDP.
Coderanger
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.