Javascript многопользовательская игра - requestAnimationFrame для логики игры / физики?

Question

Я разрабатываю многопользовательскую игру на основе Javascript.Пока у меня есть базовый сервер, клиент и сеть.

У меня была проблема, когда мой плеер двигался быстрее на экране с частотой 120 Гц, а не с экраном с частотой 60 Гц.Я исправил это, умножив скорость движения игрока на deltatime 'requestAnimationFrame'.

Однако;было бы лучшим решением отделить анимацию от логики?

Как в:

//Game loop; Do each 1/60th of a second
setInterval(gameTick, 1000/60);
function gameTick(){
  player.handleKeys();
  enemies.foreach( (enemy) => {
    enemy.update();
  });
}

//Draw loop; match to player screen refresh rate
window.requestAnimationFrame(gameLoop);
function gameLoop() {
    player.draw();
    enemies.foreach( (enemy) => {
    enemy.draw();
  });
  window.requestAnimationFrame(gameLoop);
}

Хотя разница может быть "пренебрежимо малой", я хочу избегать игроков со спамом 240 Гц.сервер и имеют преимущество перед другими игроками.

Хотя, с другой стороны, для монитора с частотой 240 Гц;только 1 в 4 кадрах будет обрабатываться ваш ввод с клавиатуры, поэтому он может выглядеть не так гладко?

Эта причина, по которой я спрашиваю, заключается в том, что это будет соревновательная игра и поэтому должна быть сбалансированной.Но я проверил различные источники, по которым, как представляется, единодушным является использование requestAnimationFrame (даже для логики; не только для рисования), хотя я сомневаюсь в этом и хотел бы знать, какой из них правильный (и / или используется в профессиональнойсоревновательные игры).

Answer 1

requestAnimationFrame (rAF) будет срабатывать только с максимальной скоростью 60 кадров в секунду.(исключение Некоторые гораздо более старые версии некоторых браузеров имели флаги для выключения VSync, которые влияли на rAF)

Примечание

• rAf, setTimeout или setInterval не являются надежнымии может отбрасывать кадры по многим причинам.
• rAF прекратит срабатывание, если вкладка или окно скрыты или (вкладка) не сфокусирована.
• setInterval и setTimeout будут ограничены, еслиTab или Window скрыты или (tab) не в фокусе.

• Аргумент времени rAF не представляет время (следующего отображаемого) кадра, а скорее время вызова обратного вызова rAF.

  Это означает, что ...

  • время между кадрами, если оно вычислено из аргумента времени rAF, будет плавать и не может быть надежно использовано в качестве дельта-времени.
  • аргумент time представляет время вызова, а не время кадра, представляемого на дисплей, и может быть на <1/60 секунды раньше, чем отображаемый контент представляется аппаратному обеспечению дисплея. </li>

Локальные сети

В многопользовательских играх сервер должен обслуживать время так, чтобы у всех игроков было общее и надежное время.Клиенты могут проецировать время вперед от последней отметки времени, чтобы избежать зависания, если сеть задерживает пакеты, но должны возвращаться к синхронизированному (серверному) времени при получении.

Большие сети

Связь зависит от расстояния,даже в идеальной сети точка-точка, если клиент находится на другом конце света, наилучший возможный пинг составляет 130 мс (около 8 кадров при 60 Гц) из-за небольшого времени прохождения.Это не включает коммутацию пакетов и фактическую длину маршрута.Обычно время пинга до наиболее удаленной точки земного шара составляет около 300 мс.

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

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

BTW

window по умолчанию this (globalThis) и как таковой не требуется,например, window.requestAnimationFrame идентичен requestAnimationFrame