Алгоритм 11.1. Контроль столкновений с помощью описанных прямоугольников.

For (для каждой вершины прямоугольника R1) do

if (проверить координаты X и У для вершин прямоугольника R2)

{

есть столкновение

выход

} } // конец

Существуют более эффективные методы контроля столкновений прямоугольников, но основная идея, я думаю, понятна. Использовать этот метод не так уж и плохо. Однако может возникнуть такая ситуация, когда мы решим, что произошло столкновение объектов, а на самом деле пересеклись только описанные прямоугольники, а не истинные изображения. Рисунок 11.6 поясняет такую ситуацию.

Чтобы, это исправить, мы можем либо уменьшить на несколько процентов размер ограничивающего объект прямоугольника, либо определять столкновения в два шага:.

• Вначале для выявления возможного столкновения использовать описанные прямоугольники по Алгоритму 11.1;

• Затем делать более тонкую проверку вероятных столкновений, отобранных после первого теста, уже с учетом истинной геометрической формы объекта.

Я вам советую просто использовать ограничивающий прямоугольник, размер которого на десять процентов меньше исходного, и игрок будет доволен.

Мы уже обсуждали основные аспекты столкновений объектов между собой в четвертой главе, «Механизмы двухмерной графики». Теперь же обсудим столкновения со стенами и другими объектами, образующими само игровое пространство -обычно такие столкновения рассматривают как отдельную задачу.

Определение столкновений в «клеточном» пространстве тривиально. Все, что надо сделать, это определить, в какую клетку перемещается игрок и осмотреть, не занята ли она уже каким-либо объектом. Например, в рассмотренном выше примере пространство имело размер 10х10 клеток, а каждая клетка -16х16 пикселей. Общий размер изображения на экране составлял 160 пикселей. Если координаты игрока принимают значение (50, 92), то он находится внутри какой-то клетки. Если же внутри этой клетки уже что-то есть, о наш игрок не должен в нее попадать!

Для расчета местоположения игрока мы делим значения координат на 16 Для координат (50, 92) мы получим третью сверху, пятую слева клетку решетки Теперь мы можем посмотреть, что находится в этой клетке. Если там уже что-то есть, нужно отправить играющего назад, устроить ему неприятность либо наоборот, доставить удовольствие в зависимости от того, с каким объектом он столкнулся.

Вы можете использовать эту технику и в трехмерном пространстве. В играх типа Wolfenstein игрок всегда находится на одной и той же высоте, поэтому нам нужно отслеживать только координаты Х и Y. В играх типа DOOM задача усложняется, так как игрок может перемещаться и по координате Z (подниматься или опускаться по ступенькам или на лифтах).

Игровые объекты

Предположим, у вас есть замечательная идея компьютерной игры и вы готовы написать 50000 или более строк программы на Си! Первая проблема, с которой вы столкнетесь при создании своей игры, будет связана с представлением объектов. Должны ли вы использовать массивы, структуры, связанные списки или что-то еще? Мой совет будет такой: «Начинайте с простого, мудрость приходит с опытом».

Мы будем использовать время от времени и массивы, и структуры, и связанные списки. Двоичные деревья поиска и другие экзотические структуры не стоит использовать, по крайней мере, до тех пор, пока вы не напишете хорошо работающие алгоритмы или, может быть, даже системы искусственного интеллекта. Используйте то, что у вас хорошо получается. Если вы можете сделать что-то более элегантное (например, вместо массивов использовать связанные списки) - делайте это, а если нет, то и не надо.

Старайтесь, чтобы выбранные вами структуры данных повышали эффективность работы программы. Например, пусть совершенно точно известно, что в вашей игре будет не более десяти объектов. Вы, конечно, можете создать связанный список и пополнять его по мере создания объектов. Это сэкономит память, но сделает программу более сложной. Столько хлопот ради десятка объектов - так ли уж это нужно? Простой массив в такой ситуации куда как уместнее!

Компьютерные игры настолько сложны, что если вы будете еще и сами усложнять простые вещи, то никогда не закончите работу. Выполните ее в черновом варианте, а затем, если хотите, возвращайтесь и совершенствуйте. У меня есть друг, который в 70-х или 80-х годах создал одну очень знаменитую компьютерную игру. Он всегда говорил мне: «Напиши игру, потом перепиши ее, а затем напиши еще лучше». Таким образом, начинайте с чернового варианта, а затем уже шлифуйте его.

Структуры данных в компьютерных играх

Теперь я хотел бы обсудить, какие структуры данных для представления объектов используются в компьютерных играх. Объектами игры может быть оружие, фантастические создания, различные предметы, которые нужно искать ц т. д. Создавая объект для игры, вы должны продумать, какими свойствами он должен обладать и отразить это в структуре данных.

Для примера рассмотрим, что требуется иметь для статического объекта. Под статическими я понимаю объекты, которые игрок может подобрать по ходу игры (в то время как динамическими я буду называть те объекты, которые могут перемещаться самостоятельно). Статический объект не совершает никаких действий, он просто лежит в определенном месте игрового пространства. Когда ваш герой находит такой объект, он поправляет свое здоровье, подкрепляет упавшие силы, пополняет арсенал и т. д. Листинг 11.1 содержит возможную структуру данных такого объекта.