Защита от накрутки побед в баттлах в TowerDefence-играх при http-соединении

[mikhailk]

Никто не решал такую или аналогичную задачу?

Если делать игровой механизм "в лоб", то получается так: игрок расставляет объекты защиты и нажимает "Старт", клиент отправляет на сервер данные на начало боя, потом идут волны противников и клиент сообщает на сервер, чем все закончилось. При этом игрок в процессе игры может активировать те или иные функции у объектов, плюс применять еще какие-нибудь воздействия напрямую - т.е., при одной и той же начальной конфигурации может быть как победа, так и поражение. Очевидно, что подменив сообщение клиента об итогах баттла, игрок может накрутить себе побед, что, в свою очередь даст ему дополнительные бонусы и позволит занять первые места в топах с откровенно нереальными результатами. Я наблюдаю, что в некоторых TowerDefence-приложениях по этой причине просто отказались от общего топа и плюнули на накрутку.

Однако, если топ все-таки необходим?

На вскидку приходит на ум шифрование ответа клиента ключом, который надо прошить в клиенте так, чтобы без декомпиляции его было не получить, да и с компиляцией непросто (напр., заэмбедить свф-ку). Это какое-то количество "кулл-хацкеров" отсеет, но 100%-ным решением все-таки не является.

[FlashRus]

Как вариант - генерация байткода на лету.
Уровень вхождения кулл хацкеров в разы упадёт.

[iNils]

А почему активация функций и воздействия не отправляются на сервер?

[mikhailk]

А почему активация функций и воздействия не отправляются на сервер?

Большая скорость игры. Несколько действий в секунду. Почему я и указал про реализацию приложения с соединением с сервером по http.

Как вариант - генерация байткода на лету.

Не совсем понял, как это тут поможет.

[caseyryan]

Большая скорость игры.

Не может же быть игра на столько быстрой, что игрок даже не будет успевать кнопки нажимать.
Как решал такой вопрос я. При стрельбе из пулеметов или автоматов, получалось слишком много трафика, если отсылать каждый выстрел и проверять его, да еще и лишняя нагрузка на сервер при парсинге, поэтому пришел к решению отправлять на сервер данные при начале стрельбы и при окончании. Сервер начинает все это просчитывать параллельно, не синхронно с клиентом, так как это не особо критично. Количество потраченных патронов на сервере и клиенте может отличаться, но это в подобных играх как правило не имеет значения. То есть при старте стрельбы шлется сообщение вроде: tY:125|tY:456|546|cX100|cY345 где первые 2 блока - координаты цели, далее код персонажа (уникальный, на случай если их много), ну и его координаты. Это конечно псевдокод, но идея должна быть понятно. Сам клиент начинает просчитывать попадания сам, а по окончании стрельбы посылает серверу сообщение об окончании и свои результаты попаданий, а сервер сравнивает с тем, что получилось у него. И если результаты хотя бы примерно сошлись, то принимает клиентские, если нет, ставит свои.

П.с. я делал, конечно же, на сокетах.

[mikhailk]

Не может же быть игра на столько быстрой, что игрок даже не будет успевать кнопки нажимать.

Ну, вот можно посмотреть движок той же "Осады" (я ее не рекламирую, просто как пример). Там монстры прут десятками, если не сотнями, на поле десяток-другой-третий ловушек и защитников, которые отрабатывают и сваливаются либо в куллдаун (воины), либо требуют немедленной перезагрузки при наличии ресурсов (ловушки). Иногда за одну секунду игрок активирует 3-5 ловушек/защитников (у кого какая координация), а каждое применение ловушки может вызвать уничтожение нескольких монстров, иногда больше десятка.

Все это гнать на сервер - я себе слабо представляю, что там с трафиком будет.


Вот идея с байткодом мне на самом деле понравилась. Надо только докрутить ее до стадии реализации.

[GBee]

Можно еще придумать промежуточную валидацию и всякие контрольные суммы. И прогонять их случайно.

[iNils]

Если объем большой, то стоит наверно отправлять полностью лог действий пользователя, а на сервер прогонять всю игру по такому же алгоритму заново и сверять результаты.

[mikhailk]

Если объем большой, то стоит наверно отправлять полностью лог действий пользователя, а на сервер прогонять всю игру по такому же алгоритму заново и сверять результаты.

Не только лог действий пользователя. Еще и вражеских юнитов логировать придется. А не дай бог модель на сервере разойдется с моделью на клиенте?

Можно еще придумать промежуточную валидацию и всякие контрольные суммы. И прогонять их случайно.

Чтобы убедиться, что игра имела место?
Типа, клиент во время баттла шлет какой-нибудь рандомный мусор, по окончанию баттла все это собирает в одну строку, хэширует MD5 (предварительно, возможно, закрывает ключом, который в нем прошит), и подписывает полученным хэшем отправляемый результат баттла? Сервер, конечно, может посчитать подпись и сравнить с пришедшей.

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


ЗЫ. Можно, конечно, еще сервер более активно в эту схему включить.

[caseyryan]

Что-то слишком много заморочек ради такой игры. Банить читеров просто и убирать их из топа. Самих пользователей к жалобам подключить.