Zachowanie agenta ukierunkowanego na cel

Do tej pory sprawdzili�my agent�w wykorzystuj�cych architektur� opart� na sko�czonej maszynie stan�w, w kt�rej zachowanie jest rozk�adane na kilka stan�w, z kt�rych ka�dy zawiera logik� umo�liwiaj�c� przej�cie do innych stan�w. Ten rozdzia� wprowadza nieco inne podej�cie. Zamiast stan�w zachowanie agenta jest definiowane jako zbi�r hierarchicznych cel�w. Cele maj� charakter atomowy lub z�o�ony. Cele atomowe definiuj� pojedyncze zadanie, zachowanie lub akcj�, takie jak d��enie do ustawienia lub prze�adowania broni, podczas gdy cele z�o�one sk�adaj� si� z kilku podzada�, kt�re z kolei mog� by� atomowe lub z�o�one, definiuj�c w ten spos�b zagnie�d�on� hierarchi�. Kompozyty zwykle opisuj� bardziej z�o�one zadania ni� ich bracia atomowi, takie jak budowanie fabryki broni lub wycofywanie si� i szukanie schronienia. Oba typy cel�w s� w stanie monitorowa� sw�j status i maj� zdolno�� do przeplanowania, je�li si� nie powiedzie. Ta hierarchiczna architektura zapewnia programi�cie AI intuicyjny mechanizm definiowania zachowania agent�w, poniewa� dzieli wiele podobie�stw z ludzkim procesem my�lowym. Ludzie wybieraj� abstrakcyjne cele wysokiego poziomu w oparciu o ich potrzeby i pragnienia, a nast�pnie rekurencyjnie rozk�adaj� je na plan dzia�ania, kt�ry mo�na zastosowa�. Na przyk�ad w deszczowy dzie� mo�esz zdecydowa� si� odwiedzi� kino. Jest to abstrakcyjny cel, kt�rego nie mo�na zrealizowa�, dop�ki nie zostanie on podzielony na mniejsze cele cz�stkowe, takie jak opuszczenie domu, podr� do kina i wej�cie do kina. Z kolei ka�dy z nich jest abstrakcyjny i nale�y go dalej podzieli�. Proces ten jest zwykle przejrzysty, ale czasami zdajemy sobie z tego spraw�, gdy rozk�ad wymaga wyboru. Na przyk�ad subgalowa podr� do kina mo�e by� zaspokojona na wiele sposob�w - mo�esz tam podr�owa� samochodem, komunikacj� miejsk�, rowerem lub pieszo - i mo�esz sp�dzi� kilka chwil zastanawiaj�c si� nad wyborem. (Jest to szczeg�lnie prawdziwe, je�li wsp�pracujesz z kilkoma innymi lud�mi, aby osi�gn�� cel - przypomnij sobie ostatni� wizyt� w wypo�yczalni wideo / DVD ze znajomymi. Argh!) Ten proces trwa, dop�ki cele nie zostan� roz�o�one na podstawowe czynno�ci motoryczne, kt�re twoje cia�o jest w stanie wykona�. Na przyk�ad cel opuszczenia domu mo�na podzieli� na nast�puj�ce cele: i�� do szafy, otworzy� drzwi szafy, zdj�� p�aszcz z wieszaka na p�aszcz, za�o�y� p�aszcz, i�� do kuchni, za�o�y� buty, otworzy� drzwi, wyj�� na zewn�trz i wkr�tce. Co wi�cej, ludzie nie lubi� marnowa� energii, wi�c generalnie nie marnujemy cennych kalorii na my�lenie o celu, dop�ki nie b�dzie to absolutnie konieczne. Na przyk�ad nie zdecydowa�by�, jak otworzy� puszk� fasoli, dop�ki nie b�dziesz mie� jej w d�oni, lub jak zawi�za� sznurowad�a, dop�ki buty nie stan� na nogach. Celowy agent na�laduje to zachowanie. Ka�da aktualizacja my�li agent sprawdza stan gry i wybiera zestaw predefiniowanych cel�w lub strategii wysokiego poziomu - ten, kt�ry wed�ug niego najprawdopodobniej pozwoli mu zaspokoi� najsilniejsze pragnienie (zazwyczaj wygran�). Nast�pnie agent b�dzie pr�bowa� pod��a� za tym celem, rozk�adaj�c go na dowolne podzadania, spe�niaj�c kolejno ka�dy z nich. B�dzie to robi�, dop�ki cel nie zostanie spe�niony lub nie uda mu si�, lub dop�ki stan gry nie b�dzie wymaga� zmiany strategii.

Powr�t Erica Chrobrego

Przyjrzyjmy si� przyk�adowi, u�ywaj�c naszego ulubionego agenta gier, Erica, kt�ry niedawno znalaz� zatrudnienie w RPG "Dragon Slayer 2." Programista AI Erica opracowa� dla niego kilka strategii, w tym Obro� przed smokiem, Smokiem ataku, Kup miecz, Zdob�d� jedzenie i Upij si�. Strategie te reprezentuj� abstrakcyjne cele wysokiego poziomu, kt�re sk�adaj� si� z mniejszych cel�w cz�stkowych, takich jak Utw�rz �cie�k�, �led� �cie�k�, Traverse Path Edge, Stab Dragon, Slice Dragon, Run Away i Hide. Dlatego, aby uko�czy� strategi�, Eric musi j� roz�o�y� na odpowiednie podzadania i kolejno zaspokaja� ka�dy z nich (w razie potrzeby dalej je rozk�adaj�c). Eric w�a�nie wszed� do �wiata gry, a poniewa� nie nosi broni i dlatego czuje si� wra�liwy, jego najwi�kszym pragnieniem jest znalezienie jakiego� spiczastego kija, zanim smok go zauwa�y. Jego "m�zg" (specjalny rodzaj celu zdolny do podejmowania decyzji) bierze pod uwag� wszystkie dost�pne strategie i stwierdza, �e Kup Miecz znakomicie pasuje do rachunku, wi�c jest to wyznaczone jako cel, do kt�rego nale�y d��y�, dop�ki nie zdecyduje inaczej

Eric nie mo�e jednak dzia�a� zgodnie z tym celem, poniewa� na tym poziomie jest on zbyt abstrakcyjny i musi zosta� roz�o�ony - lub rozszerzony, je�li wolisz my�le� o tym w ten spos�b - na sk�adowe podzadania. Na potrzeby tego przyk�adu za�o�ymy, �e Kup miecz sk�ada si� z podzada� pokazanych na rysunku

Aby zdoby� miecz, Eric musi najpierw znale�� troch� z�ota, a nast�pnie uda� si� do ku�ni, gdzie kowal ch�tnie przyjmie je jako zap�at�. Agenci realizuj� cele kolejno, wi�c Go To Smithy nie b�dzie oceniane, dop�ki nie b�dzueGetGold. Jest to jednak kolejny z�o�ony cel, wi�c aby go zrealizowa�, Eric musi dalej poszerza� hierarchi�. Zdob�d� z�oto sk�ada si� z podzada� Plan Path (Goldmine), Follow Path i Pick Up Nugget.

Cel Plan Path (Goldmine) jest spe�niony, wysy�aj�c zapytanie do Planowanie �cie�ki, aby zaplanowa� �cie�k� do kopalni z�ota. Nast�pnie jest usuwany z listy cel�w. Nast�pn� rzecz�, kt�r� Eric rozwa�a, jest Pod��anie �cie�k�, kt�r� mo�na dalej roz�o�y� na kilka atomowych cel�w Traverse Edge, z kt�rych ka�da zawiera logik� wymagan� do pod��ania za kraw�dzi� �cie�ki prowadz�cej do kopalni z�ota.

Ten proces rozk�adania i spe�niania cel�w trwa, dop�ki ca�a hierarchia nie zostanie przemierzona, a Eric pozostanie z l�ni�cym nowym mieczem w r�kach. C�, to jest to; zobaczmy teraz, jak to zrobi�.

Realizacja

Hierarchie obiekt�w zagnie�d�onych, takie jak te wymagane do wdro�enia hierarchicznych agent�w opartych na celach, s� cz�sto spotykane w oprogramowaniu. Na przyk�ad edytory tekstu, takie jak te, kt�rych u�ywam do pisania dokument�w z ksi�garni jako kolekcje element�w atomowych i kompozytowych. Najmniejsze elementy, znaki alfanumeryczne, s� pogrupowane w coraz bardziej z�o�one kolekcje. Na przyk�ad s�owo "filozofia" jest z�o�onym sk�adnikiem z�o�onym z kilku sk�adnik�w atomowych, a zdanie "My�l�, �e dlatego jestem" jest z�o�onym sk�adnikiem z�o�onym z trzech obiekt�w z�o�onych i dw�ch obiekt�w atomowych. Z kolei zdania mo�na grupowa� w obiekty akapitowe, kt�re mo�na grupowa� w strony i tak dalej. Jestem pewien, �e masz pomys�. Nale�y zauwa�y�, �e aplikacja jest w stanie r�wnomiernie obs�ugiwa� obiekty z�o�one i atomowe, niezale�nie od ich wielko�ci i z�o�ono�ci - tak samo �atwo jest wyci�� i wklei� s�owo, jak kilka stron tekstu. Jest to dok�adnie w�a�ciwo�� wymagana przez cele hierarchiczne. Ale jak to kodujemy? Z�o�ony wz�r projektowy stanowi rozwi�zanie. Dzia�a poprzez zdefiniowanie abstrakcyjnej klasy bazowej, kt�ra reprezentuje zar�wno obiekty z�o�one, jak i atomowe. Umo�liwia to klientom identyczne manipulowanie wszystkimi celami, bez wzgl�du na to, jak proste lub z�o�one mog� by�.

Na rysunku wyra�nie pokazano, w jaki spos�b obiekty kompozytowe agreguj� instancje komponent�w, kt�re z kolei mog� by� kompozytowe lub atomowe. Zwr�� uwag�, w jaki spos�b obiekty z�o�one przekazuj� ��dania klient�w do swoich dzieci. W tym archetypowym przyk�adzie ��dania s� przekazywane wszystkim dzieciom. Jednak inne projekty mog� wymaga� nieco innej implementacji, jak ma to miejsce w przypadku cel�w. Rysunek pokazuje z�o�ony wz�r zastosowany do projektowania cel�w hierarchicznych. Subgoale s� dodawane przez popchni�cie ich na prz�d pojemnika subgoal i s� przetwarzane w kolejno�ci LIFO (ostatnie wej�cie, pierwsze wyj�cie) w w taki sam spos�b jak struktura danych podobna do stosu. Zwr�� uwag�, w jaki spos�b ��dania klient�w s� przekazywane tylko do subgoalu z przodu, zapewniaj�c, �e subgoale s� oceniane w kolejno�ci

Obiekty bramkowe maj� wiele podobie�stw z klas� State. Maj� metod� obs�ugi wiadomo�ci, podobnie jak metody Stan, Aktywuj, Przetwarzaj i Zako�cz, kt�re maj� podobie�stwa z metodami wprowadzania, wykonywania i wychodzenia stanu. Metoda Activate zawiera logik� inicjalizacji i reprezentuje faz� planowania celu. Jednak w przeciwie�stwie do metody State :: Enter, kt�ra jest wywo�ywana tylko raz, gdy stan staje si� aktualny, cel mo�e wywo�ywa� metod� Activate dowoln� liczb� razy, aby wykona� operacj� ponownie, je�li sytuacja tego wymaga. Proces, kt�ry jest wykonywany na ka�dym etapie aktualizacji, zwraca wyliczon� warto�� wskazuj�c� status celu. Mo�e to by� jedna z czterech warto�ci:

• nieaktywne: Cel czeka na aktywacj�.
• aktywne: cel zosta� aktywowany i b�dzie przetwarzany na ka�dym etapie aktualizacji.
• zako�czone: cel zosta� osi�gni�ty i zostanie usuni�ty przy nast�pnej aktualizacji.
• nie powiod�o si�: cel nie powi�d� si� i zostanie ponownie wy�wietlony lub usuni�ty przy nast�pnej aktualizacji.

Metoda Terminate wykonuje wszelkie niezb�dne porz�dki przed wyj�ciem z bramki i jest wywo�ywana tu� przed zniszczeniem bramki. W praktyce cz�� logiki zaimplementowanej przez cele kompozytowe jest wsp�lna dla wszystkich kompozyt�w i mo�na j� wyodr�bni� do klasy Goal_Composite, z kt�rej wszystkie konkretne cele kompozytowe mog� odziedziczy�, w wyniku czego ostateczny projekt przedstawiono na rysunku 9.7. Diagramy UML dobrze opisuj� hierarchi� klas cel�w. Nie b�d� marnowa� papieru na list� ich deklaracji, ale my�l�, �e b�dzie pomocne, je�li wymieni� �r�d�o kilku metod Goal_Composite.

Goal_Composite :: ProcessSubgoals

Wszystkie z�o�one cele nazywaj� t� metod� ka�dym krokiem aktualizacji, aby przetworzy� swoje podzadania. Metoda zapewnia, �e wszystkie zrealizowane i nieudane cele zostan� usuni�te z listy przed przetworzeniem nast�pnego podpolecenia w linii i zwr�ceniem jego statusu. Je�li lista podrz�dnych cel�w jest pusta, zako�czona jest zwracana.

template < class entity_type >
int Goal_Composite::ProcessSubgoals() {
// usu� wszystkie uko�czone i nieudane bramki z przodu listy podrz�dnej
while (!m_SubGoals.empty() &&
(m_SubGoals.front()->isComplete() || m_SubGoals.front()->hasFailed()))
{
m_SubGoals.front()->Terminate();
delete m_SubGoals.front();
m_SubGoals.pop_front();
}
// je�li pozostan� jakie� podzadania, przetworz to z przodu listy
if (!m_SubGoals.empty()) {
// chwy� status czo�owego podrz�du
int StatusOfSubGoals = m_SubGoals.front()->Process();
// musimy przetestowa� w specjalnym przypadku, w kt�rym subgoal z przodu jest
// zg�asza "uko�czono", a lista podrz�dnych cel�w zawiera dodatkowe cele.
// W takim przypadku, aby upewni� si�, �e rodzic nadal przetwarza swoje
// lista podrz�dna, zwracany jest status "aktywny"
if (StatusOfSubGoals == completed && m_SubGoals.size() > 1)
{
return active;
}
return StatusOfSubGoals;
}
// nie ma ju� podda� do przetworzenia - zwr�� "zako�czone"
else
{
return completed;
}
}

Goal_Composite::RemoveAllSubgoals

Ta metoda usuwa list� podrz�dn�. Zapewnia, �e wszystkie podzadania s� niszczone, wywo�uj�c metod� Terminate ka�dego z nich przed usuni�ciem.

template
void Goal_Composite::RemoveAllSubgoals()
{
for (SubgoalList::iterator it = m_SubGoals.begin();
it != m_SubGoals.end();
++it)
{
(*it)->Terminate();
delete *it;
}
m_SubGoals.clear();
}

UWAGA. Niekt�rzy z was mog� si� zastanawia�, w jaki spos�b cele atomowe implementuj� metod� AddSubgoal. W ko�cu ta metoda jest bez znaczenia w tym kontek�cie (poniewa� cel atomowy nie mo�e z definicji agregowa� cel�w potomnych), ale wci�� musi zosta� zaimplementowany w celu zapewnienia wymaganego wsp�lnego interfejsu. Poniewa� klienci powinni wiedzie�, czy cel jest z�o�ony, czy nie, i dlatego nie powinni nigdy wywo�ywa� AddSubgoal w celu atomowym, wybra�em metod� zg�aszania wyj�tku

Przyk�ady cel�w u�ywanych przez Raven Bots

Boty Raven wykorzystuj� cele wymienione w Tabeli do zdefiniowania swojego zachowania.

Goal_Think jest najwy�szym celem wszystkich. Ka�dy bot tworzy kopi� tego celu, kt�ra trwa do momentu zniszczenia bota. Jego zadaniem jest wybieranie innych cel�w wysokiego poziomu (strategicznych) zgodnie z ich przydatno�ci� do aktualnego stanu gry. Nied�ugo przyjrzymy si� bli�ej Goal_Think, ale najpierw my�l�, �e dobrym pomys�em b�dzie zbadanie kodu kilku innych cel�w, aby� m�g� pozna� ich dzia�anie.

Goal_Wander

To naj�atwiejszy do zrozumienia cel i najprostszy w palecie bota Raven. Jest to cel atomowy, kt�ry aktywuje zachowanie kierowania w�dr�wk�. Oto jego deklaracja.

class Goal_Wander : public Goal< Raven_Bot >
{
public:
Goal_Wander(Raven_Bot* pBot):Goal(pBot, goal_wander){}
// musi zosta� wdro�ony
void Activate();
int Process();
void Terminate();
};

Jak wida�, deklaracja jest bardzo prosta. Klasa dziedziczy po celu i ma metody, kt�re implementuj� interfejs celu. Rzu�my okiem na ka�d� z kolei po kolei.

void Goal_Wander::Activate()
{
m_Status = active;
m_pOwner->GetSteering()->WanderOn();
}

Metoda Active po prostu w��cza zachowanie kierowania w�dr�wk� (patrz rozdzia� 3, je�li potrzebujesz od�wie�enia) i ustawia status celu na aktywny.

int Goal_Wander::Process()
{
// je�li status jest nieaktywny, wywo�aj Activate () i ustaw status na active
ActivateIfInactive();
return m_Status;
}
Goal_Wander :: Process jest r�wnie prosty. ActivateIfInactive is wywo�ywane na pocz�tku logiki proces�w ka�dego celu. Je�li status celu jest nieaktywny (jak zawsze b�dzie to pierwsze wywo�anie Procesu, poniewa� m_Status jest ustawiony jako nieaktywny w konstruktorze), wywo�ywana jest metoda Akctive, tym samym inicjuj�c cel. Wreszcie metoda Terminate wy��cza zachowanie w�dr�wki.

void Goal_Wander::Terminate()
{
m_pOwner->GetSteering()->WanderOff();
}

Teraz przeanalizujmy bardziej z�o�ony cel atomowy

Goal_TraverseEdge

To kieruje bota wzd�u� kraw�dzi �cie�ki i stale monitoruje jego post�py, aby upewni� si�, �e nie utknie. Aby to u�atwi�, wraz z lokaln� kopi� kraw�dzi �cie�ki, posiada ona cz�onk�w danych do rejestrowania czasu aktywacji celu i czasu, jaki bot ma zaj�� pokonanie kraw�dzi. Jest tak�e w�a�cicielem logicznego elementu danych, kt�ry rejestruje, czy kraw�d� jest ostatni� na �cie�ce. Ta warto�� jest potrzebna do okre�lenia, jakie zachowanie kierownicze nale�y zastosowa�, aby przej�� przez kraw�d� (szukaj normalnych kraw�dzi �cie�ki, dotrzyj do ostatniej). Oto jego deklaracja:

class Goal_TraverseEdge : public Goal< Raven_Bot >
{
private:
// kraw�d�, kt�r� pod��y bot
PathEdge m_Edge;
// true, je�li m_Edge jest ostatnim na �cie�ce
bool m_bLastEdgeInPath;
// szacowany czas, przez kt�ry bot powinien przej�� przez kraw�d�
double m_dTimeExpected;
// rejestruje czas aktywacji tego celu
double m_dStartTime;
// wraca true, je�li bot utknie
bool isStuck()const;
public:
Goal_TraverseEdge(Raven_Bot* pBot,
PathEdge edge,
bool LastEdge);
// Podejrzani
void Activate();
int Process();
void Terminate();
};

Przed okre�leniem szacunkowego czasu potrzebnego do przej�cia, metoda Aktywuj wysy�a zapytanie do pola flagi kraw�dzi wykresu, aby ustali�, czy jest z nim powi�zany jaki� specjalny rodzaj terenu - b�oto, �nieg, woda itp. - a zachowanie bota odpowiednio si� zmienia . (Ta funkcja nie jest u�ywana przez Raven, ale chcia�em pokaza�, jak sobie z ni� poradzi�, je�li Twoja gra korzysta z okre�lonych typ�w terenu). Metoda ko�czy si� kodem aktywuj�cym odpowiednie zachowanie kierowania. Oto �r�d�o:
void Goal_TraverseEdge::Activate()
{
m_Status = active;
// flaga zachowania kraw�dzi mo�e okre�la� rodzaj ruchu, kt�ry wymaga znaku
// zmiana zachowania bota pod��aj�cego za t� kraw�dzi�
switch(m_Edge.GetBehaviorFlag())
{
case NavGraphEdge::swim:
{
m_pOwner->SetMaxSpeed(script->GetDouble("Bot_MaxSwimmingSpeed"));
// ustawi� odpowiedni� animacj�
}
break;
case NavGraphEdge::crawl:
{
m_pOwner->SetMaxSpeed(script->GetDouble("Bot_MaxCrawlingSpeed"));
// ustawi� odpowiedni� animacj�
}
break;
}
// rejestruj czas, w kt�rym bot rozpoczyna ten cel
m_dStartTime = Clock->GetCurrentTime();
// obliczy� oczekiwany czas wymagany do osi�gni�cia tego punktu. Ta warto��
// s�u�y do okre�lenia, czy bot utkn�� m_dTimeExpected =
m_pOwner->CalculateTimeToReachPosition(m_Edge.GetDestination());
// uwzgl�dni margines b��du dla ka�dego zachowania reaktywnego. 2 sekundy
// powinno by� du�o
static const double MarginOfError = 2.0;
m_dTimeExpected += MarginOfError;
// ustawi� cel sterowania
m_pOwner->GetSteering()->SetTarget(m_Edge.GetDestination());
// Ustaw odpowiednie zachowanie kierowania. Je�li to ostatnia kraw�d� �cie�ki // bot powinien dotrze� do pozycji, na kt�r� wskazuje, w przeciwnym razie powinien szuka�
if (m_bLastEdgeInPath)
{
m_pOwner->GetSteering()->ArriveOn();
}
else
{
m_pOwner->GetSteering()->SeekOn();
}
}

Po aktywowaniu celu przetworzenie go jest proste. Za ka�dym razem, gdy wywo�ywana jest metoda Process, kod sprawdza, czy bot utkn�� lub osi�gn�� koniec kraw�dzi i odpowiednio ustawia m_Status

int Goal_TraverseEdge::Process()
{
// je�li status jest nieaktywny, wywo�aj Activate ()
ActivateIfInactive();
// je�li bot utkn��, b��d powrotu
if (isStuck())
{
m_Status = failed;
}
// je�li bot osi�gn�� koniec kraw�dzi powr�t jest zako�czony
else
{
if (m_pOwner->isAtPosition(m_Edge.GetDestination()))
{
m_Status = completed;
}
}
return m_Status;
}

Metoda Terminate wy��cza zachowanie kierownicy i resetuje maksymaln� pr�dko�� bota do normy.

void Goal_TraverseEdge::Terminate()
{
// wy��cz zachowania kierownicze
m_pOwner->GetSteering()->SeekOff();
m_pOwner->GetSteering()->ArriveOff();
// przywr�ci� maksymaln� pr�dko�� do normy
m_pOwner->SetMaxSpeed(script->GetDouble("Bot_MaxSpeed"));
}

Przejd�my teraz do zbadania kilku z�o�onych cel�w

Goal_FollowPath

To kieruje bota wzd�u� �cie�ki poprzez wielokrotne wyskakiwanie kraw�dzi z przodu �cie�ki i wypychanie cel�w typu kraw�dzi trawersowania na prz�d listy podrz�dnej. Oto jego deklaracja:

class Goal_FollowPath : public Goal_Composite< Raven_Bot >
{
private:
// lokalna kopia �cie�ki zwr�cona przez narz�dzie do planowania �cie�ki
std::list m_Path;
public: Goal_FollowPath(Raven_Bot* pBot, std::list path);
//podejrzani
void Activate();
int Process();
void Terminate(){}
}

Opr�cz powi�zania z nimi okre�lonych typ�w terenu, kraw�dzie wykres�w mog� r�wnie� wymaga� od bota u�ycia okre�lonej akcji do poruszania si� wzd�u� nich. Na przyk�ad kraw�d� mo�e wymaga� od agenta latania, skakania, a nawet u�ywania haka do chwytania, aby porusza� si� wzd�u� niej. Tego rodzaju ograniczenia ruchu nie mo�na rozwi�za�, po prostu dostosowuj�c maksymaln� pr�dko�� i cykl animacji agenta. Zamiast tego dla ka�dej akcji nale�y utworzy� unikalny cel typu kraw�dzi poprzecznych. Cel pod��ania �cie�k� mo�e nast�pnie sprawdza� flagi kraw�dzi w ramach metody Aktywuj i dodawa� poprawny typ celu kraw�dzi trawersu do swojej listy podrz�dnej, gdy wyskakuje z �cie�ki. Aby to wyja�ni�, oto lista metod aktywacji:

void Goal_FollowPath::Activate()
{
m_iStatus = active;
// uzyska� odniesienie do nast�pnej kraw�dzi
PathEdge edge = m_Path.front();
// usu� kraw�d� ze �cie�ki
m_Path.pop_front();
// niekt�re kraw�dzie okre�laj�, �e bot powinien u�ywa� okre�lonego zachowania, gdy
//pod��a� za nimi. Ta instrukcja switch pyta o flag� zachowania kraw�dzi i
// dodaje odpowiednie cele do listy cel�w cz�stkowych.
switch(edge.GetBehaviorFlags())
{
case NavGraphEdge::normal:
{
AddSubgoal(new Goal_TraverseEdge(m_pOwner, edge, m_Path.empty()));
}
break;
case NavGraphEdge::goes_through_door:
{
// also add a goal that is able to handle opening the door
AddSubgoal(new Goal_NegotiateDoor(m_pOwner, edge, m_Path.empty()));
}
break;
case NavGraphEdge::jump:
{
// dodaj subcel, aby przeskoczy� wzd�u� kraw�dzi
}
break;
case NavGraphEdge::grapple:
{
// dodaj subgoal, aby chwyci� si� wzd�u� kraw�dzi
}
break;
default:
throw
std::runtime_error(": Unrecognized edge type");

Aby zwi�kszy� wydajno��, zauwa�, jak tylko jedna kraw�d� jest usuwana na raz ze �cie�ki. Aby to u�atwi�, metoda Process wywo�uje Aktywuj za ka�dym razem, gdy wykryje, �e jej podzadania s� zako�czone, a �cie�ka nie jest pusta. Oto jak:

int Goal_FollowPath::Process()
{
// je�li status jest nieaktywny, wywo�aj Activate ()
ActivateIfInactive();
// je�li nie ma podzada� i nadal istnieje kraw�d� do przej�cia, dodaj
// kraw�d� jako subgoal
m_Status = ProcessSubgoals();
// je�li nie ma �adnych podzada�, sprawd�, czy �cie�ka nadal ma kraw�dzie.
// je�li wywo�a Aktywacj�, aby z�apa� nast�pn� kraw�d�.
if (m_Status == completed && !m_Path.empty())
{
Activate();
}
return m_Status;
}

Metoda Goal_FollowPath :: Terminate nie zawiera logiki, poniewa� nie ma nic do uporz�dkowania.

PORADA. Po uruchomieniu pliku wykonywalnego Raven istnieje mo�liwo�� wy�wietlenia listy cel�w wybranego agenta w menu.

Rysunek jest w skali szaro�ci, ale po uruchomieniu demonstracji aktywne cele zostan� narysowane na niebiesko, zako�czone na zielono, nieaktywne na czarno i nieudane na czerwono. Wci�cie pokazuje, w jaki spos�b cele s� zagnie�d�one.

Goal_MoveToPosition

Ten z�o�ony cel s�u�y do przeniesienia bota w dowolne miejsce na mapie. Oto jego deklaracja:

bool Goal_MoveToPosition::HandleMessage(const Telegram& msg)
{
//first, pass the message down the goal hierarchy
bool bHandled = ForwardMessageToFrontMostSubgoal(msg);
// je�li msg nie zosta� obs�u�ony, sprawd�, czy ten cel sobie z tym poradzi
if (bHandled == false)
{
switch(msg.Msg)
{
case Msg_PathReady:
// wyczy�� wszystkie istniej�ce cele
RemoveAllSubgoals();
AddSubgoal(new Goal_FollowPath(m_pOwner,
m_pOwner->GetPathPlanner()->GetPath()));
return true; // msg obs�ugiwane
case Msg_NoPathAvailable:
m_Status = failed;
return true; // msg obs�ugiwane
default: return false;
}
}
// obs�ugiwane przez subgoals
return true;
}

Subgoale Goal_MoveToPosition s� przetwarzane i stale monitorowane pod k�tem awarii. Je�li jeden z podzada� nie powiedzie si�, cel ten reaktywuje si� w celu przeplanowania.

int Goal_MoveToPosition::Process()
{
// je�li status jest nieaktywny, wywo�aj Activate () i ustaw status na active
ActivateIfInactive();
// przetwarza� podzadania
m_Status = ProcessSubgoals();
// je�li kt�rykolwiek z podzada� nie powi�d� si�, cel ten zostanie ponownie ustawiony
ReactivateIfFailed();
return m_Status;
}

Przejd�my teraz do sprawdzenia, jak dzia�a jeden z pozosta�ych cel�w na poziomie strategii: Goal_AttackTarget.

Goal_AttackTarget

Bot wybiera t� strategi�, gdy czuje si� zdrowy i wystarczaj�co uzbrojony, aby zaatakowa� sw�j obecny cel. Goal_AttackTarget jest celem z�o�onym, a jego deklaracja jest prosta.

class Goal_AttackTarget : public Goal_Composite
{
public:
Goal_AttackTarget(Raven_Bot* pOwner);
void Activate();
int Process();
void Terminate(){m_iStatus = completed;}
};

Ca�a akcja dzieje si� w metodzie Aktywuj. Przede wszystkim wszelkie istniej�ce podzadania s� usuwane, a nast�pnie sprawdzane, czy cel bota jest nadal aktualny. Jest to niezb�dne, poniewa� cel mo�e zgin�� lub wyj�� poza horyzont sensoryczny bota, gdy ten cel jest nadal aktywny. W takim przypadku cel musi zako�czy� si�.

void Goal_AttackTarget::Activate()
{
m_iStatus = active;
// je�li ten cel zostanie ponownie aktywowany, mog� istnie� pewne podzadania, kt�re
// nale�y usun��
RemoveAllSubgoals();
// cel bota mo�e umrze�, gdy ten cel jest aktywny, wi�c my // nale�y przetestowa�, aby upewni� si�, �e bot zawsze ma aktywny cel
if (!m_pOwner->GetTargetSys()->isTargetPresent())
{
m_iStatus = completed;
return;
}

Nast�pnie bot sprawdza sw�j system celowania, aby dowiedzie� si�, czy ma bezpo�redni strza� w cel. Je�li strza� jest mo�liwy, wybiera taktyk� ruchu, kt�r� nale�y zastosowa�. Pami�taj, �e system broni jest ca�kowicie oddzielnym sk�adnikiem sztucznej inteligencji i zawsze automatycznie wybiera najlepsz� bro�, celuje i strzela do bie��cego celu, bez wzgl�du na cel, do kt�rego d��y bot. Oznacza to, �e ten cel musi jedynie dyktowa� ruch bota podczas ataku. Udost�pni�em botom Raven tylko dwie mo�liwo�ci: je�li po lewej lub prawej stronie bota jest miejsce, b�dzie on toczy� si� z boku na bok, dodaj�c Goal_DodgeSideToSide do swojej listy podrz�dnej. Je�li nie ma miejsca na unik, bot po prostu szuka aktualnej pozycji celu.

// je�li bot jest w stanie strzeli� do celu (mi�dzy botem a LOS jest LOS)
// cel), a nast�pnie wybierz taktyk�, kt�r� chcesz zastosowa� podczas strzelania
if (m_pOwner->GetTargetSys()->isTargetShootable())
{
// je�li bot ma miejsce na atak, zr�b to
Vector2D dummy;
if (m_pOwner->canStepLeft(dummy) || m_pOwner->canStepRight(dummy))
{
AddSubgoal(new Goal_DodgeSideToSide(m_pOwner));
}
// je�li nie jest w stanie atakowa�, skieruj si� bezpo�rednio na pozycj� celu
else
{
AddSubgoal(new Goal_SeekToPosition(m_pOwner,
m_pOwner->GetTargetBot()->Pos()));
}
}

W zale�no�ci od wymaga� twojej gry prawdopodobnie b�dziesz chcia� da� botowi znacznie szerszy wyb�r taktyk agresywnego ruchu do wyboru. Na przyk�ad, mo�esz chcie� doda� taktyk�, kt�ra przenosi bota do idealnego zasi�gu do strzelania jego pr�dem (lub ulubiona) bro� lub taka, kt�ra wybiera dobr� pozycj� snajpersk� lub os�onow� (nie zapominaj, �e w�z�om nawigacyjnym mo�na przypisa� takie informacje). Je�li nie ma bezpo�redniego strza�u w cel - poniewa� m�g� on w�a�nie biega� za rogiem - bot dodaje Goal_HuntTarget do swojej listy podrz�dnej. Metoda Process dla Goal_AttackTarget jest trywialna. Po prostu upewnia si�, �e podzadania s� przetwarzane, a cel zostanie ponownie zainstalowany w przypadku wykrycia problemu

int Goal_AttackTarget::Process()
{
// je�li status jest nieaktywny, wywo�aj Activate()
ActivateIfInactive();
// przetwarza� podzadania
m_iStatus = ProcessSubgoals();
ReactivateIfFailed();
return m_iStatus;
}

Nie b�d� wchodzi� w szczeg�y Goal_HuntTarget i Goal_Dodge-SideToSide. To oczywiste, co robi� i zawsze mo�esz sprawdzi� kod �r�d�owy, je�li chcesz spojrze� na drobiazgi.

Arbitra� celi

Teraz rozumiesz, jak dzia�aj� cele i widzia�e� kilka konkretnych przyk�ad�w, ale prawdopodobnie nadal zastanawiasz si�, w jaki spos�b boty wybieraj� cele na poziomie strategii. Osi�ga si� to dzi�ki z�o�onemu celowi Goal_Think, kt�rego ka�dy bot posiada trwa�� instancj�, stanowi�c� podstaw� jego hierarchii cel�w. Funkcja Goal_Think polega na arbitra�u mi�dzy dost�pnymi strategiami, wybieraj�c najbardziej odpowiednie do realizacji. Jest sze�� strategicznych cel�w:

• Explore : Agent wybiera dowolny punkt w swoim �rodowisku i planuje i pod��a �cie�k� do tego punktu.
• Get Health: Agent znajduje �cie�k� o najni�szym koszcie do wyst�pienia przedmiotu zdrowia i pod��a �cie�k� do tego przedmiotu.
• Get Weapon (Rocket Launcher): Agent znajduje �cie�k� o najni�szym koszcie do instancji wyrzutni rakiet i pod��a za ni�.
• Get Weapon (Shotgun): Agent znajduje �cie�k� o najni�szym koszcie do wyst�pienia strzelby i pod��a za ni�.
• Get Weapon (Railgun): Agent znajduje �cie�k� o najni�szym koszcie do instancji Railguna i pod��a za ni�.
• Attack Target: Agent okre�la strategi� ataku na sw�j obecny cel.

Ka�da aktualizacja my�li ka�da z tych strategii jest oceniana i otrzymuje wynik reprezentuj�cy celowo�� jej realizacji. Strategia o najwy�szym wyniku jest przypisywana do strategii, kt�r� agent b�dzie pr�bowa� spe�ni�. Aby u�atwi� ten proces, ka�dy Goal_Think agreguje kilka instancji Goal_Evaluator, po jednej dla ka�dej strategii. Obiekty te maj� metody obliczania po��danej strategii, kt�r� reprezentuj�, oraz dodawania tego celu do listy podrz�dnych cel�w. R

Ka�da metoda CalculateDesirability to r�cznie wykonany algorytm, kt�ry zwraca warto�� wskazuj�c� na celowo�� bota realizuj�cego odpowiedni� strategi�. Algorytmy te mog� by� trudne do utworzenia, dlatego cz�sto przydatne jest najpierw skonstruowanie niekt�rych funkcji pomocniczych, kt�re odwzorowuj� okre�lone informacje z gry na warto�ci liczbowe w zakresie od 0 do 1. S� one nast�pnie wykorzystywane w formu�owaniu algorytm�w po��dalno�ci. Nie jest szczeg�lnie wa�ne, jaki zakres warto�ci zwracaj� metody wyodr�bniania obiekt�w - od 0 do 1, od 0 do 100 lub od -10000 do 1000 s� w porz�dku - ale pomaga, je�li s� one znormalizowane we wszystkich metodach. U�atwi to m�zg, gdy zaczniesz tworzy� algorytmy po��dania. Aby zdecydowa�, jakie informacje nale�y pobra� ze �wiata gry, rozwa� kolejno ka�dy cel strategii i jakie cechy gry maj� wp�yw na celowo�� jego realizacji. Na przyk�ad ocena GetHealth b�dzie wymaga�a informacji o stanie zdrowia bota i lokalizacji przedmiotu zdrowia. Podobnie ewaluator AttackTarget b�dzie wymaga� informacji o broni i amunicji, kt�r� nosi bot, opr�cz jego poziom�w zdrowia (bot o niskim poziomie zdrowia znacznie rzadziej zaatakuje przeciwnika ni� bot, kt�ry czuje si� sprawny jako skrzypce). Ewaluator ExploreGoal to szczeg�lny przypadek, jak si� wkr�tce oka�e, ale ewaluator GetWeapon b�dzie wymaga� dodatkowej wiedzy na temat odleg�o�ci do okre�lonej broni i aktualnej amunicji, kt�r� ma przy sobie bot. Raven u�ywa czterech takich funkcji ekstrakcji funkcji, zaimplementowanych jako metody statyczne klasy Raven_Feature. Oto lista deklaracji klasy, kt�ra zawiera opis ka�dej metody w komentarzach:

class Raven_Feature
{
public:
// zwraca warto�� od 0 do 1 w oparciu o zdrowie bota. Im lepsze
// zdrowie, tym wy�sza ocena
static double Health(Raven_Bot* pBot);
// zwraca warto�� od 0 do 1 na podstawie odleg�o�ci bota do
// dany element. Im dalej przedmiot, tym wy�sza ocena. Je�li nie ma
// przedmiot danego typu obecny w �wiecie gry w czasie tej metody
// nazywa si� zwracana warto�� to 1
static double DistanceToItem(Raven_Bot* pBot, int ItemType);
// zwraca warto�� od 0 do 1 w oparciu o ilo�� amunicji dla bota // dana bro� i maksymalna ilo�� amunicji, kt�r� bot mo�e nosi�.
// im bli�ej przenoszonej kwoty do kwoty maksymalnej, tym wy�szy wynik
static double IndividualWeaponStrength(Raven_Bot* pBot, int WeaponType);
// zwraca warto�� od 0 do 1 w oparciu o ca�kowit� ilo�� amunicji
// bot przenosi ka�d� bro�. Ka�da z trzech broni to bot // mo�e podnie�� mo�e przyczyni� si� do uzyskania trzeciej cz�ci wyniku. Innymi s�owy, je�li bot // nosi RL i RG i ma maksymaln� amunicj� do RG, ale tylko po�ow� max
// dla RL ocena b�dzie wynosi� 1/3 + 1/6 + 0 = 0,5
static double TotalWeaponStrength(Raven_Bot* pBot);
};

Teraz, gdy mamy kilka funkcji pomocniczych, przyjrzyjmy si�, jak mo�na ich u�y� do obliczenia wynik�w po��dalno�ci dla ka�dej strategii, kt�re s� r�wnie� standaryzowane w zakresie od 0 do 1.

Obliczanie celowo�ci zlokalizowania przedmiotu zdrowia

Og�lnie rzecz bior�c, celowo�� zlokalizowania przedmiotu zdrowia jest proporcjonalna do obecnego poziomu zdrowia bota i odwrotnie proporcjonalna do odleg�o�ci od najbli�szej instancji. Poniewa� ka�da z tych funkcji jest wyodr�bniana metodami om�wionymi wcze�niej i reprezentowana jako liczba z zakresu od 0 do 1, mo�na to zapisa� jako:

Celowo��_health = (1 - Health / DistToHealth)

gdzie k jest sta�� u�ywan� do poprawiania wyniku. Ta relacja ma sens, poniewa� im dalej musisz podr�owa�, aby znale�� przedmiot, tym mniej go pragniesz, a im ni�szy poziom zdrowia, tym wi�ksze twoje pragnienie. (Zauwa�, �e nie musimy si� martwi� b��dem dzielenia przez zero, poniewa� agent nie mo�e zbli�y� si� do promienia poza jego promie� ograniczaj�cy, zanim element zostanie wyzwolony.) Oto kod �r�d�owy z Raven, kt�ry implementuje to algorytm.

double GetHealthGoal_Evaluator::CalculateDesirability(Raven_Bot* pBot)
{
// najpierw z�ap odleg�o�� do najbli�szego wyst�pienia przedmiotu zdrowia
double Distance = Raven_Feature::DistanceToItem(pBot, type_health);
// je�li funkcja odleg�o�ci ma warto�� 1, oznacza to, �e
// element nie znajduje si� na mapie lub jest zbyt daleko, aby by� wart
// bior�c pod uwag�, dlatego po��dana jest warto�� zero
if (Distance == 1)
{
return 0;
}
else
{
// warto�� u�yta do ulepszenia po��dalno�ci
const double Tweaker = 0.2;
// celowo�� znalezienia przedmiotu zdrowia jest proporcjonalna do kwoty
// zdrowie pozostaj�ce i odwrotnie proporcjonalne do odleg�o�ci od zdj�cia
// najbli�sza instancja elementu zdrowia.
double Desirability = Tweaker * (1-Raven_Feature::Health(pBot)) /
(Raven_Feature::DistanceToItem(pBot, type_health));
// upewnij si�, �e warto�� mie�ci si� w zakresie od 0 do 1
Clamp(Desirability, 0, 1);
return Desirability;
}
}

Obliczanie celowo�ci zlokalizowania okre�lonej broni

Jest to bardzo podobne do poprzedniego algorytmu. Celowo�� zlokalizowania okre�lonej broni mo�na poda� jako:

Celowo��_weapons = k x ( Health x (1-WeaponStrength) / DistToWeapon)

Zwr�� uwag�, w jaki spos�b zar�wno si�a broni, jak i funkcje zdrowotne przyczyniaj� si� do potrzeby odzyskania broni. Jest to rozs�dne, poniewa� w miar� jak bot zostaje powa�nie uszkodzony lub ilo�� amunicji, kt�r� nosi dla tej konkretnej broni, jego ch�� odzyskania powinna si� zmniejszy�. Oto jak algorytm wygl�da w kodzie:

double GetWeaponGoal_Evaluator::CalculateDesirability(Raven_Bot* pBot)
{
// z�ap odleg�o�� do najbli�szego wyst�pienia typu broni
double Distance = Raven_Feature::DistanceToItem(pBot, m_iWeaponType);
// je�li funkcja odleg�o�ci ma warto�� 1, oznacza to, �e
// element nie znajduje si� na mapie lub jest zbyt daleko, aby by� wart
// bior�c pod uwag�, dlatego po��dana jest warto�� zero
if (Distance == 1)
{
return 0;
}
else
{
// warto�� u�yta do ulepszenia po��dalno�ci
const double Tweaker = 0.15f;
double Health, WeaponStrength;
Health = Raven_Feature::Health(pBot);
WeaponStrength = Raven_Feature::IndividualWeaponStrength(pBot, m_iWeaponType);
double Desirability = (Tweaker * Health * (1-WeaponStrength)) / Distance;
// warto�� u�yta do ulepszenia po��dalno�ci br> Clamp(Desirability, 0, 1);
return Desirability;
}
}

Dodatkow� zalet� wykorzystania odleg�o�ci jako czynnika do obliczenia celowo�ci przy podnoszeniu broni i przedmiot�w zdrowotnych jest to, �e w odpowiednich okoliczno�ciach boty tymczasowo zmieniaj� strategi� i zmieniaj� kurs, aby podnie�� przedmioty w pobli�u

WSKAZ�WKA. Wp�yw odleg�o�ci w analizowanych do tej pory algorytmach po��dania jest liniowy. Innymi s�owy, po��dalno�� jest wprost proporcjonalna do odleg�o�ci od przedmiotu. Mo�esz jednak chcie�, aby "przyci�ganie" przedmiotu na bocie stawa�o si� silniejsze w miar� zbli�ania si� bota (jak si�a, kt�r� odczuwasz, gdy przesuwasz dwa magnesy ku sobie), zamiast ze sta�� szybko�ci� (np. Si�a czujesz, kiedy naci�gasz spr�yn�). Najlepiej to wyja�ni� za pomoc� wykresu.

Aby utworzy� algorytm, kt�ry tworzy krzyw� po��dania-odleg�o�ci podobn� do wykresu po prawej, musisz podzieli� przez kwadrat (lub nawet sze�cian) odleg�o�ci. Innymi s�owy, r�wnanie zmienia si� na:

Celowo��_weapons = k x ( Health x (1-WeaponStrength) /DistToWeapon²)

Nie zapominaj, �e b�dziesz musia� r�wnie� dostosowa� k, aby uzyska� po��dane wyniki.

Obliczanie celowo�ci ataku na cel

Celowo�� zaatakowania przeciwnika jest proporcjonalna do tego, jak zdrowy i silny jest bot. "Pot�na" funkcja, w kontek�cie Kruka, wskazuje liczb� broni i amunicji, kt�r� nosi bot, i jest oceniana za pomoc� metody Raven_Feature :: TotalWeaponStrength. (Polecam zajrze� do tej metody nast�pnym razem, gdy b�dziesz siedzie� przy komputerze). Korzystaj�c z tych dw�ch funkcji, mo�emy obliczy� celowo�� realizacji celu AttackTarget:

Celowo��_attack = k x TotalWeaponStrength x Health

Oto jak wygl�da napisane w kodzie:

double AttackTargetGoal_Evaluator::CalculateDesirability(Raven_Bot* pBot)
{
double Desirability = 0.0;
// wykonuj obliczenia tylko wtedy, gdy istnieje cel
if (pBot->GetTargetSys()->isTargetPresent())
{
const double Tweaker = 1.0;
Desirability = Tweaker *
Raven_Feature::Health(pBot) *
Raven_Feature::TotalWeaponStrength(pBot);
}
return Desirability;

WSKAZ�WKA. W zale�no�ci od tego, jak bardzo potrzebujesz agenta, mo�esz dodawa� i usuwa� strategie z arbitra. (Pami�taj, �e Goal_Think jest arbitrem cel�w strategicznych bota Raven.) Rzeczywi�cie, mo�esz nawet w��cza� i wy��cza� ca�e zestawy cel�w strategicznych, aby zapewni� agentowi zupe�nie nowy zestaw zachowa� do wyboru. Far Cry na przyk�ad u�ywa tego rodzaju techniki z dobrym skutkiem.

Obliczanie celowo�ci eksploracji mapy

To jest �atwe. Wyobra� sobie, �e grasz w t� gr�. Mo�esz eksplorowa� map� tylko wtedy, gdy nie ma innych rzeczy wymagaj�cych Twojej natychmiastowej uwagi, takich jak atakowanie przeciwnika lub poszukiwanie amunicji lub zdrowia. W konsekwencji celowo�� eksploracji mapy jest ustalona jako niska sta�a warto��, dzi�ki czemu opcja eksploracji jest wybrana tylko wtedy, gdy wszystkie alternatywy maj� ni�sze oceny celowo�ci. Oto kod:

double ExploreGoal_Evaluator::CalculateDesirability(Raven_Bot* pBot)
{
const double Desirability = 0.05;
return Desirability;
}

��cz�c wszystko razem

Po zdefiniowaniu funkcji celowo�ci dla ka�dego obiektu ewaluatora, pozostaje tylko to, aby Goal_Think przeprowadza� iteracj� przy ka�dej aktualizacji my�li i wybiera� najwy�sz� strategi�, kt�r� b�dzie realizowa� bot. Oto kod wyja�niaj�cy:

void Goal_Think::Arbitrate()
{
double best = 0;
Goal_Evaluator* MostDesirable = NULL;
// teruj przez wszystkich oceniaj�cych, aby zobaczy�, kt�ry daje najwy�szy wynik
GoalEvaluators::iterator curDes = m_Evaluators.begin();
for (curDes; curDes != m_Evaluators.end(); ++curDes)
{
double desirabilty = (*curDes)->CalculateDesirability(m_pOwner);
if (desirabilty >= best)
{
best = desirabilty;
MostDesirable = *curDes;
}
}
MostDesirable->SetGoal(m_pOwner);
}

WSKAZ�WKA. Gracze b�d�cy lud�mi mog� przewidywa�, co zrobi inny gracz, i odpowiednio post�powa�. Mo�emy to zrobi�, poniewa� jeste�my w stanie kr�tko zmieni� punkt widzenia na innych graczy i zastanowi� si�, jakie mog� by� ich pragnienia, je�li rozumiemy ich stan i �wiat gry. Oto przyk�ad: z dystansu obserwujesz dw�ch graczy, Sid i Erica, walcz�cych z wyrzutniami rakiet, gdy nagle, po dwukrotnym trafieniu z rz�du, Eric odrywa si� i zaczyna biec korytarzem. Zmieniasz punkt widzenia na Erica, a poniewa� wiesz, �e ma ma�o zdrowia, przewidujesz, �e bardzo prawdopodobne jest, �e zmierza w kierunku pakietu zdrowia, o kt�rym wiesz, �e znajduje si� w pokoju na ko�cu korytarza. Zdajesz sobie r�wnie� spraw�, �e jeste� umieszczony bli�ej zdrowia ni� Eric, wi�c decydujesz si� go "ukra��" i odczeka�, a� dotrze na miejsce, po czym wysmarujesz jego jelita wzd�u� �ciany karabinem plazmowym. Umiej�tno�� przewidywania dzia�a� innych w ten spos�b jest wrodzon� cech� ludzkich zachowa� - robimy to ca�y czas - ale mo�liwe jest nadanie agentowi podobnej, cho� nieco os�abionej zdolno�ci. Poniewa� pragnienia agent�w arbitra�owych bramek s� ustalane algorytmicznie, mo�esz sprawi�, by bot uruchomi� odpowiednie atrybuty (zdrowie, amunicj� itp.) Gracza poprzez w�asny (lub niestandardowy) arbiter, aby zgadywa�, jakie mog� by� pragnienia gracza by� w tym czasie. Oczywi�cie dok�adno�� tego przypuszczenia zale�y w du�ej mierze od tego, jak �ci�le pragnienia bota odpowiadaj� graczowi - i to zale�y od twoich umiej�tno�ci modelowania behawioralnego - ale zwykle nie jest zbyt trudne wykonanie od czasu do czasu dok�adnej prognozy, kt�ra pozwala botowi da� graczowi przykra niespodzianka, nawet w przypadku bardzo podstawowego modelu.

Podzia�y

Jedn� wielk� zalet� hierarchicznego projektu arbitra�u opartego na celach jest to, �e dodatkowe funkcje s� dostarczane przy niewielkim dodatkowym wysi�ku ze strony programisty. Sp�dzimy reszt� rozdzia�u, przygl�daj�c si� im.

Osobowo�ci

Poniewa� oceny celowo�ci s� ograniczone do tego samego zakresu, �atwo jest stworzy� agent�w o r�nych cechach osobowo�ci, mno��c ka�dy wynik przez sta��, kt�ra przesuwa go w wymaganym kierunku. Na przyk�ad, aby stworzy� bota Ravena, kt�ry gra agresywnie, nie dbaj�c o w�asne bezpiecze�stwo, mo�esz zmniejszy� jego ch�� uzyskania zdrowia o 0,6 i ch�� zaatakowania cel�w o 1,5. Aby stworzy� gr�, kt�ra gra ostro�nie, mo�esz zaspokoi� pragnienia bota, aby by� bardziej podatny na zbieranie broni i zdrowia ni� atak. Je�li mia�by� zaprojektowa� agent�w ukierunkowanych na cel dla gry RTS, mo�esz stworzy� jednego przeciwnika, kt�ry faworyzuje eksploracj� i badania technologii, drugiego, kt�ry woli tworzy� ogromne armie tak szybko, jak to mo�liwe, a drugiego, kt�ry ma obsesj� na punkcie obrony miasta. Aby u�atwi� takie cechy osobowo�ci, klasa podstawowa Goal_Evaluator zawiera zmienn� sk�adow� m_dCharacterBias, kt�rej klient w konstruktorze przypisuje warto��:

class Goal_Evaluator
{
protected:
// gdy oceniono celowo�� dla bramki, jest ona mno�ona
// wed�ug tej warto�ci. Mo�na go u�ywa� do tworzenia bot�w z preferencjami opartymi na
// ich osobowo�ci
double m_dCharacterBias;
public:
Goal_Evaluator(double CharacterBias):m_dCharacterBias(CharacterBias){}
/* DODATKOWE SZCZEGӣY POMINI�TO */
};

m_dCharacterBias jest wykorzystywany w metodzie CalculateDesirability ka�dej podklasy do dostosowania obliczania wyniku oceny po��dalno�ci. Oto jak jest dodawany do obliczania celowo�ci AttackTarget:

double AttackTargetGoal_Evaluator::CalculateDesirability(Raven_Bot* pBot)
{
double Desirability = 0.0;
// wykonuj obliczenia tylko wtedy, gdy istnieje cel
if (pBot->GetTargetSys()->isTargetPresent())
{
const double Tweaker = 1.0;
Desirability = Tweaker *
Raven_Feature::Health(pBot) *
Raven_Feature::TotalWeaponStrength(pBot);
//odchylenie warto�ci zgodnie z osobowo�ci� bota
Desirability *= m_dCharacterBias;
}
return Desirability;
}

Je�li tw�j projekt gry wymaga, aby osobowo�ci bot�w pozostawa�y mi�dzy grami, powiniene� utworzy� osobny plik skryptu dla ka�dego bota zawieraj�cy uprzedzenia (plus wszelkie inne dane charakterystyczne dla bota, takie jak dok�adno�� celowania broni, preferencje wyboru broni itp.) . Jednak w Raven nie ma takich bot�w; za ka�dym razem, gdy uruchamiasz program, tendencyjno�ci boty s� przypisywane losowe warto�ci w konstruktorze Goal_Think, tak jak:

// te uprzedzenia mog� zosta� za�adowane ze skryptu dla poszczeg�lnych bot�w
// ale na razie podamy im losowe warto�ci
const double LowRangeOfBias = 0.5;
const double HighRangeOfBias = 1.5;
double HealthBias = RandInRange(LowRangeOfBias, HighRangeOfBias);
double ShotgunBias = RandInRange(LowRangeOfBias, HighRangeOfBias);
double RocketLauncherBias = RandInRange(LowRangeOfBias, HighRangeOfBias);
double RailgunBias = RandInRange(LowRangeOfBias, HighRangeOfBias);
double ExploreBias = RandInRange(LowRangeOfBias, HighRangeOfBias);
double AttackBias = RandInRange(LowRangeOfBias, HighRangeOfBias);
// utw�rz obiekty oceniaj�ce
m_Evaluators.push_back(new GetHealthGoal_Evaluator(HealthBias));
m_Evaluators.push_back(new ExploreGoal_Evaluator(ExploreBias));
m_Evaluators.push_back(new AttackTargetGoal_Evaluator(AttackBias));
m_Evaluators.push_back(new GetWeaponGoal_Evaluator(ShotgunBias,
type_shotgun));
m_Evaluators.push_back(new GetWeaponGoal_Evaluator(RailgunBias,
type_rail_gun));
m_Evaluators.push_back(new GetWeaponGoal_Evaluator(RocketLauncherBias,
type_rocket_launcher));

PORADA. Arbitra� celowy jest zasadniczo procesem algorytmicznym zdefiniowanym przez kilka liczb. W rezultacie nie jest sterowany przez logik� (jak FSM), ale przez dane. Jest to niezwykle korzystne, poniewa� wszystko, co musisz zrobi�, aby zmieni� zachowanie, to poprawienie liczb, kt�re wolisz przechowywa� w pliku skryptu, aby inni cz�onkowie Twojego zespo�u mogli z nimi z �atwo�ci� eksperymentowa�.
Pami�� stanu

Charakter z�o�onych cel�w (LIFO) automatycznie nadaje si� do agent�w z pami�ci�, umo�liwiaj�c im tymczasow� zmian� zachowania poprzez wypchni�cie nowego celu (lub cel�w) na prz�d listy podrz�dnych cel�w. Gdy tylko nowy cel zostanie osi�gni�ty, pojawi si� na li�cie, a agent wznowi wszystko, co wcze�niej robi�. Jest to bardzo pot�na funkcja, kt�r� mo�na wykorzysta� na wiele r�nych sposob�w. Oto kilka przyk�ad�w.

Przyk�ad pierwszy - automatyczne wznawianie przerwanych czynno�ci

Wyobra� sobie, �e Eric, kt�ry jest w drodze do ku�ni ze z�otem w kieszeni, zostaje z�apany przez z�odzieja z no�em Rambo. Dzieje si� to tu� przed osi�gni�ciem trzeciego punktu na drodze, kt�r� pod��a. Lista subgoal jego m�zgu przypomina w tym miejscu

Eric nie spodziewa� si�, �e tak si� stanie, ale na szcz�cie programista AI stworzy� cel, aby poradzi� sobie z tego rodzaju spraw�, zwan� DefendAgainst-Attacker. Cel ten zostaje przesuni�ty na prz�d jego listy podrz�dnej i pozostaje aktywny, dop�ki z�odziej nie ucieknie lub nie zostanie zabity przez Erica.

Wspania�� rzecz� w tym projekcie jest to, �e gdy DefendAgainstAttacker jest usatysfakcjonowany i usuni�ty z listy, Eric automatycznie wznawia �ledzenie kraw�dzi do punktu trzeciego. Niekt�rzy z was zapewne b�d� my�le�: "Ach, ale co, je�li �cigaj�c z�odzieja, Eric straci wzrok z punktu trzeciego?" To fantastyczna cecha tego projektu. Poniewa� cele maj� wbudowan� logik� do wykrywania awarii i ponownego tworzenia planu, je�li cel nie powiedzie si�, projekt przesuwa si� w g�r� hierarchii do momentu znalezienia elementu nadrz�dnego, kt�ry jest w stanie ponownie zaplanowa� cel.

Przyk�ad drugi - negocjowanie przeszk�d na specjalnej �cie�ce

Wiele projekt�w gier wymaga od agent�w pokonywania jednego lub wi�cej rodzaj�w przeszk�d na drodze, takich jak drzwi, windy, mosty zwodzone i ruchome platformy. Cz�sto wymaga to od agenta wykonania kr�tkiej sekwencji dzia�a�. Na przyk�ad, aby skorzysta� z windy, agent musi znale�� przycisk, kt�ry go wywo�uje, podejd� do przycisku, naci�nij go, a nast�pnie cofnij si� i sta� przed drzwiami, a� winda si� pojawi. Korzystanie z ruchomej platformy jest podobnym procesem: agent musi podej�� do mechanizmu, kt�ry dzia�a na platformie, naci�nij / poci�gnij j�, podejd� do miejsca wsiadania, poczekaj na platform�, a na koniec wejd� na platform� i poczekaj, a� dojdzie do celu.

Te "przeszkody" powinny by� przejrzyste dla planisty �cie�ki, poniewa� nie stanowi� one przeszk�d dla ruchu agenta. Oczywi�cie negocjowanie ich wymaga czasu, ale mo�e to znale�� odzwierciedlenie w kosztach nawigacyjnych. Aby agenci mogli poradzi� sobie z takimi przeszkodami, przechodz�ca przez nie kraw�d� wykresu musi by� opatrzona adnotacjami odzwierciedlaj�cymi ich rodzaj. Cel FollowPath mo�e nast�pnie sprawdzi� te informacje i upewni� si�, �e w�a�ciwy typ celu jest wypychany na pocz�tek listy cel�w agenta, gdy taka kraw�d� zostanie napotkana. Tak jak w poprzednim przyk�adzie, agent b�dzie realizowa� ten nowy cel cz�stkowy, dop�ki nie zostanie uko�czony, a nast�pnie wznowi wszystko, co robi� wcze�niej. Aby zilustrowa� t� zasad�, doda�em wsparcie przy negocjowaniu przesuwnych drzwi do repertuaru bot�w Raven. Drzwi przesuwne s� otwierane poprzez dotkni�cie "przycisku" znajduj�cego si� w pobli�u drzwi (po jednym z ka�dej strony). Kiedy drzwi s� dodawane w edytorze map, wszelkie kraw�dzie wykresu przekraczaj�ce granic� drzwi s� oznaczane flag� idzie_through_door. Je�li bot napotka kraw�d� oznaczon� w ten spos�b (poniewa� s� one �ci�gane ze �cie�ki w Goal_FollowPath :: Activate), cel NegotiateDoor jest dodawany do listy podrz�dnej w taki spos�b:

void Goal_FollowPath::Activate()
{
// uzyska� odniesienie do nast�pnej kraw�dzi
const PathEdge& edge = m_Path.front();
switch(edge.GetBehaviorFlags())
{
case NavGraphEdge::goes_through_door:
{
//dodaj cel, kt�ry jest w stanie obs�u�y� otwieranie drzwir
AddSubgoal(new Goal_NegotiateDoor(m_pOwner, edge));
}
break;
//etc

Cel NegotiateDoor kieruje bota poprzez sekwencj� dzia�a� wymaganych, aby otworzy� i przej�� przez drzwi. Jako przyk�ad rozwa�my przypadek bota pokazanego na rysunku, kt�rego �cie�ka wiedzie wzd�u� kraw�dzi AB, kt�ra jest zas�oni�ta przesuwanymi drzwiami

Aby przej�� przez przesuwane drzwi, bot musi wykona� nast�puj�ce kroki

1. Uzyskaj list� przycisk�w otwieraj�cych drzwi (b1 i b2).
2. Z listy wybierz najbli�szy przycisk nawigacyjny (b1).
3. Zaplanuj i pod��aj �cie�k� do przycisku b1 (przycisk uruchomi si�, otwieraj� si� drzwi).
4. Zaplanuj i pod��aj �cie�k� do w�z�a A.
5. Przejd� przez kraw�d� AB.

Goal_NegotiateDoor rozwi�zuje ka�dy z tych krok�w w metodzie Activate, dodaj�c podzakresy niezb�dne do wykonania zadania. Listing pomo�e to wyja�ni�

void Goal_NegotiateDoor::Activate()
{ m_iStatus = active;
// je�li ten cel zostanie ponownie aktywowany, mog� istnie� pewne podzadania, kt�re
// nale�y usun��
RemoveAllSubgoals();
// uzyska� pozycj� najbli�szego prze��czalnego prze��cznika
Vector2D posSw = m_pOwner->GetWorld()->GetPosOfClosestSwitch(m_pOwner->Pos(),
m_PathEdge.GetDoorID());
// poniewa� cele s� * wypychane * na prz�d listy podrz�dnych cel�w, kt�re musz�
// by� dodany w odwrotnej kolejno�ci.
// po pierwsze, cel przej�cia przez kraw�d�, kt�ra przechodzi przez drzwi
AddSubgoal(new Goal_TraverseEdge(m_pOwner, m_PathEdge));
// nast�pnie cel, kt�ry przeniesie bota na pocz�tek kraw�dzi, �e
// przechodzi przez drzwi
AddSubgoal(new Goal_MoveToPosition(m_pOwner, m_PathEdge.GetSource()));
// wreszcie cel, kt�ry skieruje bota do po�o�enia prze��cznika
AddSubgoal(new Goal_MoveToPosition(m_pOwner, posSw));
}

Mo�esz zobaczy� roboty Ravena poruszaj�ce si� po drzwiach, uruchamiaj�c Raven i �aduj�c map� Raven_DM1_With_Doors.map. U�ywa rzadkiego wykresu nawigacyjnego, dzi�ki czemu mo�esz wyra�nie zobaczy�, jak dzia�a cel NegotiateDoor.

Kolejkowanie polece�

Gry strategiczne w czasie rzeczywistym ogromnie si� skomplikowa�y w ci�gu ostatnich kilku lat. Zwi�kszono nie tylko liczb� NPC, kt�r� gracz jest w stanie kontrolowa�, ale tak�e liczb� polece�, kt�re mo�e poinstruowa� NPC. Wymaga�o to kilku ulepsze� interfejsu u�ytkownika, jednym z nich jest zdolno�� gracza do kolejkowania rozkaz�w NPC - co�, co sta�o si� znane jako kolejkowanie polece� (lub budowanie w kolejce). Jednym z pierwszych zastosowa� kolejkowania by�o ustawienie punkt�w trasy, kt�rymi NPC pod��a�by �cie�k�. Aby to zrobi�, gracz przytrzymuje klawisz, klikaj�c map�, aby utworzy� seri� punkt�w trasy. NPC przechowuje punkty w strukturze danych FIFO (pierwsze wej�cie, pierwsze wyj�cie) i pod��a za nimi w kolejno�ci, zatrzymuj�c si�, gdy kolejka jest pusta.

Projektanci szybko zdali sobie spraw�, �e przy niewielkich modyfikacjach u�ytkownik mo�e r�wnie� przypisa� punkty patrolowe NPC. Je�li punkty drogi zostan� przypisane przez gracza jako punkty patrolowania (przytrzymuj�c inny klawisz podczas klikania), s� one zwracane na ty� kolejki, gdy dotrze do nich NPC. W ten spos�b NPC b�dzie niesko�czenie kr��y� przez punkty patrolowania, dop�ki nie otrzyma instrukcji.

Bardzo kr�tko po tej innowacji zdano sobie spraw�, �e wektory pozycjonuj�ce mog� nie tylko sta� w kolejce, ale tak�e ka�dy rodzaj polecenia. Nast�pnie, zamiast wydawa� tylko jedno rozkaz na raz, po prostu przytrzymuj�c klawisz podczas wybierania rozkaz�w, gracz mo�e kolejkowa� wiele polece�. Na przyk�ad NPC mo�e zosta� poinstruowany, aby zebra� troch� z�ota, a nast�pnie zbudowa� koszary, a nast�pnie zaatakowa� wrog� jednostk�. Po wydaniu rozkaz�w gracz mo�e skoncentrowa� si� na innym miejscu, maj�c pewno��, �e NPC wykona rozkazy. Kolejkowanie polece� znacznie skraca czas, jaki gracz musi po�wi�ci� na mikrozarz�dzanie i zwi�ksza czas dost�pny na przyjemniejsze aspekty gry. Dlatego sta� si� nieodzown� cech� gatunku RTS. Na szcz�cie dzi�ki z�o�onej architekturze cel�w ta funkcja jest niezwykle �atwa do wdro�enia. Wszystko, co musisz zrobi�, to pozwoli� klientom dodawa� cele z ty�u listy podrz�dnej opr�cz frontu. Ot� to! Pi�� minut pracy i kolejka polece�. Mo�esz obserwowa� kolejkowanie polece� w akcji w Raven. Niestety, w przeciwie�stwie do RTS, Raven nie ma wielu interesuj�cych polece�, ale mo�esz ustawi� w kolejce wiele cel�w MoveToPosition, przytrzymuj�c klawisz "Q" podczas klikania mapy. Zaimplementowa�em to, dodaj�c metod� QueueGoal_ MoveToPosition do Goal_Think i troch� dodatkowego kodu do wywo�ania tej metody, je�li gracz kliknie map�, przytrzymuj�c odpowiedni klawisz. Je�li zwolnisz klawisz "Q" i ponownie klikniesz map� prawym przyciskiem myszy, kolejka zostanie wyczyszczona i zast�piona jednym nowym celem. By�oby to jednak r�wnie �atwe do wdro�enia z dowolnym wybranym przez ciebie celem, poniewa� kolejkowanie samo si� zajmuje.

Korzystanie z zachowania kolejki do skryptu

Kolejn� zalet� przekszta�cenia listy podrz�dnej w kolejk� jest to, �e umo�liwia ona pisanie scenariuszy akcji liniowych bez wi�kszych trudno�ci. Na przyk�ad mo�esz utworzy� takie zachowanie:

• Gracz wchodzi do pokoju i pojawia si� widmowa posta�, kt�ra unosi si� do skrzyni ustawionej w rogu, otwiera skrzyni�, wyjmuje zw�j, p�ynie z powrotem do gracza i wr�cza mu zw�j.
• Gracz wchodzi do holu hotelowego ze szklanym sufitem. Po kr�tkim czasie sp�dzonym w pokoju s�ycha� helikopter. Kilka sekund p�niej sufit rozbija si� na milion od�amk�w i wida�, jak kilku uzbrojonych m�czyzn w czerni zje�d�a z helikoptera. Kiedy uderz� o pod�og�, rozpraszaj� si�, ka�dy znajduje os�on� w osobnym miejscu i zaczynaj� strzela� do gracza.
• Gracz znajduje star� mosi�n� lamp�. Pociera j� i pojawia si� d�in. D�in m�wi "P�jd� za mn�" i prowadzi gracza do wej�cia do tajnego tunelu, gdzie natychmiast znika w k��bach dymu.

Aby to zrobi�, musisz upewni� si�, �e zdefiniowa�e� cel dla ka�dego kroku sekwencji oraz wyzwalacze wymagane do aktywacji skryptu. Ponadto musisz udost�pni� odpowiedni kod C ++ w swoim j�zyku skryptowym. Na przyk�ad, aby napisa� trzeci przyk�ad z poprzedniej listy w Lua, musisz wykona� te zadania.

1. Utw�rz trzy cele:

* Cel SayPhrase, kt�ry spowoduje wy�wietlenie tekstu na ekranie okre�lony czas.
* Cel LeadPlayerToPosition. Jest to podobne do celu MoveTo-Position widocznego w Raven, z tym �e ma dodatkow� logik�, aby upewni� si�, �e d�in nie traci z oczu gracza podczas prowadzenia go do tajnego tunelu.
* Cel VanishInPuffOfSmoke, kt�ry usunie instancj� d�ina ze �wiata gry i pozostawi po sobie k��bek dymu.

2. Utw�rz wyzwalacz, kt�ry jest aktywowany, gdy gracz wykonuje akcj� "pociera�" na konkretnym obiekcie "lampy". Po aktywacji spust powinien wywo�a� odpowiedni� funkcj� Lua.
3. Ods�o� Lu� odpowiednie cz�ci architektury gry. Idealnie by�oby napisa� skrypt, kt�ry wygl�da troch� tak:

function AddGenieTourGuide(LampPos, TunnelPos, Player)
--create an instance of a genie at the position of the lamp
genie = CreateGenie(LampPos)
--first welcome the player, text stays on screen for 2 seconds
genie:SayPhrase("Welcome oh great "..Player:GetName().. "!", 2)
--order the player to follow the genie. text stays on screen for
--3 seconds
genie:SayPhrase("Follow me for your three wishes", 3)
--lead the player to the tunnel entrance
genie:LeadPlayerToPosition(Player, TunnelPos)
--vanish
genie:VanishInPuffOfSmoke
end

Dlatego musisz ujawni� metod� C ++, kt�ra tworzy d�ina, dodaje go do �wiata gry i zwraca wska�nik do niego, a tak�e metody dodawania odpowiednich cel�w do kolejki bramek d�ina.

Podsumowuj�c

Przedstawiono elastyczn� i wydajn� architektur� agent�w zorientowanych na cele. Nauczy�e� si�, jak zachowanie agenta mo�e by� modelowane jako zestaw strategii wysokiego poziomu, z kt�rych ka�da sk�ada si� z zagnie�d�onej hierarchii cel�w z�o�onych i atomowych. Dowiedzia�e� si� tak�e, jak agenci mog� rozstrzyga� mi�dzy tymi strategiami, aby wybra� najbardziej odpowiedni� do realizacji w danym stanie gry. Chocia� ��czy wiele podobie�stw, ten typ architektury jest znacznie bardziej wyrafinowany ni� projekt oparty na stanie i wymaga pewnej wprawy, zanim b�dzie mo�na go bezpiecznie u�ywa�. Jak zwykle zako�cz� ten rozdzia� kilkoma pomys�ami, z kt�rymi mo�esz si� pobawi�, aby pom�c Ci lepiej zrozumie�.

Praktyka czyni mistrza

1. Przyzwoici ludzcy gracze FPS odczuwaj� "wyczucie", kiedy dany przedmiot zaraz si� odrodzi. Rzeczywi�cie, niekt�rzy gracze w deathmatch nie mog� bawi� si� budzikiem z boku swojego monitora! Jednak roboty Raven obecnie nie maj� poj�cia, kiedy przedmiot si� zbli�a odrodzi� si�. Utw�rz warunek zako�czenia wyszukiwania Dijkstry algorytm, kt�ry oblicza, czy nieaktywny (niewidoczny) typ przedmiotu odrodzi si� w czasie potrzebnym do jego osi�gni�cia, umo�liwiaj�c w ten spos�b botowi go wyprzedzi�.
2. Boty Raven nie maj� strategii obronnej. W tej chwili pr�buj� po prostu wytropi� typ przedmiotu, je�li nie czuj� si� wystarczaj�co silni, aby zaatakowa� i maj� nadziej�, �e to wyprowadzi ich z drogi. Gdy zobaczysz wersj� demonstracyjn�, zauwa�ysz, �e takie zachowanie cz�sto wp�dza ich w k�opoty, poniewa� nie pr�buj� unika� strza��w podczas �cigania przedmiotu. Napisz logik� i wszelkie dodatkowe cele wymagane, aby umo�liwi� botom wykrywanie takich sytuacji i unikanie ich z boku na bok, wci�� cigaj�c typ przedmiotu.
3. Dodaj skrypt Raven do postaci i stw�rz jedn� lub dwie sekwencje skryptowe. To �wietne �wiczenie, kt�re wzmocni wiele rzeczy, kt�rych nauczy�e� si� do tej pory. Nie musisz pisa� scenariuszy w �aden skomplikowany spos�b. Na przyk�ad, mo�esz zrobi� co� podobnego do opisanego wcze�niej przyk�adu d�ina. Utw�rz skrypt z punktu widzenia gracza: natura Kruka, ale wiesz, co mam na my�li), zatrzymuje si� przed graczem, m�wi "Follow Me", a nast�pnie prowadzi gracza w losowe miejsce.

Agent ukierunkowany na celProgramownie A.I. Gier

Zachowanie agenta ukierunkowanego na cel