сетевые игры

КРИС КАСПЕРСКИ АКА МЫЩЪХ

Спецвыпуск: Хакер, номер #064, стр. 064-062-2

С игроками дела обстоят значительно сложнее. Допустим, два горячих мудреца стоят супротив друг друга и каждый пускает по торпеде. Если информация о перемещении одного из игроков хоть чуть-чуть запоздает, очень может случиться так, что с точки зрения ведомого компьютера торпеда пройдет мимо, а ведущий увидит, как противника разорвало в клочья. Первое, что приходит на ум, — осуществлять перемещение только после подтверждения. Игрок нажимает на стрелку, компьютер А (неважно, ведущий или ведомый) отправляет уведомление компьютеру B (первая стадия), компьютер B обновляет свое игровое пространство и посылает подтверждение компьютеру А (вторая стадия), компьютер А принимает его и перемещает игрока (третья стадия). Только в жизни... Игрок давит на клавишу, а фигурка на экране остается неподвижной (задержка передачи данных по сети). Что делает игрок? Давит на клавишу еще и еще! Если же случится задержка на третьей стадии, в игровых мирах вновь произойдет рассинхронизация и дело закончится лесом. Следовательно, возникает необходимость четвертой стадии, которая обеспечила бы дополнительный уровень подтверждений, но… Как же тогда все будет тормозить!

«Быстрая» и «медленная» синхронизация

Можно использовать полуэвристический алгоритм. Когда игроки находятся в разных концах игрового поля, они перемещаются без подтверждений, но как только их игровые миры соприкоснутся (один игрок увидит другого или в поле их зрения попадет общий монстр), автоматически активируется режим «обмена подтверждениями».

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

Борьба с жульничеством

Еще одна серьезная проблема — читерство. Ведущий компьютер может мухлевать как угодно — код и данные игрового процесса находятся в полном ведении игрока. Что ему стоит, слегка повозившись с отладчиком, приобрести божественное здоровье или нескончаемые патроны? Некоторые программисты просто отмахиваются от этой проблемы, делая вид, что ее не существует: «Ты либо доверяешь ведущему компьютеру, либо нет».

На самом деле решение лежит на поверхности! Пусть ведомый и ведущий компьютеры периодически меняются ролями — на программном уровне реализуется достаточно просто и надежно защищает от взлома. Конечно, хакер может исправить свой экземпляр программы так, чтобы пули не кончались, но подобный трюк сработает только тогда, когда его компьютер станет ведущим. Даже такой «половинчатый хак» дает огромное преимущество в игре, однако оба игрока находятся в равных условиях и «хакерствовать» может каждый. Уже нет компьютера, владелец которого приравнивается к Богу...