Урок 19. Монстры бросаются в погоню

Монстры бросаются в погоню. Битвы в нашей игре приобрели подобие реальных схваток, им не хватает малости. Хотя монстры и научились давать сдачу, они пока не умеют преследовать персонажа.

Поэтому герой в случае неудачно развивающейся схватки может без проблем покинуть поле боя, восстановить силы в источнике, после чего вновь напасть на ослабевшего и недвижимого монстра. Чтобы подобных несправедливостей не возникало, добавим в программу новую процедуру MonstersStep. Она представляет собой реализацию очереди хода монстров - враги перемещаются в направлении персонажа и, если есть такая возможность, нападают на него. Остается только уточнить, в каком месте программы должна вызываться такая процедура.

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

Например, исходные пять пунктов можно потратить на две атаки или одно обращение к инвентарю и смену оружия и одну атаку. Конкретный способ учета действий зависит прежде всего от выбранной игровой системы. Так, достаточно строга в этом плане уже упоминавшаяся GURPS. Данные ограничения относится в основном к играм, проходящим в пошаговом режиме. Однако они применимы и к сражениям, протекающим в масштабе реального времени.

Дело в том, что классические РПГ допускают в любой момент быстро развивающегося сражения возможность вызвать режим паузы, во время которого человеку удается выполнить множество вспомогательных действий. Режим реального времени при этом, очевидно, теряет смысл.

В любом случае некоторый объем действий героя рано или поздно приводит к активизации противника. Если персонаж длительное время ничего не делает, то монстры постепенно подберутся к нему и нападут. То же произойдет, если персонаж ведет бой, оставаясь на одном месте. Он может быть обнаружен врагом, если, конечно, находится в зоне его видимости. Мы как авторы игры должны решить, будут ли монстры реагировать на любую активность героя - в таком случае вызов процедуры MonstersStep можно поместить в начало цикла опроса клавиатуры главной программы, туда, где вызывается процедура ShowGame, отображающая ситуацию в локации. В результате любое действие персонажа, будь то обращение к инвентарю или обмундированию или подъем предметов с земли, будет расценено как полноценное игровое действие, на которое расходуется достаточно большой период времени, и после которого настает очередь хода монстров. Это справедливо. Мы выберем другой подход - не потому, что он лучше или хуже, а просто потому, чтобы продемонстрировать все возможные в таких ситуациях приемы.

Обращение к процедуре MonstersStep будет происходить в процедуре MoveHero, то есть в момент, который по определению должен вызвать ответную реакцию противника. Ситуацию, когда персонаж наносит монстрам удар, мы вроде бы отработали, так как ответное нападение вызывается из процедуры MonstersAttack. Однако эта отработка не завершена, потому что монстры только наносят ответный удар, но не передвигаются. Поэтому заменим вызов MonstersAttack на MonstersStep, и такой же вызов поместим в самый конец процедуры, когда герой уже выполнил перемещение:

procedure  MoveHero(   dx,dy:    Integer   );

var m,   dam:   Integer;

begin

if not  FreeTile(   GameMap[CurMap].Cells[

Heroes[CurHero].x+dx,Heroes[CurHero].y+dy].Tile   )   then

Exit;

m   :=   IsMonsterOnTile(Heroes[CurHero].x+dx, Heroes[CurHero].y+dy) ;

if m  >   0   then

begin

…Attack(Heroes[CurHero],   m) ;

…stop;

…

…

…(Heroes[CurHero].x,dx);

…(Heroes[CurHero].y,dy);

…Table(CurHero);

Heroes[CurHero].x - GameMap[CurMap].LocalMapLeft)   <

…SCROLL_DELTA) or

(Heroes[CurHero].x  -  GameMap[CurMap].LocalMapLeft)   >

… WIDTH - SCROLL_DELTA)   or

Heroes[CurHero].у -   GameMap[CurMap].LocalMapTop)   <

… Height - SCROLL_DELTA) or

(Heroes[CurHero].у  -   GameMap[CurMap].LocalMapTop)   >

… Height - SCROLL_DELTA) then

…MAP;

Map[CurMap].Cells [

Heroes[CurHero].x, Heroes[CurHero].y].Tile  in     TrapTileSet   then

Begin

Map[CurMap].Cells[Heroes[CurHero].x, Heroes[CurHero].y].Tile:=tileGround;

..SkillTest(Heroes[CurHero], SkillTrapSearch) then

begin

…:=random ( round(Heroes[CurHero],MaxHP*1.1) )+1;

…(STR_TRAP + IntToStr(abs(dam))); r in Hero], -dam );

…(Heroes[CurHero] .y,-dam);.

If Map[CurMap].Cells[…, Heroes[CurHero].yTile in LiveTileSet   then

…(STR_LIVE);

Heroes[CurHero],   Heroes[CurHero].MaxHP   );

…

End;

End;

Сделаем при приближении реализацию новой процедуры, поместив ее в модуль

Procedure MonstersStop;

Var ..:integer;

Begin

For i:=1 to MaxMonsters do

If (Monsters[i].HP=0) and (…(I, CurHero) ) then

…p(I,CurHero);

End;

Проверка если монстр здоров, и если он способен преследовать героя запускается процедура, отвественная за его перемещение. Проверка возможности преследования героя происходит в. функции Can Trace, которую мы реализуем в текущем модуле.

function CanTrace(mi,   hi:   Integer):   Boolean;

var d:   Integer;

begin

d   :=   Distance(   Monsters[mi].x,Monsters[mi].y,

Heroes[hi].x,Heroes[hi].у   );

CanTrace   :=   (d <= Monsters[mi].ViewZone)   and   (d >  l);

end;

Все, что здесь выполняется - это проверка расстояния от монстра до героя. Выясняется, не превосходит ли это расстояние параметра монстра ViewZone, своеобразной дальности его видимосги. Кроме того, нам надо убедиться, что монстр находится вдали от героя - на расстоянии более одного таила. В противном случае, если монстр рядом с персонажем, преследование выполнять не нужно.

Перемещение монстра, процесс погони за героем, будет более сложным но замыслу. Этот процесс называется поиском кратчайшего пути. Различные соответствующие алгоритмы многократно описаны специалистами по искусственному интеллекту. В нашем случае хитроумные методы не потребуются, однако выбранное представление локации и размещенных на ней препятствий вызывает определенные дополнительные трудности. Если мы попробуем механически сокращать расстояние до персонажа по кратчайшему пути, уменьшая наиболее длинную (или наиболее короткую - не имеет значения) координату, то монстры окажутся слишком тупы и предсказуемы. Взглянем, например, на следующую ситуацию.

o…..

.ooo.г

м.о…

……

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