Несколько лет назад появился прототип игры War Robots (тогда она еще называлась Walking War Robots). Это был первый опыт Pixonic в жанре тактического PvP, поэтому многие будущие проблемы были заложены в коде изначально. Но несмотря на ряд трудностей (популярность проекта стремительно росла, небольшая команда не могла полностью изменить архитектуру игры в краткие сроки), нам в итоге удалось свести к минимуму количество читеров, а также исправить другие недостатки оригинального кода. Расскажу немного подробнее.
Самая первая реализация WR не использовала авторитарный сервер — каждый из клиентов самостоятельно контролировал свои показатели здоровья и пересылал по сети их изменения остальным игрокам. Для пересылки сообщений мы использовали удаленный вызов процедур (RPC).
Схематичное изображение отправки нового значения здоровья с помощью RPC при получении урона через Photon Cloud Server с последующей доставкой другим игрокам.
Такой подход было легче реализовать с точки зрения архитектуры, так как он не требовал логики на сервере, а вычисления проводились на клиентах. В результате команде удалось быстро получить пилотную версию игры и оценить интерес аудитории.
Разумеется, в итоге остро встал вопрос честной игры. Невозможно напрямую проконтролировать, действительно ли клиент регистрирует весь входящий урон. И при росте аудитории эта проблема ожидаемо становилась все более актуальной.
«Неубивашки»
Проблему «бессмертных» игроков можно условно описать тремя ситуациями:
- Игрок испытывает проблемы с подключением к сети. В результате он просто «не видит» своих повреждений и не посылает обновленное состояние. Для остальных участников игры это выглядит так, словно попадание по цели проходило с задержкой, неполностью или вовсе отсутствовало в какой-то промежуток времени.
- Игрок намеренно обрывает свое подключение к интернету (например, переведя приложение в неактивный режим) и игнорирует входящие повреждения.
- Игрок жульничает другим способом и становится бессмертным.
Существует несколько способов решения этой проблемы.
- Можно выискивать и банить читеров или автоматизировать их поиск по разным критериям (например, по среднему урону в бою). Для этого потребуется выстроить комплексную программную защиту, которая, исходя из поведения игрока и других аспектов матча, могла бы распознать нечестную игру.
Но это довольно трудоемкий вариант, так как необходимо будет отслеживать игровой процесс каждого игрока, а также сформировать и протестировать набор правил, по которым читеры будут выделяться из общей массы. - Другое популярное решение — авторитарный сервер. В этом случае вся логика матча работает на сервере, и он полностью контролирует стрельбу и урон.
Мы думали о разных способах реализации этого подхода, также рассматривали вариант с запуском Unity в batchmod’е, но в итоге отказались от идеи, так как она требовала полностью переделать клиент-серверное взаимодействие в проекте.
Тогда мы стали искать другой выход из ситуации, который свел бы проблему к минимуму.
К чему же мы пришли?..
Демократия
Мы использовали ту же базу, что уже была в прототипе, но изменили один ключевой момент — здоровье игроков теперь контролировал сервер на основе всех поступающих к нему данных.
Каждый из клиентов отправлял на сервер показатели урона не только по себе, но и по другим игрокам. Далее сервер принимал решение о текущем состоянии здоровья клиентов, набирая кворум показаний и рассылал это игрокам. Таким образом, у нас получилась некоторая смесь между локальным подсчетом урона и авторитарным сервером.
Сразу стоит отметить ограничения такого способа. Он не работает для игр 1 на 1. Совсем. Если у двух игроков будет расхождение в показаниях — непонятно, какой из них говорит истину.
Главный плюс — это было относительно «дешевое» решение, так как нам не пришлось глобально переписывать сетевой код и в то же время удалось решить проблему с «читерами».
Алгоритм
Фактически алгоритм нанесения урона условно можно разделить на 3 части:
- Регистрация урона каждым клиентом всех игроков и отправка этих показаний на сервер.
- Сбор показателей урона, агрегация, вычисление текущего здоровья жертвы и рассылка итогового значения всем участникам матча.
- Получение актуального здоровья с сервера.
Более подробно это происходит так: каждый из клиентов отслеживает попадания по каждому игроку и регистрирует этот урон на сервере. На сервер отправляется RPC-сообщение с информацией о попадании в виде:
В сообщении указаны ID жертвы, ID нанесшего урон, ID выстрела и сам урон. Стоит отметить, что в War Robots за каждым снарядом закреплен определенный идентификатор, который синхронизирован между клиентами.
Следующий шаг — агрегация показателей урона на сервере. Берется кворум размера N, после чего клиентские показатели урона агрегируются. Финальный урон применяется к цели и новое состояние здоровья рассылается всем участникам боя. Схематично это выглядит так:
Таким образом, это и не авторитарный сервер, но и не простой локальный подсчет урона на каждом игроке. В итоге один человек не может «уронить» всю систему. Он, конечно, может попытаться скорректировать урон, но полностью его избежать ему не удастся.
Разумеется, это решение не идеальное. Главной трудностью является необходимость синхронизировать ID каждого выстрела (что является отдельной проблемой). Но вот что произошло с жалобами игроков на читеров после ввода новой системы подсчета урона:
Синий график — количество жалоб игроков на читеров.
Конечно, работа над WR продолжается, но главное, что мы вынесли из этой истории — не стоит всегда опираться на готовые ответы из учебников. На каждом из этапов — от прототипирования до удержания существующей базы игроков — мы исходили из текущих задач и потребностей.
Если бы всё сразу делали «как надо» несколько лет назад, некоторых ошибок можно было бы избежать, но сама игра могла бы просто не выстрелить, а ресурсы были бы потрачены.
Комментарии (56)
aamonster
28.11.2017 13:17Молодцы.
Кстати, напрашивается ещё одно усовершенствование, которое позволит проводить пересчёты и при игре один на один: считать "показатель честности" игрока. Если в ходе игр регулярно видим занижение урона — снижаем показатель. А при расчёте итогового урона — более значимы данные от игроков с высоким показателем.
skzloy Автор
28.11.2017 15:06Мысль интересная. Я бы развил ее в отдельный функционал в игре — оценка игроками соперников/союзников. Тут уже добавится и социальный фактор, который можно использовать. Если среди оценок будет фигурировать стабильно «читер» или не командный игрок, то делать выводы. Это должно усложнить жизнь как и читерам, так и ливерам и т.д.
vlx
28.11.2017 15:48Толи PUBG то ли Fortnite недавно стравливала читеров — в 200 рыльное поле боя попадали в основном читеры или заподозренные в читах и грызлись там на своих мапхаках, проваливаниях в текстуры и прочих дырах клиента.
Но вообще верить клиенту это фуфуфу. Но серверсайд-обработка реализуема в стратежках и прочих слоупочных играх, но никак не в экшонах и тем более FPS.mayorovp
28.11.2017 16:57Ха-ха, все совсем наоборот. Именно в FPS серверсайд-обработка вполне реализуема из-за малого количества участников. А вот в стратежках общее количество юнитов просто заставляет использовать всяческие Lockstep.
T-362
28.11.2017 15:57Оценка игроками для занижения кого-то — очень плохая идея, максимум что с ней можно делать так повышать награду за бой (если она есть) игроку с самыми положительными оценками от других (см. сессионки от близзард). Бездушный алгоритм на стороне сервера решает.
Именно тот-же социальный фактор будет портить игру — если человек, например, удак, или мамкин трубашататель, но играет хорошо, а ему за это будут понижать чисто геймплейный показатель а не чат мьютить — это какая-то фигня.
А еще показателю желательно быть лимитированным, типа от 50% доверия до 125%, и считать в среднем за последние N сессий, дабы избежать проваливания игроков с плохим коннектом в пучину негативной кармы, из которой они не выберутся даже если будут играть пару лет с нормального соединения.
skzloy Автор
28.11.2017 18:47Согласен, что занижать геймплейный показатель ориентируясь на оценку других игроков не лучшая затея. Но можно объединять игроков со схожими оценками в одни матчи с возможностью реабилитироваться. Например ливеров с ливерами, читеров с читерами.
T-362
29.11.2017 14:58В любом случае можно алгоритмически выявлять "потенциально плохую связь" (потери всех пакетов, пинг) и "потенциально читеров" (получение аномальных значений в пакетах, потеря определенных типов пакетов), потому-что если объединять в матчах читеров и игроков с плохим коннектом, или просто игроков с плохим коннектом — получится еще более жестоко, хотя и очень весело.
Dart_Zaiac
29.11.2017 21:31Работа с комьюнити — это всегда самый страшный ужас разработчика онлайн игр.
Я играю в Лигу Легенд и могу описать до чего там эволюцилнировали систему чести. Все прошлые этапы эволюции описывать лень.
1. После каждой игры на экране появляется 4 картинки персонажей своей команды (игра 5 на 5 игроков), где ты можешь похвалить (в течение 30 секунд) одного игрока или за хорошую игру (GG) или за коммуникацию или «не терял духа» (все проигрывают, а он подбадривал).
2. После игры можно зарепортить игрока за фид, ругань и прочие непотребства (и читерство в тч). Не только своего, но и противника.
В результате получаешь очки чести, которые повышают твой ранг чести от 0 до 5. Все начинают со 2 ранга. Если часто репортятся, то теряют очки и опускаются ниже и лишаются чата, возможности играть с приятными людьми. Если репортов нет, то получают условно 1 очко. За похвалу 2-3.
3. За 3-4-5 ранг дают плюшки ввиде чемпионов на халяву (точнее осколков, которые можно собрать в полноценных дешевле, чем покупать новых).
Это заставляет игрокова быть вежлевее/честнее. Самых отпертых негодяев (даже суперумелых) вышвыривают на год. Просто банят все учетные записи.
Tiendil
28.11.2017 13:19Не лучший вариант, но лучше так, чем никак. В случайных боях будет работать.
Более общее решение — считать контрольные суммы состояния игры и сверять их на сервере. Но это требует качественной реализации клиентской логики (должна быть строго детерминированной) и проблема с кворумом остаётся.
maxim_0_o
28.11.2017 13:20+1У этого варианта минимум два минуса:
- Не работает на PvP (как вы писали в статье)
- Куча читеров может всех унижать (как писали выше в комментариях)
А я тут подумал, а что если зарегистрировать служебного пользователя, захостить его где-нибудь на сервере и подключать к каждой игре? Получается он смог бы, как текущие клиенты, отслеживать все действия в игре и отправлять данные на сервер. А на сервере сделать, чтобы он доверял только этому специальному клиенту и при этом не показывал его присутствие остальным участникам. Это бы решило предыдущие проблемы.
mayorovp
28.11.2017 14:07В таком случае «служебный клиент» становится просто частью сервера. То есть этот подход не позволяет переложить расчеты на клиентов.
maxim_0_o
28.11.2017 14:19Так получается, что расчет переложен на отдельный «микро-сервис». Насколько я понял, на сервер не хотели перекладывать обязанность подсчета, потому что пришлось бы менять протокол общения с клиентом. А так получается протокол остается старым, но при этом расчет происходит на сервере.
skzloy Автор
28.11.2017 15:13Действительно было желание оставить протокол клиент-серверного общения без существенных изменений. В данном случае, если делать совсем честного наблюдателя на сервере в качестве «микро-сервиса», то придется и физику расчитывать на сервере. В таком случае можно уже подумать в направлении полностью авторитарного сервера, так как почти все условия для этого уже будут созданы.
mayorovp
28.11.2017 14:14Правильно ли я понимаю, что каждый выстрел рассылается сервером по всем клиентам? В таком случае у каждого клиента уже есть его картина мира, в которой известно кто кому сколько урона нанес. А значит, голосование за размер этого урона кворумом не нужно и его можно выкинуть, игра от этого только ускорится.
Кстати, получившийся после выкидывания лишнего шага алгоритм называется Lockstep и часто используется в стратегиях.
Однако у него есть принципиальная уязвимость (которая у вас, видимо, есть тоже) — maphack. Поскольку без авторитарного сервера каждый клиент обладает всем состоянием игры — читер всегда найдет способ вывести себе на экран ту информацию которую он видеть не должен.skzloy Автор
28.11.2017 16:29Правильно понимаете, что каждый выстрел рассылается сервером по всем клиентам. У каждого клиента действительно есть его картина мира, и есть информация о том кто кому сколько урона нанес. Это была первая реализация WR. Проблемы начинаются когда какой-то клиент изменяет свою картину мира каким-либо способом, встает вопрос кому доверять. Это решается с помощью кворума сейчас.
mayorovp
28.11.2017 16:55Так зачем кворум-то? Пусть сидит в своей картине мира если такой умный, остальные будут пользоваться правильной.
TheShock
29.11.2017 03:10Вопрос — когда на сервере отмечать игрока как «мертвого» и переставать посылать от него выстрелы другим игрокам?
skzloy Автор
29.11.2017 21:42В тот момент, когда на сервере здоровье кончилось, отправить команду всем участникам матча на уничтожение «мертвого» игрока. Ничего не мешает для каждого игрока хранить начальное значение здоровья, потом накатывать изменения.
TheShock
29.11.2017 22:18А если лже-клиент пришлет, что здоровье кончилось, хотя он не мог попасть по врагу? Сообственно, вы же автор топика, вы сами понимаете, что с тонким сервером «сидит в своей картине мира» врядли получится сделать — всегда возникнет куча вопрос.
skzloy Автор
29.11.2017 21:54Кворум нужен, чтобы определить какой урон в итоге нужно применить к игроку. У нас на сервере пока нет расчета физики (возможно в будущем придем к использованию упрощенной физики на сервере), так что приходится полагаться на клиент даже в таком простом вопросе как попал по противнику или нет. Соответсвенно либо придется доверять какому-то одному клиенту в плане расчета урона (использовать мастер-клиент), либо опираться на несколько мнений, что делаем сейчас. А так действительно, читер сейчас будет модифицировать только свой локальный мир.
mayorovp
30.11.2017 08:39А зачем тонкому серверу вообще доверять хоть кому-то? Каждый клиент доверяет только себе, а сервер вообще ничего не знает.
Вот в конце матча его результаты можно уже и кворумом утвердить.skzloy Автор
30.11.2017 16:50+1Тогда у нас может быть масштабный рассинхрон в игре, который непонятно как компенсировать. В худшем случае все будут играть в свою игру и состояние игры будет неопределенно. Непонятно как определять кто кого убил в итоге. Боюсь в конце матча кворум уже может не помочь. Кажется проще/надежнее выбрать кого-то из активных игроков и назначить его главным рефери игры.
Atox
30.11.2017 16:28+1Эх, если бы все было так просто. На деле, если все игроки будут самостоятельно симулировать весь игровой мир, а не только свои объекты, мы получим большую проблему рассинхронизации даже у честных игроков. Есть несколько причин, по которым это происходит. Во-первых, потеря пакетов. Во-вторых, недетерминированность игрового процесса. Рассчеты различаются, даже период игрового цикла нужно синхронизировать, иначе в перспективе могут быть проблемы. Еще есть проблема с погрешностью операций с числами с плавающей запятой. Более того, речь идет о Unity с кросс-платформенным рантаймом Mono — про детерминированный float можно забыть. Решить все эти проблемы для риалтайм игры, тем более 3D, намного сложнее, чем кажется, поэтому предпочтительно производить симуляцию объектов, которые принадлежат игроку, на его железе и отправлять результаты остальным участникам. В том числе и события в роде «в меня попали, я потерял 30 ХП.» Автор предложил улучшение в виде кворума, чтобы можно было определить кто есть кто и контролировать эти события. Я это к тому, что остальные не будут пользоваться правильной картиной мира, как вы предлагаете, просто потому что они не смогут ее просчитать с одинаковым результатом. В этом и заключается вся проблема. Пришлось бы синхронизировать состояния при расхождении, но опять же, кому тогда верить, что выбрать за эталон? Снова прибегнуть к кворуму?:) Возможно Вы имеете в виду только события выстрела и нанесения урона по игроку, а не движение игрока. Опять же, картина различается. Игрок пришлет всем информацию о том, что он выстрелил, а остальные по-своему рассчитают попал ли он или нет… В то время, как картина мира у всех своя. Какая бы ни была абстракция, рассхождения будут. Да и вообще, оба решения имеют те же недостатки. Мы не можем честно проверить, попал ли игрок по игроку без арбитра со своей симуляцией. Когда у нас две симуляции на разных машинах — это конец, в теории погрешности уже не миновать и не важно, какой подход вы выберите: «в меня попали» или «я выстрелил, посчитайте куда я попал,» потому что позиция противника в одно и то же время на разным машинах может различаться (как минимум в связи с особенностями сети), ровно как и его направление выстрела. С одной стороны, игрок может всем говорить, что никто в него не попал и, может быть, с его пингом он даже будет прав, хотя другие будут считать иначе. Все проблемы мог бы решить сервер, который симулировал бы игровой мир и ставил точки над i, но это чрезвычайно сложная задача. Более того, оно того зачастую не стоит, если у вас, конечно, игроки сами сервер не хостят ведь мы часто хотим разработать свою систему мультиплеера и монетизировать ее, в этом весь смысл. Если оно того стоит, то надежнее авторитарного сервера пока ничего не придумали. Я считаю, стоит приобщиться к консольному рынку, который, к тому же, является основным в игровой индустрии и забыть про нечестных игроков, ведь платформа закрыта. Чтобы ваша игра с такой сложной системой, которую еще нужно обслуживать имела смысл, она должна покрывать все расходы. Обратите внимание, какие игры сегодня используют авторитарный сервер? Либо MMO, либо сессионные игры, в которых игроки сами хостят серверы (для них этот подход абсолютно оправдан). Разработать свое решение действительно непросто, отнюдь. Рассчитывая объекты игрока на его железе мы значительно экономим ресурсы, время и нервы. Авторитарный сервер, ко всему прочему, дорог в содержании, а не только в разработке. Знаю, ваш вопрос был не про сервер, но это я лишь к тому, что нет здесь идеального решения, есть только компромисс. Поправьте меня, если я неправ, я тоже хочу узнать в этой теме что-то новое.
mayorovp
30.11.2017 16:35Я спорю не про разницу между Lockstep и авторитарным сервером, а про необходимость прикручивания дополнительного механизма кворума в то время когда Lockstep уже реализован.
skzloy Автор
30.11.2017 17:08Когда Lockstep уже реализован и игра может гарантировать детерминированность на всех устройствах при получении одинакового ввода, то можно задуматься и об использовании Lockstep. Но опять же соглашусь с Atox, что необходимость гарантировать такую детерминированность в сетевом шутере может стать отдельной головной болью и это желательно заложить еще при проектировании игры и выборе движка. Если изначально этого заложено не было, то можно потом начать разгребать букет проблем.
IamNoExist
29.11.2017 13:54Кстати, получившийся после выкидывания лишнего шага алгоритм называется Lockstep и часто используется в стратегиях.
Вы упускаете одну очень важную деталь, практически во всех стратегиях все вычисления влияющие на состояние мира — детерминированы, и там очень критичен рассинхрон хотя бы в одном параметре отдельного юнита, у автора же другая ситуация, ничего не детерминировано, и все параметры синхронизируются «на лету», поэтому небольшое различие в состояниях отдельных юнитов не критично, так как оно рано или поздно будет синхронизировано с данными от клиента — хозяина.
hokum13
28.11.2017 16:31Немного смущает использование средне-арифметического, а не медианы. Но расчет медианы конечно же гораздо более ресурсоемкий.
skzloy Автор
28.11.2017 17:08Я не писал про использование средне-арифметического. Вопрос агрегации показаний сам по себе интересен и достоен отдельного обсуждения.
hokum13
29.11.2017 09:43Он, конечно, может попытаться скорректировать урон, но полностью его избежать ему не удастся.
Просто вот это я воспринял, как подтверждение версии со средним арифметическим.
Жду «отдельного» обсуждения!
Спасибо за статью, было интересно.
mSnus
28.11.2017 17:21А нельзя просто стрелять периодически "волшебной пулей" и проверять урон? Если, он есть, все ок, и "рана заживает", если нет — мочим читера!
IamNoExist
29.11.2017 13:56Это будет работать до тех пор пока читер не знает о «волшебной пуле».
Psychosynthesis
30.11.2017 23:43А идея неплохая, вообще-то.
Откуда он узнает, если, например, сервер будет рандомно выбирать ID снаряда для проверки урона?
Neuyazvimy1
28.11.2017 23:40У вас в данный моммент есть проверка на телепорты?
Поидее можно было бы еще с каждым выстрелом отправлять Vector3 прицела и время выстрела и убрать damage. На сервере Raycast-ить и все(немного математики). Лучше никогда не доверять игроку.skzloy Автор
29.11.2017 22:02Согласен, что не стоит доверять клиенту, и если есть возможность все расчеты проводить на сервере. Но это и более дорогое решение, так что должна быть уверенность, что затраченные усилия окупятся. У нас в игре 3D мир, со своим рельефом, так что даже raycast кинуть становится интересной задачей. Сейчас у нас есть отдельные проверки на очень «быстрые» перемещения в игре, которые не стыкуются со скоростью игроков.
mephius
29.11.2017 10:27Теперь самое время заняться валидацией перемещений, таймеров перезарядки и далее по списку, пока не получится авторитарный сервер ;)
GerrAlt
29.11.2017 11:50Достаточно необычная ситуация, получается что провести серверный рассчет урона это трудно(т.е. долго), а дождаться ответа всех участников матча и только после этого всем ответить это ОК. Обычно сетевые задержки это чуть ли не главное зло, а у вас получается что без оптимизации (и в худшем случае) у вас скорость сетевого взаимодействия всех клиентов с сервером будет чуть ниже скорости сетевого взаимодействия самого медленного участника матча. И что делать если мнения о ситуации поделились без большинства за один вариант?
vlreshet
30.11.2017 17:04И что делать если мнения о ситуации поделились без большинства за один вариант
return random() > 0.5; // :)
ZeXTeR
30.11.2017 16:28Да, количество репортов уменьшилось, но сам по себе этот график абсолютно ни о чем не говорит без графика с активными аккаунтами.
На данный момент это выглядит так, как будто вы просто потеряли большую часть аудитории, из-за чего, само собой, уменьшилось количество репортов.
Germes_Fox
30.11.2017 16:30Не совсем понял, каким образом вы получаете значение урона, которое нужно нанести. Среднее арифметическое? Или как понимать вашу фразу о том, что читер «может занизить урон, но не может его избежать»?
Возможно, стоит использовать медиану? Т.е. тот показатель урона, о котором сообщила большая половина пользователей? А в случае, если 50 на 50, то решение может вынести либо алгоритм проверки «честности», либо «дополнительные пользователь», о котором говорили выше.skzloy Автор
30.11.2017 16:40+3Выше по комментариям писал про агрегацию урона. Используем не среднее арифметическое. Агрегировать можно по разному, зависит от того результата, который необходимо получить в первую очередь.
Я имел в виду, что если читер будет пробовать манипулировать показателями урона/здоровья и его показания попадут в кворум, то при агрегации в кворуме эти показания изменятся в сторону реалистичных показаний. Насколько изменятся уже будет зависеть от выбранного способа агрегации (среднее арифметическое, медиана и т.д.).Germes_Fox
30.11.2017 16:54Прошу прощение за дублирование) и спасибо за ответ.
Аккаунт на хабре у меня неполноценный) видимо, пока вопрос висел в «одобрении», кто-то другой успел задать такой же :)
Спрашивал-то я ещё в день публикации
ThunderCat
30.11.2017 17:35я чет недопонимаю смысла вашего демократического подхода, если у вас всем рассылается информация об уроне и дамаге, то не проще для каждой игры вводить «наблюдателя» от сервера (виртуального клиента с минимальными функциями) и опрашивать только его на предмет достоверности?
Psychosynthesis
01.12.2017 04:24Статья интересная, спасибо.
Но и косяков у вас достаточно, причём в вопросах, которые, вроде бы порядком проще. Расскажите, например, как у вас реализован алгоритм подбора игроков для случайного боя и почему так часто попадаются заведомо проигрышные ситуации, когда у одной из сторон, например, в сумме на три-четыре робота больше? С другой стороны, последнее время таких ситуаций стало меньше, но было бы интересно почитать про алгоритм всё-таки.
Ещё интересно что это у вас за нездоровая любовь ко всяким лотерейным розыгрышам и сундукам? Ощущение что кто-то из разработчиков ушёл из казино и ему теперь покою не дают крутящиеся барабаны из прошлого, ибо розыгрыши на «чёрном рынке» у вас по тому же принципу работают. Впрочем, они даже хуже — там ведь нет никакого элемента случайности — заведомо понятно, что первые три-четыре открытых лота будут: «премиум» или «серебро», «премиум» или «чуть-чуть деталей» и т.п. в зависимости от того какие призы исключить. Какое-то кидалово, короче.
В общем вопросов ещё много, аффтар, пешы исчо.
P.S. А ещё интересно почему вы не рассматриваете вакансии удалённых разработчиков, но это так, в порядке любопытства.
shishmakov
01.12.2017 11:07Про сундуки — они просто делают как все. Это как видео рекламу других игр показывать.
Вопрос про время ожидания ответа: какие у вас задержки между Req/Resp клиент-сервер-клиент? То есть я сделал выстрел и хочу получить сразу эффект урона по противнику или узнать свой урон, но прийдётся ждать кворума и только потом получение ответа.
Вопрос второй: клиент начинает визуализацию без получения ответа от сервера, чтобы не давать ощущение "тормозов"?
Всё это про хэдшот и определение жизни/смерти себя/противника, при малом количестве жизней. Клиент может визуализировать смерть противника, а потом после решения кворума — живой.
ierostenko
02.12.2017 14:36Спасибо за статью! А скажите, правильно ли я понял раз у вас нет авторитарного сервера, вы наверняка предсказания, интерполяцию и всякие такие штуки не делаете?
Zibx
При кворуме клан читеров всегда побеждает. Причём над противниками можно прям издеваться.
Dreyk
только хотел написать: собираешь компанию читеров и по одному мочишь в сортирах честных чуваков
skzloy Автор
Клан читеров, который бы начал издеваться над противниками не сложно вычислить. А будет ли он всегда побеждать зависит от размера кворума и от того как он собирается.
qw1
Тогда нужно голоса собирать поровну от каждой команды.