Несколько лет назад появился прототип игры 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 продолжается, но главное, что мы вынесли из этой истории — не стоит всегда опираться на готовые ответы из учебников. На каждом из этапов — от прототипирования до удержания существующей базы игроков — мы исходили из текущих задач и потребностей.
Если бы всё сразу делали «как надо» несколько лет назад, некоторых ошибок можно было бы избежать, но сама игра могла бы просто не выстрелить, а ресурсы были бы потрачены.
Автор: skzloy
