Не видел ни одного крутого специалиста, который бы считал невыгодным делиться опытом.
NDA — другое дело, но если вы говорите о реверс-инжиниринге, NDA вряд ли применяется.
TDD — это процесс, а не просто работа программиста, так что он может применяться, а может и не применяться.
И, что более важно, TDD никак не исключает QA.
Забавно. Мне кажется, есть весьма ограниченный класс компаний, куда можно устроиться подобным методом.
Я искренне не верю, что по результату технического интервью и/или тестового задания специалист не может отличить профессионала от дилетанта.
Пожалуйста) Я старался чтобы было максимально понятно)
Но хочу вас разочаровать: я не знаю. И автор не знает. Никто не знает) Потому что правильного варианта вообще нет, есть только грязные приемчики, дающие приемлемый результат)
В контексте данной статьи корректно было бы использовать время от отправки UDP пакета на сервер до получения ответа от него.
FPS как на клиенте так и на сервере безусловно влияет на получение более свежего состояния. Не сложно посчитать, что в худшем случае пингг возрастает на время равное 1/FPS, причем это верно как для FPS сервера, так и игровой машины.
Авторитарность сервера не так-то сильно и нарушается. Для AutoAim не нужна лагокомпенсация. Клиент знает положение врага?
Знает.
Значит может выстрелить ему в нос в реальном времени. Зачем для этого в прошлое возвращаться?
Я говорю о том, что до клиента так или иначе должны доходить ВСЕ дельты. Это обязательно, иначе будет расхождение в мире. Пусть изначальное состояние
X = 0.
Delta 0
X += 1
Delta 1
X -= 1
Delta 2
X += 1
Если, например, Delta1 не дойдет до клиента, у него X будет всегда на единицу больше чем надо.
Значит надо чтобы все дельты дошли. Так как UDP не гарантирует доставки пакетов, а использовать TCP — самоубийство, надо строить reliable протокол над UDP.
Верно. Единственная проблема дельта-компрессии в том, что для отображения n-ного состояния мира, нужно получить все состояния от 0 до n, а значит надо посылать состояния через reliable протокол, построенный над udp)
О_О привязка к фпс звучит очень странно.
Все обычно наоборот стараются абстрагироваться от FPS. А чтобы привязывали износ к FPS — это знатный изврат)
На тему рукопашки. Рукопашный бой — это вообще больная тема. С точки зрения игрока A, A и B находятся рядом, а с точки зрения игрока B, A и B рядом никогда не были. И что тут делать?
NDA — другое дело, но если вы говорите о реверс-инжиниринге, NDA вряд ли применяется.
Например, так.
И, что более важно, TDD никак не исключает QA.
Я искренне не верю, что по результату технического интервью и/или тестового задания специалист не может отличить профессионала от дилетанта.
Кстати, ссылки в комментариях можно делать кликабельными. Автоматически они не парсятся.
Компенсация лага баллистических снарядов — очень интересный аспект.
Думаю, вам тоже была бы полезна гифка)
Очевидно что в такой ситуации движок с которым знакомо большее количество разработчиков выйдет в топ.
Чтения из текстур довольно заметно влияют на скорость отрисовки.
Но хочу вас разочаровать: я не знаю. И автор не знает. Никто не знает) Потому что правильного варианта вообще нет, есть только грязные приемчики, дающие приемлемый результат)
FPS как на клиенте так и на сервере безусловно влияет на получение более свежего состояния. Не сложно посчитать, что в худшем случае пингг возрастает на время равное 1/FPS, причем это верно как для FPS сервера, так и игровой машины.
Знает.
Значит может выстрелить ему в нос в реальном времени. Зачем для этого в прошлое возвращаться?
Пусть изначальное состояние
X = 0.
Delta 0
X += 1
Delta 1
X -= 1
Delta 2
X += 1
Если, например, Delta1 не дойдет до клиента, у него X будет всегда на единицу больше чем надо.
Значит надо чтобы все дельты дошли. Так как UDP не гарантирует доставки пакетов, а использовать TCP — самоубийство, надо строить reliable протокол над UDP.
Я на выходных покопаюсь, может найду что-нибудь.
Все обычно наоборот стараются абстрагироваться от FPS. А чтобы привязывали износ к FPS — это знатный изврат)
На тему рукопашки. Рукопашный бой — это вообще больная тема. С точки зрения игрока A, A и B находятся рядом, а с точки зрения игрока B, A и B рядом никогда не были. И что тут делать?