Artículos

AiGameDev entrevista a Dmitriy Iassenev, el auténtico cerebro de A-Life

Desde que se anunció, S.T.A.L.K.E.R. no ha dejado de capturar la imaginación de los jugadores más ansiosos, deseosos de un mundo poblado y dirigido por el sistema A-Life. Este título además, ha llamado mucho la atención a los chicos de AiGameDev, en donde os recordamos que S.T.A.L.K.E.R. consiguió importantes menciones en los Premios por la IA del 2007. Esta vez AiGameDev nos propone una entrevidsta exclusiva con Dmitriy Iassenev, la mente que está detrás de la IA y el sitema A-Life en S.T.A.L.K.E.R., quien ha aceptado responder algunas preguntas sobre la IA y su implementación.

Haciendo click en Leer Más..., podéis leer la entrevista traducida al castellano.

Os informa el enviado especial a la Zona

Alex Champandard: Hola Dmitriy. Gracias por prestarnos algo de tu tiempo para contestar estas preguntas. ¿Puedes contarnos algo sobre ti y repasar un poco tu historial en cuanto a Inteligencia Artificial y Desarrollo de Videojuegos se refiere?

Dmitriy Iassenev: Hola Alex. Actualmente trabajo como Desarrollador Jefe con GSC Game World en S.T.A.L.K.E.R.: Clear Sky.

Lo primero que supe sobre la Inteligencia Artificial en los videojuegos fue en mi curso sobre IA en la Universidad. El interés provocado por ese curso, hizo que crear un programa que podía jugar al reversi; no fue de lo mejor, a pesar de que ganase un campeonato de juegos sincronizados-aleatoriamente (los oponentesjuegan en ambos negro y blanco simultaneamente, una vez acaban el ganador se determina por la suma de resultados). Después de graduarme en 2002, empecé a trabajar para GSC Game World como programador en la IA de S.T.A.L.K.E.R.: Shadow of Chernobyl.

AC: Una de las características clave para S.T.A.L.K.E.R. es el sistema A-Life. ¿Puedes darnos tu opinión sobre la esencia de A-life, y como puede aplicarse?

DI: La esencia de A-life es que los personajes en el juego puedan vivir su propia vida y estar ahí todo el tiempo, no solo cuando están en el campo de visión del jugador. Va en contra de los conocidos procesos de optimización para el desarrollo de videojuegos (¿porqué realizar tareas que el jugador no puede ver?). Todo esto hace necesario que un sistema así, solo se use cuando se sabe realmente hacia donde queremos llegar al finalizar el desarrollo. En nuestras ideas, decidimos que los personajes no debían vivir solo en ciertos niveles, sino moverse entre ellos, memorizando información que han adquirido durante su existencia. Por lo tanto, hemos decidido que cada personaje debería actual solamente alguna motivación independientemente del nivel en el que esté; que es lo que intentamos hacer a través de ciertos métodos.

AC: Juego y simulación son conceptos que en ocasiones pueden llegara confundirse. ¿Hasta qué punto habéis meditado en esto mientras implementáis el motor A-Life en S.T.A.L.K.E.R.?

DI: Nuestra implementación de A-life no pretende ser completa, y mucho menos pura. El concepto de un mundo vivo, en el que los personajes tienen su propio objetivo, es muy amplio y complicado a la vez. Además, su realización es una labor muy complicada, especialmente si hablamos de shooters, con sus detalles durante los enfrentamientos, y en los cuales normalmente buenos gráficos y animaciones dan más puntos que la forma en la que toman decisiones los personajes.

AC: ¿Puedes contarnos algo más sobre como has implementado A-Life?

DI: Nuestra implementación de A-Life es muy sencilla. Hemos introducido dos conceptos que caracterizan otras dos patrones de comportamiento en los personajes: OffLine y OnLine. El comportamiento OffLine es muy sencillo: el personaje no ejecuta animaciones o sonidos, no administra su inventario de forma activa, no viaja por caminos detallados (aunque se mueve correctamente por el mapa, pero os diré más luego), etc.. Por otro lado, el comportamiento OnLine está repleto de detalles. Por lo tanto, el comportamiento OffLine puede considerarse como la versión LoD (Baja en Detalles) del OnLine.

En nuestro sistema a la vez que el jugador actúa en un nivel, los demás personajes viven en otros niveles, en modo OffLine y utilizando por lo tanto el comportamiento OffLine. Además, considerando la elevada densidad de personajes en un nivel, no todos los personajes que estén en el nivel del jugador estarán en modo OnLine, sino simplemente aquellos que estén en un radio pre-establecido del jugador (puede variar según cada nivel, pero normalmente está fijado en los 150 metros), o aquellos que hayan sido definidos por los diseñadores. Para obtener este resultado, el sistema A-Life sigue los pasos del jugador y de los personajes OffLine, y cambia los estados OnLine/OffLine según convenga.

Por útlimo, cabe mencionar el movimiento de los personajes en los modos OnLine y OffLine. Nuestro juego tiene varios niveles, y cada uno de ellos tiene gráficas de navegación hechas y utilizadas por los personajes para el movimiento en modo OnLine; las llamamos gráficas detalladas. Por cada gráfica, se crea otra menos detallada, para que los vértices de cada gráfica estén conectados con los de otros niveles. Esta es la gráfica utilizada por los personajes durante el movimiento OffLine. Por ejemplo, si un personaje OffLine decide moverse por el nivel o desplazarse a otro, buscará un camino por el mapa global, por lo que usará los gráficos detallados de su nivel para crear un camino que le lleve de su posición a otra del mapa global. Si ese punto está en otro nivel, el personaje se teletransportará allí y pasará al modo OffLine. Para prevenir que el jugador pueda ver eso, hemos colocado estos puntos lejos de las zonas de transición habituales, en las esquinas de los mapas.

AC: ¿Cuáles son los otros puntos importantes en el desarrollo de A-Life en S.T.A.L.K.E.R.?

DI: Todo personaje en el juego tiene un objetivo: descubrir los misterios de la Zona. En las primeras versiones del simulador, los personajes conocían uno o varios comerciantes, que tenían una serie de misiones que generaban basadas en un mapa con actividad anómala y peticiones por parte de las Facciones, las cuales quieren enriquecerse con la búsqueda de artefactos en la Zona. Al finalizar una misión, lleva cada personaje un poco más cerca de su objetivo. Solo había un tipo de misión “Consigue el Artefacto”. El personaje decidía tomar esa misión para ir en búsqueda de un artefacto, se dirige hacia algún lugar donde posiblemente pueda encontrar el artefacto, y si conseguía dar con el artefacto, lo llevaba de vuelta al comerciante, regatea con él para obtener los mejores beneficios, y toma una nueva misión. En su camino podrá toparse con enemigos y luchar contra ellos. En el Modo OffLine esto se simulaba a través de un Sistema de Turnos (Turn-Based System – TBS): el oponente utiliza un turno para realizar algún movimiento, el resultado se basa en una fórmula y otros factores aleatorios. El resultado es que el oponente podía escaparse del otro, a veces ese personaje moría, y otras veces no se dan cuenta los unos de los otros o deciden evitar la confrontación. Si el personaje era un stalker o se topaba con un neutral o un amigo, comercian entre si, guiados por un determinado esquema de comercio. Todo esto se hace en ambos modos OffLine y OnLine. Para avisar al jugador de la actividad OffLine, utilizamos un sistema de noticias, que se generaban si algún personaje informaba sobre algún evento o sus consecuencias.

Se había planeado que el número de los tipos de misiones aumentaría, y el comportamiento de los personajes se diversificaría debido a la introducción de algunas necesidades como comer o dormir. También se planeó que nuestros personajes podía descubrir los misterios de la Zona antes del jugador, o al menos recopilar cierta cantidad de información.

Luego cambiamos la forma en la que se generaban las misiones. Los personajes ya no recibían las misiones desde los comerciantes, sino a través de “Terrenos Inteligentes” (Smart Terrains). Ahora la vida de los personajes se desarrollaba de forma que, cuando tomaba una misión generada por algún terreno inteligente, caminaba hasta la posición que se le había asignado. Después de llegar allí, tomaría ciertos puntos, y el terreno inteligente le tendría bajo control durante un tiempo. Bajo el control de un terreno inteligente, el personaje hace prioritarias y lleva a cabo las tareas disponibles. Así es como el juego puede tener Bases de las Facciones, stalkers alrededor del fuego, y ese tipo de cosas.

Esto significa que, la migración de personajes de un sitio a otro, su movimiento entre niveles, todo es causa de cambios en sus objetivos.

AC: ¿Cómo pueden unir estas ideas con las IA en niveles inferiores?

DI: Deberíamos tomar los dos modelos de IA: OffLine y OnLine; que a pesar de ser tan distintos tienen puntos en común.

La IA OffLine es muy sencilla: si no hay objetivos, trata de buscarte uno. Si no puedes dar con misiones, plantéate ir a otro lugar. Si hay una misión, ve al sitio donde podrás cumplir con ella. Cuando un personaje está bajo control del Terreno Inteligente, puede obtener comandos adicionales para el movimiento, pero no podrá realizar muchas más acciones.

La IA OnLine trabaja en tres perfiles:

• búsqueda y proceso de información
  
• tomar decisiones
  
• un conjunto de controladores de nivel bajo
  

Un personaje tiene tres tipos de receptores: visión, sonido y daño. Con la información que recibe de los receptores, el personaje sabe que alrededor suyo hay enemigos, amenazas u objetos que pueden recogerse.

AC: ¿Cómo toman decisiones los personajes en S.A.T.L.K.E.R.?

DI: El modelo de toma de decisiones ha sufrido muchos cambios durante el curso de su desarrollo. Hubo cuatro cambios de rumbo en total. Primero, usamos un FSM de montón escrito a mano. Después cambiamos a FSM jerárquico, entonces leí el extraordinario artículo GOAP ( Planificación de Acción Orientada al Objetivo) de Jeff Orkin en Game Programing Wisdom II, luego un artículo sobre gráficos de motivación, y comenzamos a usar gráficos de motivación para la selección de objetivos y GOAP para la selección de acciones.

Hay varios matices aquí, de los cuales he hablado por correspondencia con Jeff Orkin. Hemos decidido usar la planificación exclusivamente para la selección de acciones. Es decir, sólo necesitamos un plan para seleccionar la primera acción. Todas las otras partes del plan fueron ignoradas. El valor de la primera acción está en el hecho de que no ha sido escogido arbitrariamente, sino en el contexto de algún plan. Esto está muy bien para eliminar fallos. Usted siempre conoce lo que hace su personaje y, lo que es más importante, por qué. Esto también facilita la tarea de determinar si un plan es todavía válido, ya que nuestro plan es siempre válido.

Para mantener el plan válido, nuestra implementación de GOAP siguió teniendo en cuenta aquellas propiedades del mundo que son necesarias para crear el plan de menor peso. No hemos seguido reconstruyendo planes, sino que nos basamos en las propiedades del mundo que el planificador usó para crear el plan actual. Si cualesquiera de ellos cambiaba de valor, entonces el plan entero era reconstruido.

Por otra parte, un personaje siempre debe tener algún plan no vacío. Un plan vacío significa que el personaje no sabía que hacer, ya que no había ninguna secuencia de acciones que podrían transferir el estado global actual al objetivo número uno usando un conjunto de operadores disponibles (o su logro requería demasiados vértices para visitar, lo que ha llegado a pasar, pero raras veces. En el 99 % de los casos ésto quiso decir que no había tal secuencia, pero el planificador no podía demostrarlo, debido al límite del número de vértices visitados). La condición de existencia de un plan no vacío nos exigió elaborar una propiedad del mundo que siempre tenga un sólo valor, que es probable que no sea muy elegante muy elegante.

Para elegir el comportamiento de un personaje (stalker) hemos usado varias docenas de operadores (aproximadamente 70). Para controlar fácilmente un número tan elevado de operadores, usamos las jerarquías de planificadores. Es decir, un operador podría ser un planificador. La interacción de los planificadores de niveles diferentes fue realizada de esta forma: si el planificador de alto nivel cambiaba el plan, con lo cual el estado actual también cambiaba, entonces el planificador anterior era informado de que ésto debería terminar. Si el operador fuera también un planificador, informaba a su propio planificador actual, y así sucesivamente . Se debería advertir que la finalización era una acción instantánea, p. ej. si la acción no hubiera podido ser parada inmediatamente, esto tendría que tenerse en cuenta no sólo en su nivel, pero también en otros niveles que introducen una complejidad adicional.

Es eso por lo que decidimos no usar GOAP para los comportamientos de monstruos, ya que los monstruos dependen sumamente de las animaciones que no pueden ser interrumpidas o mezcladas. Por lo tanto usamos FSM jerárquico para ellos, pero, en realidad, esto no solucionó el asunto de acción no instantánea. En la precuela hemos dado con la solución para esta complejidad transfiriendo una parte de la lógica hacia los reguladores de nivel bajos: la lógica de alto nivel selecciona objetivos para los reguladores de bajo nivel. Por eso un cambio en la acción instantánea de alto nivel alto no significa un cambio en la acción instantáneo de alto nivel.

Hay también un matiz en la combinación de dos métodos para manipular la lógica. Al principio, introdujimos gráficos de motivación para aligerar el planificador GOAP. Finalmente hemos descubierto que el planificador se enfrentó con su tarea principal, y que la búsqueda nunca excedió 200 vértices. Además, determinar la lógica para atravesar objetivos consistió en que el autor del gráfico topológico asumiera parte del trabajo. Al final, dejamos de usar gráficos de motivación en absoluto, ya que se hizo más fácil poner toda la lógica en un solo lugar. Diferentes objetivos fueron usados solamente para personajes vivos y muertos (para agarrar el gatillo mientras mueres).
Reguladores de bajo nivel eran los responsables de la animación, el movimiento, el control de objetos, el sonido, la orientación del personaje. La puesta en práctica de estos reguladores no tiene un interés particular, excepto que también hemos usado GOAP para controlar los objetos (y, dicho de paso, bastante satisfactoriamente). En mi opinión, sería interesante ver una propuesta de usar a un gerente de regulador que llevaría a cabo unas planificaciones parciales sobre los operadores de controladores de bajo nivel. Aquí, desde luego, el aspecto de la velocidad en su funcionamiento es muy importante, ya que los reguladores de bajo nivel normalmente se renuevan cada fotograma. Por otra parte, debido a ésto también podrían emerger muchas asuntos con la interacción implícita entre los reguladores. Tal vez ésto podría usarse no sólo para la lógica de reguladores de bajo nivel, sino para todo la lógica del personaje, como se ha comentado en vuestra página (Replanteando el Interfaz AI/Animación).

AC: Ya que el juego final tenía un elemento de historia, también hay ciertas áreas en el juego que estaban programados de un modo más tradicional. ¿Podría usted decirnos algo más sobre cómo integró el sistema A-vida con los scripts?

DI: Como ya ha sido mencionado, las misiones en el juego son generadas por smart terrain (terrenos inteligentes). Esto también se aplica a la historia. Las misiones principales tienen más prioridad. Además, las áreas del argumento son rodeados por el llamado reductor del espacio (space restrictors). Su objetivo consiste en impedir a los personajes principales alejarse lejos, y a los personajes secundarios de interferir con elementos de la historia. Es decir, hay control significativo sobre la simulación. Por otra parte, después de que el jugador completa la historia, los persoanjes principales se vuelven corrientes y siguen reglas corrientes, p. ej. escogen tareas y van a realizarlas en las ubicaciones apropiadas de terrenos inteligentes. Al mismo tiempo, el área es liberada de todas las limitaciones.

AC: ¿El proceso de integrar estas áreas escritas por la A-vida era un proceso difícil para los diseñadores? ¿Cómo han abordado el proceso?

DI: Era difícil sin los reductores de espacio. De esta forma, cada personaje exterior rompería con la historia distrayendo a otros personajes, o, si no se les permitiera prestar la atención, ocurrirían situaciones absurdas, como que un perro muerda a un personaje que no le presta ninguna atención y finalmente muere completamente armado.

Para generalizar, uno podría decir que los reductores de espacio, junto con la dirección cuidadosa de información que viene de receptores, solucionó este problema prácticamente completamente, a tiempo.

AC: En retrospectiva, ¿qué partes del sistema y/o el proceso de desarrollo le agradó a Usted particularmente?

DI: Yo era muy feliz con el trabajo hecho cuando seguí a un stalker de un nivel al otro, vi como buscó artefactos, los encontró, volvió al comerciante, se le acercó, negoció, escogió una nueva misión, continuó – es un apena que no hicieran eso en el juego original. Era algo muy interesante de presenciar.

Cuando nosotros solamente estábamos poniendo en práctica el GOAP, era muy interesante mirar a dos personajes enemigos desarmados que sabían dónde conseguir armas y munición: ellos primero corren hacia las armas, ven que no tienen munición, luego corren hacia la munición, el primer que llega allí provoca pánico al otro si éste está aún muy lejos de las armas y la munición, el primero dispara, el otro cae herido al suelo y el primero se acerca para rematarlo (ésto no ocurría en el juego original ya que todos los personajes recibían munición ilimitada y situaciones como ésta no podían darse).

Era muy interesante ver la pelea entre varios perros y un stalker – era impresionante ver ese espectáculo, como él escapa de los perros, cambiando de coberturas. A veces él moría rápidamente, a veces lograba eliminar a 4-5 perros, y a veces mataba a los 6.

AC: ¿Qué pasa con las decepciones? ¿Había algo en particular sobre el sistema o su desarrollo que Usted habría hecho de manera diferente?

DI: En la simulación: Me hubiera gustado mucho jugar a un juego en el cual los personajes vivieran sus propias vidas, cada uno tuviera su propio objetivo en el juego, cada uno tuviera unas necesidades humanas (o algunas específicas para monstruos) necesitan que el carácter tenga que satisfacer. Ahora, en vez de la creación de un algoritmo para la opción de las necesidades actuales y su satisfacción, se ha usado un modelo más simple, que cargó este trabajo sobre los terrenos inteligentes, responsables del cambio de tareas por los personajes, capaces de asignar tareas como “dormir”, que, desde luego, no es lo mismo.

• En el aspecto visual: se puede hacer mucho para perfeccionar las peleas, el trabajo en equipo, la eficacia del combate y eficacia de las acciones del personaje. Realmente quiero cambiar la imitación de acciones de equipo por la verdadera AI de equipo, incluso si esto significa solamente algunas acciones.
• En intelecto: adaptación y aprendizaje de los personajes por el estilo de juego del jugador. La parte emocional también sería muy interesante.
  
• Mixto: Realmente me gustaría enseñar a los personajes a reaccionar adecuadamente al entorno: caminar alrededor de los obstáculos dinámicos, usar el terreno (el camino y los objetos dinámicos) de varios modos, ser capaz de conducir vehículos, pilotar el helicóptero, etc. Hay muchas cosas que ellos no pueden hacer por varios motivos, pero en las futuras iteraciones de nuestro juego trataremos de añadir gradualmente los elementos que faltan.

AC: ¿Cuáles son las lecciones que habéis aprendido? Si usted tuviera treinta segundos para dar un consejo a otros desarrolladores de videojuegos, ¿cuál sería?

DI:

1. No re-inventar de nuevo la rueda. Usar Internet para encontrar soluciones a los problemas.
   
2. Hay que tener una idea clara sobre el juego juego que se está haciendo, sobre qué características tendrá y cuáles no, usar prototipos para evitar implantar las características que no entrarán en la versión final.
   
3. Ajustar a los personajes con herramientas cómodas: cada componente debería tener su ajuste dibujar/modo/mostrar. Dibujar caminos (todas las iteraciones, todas las tramos rectos etc.), dibujar el control de visibilidad para averiguar por qué el personaje no ve, dibujar la información de las coberturas, etc. Para ajustar el comportamiento de los personajes hemos creado una pantalla de ajuste con todos los datos de todas las capas, así que fácilmente podemos coger al personaje y ver lo que pasa con él. El factor de pausa y tiempo son inapreciables para el ajuste animación/movimiento (orientación).
   
4. Dejar a los programadores hacer el trabajo de los trabajadores y a los diseñadores diseñar. Un diseñador es un mal programador, y un programador es un mal diseñador. Ésto podría ser un problema cuando usas scripts. Dejar a la gente hacer las cosas que son su fuerte. En vez de enseñarles a los diseñadores a programar, es mejor crear un editor WYSIWYP con muchas opciones para el ajuste.
   
5. Estar atentos a todos los avances en su área, leer fuentes de Internet, como AiGameDev.com.
   
6. Implantar algo nuevo en su juego. Tal vez sólo sea una cosa (ya que varias pueden ser demasiado para un sólo proyecto), pero que necesariamente sea nueva. Nosotros vemos una puesta en práctica excelente de ramas de decisión en Black & White, Jeff Orkin ha creado una implementación excepcional de un planificador GOAP en F.E.A.R., nosotros hemos tratado de realizar una especie de A-Life en un shooter, tal vez alguien hará algo nuevo mañana - esto beneficiará a los jugadores, que conseguirán juegos diversos, y a los desarrolladores en sí, que darán un ejemplo de un buen método o enfoque.

AC: ¿Puede hablarnos sobre la precuela de S.T.A.L.K.E.R. En la que está trabajando? ¿Adónde le gustaría llevar al tecnología A-Life?

DI: Hemos cambiado el papel de facciones en cuanto a simulaciones. As decir, es algún terreno inteligente, uno de cientos, el que genera las misiones con la pre-condición de queéstas solamente pueden ser tomadas por los miembros de una cierta facción, pero ahora la facción en sí es una entidad dentro del juego, tiene sus propios objetivos dentro de la simulación, lucha contra otras facciones, mientras el jugador puede ayudarla e inmediatamente ver el resultado de sus acciones.

También, hicimos varios cambios al comportamiento de combate dl personaje. Ahora luchan de una manera más eficiente y se han vuelto más creíbles.

AC: ¡Muchas gracias para su tiempo, Dmitriy, y mucha suerte con su próximo proyecto!

Pantalla de debugging de S.T.A.L.K.E.R.

Fuente Original

{mos_fb_discuss:153}