Независимо от мнений о подходе, вы ищете порог скорости, который считается «обманом». Учитывая расстояние и приращение времени, вы можете легко увидеть, не продвинулись ли они «слишком далеко» на основе вашего порога читерства.
time = thisTime - lastTime;
speed = distance / time;
If (speed > threshold) dudeIsCheating();
Время, используемое для измерения, - это время приема пакетов сервером. Хотя это кажется тривиальным, он рассчитывает расстояние для каждого движения персонажа, что может оказаться очень дорогостоящим. Лучший способ - сервер вычислить позицию на основе скорости, а это позиция персонажа. Клиент никогда не сообщает положение или абсолютную скорость, вместо этого клиент отправляет «процент от максимальной» скорости.
Уточняю: это было просто для проверки на чит. Ваш код может задерживаться или долго обрабатываться на сервере, что повлияет на ваш результат. Формула должна быть такой:
maxPlayerSpeed = 300; // = 300 pixels every 1 second
if (maxPlayerSpeed <
(distanceTraveled(oldPos, newPos) / (receiveNewest() - receiveLast()))
{
disconnect(player); //this is illegal!
}
Это сравнивает скорость перемещения игроков с максимальной скоростью перемещения. Временные метки определяются тем, когда вы получаете пакет, а не когда вы обрабатываете данные. Вы можете использовать любой метод, который вам нужен для определения обновлений для отправки клиентам, но для порогового метода, который вы хотите определить для определения мошенничества, задержка не повлияет на вышеуказанное.
Получить пакет 1 в секунду 1: символ в позиции 1
Получить пакет 2 в секунду 100: символ в позиции 3000
пройденное расстояние = 2999
время = 99
рейтинг = 30
Обмана не было.
Получить пакет 3 на секунде 101: символ в позиции 3301
Пройденное расстояние = 301
время = 1
рейтинг = 301
Обнаружен обман.
То, что вы называете «всплеском задержки», на самом деле является большой задержкой при доставке пакетов. Но это не имеет значения, поскольку вы не проходите мимо обработки данных, вы проходите мимо момента получения каждого пакета. Если вы сохраните расчеты времени независимо от обработки игрового тика (как и должно быть, как и все, что произошло во время этого «тика»), высокая и низкая задержка влияют только на то, насколько сервер уверен в позиции персонажа, что вы используете интерполяцию + экстраполяцию для решения .
Если клиент недостаточно синхронизирован с тем местом, где он не получил никаких поправок к своему положению, и сильно не синхронизирован с сервером, происходит значительная потеря пакетов и высокая задержка, которую ваша проверка на мошенничество не сможет учесть. Вы должны учитывать это на более низком уровне с обработкой фактических сетевых коммуникаций.
Для любых игровых данных идеальный метод состоит в том, чтобы все системы, кроме сервера, отставали на 100-200 мс. Допустим, у вас есть запланированное обновление каждые 50 мсек. Клиент получает первое и второе. У клиента нет данных для отображения, пока он не получит второе обновление. В течение следующих 50 мс он показывает последовательность изменений, которые уже произошли (т. Е. Воспроизведение с очень небольшой задержкой). Клиент отправляет серверу состояние своих кнопок. Локальный клиент также прогнозирует движение, эффекты и т. Д. На основе этих нажатий кнопок, но отправляет серверу только «состояние кнопки» (поскольку существует конечное количество кнопок, существует конечное количество битов, необходимых для представления каждого состояния, что позволяет использовать более компактный формат пакета).
Сервер - это авторитетная симуляция, определяющая фактические результаты. Сервер отправляет клиентам обновления каждые 50 мсек. Вместо интерполяции между двумя известными кадрами сервер экстраполирует позиции и т. Д. Для любых недостающих данных. Сервер знает, какая была последняя реальная позиция. Когда он получает обновление, следующий пакет, отправленный каждому из клиентов, включает обновленную информацию. Затем клиент должен получить эту информацию до достижения этого момента времени, и игроки реагируют на нее по мере ее появления, не видя никаких странных прыжков, потому что он никогда не отображал неправильную позицию.
Можно сделать так, чтобы клиент был авторитетным для некоторых вещей или чтобы клиент выступал в качестве авторитетного сервера. Ключевым моментом является определение степени доверия к клиенту.
Клиент должен регулярно отправлять обновления, скажем, каждые 50 мс. Это означает, что при «пике задержки» (задержка приема пакетов) в 500 мс либо все пакеты, отправленные в течение периода задержки, будут задержаны на аналогичную величину, либо пакеты будут получены не по порядку. Базовая сеть должна аккуратно обрабатывать эти задержки (отбрасывая пакеты, которые имеют слишком большую задержку, принудительно выполняя доставку пакетов и т. Д.). Конечным результатом является то, что при правильной обработке пакетов ожидаемые проблемы возникнуть не должны. Кроме того, отказ от получения явных местоположений символов от клиента и вместо этого явное исправление сервером клиента и получение только состояний управления от клиента предотвратит эту проблему.
person
Matt
schedule
06.11.2009
