mk4i9661, on 18 February 2014 - 05:59 AM, said:
Думаю имелось в виду следующее: один игрок, например, выстрелил из лазера. Информация о выстреле идет на сервер, сервер обрабатывает и отправляет всем остальным результат обработки (возможно, тут исключают самого игрока, как уж разработчики сделают)...
Благодарю, это достаточно точное отражение того, что я хотел передать.
Quote
А вот тут и всплывает оптимизация сетевого кода "пиранья-стайл", ведь при такой конфигурации бой 64 игроков будет просто адским для любого сервера. А вот только одна из идей оптимизации. Для начала принимаем тот факт, что клиент отсылает на сервер пакет с данными, которые он совершил за такт, каждый такт, и размер пакета примерно не меняется. В этом случае увеличение числа игроков увеличивает нагрузку на сервер линейно. Далее вспоминаем тот факт, что на клиентском компе отсчитывается всё поле боя, так что каждый клиент должен получать информацию о каждом мехе. В данном случае получаем тот факт, что всем игрокам нужно отослать информацию обо всех игроках, то есть всем клиентским приложениям достаточно отослать один и тот же пакет с данными. В итоге получаем, что нагрузка при правильной оптимизации должна возрастать линейно, хотя тут ещё нужно учесть возрастающий объём пакета данных, но в итоге получим примерно 64*4, но никак не 64*64. Далее можно ещё упростить введя второй сервер, назовём его промежуточным, на него поступают данные от игроков, он формирует большой "общий" пакет данных, и пересылает его на основной, расчётный сервер. Основной сервер обрабатывает данные и отсылает "общий" ответ на промежуточный сервер. Он уже дробит пакет основываясь на нуждах клиентов и рассылает пакеты игрокам. В данном варианте промежуточных серверов может быть несколько, и они могут быть распределены по регионам. Я это в вкратце накидал, и это далеко от реальности, но это показывает, что если нагрузка при увеличении игроков возрастает квадратично, а не линейно, то надо плавники отрывать создателям и оптимизаторам сетевого кода...
Нед. Все равно будет 64х64. Потому как пакет от каждого клиента должен дойти до каждого играющего. Т.е. один пакет от одного играющего должен быть передан 64 раза. И речь идет не про количество пакетов, а про возрастание трафика, не надо путать эти вещи. В процессе передачи сообщений, при превышении некоторого размера пакет может быть нарезан на несколько частей. И наоборот, если два пакета посланы с достаточно коротким промежутком времени, принимающий компьютер вполне может их объединить в один. Так что уместно говорить именно о трафике, а не о пакетах.
Оптимизация сетевого кода ведется несколько иным путем. Например, в первую очередь, избавляются от лишней информации. Например, для передачи текстовой информации на каждый символ нам нужен 1 байт данных ( 8 бит). При этом, на каждый символ, который является цифрой, нам вполне достаточно 5 битов. Можно провести этакую компрессию, зная тип передаваемых данных.
Или, как еще один вариант: передавать данные только тех игроков, которые непосредственно видны самому игроку. Но это увеличит нагрузку на вычислительную часть сервера.
А вообще, исходя из того, что я читал про код Рыб с их же собственных слов, до оптимизации нам очень далеко. Может быть я ошибаюсь, конечно, но они постоянно транслируют данные о мехе, на которого вы навелись, тем самым создавая заметный трафик и сами же на него жалуются.
Но как же все же должно быть в идеале? А в идеале должно быть несколько иначе. Посылать пакеты каждый такт - это жесть, давайте оставим такую штуку для игр типа Supreme Commander. А в экшенах и симуляторах должен использоваться "событийный" тип передачи сообщений. Изменил скорость - сообщил об этом серверу, начал поворачивать торс - сообщил серверу. Таким образом тоже нагрузка падает. Но создает возможности для неприятных рассинхронизаций.
В общем, поверьте, вопрос про увеличение количества игроков - штука очень сложная и зачастую требует хорошо продуманной концептуальной мысли или же нового подхода. А поскольку сейчас есть куда как более важные проблемы, то едва ли мы это все увидим в МВО.
Edited by Nanotentacle, 18 February 2014 - 10:34 PM.
2
