Обман в геймдеве: компенсация задержки и игровое время

Обман в геймдеве — компенсация задержки
23.09.2024 12:28:34

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

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

В геймдеве же основной упор делается на удовлетворенности игрока. Существует множество ситуаций, особенно в динамичных играх, вроде сетевых шутеров, когда все сделать точно попросту не нужно.
Вот вам пример: игрок А с пингом в 10мс стреляет в игрока Б с пингом в 50мс. Если в такой ситуации все обработать честно, при такой задержке в обмене сообщениями с сервером игрок А убьет игрока Б еще до того, как тот сможет его увидеть. В итоге имеем полностью удовлетворенного игрока А, который действует как ниндзя и убивает всех очень быстро банально потому, что те его даже заметить не успевают и полностью неудовлетворенного игрока Б, который не понимает что вообще происходит. В результате перестанут играть оба, потому что обоим очень быстро станет не интересно.

В Genesyx, кстати, тоже случались подобные проблемы когда один игрок вроде бы успешно убегал по пустошам от другого, а тот на самом деле уже его настиг и затянул в бой. Есть различные подходы к решению этой проблемы и в их основе обычно лежит идея работы с игровым временем (или кадром), а не реальным. Это означает, что в моем примере выше программисту нужно будет учитывать пинги всех игроков и в момент условного нажатия выстрела игроком А не выполнять эту операцию сразу, а высчитывать в какой игровой момент (в каком кадре) это должно случиться по отношению к игроку Б и отложить выстрел в будущее. Обычно такие операции закладываются в половину самого долгого пинга, чтобы для всех участников игры все выглядело более-менее естественно. Заложенная задержка позволит игроку Б увидеть отыгрывающие анимации игрока А и, возможно, успеть увернуться от пули.

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