34ª Jornadas Argentinas de Inform ática e Investigación Operativa

“Algorit mos de búsqued a heurística en tiempo real.

Aplicación a la naveg a ción en los juegos de vídeo”

Autor: Fernández, Martín Osvaldo

e- mail: martinosvaldofern a n d e z@g m ail.com

Director: Felice, Laura

e- mail: lfelice@exa.unicen.edu.ar

Categoría: Trabajos de Cátedra

Área: Algoritmos, Lenguajes y Programación

Asignatura:
Análisis y diseño de algoritmos II
2º año de la carrera de Ingeniería de Sistemas
Facultad de Ciencias Exactas
Universidad Nacional del Centro de la Provincia de Buenos Aires
Tandil
 Algoritmos de búsqueda heurística en tiempo real.
Aplicación a la navegación en los juegos de vídeo.

Resumen

Este trabajo se inició en el marco de un curso de intro d u cción al análisis y

diseño de algorit m o s, dictado en el 2º año de una carrera de infor m á tica. La
motivación fue estudiar cómo se extien de n los concep to s básicos de búsq ue d a
para adapta rlos a los requeri mien t o s de los siste ma s de tiemp o real. Como
caso de estudio se eligió la navegación en los juegos de vídeo, por ser un
proble m a que se resuelve natural m e n t e median t e la búsq ue d a. Se consideran
los juegos en tiempo real en los que el entorn o es dema siad o grande o el
terreno es diná mico, de modo que las estrategias básicas de búsq ue d a
resulta n inadecua da s. En este contexto, se analiza n e imple me n t a n algorit m o s
de búsq ue da heurística en tiem p o real los cuales fueron concebidos para
resolver problem a s con estas características.

1. Introducción
La consta n te evolución de los juegos de vídeo ha llevado a que la inteligencia artificial
constit uya uno de los aspectos más impo rta n t e s; es fund a m e n t al que los agente s
(entida de s autóno m a s) controla dos por la comp u t a d o r a se comp o r te n en forma
inteligente. Un proble ma característico es la navegación , que consiste en deter min a r el
camino más conveniente entre una posición inicial y una posición de destin o. Si bien el
planteo del proble ma es sencillo, el mis mo está lejos de ser trivial debido a la creciente
complejida d de los entor nos simulado s y los requeri mie n t o s de tiemp o real de los juegos
moder n os [Nareyek - 04 ].

La búsque da es una de las técnicas más utilizada s para resolver los proble ma s de
pathfinding 1 o planificación que se presen ta n en la inteligencia artificial en los juegos de
vídeo. En particular, la búsque da es utiliza da para resolver el proble m a de la navegación.
De los distintos tipos de algorit m os de búsq ue d a (figura 1 ), los algorit m o s búsq ue d a
heurística completa se encuentr a n amplia me n te difun did o s. Sin dudas, el algorit m o A* es
el algorit m o de búsque da heurística más popular [Stout - 96 ].

1 Es importante mencionar una ambigüeda d en la utilización del término pathfinding en la bibliografía referenciada.
Pathfinding se utiliza para hacer referencia tanto al problema general de encontrar una serie de pasos para llegar a un estado
objetivo partiendo de un estad o inicial, en el contexto de un problema cualquiera, como al problema específico de la
navegación.
 Los algorit m o s heurísticos tradicionales mues tra n limitacione s impor ta n t e s cuan do el
espacio de búsque da es demasia d o grande o existen factores diná micos. En la
navegación, de los juegos de vídeo en tiemp o real, este proble ma aparece cuan d o las
rutas a deter mina r son muy largas, el terreno es modificable o existen muc ho s objeto s
móviles. Bajo esas condiciones, los algorit m o s de búsq ue d a básicos no puede n respo n d e r
en el tiempo requerido y resulta n inadecua d o s. De esta forma, surge la necesida d de
desarrollar nuevas estrat egias de búsq u e d a, que se adap te n a los requeri mie n t o s de
tiempo real de los juegos de vídeo y resuelvan adecua d a m e n t e caminos en condiciones
de incertidu m b r e sobre terre nos de gran extensió n [Laird,Pottinger - 00 ].

Actual me nt e existen dos clases de algorit m o s de búsq u e d a que se adecua n a la

resolución de problem a s con las características mencion a d a s: los algorit mo s de
búsqueda heurística incre me ntales y los algorit m o s de búsqueda heurística en tiempo
real . Los algorit m o s increme n t ales utilizan infor mació n de búsq ue d a s previas para
encont ra r soluciones a proble ma s similares posiblem en t e más rápido que realizan d o
cada búsque d a partie ndo de cero [Koenig - 04 ]. Por otra parte, los algorit m o s de búsq ue d a
en tiempo real alternan planificación y ejecución del plan y restring en la planificación a
la parte del domi nio inmediata al estado actual del agente [Koenig - 01 ].

Aunque ambas técnicas se adapta n a los reque ri mie n t o s de los juegos en tiem p o real,
la idea de dividir la planificación en etapas de duració n limita da parece ser la más
difundi da. Esto se debe a que los algorit m o s de tiemp o real se basan en las estrat egias de
búsque da de profun di d a d limitada utiliza d a s en los proble ma s de juegos de dos
jugadores como el ajedre z, las dama s y el Othello [Brockington - 00 ].

Este trabajo se desarr olla considera n d o los algorit m o s de búsq ue d a heurís tica en
tiempo real. En la sección 2 se presenta n los fun da m e n t o s de la búsq ue d a en tiemp o real.
Esta discusión es carácter general y no se habla de ningún algorit mo en particular. En la
sección 3 se describen los algorit m o s imple me n t a d o s; además, se presen t a n los
resulta do s de las prueba s realizada s para analizar experi me n t al m e n t e el comp o r ta mie n t o
de estos algorit mo s, en un entor no similar al de los juegos de vídeo en tiem po real. Una
parte esencial del proyecto consistió en el desarrollo de la aplicación que proporcio nó la
platafor m a de prueba para los algorit m o s. Todas las imágene s de los ejemplo s
present a d o s en las figuras fueron generad a s con la misma. Los detalles del diseño y la
imple me n t ación de esta aplicación se encuen tr a n en el apén dice. Finalmen te en la sección
4 se encue ntra n las conclusiones y come n ta rios finales.
2. Fundamentos de la búsqueda en tiempo real
La búsque da es una técnica para resolver proble ma s cuya solución consiste en una serie
de pasos que frecuente m e n t e deben deter min a r s e media n te la prueba siste m á tica de las
alter na tivas. Desde los inicios de la Inteligencia Artificial, la búsq ue d a se ha aplicado en
diversas clases de proble ma s como juegos de dos jugadore s, proble m as de satisfacción
de restricciones y proble ma s de pathfin ding de un único agente [Korf- 00 ].

En la figura 1 , se presenta una clasificación de los algorit m o s de búsq u e d a, hacien do

hincapié en su modo de operación, y se incluyen los algorit m o s más represe n t a tivos de
cada clase [Bender - 96 ].

Búsqueda

Completa Parcial – Tiempo Real

off-line on-line

Real-Time A* (RTA*)
Learning Real-Time A* (LRTA*)
Min-max LRTA*

Simple Heurística

Breadth first search Best first search

Depth first search A star search (A*)
Iterative deepening search Iterative deepening A star search (IDA*)

Figura 1: Clasificación de los algoritmos de búsqueda.

Los algorit m os de búsque d a completa 2 tradicionales se caracteriz a n por su modo de

operación off - line , que deter mina que debe encont ra r s e la solución entera en una única
etapa de planificación, antes de comen z a r la ejecución de los pasos o acciones que la
compo ne n (figura 2 ). Es posible utilizar este esque m a de búsq u e d a si se cuenta con la
infor m ación suficiente sobre el proble m a y el tamañ o del espacio de búsq u e d a permite el
cálculo de la solución con los recursos comp u t acion ales dispo nibles.

Planificación Ejecución

Figura 2: Modo de operación off- line.

2 La búsqueda completa puede realizarse sin información o utilizan do conocimiento del dominio del problema, lo que da
lugar a los algoritmo s de búsqued a simple y búsq ue da heurística respectivamen te.
 Hacia fines de los 80' se comen z ó a utilizar concep to s de la búsq ue d a aplicada a
juegos de dos jugadore s en el desarrollo de estrategias para resolver problem a s de
pathfindi ng de un único agente. La idea funda m e n t al que se tomó fue la de intercalar
etapas de planificación (donde se realizan búsq u e d a s de profu n d i d a d limitad a) con
etapas de ejecución (figura 3 ). Este modo de operación se deno min a on- line y da lugar
los algorit m os de búsque da de tiem p o real 3 . Estos algorit m o s de búsq u e d a general son
capaces de respond e r a los requeri mien t o s de las aplicaciones de tiemp o real sobre
espacios de búsque da grande s y en condiciones de incertid u m b r e. Algunos algorit mo s
desarrolla dos con estas características son el Real- Time A*, el Learning Real- Time A* y
el Min- Max Learning Real- Time A*.

Planificación Ejecución Planificación Ejecución ... Planificación Ejecución

Figura 3: Modo de operación on- line.

2.1. Descripción de las fases de la búsqueda heurística en tiempo real

De la discusión anterior se ve que el proceso de búsq ue d a en tiem p o real se lleva a cabo

alter na n do dos modos de operación bastan te distinto s. El primer modo es de
planificación, donde se simulan los movimien to s del agente para evaluar los resulta d o s
de las acciones inmediata s. Luego de termin a r la búsq u e d a, en este espacio acotad o de
posibilida de s, el agente pasa al mod o de ejecución y realiza efectivamen te un
movimiento. El proceso continúa altern a n d o fases de planificación y ejecución hasta que
se alcanz a el estado objetivo [Korf - 90 ].

2.1.1. La fase de planificación

Durante la etapa de planificación, es funda m e n t a l restringir la profu n di d a d de búsq u e d a

para poder respon de r dentr o de los límites de tiemp o impues t o s. Si bien el tiempo de
ejecución de los algorit m os de búsq u e d a es exponen cial respecto a la frontera de
búsque da, la mis ma está acota da por una consta n t e y por lo tanto también lo está el
tiempo de ejecución. Dado que la profu n di d a d de búsq u e d a es limita da, es necesario
contar con un métod o para evaluar los estad os no - objetivos. Es esencial para el
funciona mie nt o de esta estra tegia la utilización de heurís ticas que permi ta n estima r el
costo de alcanz ar un objetivo desde un estad o inter me dio.
3 Los algoritmos de búsq ueda en tiempo real también se conocen como algoritmos de búsq ueda de profun didad limitada,
algoritmos de búsq ue da parcial o local. No existe aún un término común para denominar a estos algoritmo s, aunque
reciente mente se ha prop u esto el de “búsqued a centrada en el agente” [Koenig - 01 ] (que abarca a todos los algoritmos que
intercalan búsqued a y ejecución, incluyend o aquellos que no respon den en tiempo constante que es el requerimiento de los
algoritmos de tiempo real).
 Utilizando una función heurística, extendida median te búsq u e d a, es posible constr uir
una función de evaluación de estad o s que incluya el costo para alcan za r un esta do
deter mi na d o así como una aproximación sobre el costo para encontra r el objetivo desde
ese estado (figura 4 ). Se definen los siguientes costos:
• f(n) es el costo heurístico asociado a un estado n
• g(n) es el costo real para alcanza r un estado n a partir del estado actual 4
• h(n) es el costo heurístico para alcanza r un objetivo desde el estado n
La relación que existe entre los costos es:
f(n) = g(n) + h(n)

Una función heurística h es admisible si las estimacio ne s arroja da s nunca sobresti m a n

los valores reales de los estados evalua do s. La admisibilida d es una propied a d
impor ta n te de la función heurística, y frecuen te m e n t e es requeri da por los algorit mo s de
control para garanti zar un funciona mie n t o correcto.

f = g + h = 5,23
1
1
Estado 1
Inicial

h = 2,23

Estado
g=3 Evaluado

Estado
distancia real: 8 Objetivo

Figura 4: Los componen tes de la función de evaluación de estados para un ejemplo sencillo
Los gráficos corresponden a los estados alcanzad os mediante los movi me n tos simulados.
La heurística utilizada es la distancia euclídea y la profundidad de búsqueda es 3.

Al diseñar el algorit m o de planificación se deben realizar concesiones entre los

recurso s compu t a cionale s invertidos y la precisión de las evaluaciones devueltas. La
función heurística h en conjunto con la búsq ue d a de profu n di d a d limitada se consideran
una sola función heurística f . La precisión de los valores obtenido s dura n te la
planificación aumen ta al incre me nt a r la profu n di d a d búsq u e d a, pero al mis mo tiemp o el
costo de ejecución aume nt a exponencialm e n t e. De esta forma, se obtiene toda una gama
de funciones de evaluación heurísticas que interca m bia n precisión por costo [Korf- 00 ].

4 En general, el costo entre dos estados vecinos puede ser fijado arbitrariamen te. En adelante se supon d rá un costo de una
unidad para pasar de un estado a cualq uier estado vecino.
 2.1.2. La fase de ejecución

Uno de los principios más importa n t e s de la búsq ue d a en tiem p o real es la utilización de

la estrategia del menor compr o mi s o para los movimien t o s. Es decir, la inform ación
obtenida en cada etapa de planificación sólo se utilizará para deter mi n ar el próximo
movimiento. La razón es que luego de ejecutar la acción, se supo ne que la fronter a de
búsque d a se expan dirá, lo cual puede llevar a una elección para el segun d o movimien t o
diferente a que la que arrojó la primera búsq u e d a.

Sin embargo, para realizar una secuencia de decisiones no es suficiente con la

infor m ación devuelta por el algorit m o de planificación. La estrategia básica de repetir el
algorit m o de planificación para cada decisión resulta inadecua d a al ignorar la
infor m ación relaciona da con los estado s anteriore s. El proble m a radica en que, al volver a
un estado previa me n te visitado, se entrará en un ciclo infinito. Esto es algo que sucederá
con frecuencia, debido a que las decisiones se basan en infor mació n limita da y por lo
tanto direcciones que al principio parecían favorables puede n resulta r equivocadas al
reunir más inform ación durant e la exploración. En general, se desea evitar entrar en
ciclos infinitos y a la vez permitir volver a estados ya visitados cuand o parezca favorable.

El principio para resolver el problem a del control de la etapa de ejecución es: sólo se
debería regresar a un estado visitado cuando la estimación de resolver el proble m a desde
ese estado más el costo de volver al mis mo es menor que el costo estimado de seguir hacia
adelante desde el estado actual . Los primero s algorit m o s en imple me n t a r esta solución
fueron el Real- Time A* y una variante llamad a Learning Real - Time A* [Korf - 90].

3. Análisis e implementación de los algoritmos RTA* y LRTA*

El estudio se centró en el análisis e imple me n t a ción de los dos algorit m o s más conocidos
para el control búsque da de tiem po real, el Real- Time A* (RTA* ) y el Learning Real- Time
A* (LRTA* ); como la función de evaluación o algorit m o de planificación se implem en t ó el
algorit m o Minimin . Con este fin, se desarrolló una aplicación que propo rcio na un entor n o
similar al de un juego en tiempo real. El entorn o de navegación consiste en un espacio
discreto de dos dimensione s en forma de grilla, deno mi n a d o gridworld . Al utilizar un
entor no tan simple se evita el análisis de terreno , que consiste en la extracción de
infor m ación útil y manejable de un modelo complejo de terren o [Pottinger - 00 ].
3.1. Los algoritmos utilizados

En esta sección se describen y prese n t a n las caracterís ticas principales de los algorit mo s
que se utilizaron para la planificación y el control de la navegación.

3.1.1. El algoritmo de planificación: Minimin

Minimin [Korf - 90 ] es un algorit m o búsq ue d a de profu n di d a d limitada que se emplea

dura nt e la etapa de planificación. La búsq ue d a se hace a partir del estado actual hasta
una profun di da d deter mi na d a y en los nodos de la fronter a se aplica la función de
evaluación f . El valor de cada nodo intern o es el míni mo de los valores de los nodos de la
frontera del subárbol debajo del nodo (figura 5 ).

5,23

∞ 5,23

∞ 5,23

g=3 g=3
h=3 h = 2,23
6 5,23
profundidad de búsqueda: 3

Figura 5: Ejemplo de la asignación de valores a los estados intermedios realizada por el algoritmo Minimin.
Los gráficos corresponden a los estados alcanzad os mediante los movi me n tos simulados.
La heurística utilizada y el estado objetivo son los mismos que los del ejemplo de la figura 4.

Si la función heurística h es monót o n a no decreciente, es posible aplicar branch - and -

bound . El algorit m o resulta nt e se deno min a poda alfa por analogía con el algorit m o alfa -
beta . De esta forma, se añade un pará me t r o alfa que será el mínimo valor f de los nodos
de la fronter a evaluados hasta el mome n t o. Cuando se genera cada nodo interno se
calcula su valor f , si el mis mo iguala o supera el valor de alfa se termina la rama de
búsque da corres pon die n te. Es más, si se ordenan los esta do s expan did o s de mod o que
los mejores nodos de la fronte ra sean evalua do s primero, será posible reducir
considerable me n t e la búsque da al mejorar la eficiencia de la poda.
 3.1.2 Los algoritmos de control de la ejecución

• Real- Time A*

RTA* [Korf- 90 ] es un algorit m o de para controlar la fase de ejecución de la búsq ue d a

en tiempo real, y es indepen die nt e del algorit m o de planificación. El algorit m o guarda
el valor de cada estado visitado duran te la etapa de ejecución en una tabla de hash. A
medida que la búsque da avanza se actualiza n estos valores utilizan d o técnicas
derivadas de la progra m a ción diná mica [Koenig - 01 ].

El proceso de búsque da que realiza el algorit m o es el siguien te:

• A los estados que no fueron visitados se les aplica la función de evaluación
heurística, posibleme nte extendida mediante una búsqueda.
• Para los estados que se encuentra n en la tabla se utiliza el valor heurístico h
guardado en ella.
• El vecino con el menor valor f es elegido para ser el nuevo estado actual y la
acción para alcanz ar ese estado es ejecutada.
• El anterior estado actual se guarda en la tabla y se le asocia el segundo mejor
valor f de los vecinos más el costo para regresar al mis mo desde la nueva
posición.

La propieda d más importa n t e de RTA* es que, en espacios finitos y si el estado

objetivo se puede alcanz a r, se garanti za que se encontra r á una solución. Además, el
espacio requeri do es lineal respecto al nú mero de movimien to s realizad o s, ya que sólo
lleva una lista de los estados previame n t e visitado s. El tiemp o de ejecución también es
lineal respecto a los movimien tos ejecuta d o s. Esto se debe a que, aunq u e el tiemp o de
planificación es exponencial respecto a la profu n di d a d de búsq u e d a, el tiemp o esta
acotado por una consta n te al limitar la profu n di d a d de búsq u e d a.

• Learning Real- Time A*

LRTA* [Korf- 90 ] es una versión del RTA* con apren di z aje. LRTA* es un algorit m o
eficiente para resolver proble m a s de búsq u e d a donde el estado objetivo es el mismo. El
algorit m o tiene la propieda d de que con las sucesivas resolucione s de un proble m a los
valores heurísticos convergira n a los valores exactos de los caminos óptim o s.

LRTA* se compor t a en forma similar que RTA*, sólo cambia la forma en la que se
guarda n los valores en la tabla (figura 6 ). En vez de guarda r el segun d o mejor valor f , la
tabla se actualiza con el mejor valor f . Entonces, cuando un proble m a es resuelto, se
guarda n los valores heurísticos y estos se convierten en los valores iniciales para la
próxima instancia del proble ma
Fig u ra 6 : Com para ción d e la form a en qu e se a ctu a liz a n
los v alores h eu rísticos, a l rea liz a rse la tra n sición d e f1
estados, en los alg oritm os RTA * y LRTA *.
Estado Segundo
f2 f3
Actual
mejor

f4 Mejor

RTA* LRTA*

f1 Segundo mejor f + 1 f1 Mejor f + 1

Estado Estado
f2 Anterior f3 f2 Anterior f3
f3 + 1 f4 + 1

Estado Estado
Actual Actual

A qu í se m u estra com o fu n cion a n los a lg oritm os RTA * y LRTA * p a ra la resolv er d el ca m in o d el ejem p lo qu e se v ien e
desarrollan do. Los n ú m eros celestes son los v a lores h eu rísticos a sig n a d os a la s p osicion es p or el a lg oritm o Min im in d u ran te
la etapa de plan ifica ción . Los n ú m eros n eg ros son los v a lores h eu rísticos g u a rd a d os en la ta b la p a ra la s p osicion es v isitadas
du ran te la ejecución d e los m ov im ien tos.

RTA*

LRTA*

3.2. Detalles de la implementación del control de la navegación

Al diseñar la aplicación, se decidió modelar en forma separa d a los comp o n e n t e s lógicos y

los compone n t e s que los controlan (ver apéndice ). La clase Simple_Token describe los
element o s lógicos con la capacida d de moverse y la clase Simple_Controller define un
tipo de controla dor, que le per mite a la comp u t a d o r a dirigir el proceso de navegación de
los element os asociados (figura 7 ).

La clase Simple_Controller toma las decisiones de más alto nivel en el proceso de

navegación: deter mina una posición de destino y le orde na al elemen t o asociado que se
mueva en una dirección deter mi na da. Este proceso se imple me n t a en el méto d o update
que será llamado periódica m e n t e (figura 8 ). La elección del movimien t o se realiza a
través de un pathfinder o buscador , indepe n di z a n d o al controla d o r de la estrategia de
búsque da elegida.

El proceso de búsque da en tiempo real está imple me n t a d o en la clase Pathfinder . Los

buscadore s mantiene n las estruc t u r a s de los algorit m o s de ejecución y realizan la
planificación. El método get_move imple me n t a los algorit m o s RTA* y LRTA* (figura 9 ). El
método mini min imple me n t a el algorit m o de búsq ue d a Minimin con poda alfa, que se
utiliza para la evaluación de estado s (figura 10 ). Un aspecto relevante de la
imple me n t ación de estos métodos es la forma en la se utilizan los valores heurís tico s
guarda d os, que difiere un poco a lo descrip to en la sección anterior. La tabla de hash
h_values es actualiza da en el método get_move , pero es en el méto d o mini min que se
utilizan sus valores en reem pla z o de la función heurística siem p re que sea posible.

Figura 7: Diagra m a de clases de los componentes de la aplicación que implementa n el control de la navegación

void Simple_Controller::update (void) {

// si no hay un objetivo, elegir como nuevo objetivo aquel que se encuentre más cerca
if current_goal == 0
min = ∞
for each: goal in: goals
d = distance (token->get_x(), token->get_y(), goal->get_x (), goal->get_y ())
if d < min
min = d
current_goal = goal
if current_goal != 0
pathfinder.set_current_goal (current_goal)

if current_goal != 0
// verificar si se alcanzó la posición de algún objetivo
isgoal = false
for each: goal in: goals
if is_goal (token->get_x(), token->get_y(), goal->get_x(), goal->get_y())
isgoal = true
current_goal = goal
if isgoal
// si se alcanzó un objetivo se destruye el mismo
current_goal->destroy ()
current_goal = 0
else
// sino, se ejecuta un nuevo movimiento en la dirección del objetivo actual
move = pathfinder.get_move ()
token->perform_action (move)
}

Figura 8: Pseudocódigo del método Simple_Controller::update que imple me n ta el control global del proceso de navegación.
string Pathfinder::get_move (void){
action = ""
best = second_best = alpha = ∞

position = new Position (token->get_x(), token->get_y())

visited.insert (position)

get_ordered_moves (moves)
for each: move in: moves
token->perform_action (move)
f = minimin (0, alpha, visited)
token->undo_action (move)
if f < best
second_best = best
best = f
action = move
else
if f < second_best
second_best = f

if RTA*
p.h = second_best + 1
else // LRTA*
p.h = best + 1

h_values.erase (p)
h_values.insert (p)

return action
}

Figura 9: Pseudocódigo del método Pathfinder:: get_move que impleme nta los algoritmos de control RTA* y LRTA*

float Pathfinder::minimin (float g, float & alpha, hash_set<Position> & visited){

if Simple_Controller::is_goal (token->get_x(), token->get_y(), goal->get_x(), goal->get_x())
if g < alpha
alpha = g
return g
else
position = new Position (token->get_x(), token->get_y())
pos = h_values.find (position)
if pos != h_values.end ()
if pos->h + g < alpha
alpha = pos->h + g
return pos->h + g
else
h=Simple_Controller::distance(token->get_x(),token->get_y(),goal->get_x(),goal->get_y())
if (g >= depth) || (h + g >= alpha)
if h + g < alpha
alpha = h + g
return h + g
else
minimum = ∞
visited.insert (position)
get_ordered_moves (moves)
for each: move in: moves
token->perform_action (move)
neighbor = new Position (token->get_x (), token->get_y ())
if visited.find (neighbor) == visited.end ()
f = minimin (g + 1, alpha, visited)
if f < minimum
minimum = f
token->undo_action (move)
visited.erase (position)
return minimum
}

Figura 10: Pseudocódigo del método Pathfin der::mini min que imple me nta el algoritmo de planificación Minimin
3.3. Análisis del comportamiento de los algoritmos

El análisis consistió en la observación del compo r t a mie n t o de los algorit m o s en

laberintos genera dos mediante la aplicación. Los laberint o s son de distin to s tamañ o s e
incluyen obstáculos estáticos y móviles, y pueden ser modificado s diná mica m e n t e. Tanto
el RTA* como el LRTA* fueron proba d o s con distin to s límites de profu n di d a d para el
algorit m o Minimin y utilizan d o la distancia euclídea como función heurística.

Se realizó una compara ción entre el RTA* y la primera instancia de resolución del
LRTA* en varios laberint os. En general se vió que el RTA* tiene un desem p e ñ o mucho
mejor. Esto se debe a que el LRTA* guarda valores meno res para los estado s visitado s y
por lo tanto tiende a volver a ellos con más frecuencia.

Por otra parte, la calidad de las soluciones de LRTA* tiende n a mejorar notable me n t e
en pocas repeticiones de la resolución del mismo camino. Esto no se da siem p re ya que,
cuando la frontera de búsque da es peque ñ a y los laberin to s son relativa me n te
complicados, el costo de las soluciones tarda varios ciclos en estabilizars e cerca del
óptimo.

Respecto a la variación de la profu n d i d a d de búsq ue d a se tuviero n resulta d o s que van

en contra de lo que se esperaba. Al aumen ta r la profu n di d a d de búsq ue d a y contar con
evaluaciones más precisas mejoran alguno s aspecto s del compo r ta m ie n t o de la
navegación, pero no siempre aume nt a la calidad de la solución. En general, depen dien d o
del laberinto y el camino a resolver, contar con una función de evaluación más precisa no
lleva a que el RTA* o una primera instancia del LRTA* ejecute menos movimien t o s.

El proble ma es que el agente vuelve a posiciones ya visitadas con mucha frecuencia,

aunq ue la dirección que llevaba era la correcta. Un primer análisis per mitió observar que
los valores heurísticos guarda do s son parte de la función evaluación de estad os, y que la
única forma en la que los algorit m o s básicos puede n actualizar estos valores es
visitándolos otra vez. Cuando las evaluaciones iniciales están por debajo de los valores
exactos el proceso de búsque d a se vuelve prope n s o a regresar a esos estados. Así se
recorrerá n zonas ya visitadas sólo para subir los valores heurísticos asignad o s y ajustar
la diferencia. Como ya se señaló, el algorit m o LRTA* guarda valores heurístico s menore s,
en compa ración con el RTA*, y por lo tanto sufre mucho más de este problem a.

Después de una investigación más profu n d a del proble m a, se encont ró un trabajo en

el que se aplica la búsque da en tiemp o real a la navegación y búsq u e d a de objetivos
móviles [Ishida - Korf- 95 ]. Allí se discu te el proble ma expues to y se lo denomina
“depresión heurística”. El proble m a de la depresión heurística consiste en la for mación
de regiones que son asigna da s valores heurísticos meno res que los exactos y queda n
limitadas por regiones de valores más elevados. Cuando se forma una depresió n
heurística, el proceso de búsq ue d a queda estanca d o mome n t á n e a m e n t e en las posicione s
de esta región, hasta que los valores asignado s a las mism as iguala a los valores del
límite de la depre sión. Una forma de solucionar el proble ma es identificar la formació n
de una depresión y actualiz ar los valores de la región median te una búsq ue d a off- line.

Por otra parte, se compr obó una mejora muy importa n t e en la perfor m a n c e del
algorit m o Minimin con poda alfa, respecto a la versión sin poda (figura 11 ). Esta
optimi za ción, en conjunto con el orde na mie n t o de los nodos, es de extre ma impor ta ncia
para tener buenos tiempos de respue s t a, sin sacrificar demasia da precisión en las
evaluaciones.

Sin pod a Con poda alfa

Figura 11 : Comparación de los estados expandidos durante la planificación por el algoritmo Minimin, sin realizar podas y
utilizando branch - and - bound o poda alfa y ordena miento de nodos. La frontera de búsqueda es 10.

Las prueba s en entor nos diná micos fueron bastan t e satisfactorias con ambos
algorit m os. La estrategia de tener en cuenta sólo los cambios más cercano s al estado
actual parece ser basta nte buena, sobre todo en entorn o s dond e hay una cantidad elevada
de element o s diná micos. En general, si los obstáculos móviles no son extre ma d a m e n t e
difíciles de sortear, los movimient o s realiza d o s eventual m e n t e se coordina n para
supera rlos.

En la figura 12 se compa ra n los algorit m o s RTA* y LRTA* utilizan d o distin ta s

profun di da d e s. En este caso particular, es posible ver algunos de los resulta d o s
present a d o s. En este ejemplo, se muest ra n las posiciones que visita cada algorit m o junto
con los valores heurís ticas asigna dos, y se indica aproxima d a m e n t e la máxima extensión
que alcanza la zona de depre sión heurística en los casos donde es posible observar el
fenómeno con claridad.
Profundidad 0 – Movimientos 102 Profundidad 0 – Movimientos 104

Profundidad 5 – Movimientos 74 Profundidad 5 – Movimientos 410

Profundidad 10 – Movimientos 116 Profundidad 10 – Movimientos 398

RTA* LRTA*
Figura 12 : Valores asignados a las posiciones visitadas para la mism a búsqueda utilizando la profundidad de búsqueda y
realizando el número de movi mientos indicados. El nú mero de movi mientos óptimo es 46. La posición de salida es siempre la
esquina superior izquierda y el destino es el casillero con el marco rojo. La heurística utilizada es la distancia euclídea.
En los casos que corresponde, se indica aproxim ad a m e n te la máxim a extensión de la zona de depresión heurística.
4. Conclusiones
La experiencia de implem e n t a r los algorit m o s y el análisis realiza do per mitió ganar una
compre n sió n mucho mayor del tema de búsq ue d a en general y, por sup ue s t o, de los
algorit m os de búsque da en tiem po real. Con la infor m ació n recopilad a dura n te el estu dio
de las técnicas de búsque da y los juegos de vídeo, y junto con los resulta d o s obtenid o s
dura nt e los experime n t o s realizados, se puede concluir que los algorit m o s de búsq ue d a
en tiempo real constit uyen una alterna tiva viable para la navegación en el context o de los
juegos de vídeo en tiempo real. Sin embargo, se ve son necesarias técnicas y estrategias
adicionales para poder obtener solucione s de la calidad requerid a por este tipo de
aplicaciones.

En muchos casos el compor ta mi e n t o de los algorit m o s implem e n t a d o s fue aceptable.

En particular, la navegación en entorn o s dinámicos resultó satisfacto ria. Sin embarg o, se
observó que los algorit m os presen ta n alguno s inconvenie n te s. El proble ma más
impor ta n te lo constituye la formació n de regiones de depresió n heurística. Este
fenóme no lleva a que la búsque d a se estan q u e en una región dura n te un tiemp o
considerable. Lo peor es que esto sucede con frecuencia, sobre todo cuando se utiliza el
algorit m o LRTA*. Una alterna tiva para de solució n es la utilización de búsq ue d a s off -
line, que eviten la necesidad de regresar innecesaria m e n t e a regiones ya visita das. En el
contexto de la navegación en los juegos de vídeo, el comp o r t a m ie n t o de los algorit m o s
puede ser mejora do considerable m e n t e. En este sentido, muchas de las técnicas
utiliza da s para mejorar el dese m pe ñ o de los algorit m o s tradicionales como el A* [Pinter -
01 ] podrían ser adapta d a s para que funcione n con el RTA* y el LRTA*.

Es impor te mencionar que la aplicación desarrollad a, en la cual se encue nt ra n

imple me n t a d o s los algorit m o s estudia d o s, se convirtió en un proyecto open source. En
realidad, esta fue una idea que surgió al comien z o del proyecto y se decidió llevar
adelante debido a los resulta do s resulta d o s satisfacto rio s obtenid o s con la misma para
demos t r a r el funciona mie n t o de la búsq u e d a en tiem po real. El proyecto se encuen t ra en
SourceForge.net bajo el nombre de “Simple Real Time Search for Pathfinding ”. El enlace
es: sourceforge.net / p r ojects / r ts - simple . Además de subir el código, se planea incluir
docu m e n t ación relaciona da y hacer disponibles todas las extensio ne s que se realicen
sobre este trabajo.
 Apéndice – Diseño e implementación de la aplicación

A.1. La arquitectura
La aplicación fue desarrollada tenien d o como premisas principales de diseño la
flexibilida d y expansibilidad. Para conseguirlo se crearon una serie de clases que abstrae n
las características y compor t a mi e n t o comú n de los juegos en tiemp o real que se
desarrollan en laberint os de dos dimensio n e s. Este conju n to de clases describe n una
arquitect ur a para la aplicación muy simple que se describe a contin uació n.

Lo primero que se identificó fue la existencia de comp o n e n t e s que concept u al me n t e

son indepe n die n te s. Los compo ne n t e s principales que se consider an son los elemen t o s
que constit uye n la lógica (por ejemplo el jugado r, los enemigos, las parede s del laberinto,
etc) y los element os visuales (como las animacione s y efectos). Además, como parte de la
lógica se distingue n los elemento s lógicos pro pia m e n t e dichos y los comp o n e n t e s que
deter mi na n su compor ta m ie n t o y los controla n (como los mód ulos de la inteligencia
artificial). Todos estos compo ne nt e s estan relaciona d o s ya que deben trabajar en
conjun to; sin embargo es deseable que exista cierta indepe n d e n cia entre ellos. Esto se
consigue modelan d o la lógica, el control y la visualización en forma separa d a. La clase
Base_Token modela los atribut os y compo r t a m ie n t o de estado comú n que poseen estos
compo ne n t e s, e imple me nt a un mecanis mo para comu nica rlos a través de los méto d o s
del patrón observador [Gam m a - 94 ]. La intención es definir a partir de esta clase a el
resto de las clases que modelan la lógica, control y visualización.

Figura A.1: La clase base los elementos lógicos, los controladores y los elementos visuales

La arquitect ur a incluye los compon e n t e s funda m e n t a les que constit uyen la lógica del
juego. A través de las clases Logic_Token y Action se logra desaco plar de los elemen t o s
lógicos los coman do s o acciones median t e los cuales modifican su estad o o el estado de
su entor no (este mecanis m o constituye el patró n coman d o [Gam m a - 94 ]). La clase Space
represe nt a a una estruc t ur a que per mite el acceso a los elemen to s lógicos a través de su
posición.
 Figura A.2: Los componen tes de la lógica modelados en el fra mew ork

La visualización fue un aspecto secun d a rio y esto llevó a que sólo se añadiera un
sopor te míni mo para la visualización de animacio nes a través de la clase Anima tion . Sin
embargo, extende r esta parte del siste m a debería ser fácil porq ue el resto de los
compo ne n t e s son indepe ndie nt e s de la represe n tación gráfica.

Figura A.3: Los componentes de la visualización modelados en el frame work

A.2. La aplicación
El desarrollo de la aplicación consistió funda m e n t al m e n t e en comple tar la definición de
las clases abstracta s introd uci das en la arquitect u ra general descrip ta. De esta forma se
introd uje r on varias clases que definen el comp o r ta mi e n t o y atribu t o s de los elemen t o s
lógicos (Simple_Token), de control (Automove /Player /Si m p le_Cont r oller) y visualización
(Simple_Anima tion) específicos.

Figura A.4: Los clases introducidas por la aplicación para instanciar el fra mework

En lo que respecta a la lógica es impor ta n t e remarcar que objeto s lógicos tan diversos
como los enemigos, las parede s y diama n t e s son todos instancias de la clase
Simple_Token . Esto se debe a que los atribu t o s estáticos (como la posición) son
esencialme nt e los mismos para todos. Lo que cambia es el compo r ta mi e n t o y esto se
modela mediante la asociación diná mica de las acciones y los controla d o re s.

Hay muchas ventajas al trabajar con el bajo nivel de acopla mie n t o presen t e entre los
compo ne n t e s lógicos, el control y la visualizació n. En la aplicación esto per mitió
imple me n t a r un siste m a de configuración median te script s muy flexible.
A.3. Detalles de la implementación

El lenguaje de progra m ación en el que se desarr olló la aplicación es C+ + stan da r d. La

idea es que la aplicación corra en varias platafor m a s, por eso todas las librerías
utiliza da s son multi - platafor m a. El compila do r utiliza d o es el de la Gcc (versión 3.x.x),
pero deberían poder utilizarse otros sin necesidad de realizar modificaciones al código.
Las platafor m a s probada s hasta el mo me n t o son Linux (que es la platafor m a de
desarrollo principal) y todas la versiones de Windows (9x y NT) (utilizan d o el port de la
Gcc provisto por la MinGW).

Las librerías que se utilizan son:

• Lua: Motor de scripting.

www.lua.org

• SDL (Simple Media Layer): Multime dia (video, sonido, entra da, eventos, thread s).

www.libsdl.org

• STLport : Impleme n t a ción portable de la STL (Standar d Template Library) de C++.

www.stlpor t.or g
Bibliografía
[Bender - 96] “Mathe m a tical Methods in Artificial Intelligence ”
Edward A. Bender (IEEE Comp u te r Society Press and John Wiley –
Enero 1996)

[Brockinton - 00] “Pawns Captures Wyvern: How Computer Chess Can Improve Your
Pathfinding ”
Mark Brockingto n (Game Developer Conference – 2000)

[Gamma - 94 ] “Design Patterns. Elements of Reusable Object - Oriented Software ”

Erich Gamma, Richad Helm, Ralph Johnso n, John Vlissides
(Adisson - Wesley – 1994)

[Ishida,Korf - 95] “Moving - Target Search: A Real- Time Search for Changing goals ”
Toru Ishida, Richard E. Korf (IEEE Transaction s on Pattern Analisys
and Machine Intelligence, 17 – Junio 1995)

[Koenig - 01] “Agent - Centered Search ”

Sven Koenig (Artificial Intelligence Magazine, 22 – 2001)

[Koenig - 04] “Incre me ntal Heuristic Search in Artificial Intelligence ”

Sven Koenig, Maxim Likhachev, Yaxin Liu, David Furci (Artificial
Intelligence Magazine – 2004)

[Korf - 90] “Real- Time Heuristic Search ”

Richard E. Korf (Artificial Intelligence, 42 – Marzo 1990)

[Korf - 00] “Artificial Intelligence Search Algorith m s ”

Richard E. Korf (Agosto 2000)

[Laird,Pottinger - 00] “Game AI: The State of the Industry, Part Two ”
John E. Laird, Dave C. Pottinger (Gamasu t r a – Noviemb re 2000)

[Nareyek - 04] “AI in Computer Games ”

Alexander Nareyek (Game Develop me n t Vol 1, 10 - Febrero 2004)

[Pinter - 01] “Toward More Realistic Pathfinding ”

Marco Pinter (Gamasu t r a – Marzo 2001)

[Pottinger - 00] “Terrain Analysis in Realtime Games ”

Dave C. Pottinger (Game Developer Conference – 2000)

[Stout - 96] “Smart Moves: Intelligent Pathfinding ”

Bryan Stout (Game Developer Magazine – Octubre 1996)

[Underger - 01] “Real- Time Edge Follow: A New Paradig m to Real- Time Search ”
Cagatay Underger, Faruk Polat, Ziya Ipekkan (2001)

Links
www.gamas ut r a.co m
www.gamedev.net
www- cs - studen t s.s t a nfo r d.e du / ~ a m i t p / g a m e p r o g. h t m l