В целом можно реализовать упрощенную физику просто для валидации именно попадания, поинт хороший. Выйдет дороже, но и точнее. Тут стоит отметить, что если есть пушки которые стреляют по сложной траектории, то нужно еще заложить реализацию общих библиотек для расчета траекторий, ну и соответственно поддерживать общую библиотеку. Опять же, если в игре сняряды взаимодейтсвуют друг с другом, то тогда такое решение не подходит и нужно уже всю физику на сервер переводить.
Про матчмейкинг думаю стоит отдельно статью подготовить, там есть интересные нюансы. Если коротко, то сначала была проблема с матчингом, так как алгоритм подбора был реализован довольно просто. Потом появились лиги, которые изменили в целом подбор игроков в случайном бою и стало получше. Тут вероятно как у всех, слушаем комьюнити, анализируем, где есть проблемы с подбором игроков, и решаем их по мере поступления.
Действительно визуализация эффекта урона начинается без сервера, чтобы не было ощущения «тормозов». Изменение хп или смерть происходит только по команде. Самые дорогие по времени задержки в цепочке Req/Resp клиент-сервер-клиент связаны с передачей 2х пакетов клиент — сервер — клиент. Если сейчас наше среднее по больнице время передачи пакета оценить в 300 мс, то за 700 мс клиент обновит хп уже.
Вы не упомянули, что авторитарному серверу еще и физику нужно посчитать, чтобы вычисления по честному провести. Соответственно, нужно либо упрощенную физику сделать на сервере + протестить ее, либо клиент в батч-моде запускать на сервере (дешевле по времени, но совсем дороже по ресурсам). Так же нужно из клиента все это вытащить + протестить. Все это против нескольких дней разработки.
ZeXTeR вы правы, что график с кол-вом активных пользователей хорошо бы дополнил график по жалобам на нечестную игру, по возможности добавлю его туда. Судя по нашей аналитике мы кратно расширили аудиторию при падении жалоб на читеров.
Когда Lockstep уже реализован и игра может гарантировать детерминированность на всех устройствах при получении одинакового ввода, то можно задуматься и об использовании Lockstep. Но опять же соглашусь с Atox, что необходимость гарантировать такую детерминированность в сетевом шутере может стать отдельной головной болью и это желательно заложить еще при проектировании игры и выборе движка. Если изначально этого заложено не было, то можно потом начать разгребать букет проблем.
Тогда у нас может быть масштабный рассинхрон в игре, который непонятно как компенсировать. В худшем случае все будут играть в свою игру и состояние игры будет неопределенно. Непонятно как определять кто кого убил в итоге. Боюсь в конце матча кворум уже может не помочь. Кажется проще/надежнее выбрать кого-то из активных игроков и назначить его главным рефери игры.
Выше по комментариям писал про агрегацию урона. Используем не среднее арифметическое. Агрегировать можно по разному, зависит от того результата, который необходимо получить в первую очередь.
Я имел в виду, что если читер будет пробовать манипулировать показателями урона/здоровья и его показания попадут в кворум, то при агрегации в кворуме эти показания изменятся в сторону реалистичных показаний. Насколько изменятся уже будет зависеть от выбранного способа агрегации (среднее арифметическое, медиана и т.д.).
Согласен, что не стоит доверять клиенту, и если есть возможность все расчеты проводить на сервере. Но это и более дорогое решение, так что должна быть уверенность, что затраченные усилия окупятся. У нас в игре 3D мир, со своим рельефом, так что даже raycast кинуть становится интересной задачей. Сейчас у нас есть отдельные проверки на очень «быстрые» перемещения в игре, которые не стыкуются со скоростью игроков.
Кворум нужен, чтобы определить какой урон в итоге нужно применить к игроку. У нас на сервере пока нет расчета физики (возможно в будущем придем к использованию упрощенной физики на сервере), так что приходится полагаться на клиент даже в таком простом вопросе как попал по противнику или нет. Соответсвенно либо придется доверять какому-то одному клиенту в плане расчета урона (использовать мастер-клиент), либо опираться на несколько мнений, что делаем сейчас. А так действительно, читер сейчас будет модифицировать только свой локальный мир.
В тот момент, когда на сервере здоровье кончилось, отправить команду всем участникам матча на уничтожение «мертвого» игрока. Ничего не мешает для каждого игрока хранить начальное значение здоровья, потом накатывать изменения.
Согласен, что занижать геймплейный показатель ориентируясь на оценку других игроков не лучшая затея. Но можно объединять игроков со схожими оценками в одни матчи с возможностью реабилитироваться. Например ливеров с ливерами, читеров с читерами.
Правильно понимаете, что каждый выстрел рассылается сервером по всем клиентам. У каждого клиента действительно есть его картина мира, и есть информация о том кто кому сколько урона нанес. Это была первая реализация WR. Проблемы начинаются когда какой-то клиент изменяет свою картину мира каким-либо способом, встает вопрос кому доверять. Это решается с помощью кворума сейчас.
Действительно было желание оставить протокол клиент-серверного общения без существенных изменений. В данном случае, если делать совсем честного наблюдателя на сервере в качестве «микро-сервиса», то придется и физику расчитывать на сервере. В таком случае можно уже подумать в направлении полностью авторитарного сервера, так как почти все условия для этого уже будут созданы.
Мысль интересная. Я бы развил ее в отдельный функционал в игре — оценка игроками соперников/союзников. Тут уже добавится и социальный фактор, который можно использовать. Если среди оценок будет фигурировать стабильно «читер» или не командный игрок, то делать выводы. Это должно усложнить жизнь как и читерам, так и ливерам и т.д.
Клан читеров, который бы начал издеваться над противниками не сложно вычислить. А будет ли он всегда побеждать зависит от размера кворума и от того как он собирается.
Я имел в виду, что если читер будет пробовать манипулировать показателями урона/здоровья и его показания попадут в кворум, то при агрегации в кворуме эти показания изменятся в сторону реалистичных показаний. Насколько изменятся уже будет зависеть от выбранного способа агрегации (среднее арифметическое, медиана и т.д.).