Многопользовательская производительность FPS на стороне сервера

Это связано с производительностью MMO за исключением того, что вопрос касается пропускной способности. Это о загрузке процессора.

Я собрал простой FPS, используя node.js и webGL. Это очень просто, очень похоже на клон BuddyMaze MIDI Maze. Происходит очень мало, все движутся в двух измерениях (без высоты), стреляют простыми снарядами и врезаются в стены.

Прямо сейчас, если я сделаю несколько подключений к серверу, где каждый игрок быстро стреляет, вращаясь по кругу, я могу привлечь в игру около 15-20 игроков, пока сервер не исчерпает ядро ​​и не замедлит работу. И это при работе на скорости 30 кадров в секунду на сервере. При 10 кадрах в секунду я получаю около 25-30 соединений. Это довольно плохо, так как в ближайшее время у игры будет гораздо больше дел, и мне нужно собрать больше игроков, чтобы это было осуществимым начинанием.

Мой брат только что указал некоторые статистические данные о сервере TF2 своего коллеги. Его сервер имеет более низкие характеристики, чем наш, но он работает с TF2, очевидно, гораздо более сложной игрой, с колоссальными 500 тактами в секунду, с 36 пользователями на ядро. Кроме того, в настоящее время мы потребляем гораздо большую пропускную способность, чем они, но мы еще не пытались снизить ее.

Как это возможно? Какие хитрости существуют для увеличения производительности сервера до такой величины? Вот некоторые вещи, которые я знаю:

• Снижение частоты кадров на сервере и интерполяция позиций на клиенте. Я получил некоторую выгоду, но, очевидно, сервер TF2 даже не беспокоится об этом.
• Делать дорогостоящие вещи, такие как обнаружение коллизий на клиенте, и редко проверять его на сервере. Я еще не перенес это, я сделаю это сегодня вечером. Несмотря на это, я не ожидаю такой огромной выгоды.
• Разбейте игровое поле на регионы (квад-деревья), чтобы минимизировать вычисления. У меня еще не было возможности для этого.
• Я рассмотрел досадную возможность того, что node.js намного медленнее, чем тот, который использует TF2, и может не подходить для такого рода задач с высокой интенсивностью.
• Это все в магии конфигурации сервера?

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

Обновить

Профилирование - единственная мантра, которую я когда-либо нашел, это абсолютно непогрешимо. Я быстро обернул некоторые функции синхронизации вокруг своего кода (спасибо, FP!) И обнаружил то, чего никогда не ожидал: передача данных клиентам занимает почти все время выполнения. В частности, около 90%. Дальнейшее тестирование показало, что это время зависит как от количества клиентов, так и от размера данных, но в большей степени от последних. При загрузке 20 пользователей я сократил время вещания на 90% с 24 мс до чуть более 2 мс, отправив только "{}" вместо полных данных. Но только с 5 пользователями вещание занимает около 0,5 мс. Поэтому мне явно необходимо провести некоторую оптимизацию здесь.

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

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

Это значительно уменьшит сетевой трафик.

Еще одна вещь, которую следует учитывать, - не иметь игровых галочек на сервере, а вместо этого заставить клиента отправлять сообщения только тогда, когда происходит действие (изменение направления, выстрел), а затем вычислять заранее на сервере при получении действия.

Я рассмотрел досадную возможность того, что node.js намного медленнее, чем тот, который использует TF2, и может не подходить для такого рода задач с высокой интенсивностью.

Это наверное так. Сервер TF2 написан с использованием C / C ++ и, следовательно, будет работать быстрее, чем node.js (который, если я правильно помню, использует Javascript, интерпретируемый в Java)

Quake на основе WebGL от Google использует Java для сервера, а исходный код находится здесь: http://code.google.com/p/quake2-gwt-port/ . Возможно, стоит посмотреть через это, чтобы увидеть, как это делается. Мне также интересно, что вы имеете в виду, когда говорите о наличии частоты кадров на сервере. Нет никаких причин для рендеринга чего-либо на сервере, оно должно быть просто для обработки команд, отправленных клиентом.

Наконец, правило «не доверяй клиенту» важнее, чем перекладывать дорогостоящие вычисления на клиента в надежде повысить производительность. Особенно такая важная вещь, как обнаружение столкновений. Вдвойне так, когда ваша игра основана на Javascript, и поэтому довольно легко взломать (по сравнению с чем-то вроде TF2, который компилируется).

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