modelo metodológico para diseñar y coontruir personajes en

DATOS ESTUDIANTES

Estudiante Jaime Adalberto López Vivas

Dirección Cra 2 # 22BN – 115 Apto 407E Campo Real – Popayán

Teléfono 3006751833

Correo electrónico [email protected]

Profesión Ingeniero de Sistemas – Especialista en Gerencia de

proyectos

Empresa SIIGO S.A

Cargo Líder de equipo de desarrollo

Modelo metodológico para diseñar y construir personajes en videojuegos

Proyecto de Trabajo de Grado Jaime Adalberto López Vivas

Director Andrés Adolfo Navarro Newball

Pontificia Universidad Javeriana Maestría en Ingeniería

Énfasis en ingeniería de sistemas y computación Cali, Marzo de 2016

TABLA DE CONTENIDO

ABSTRACT .......................................... .......................................... 8

1. INTRODUCCION ...................................................................... 9

1.1. DEFINICIÓN DEL PROBLEMA DE INVESTIGACIÓN ...................................... 10

1.1.1. PLANTEAMIENTO DEL PROBLEMA ............................................................... 10

1.2. OBJETIVOS DE PROYECTO .......................................................................... 12

1.2.1. OBJETIVO GENERAL ...................................................................................... 12

1.2.2. OBJETIVOS ESPECÍFICOS ............................................................................ 12

1.2.3. ALCANCES DEL TRABAJO ............................................................................. 12

1.3. JUSTIFICACIÓN .............................................................................................. 14

2. MARCO TEORICO ................................................................. 16

2.1. Estado del arte ................................................................................................. 16

2.1.1. Videojuegos .............................................................................................. 16

2.1.1.1. Historia de los Videojuegos ...................................................................... 16

2.1.1.2. Tipos de videojuegos ................................................................................ 17

2.1.2. Personajes................................................................................................ 20

2.1.3. Agentes Software ..................................................................................... 22

2.1.3.1. ¿Qué es un Agente? ................................................................................. 22

2.1.4. Propiedades de los Agentes ..................................................................... 23

2.1.5. Metodologías de Agentes ......................................................................... 24

3. MODELO METODOLÓGICO ............................... ................... 32

3.1. Definición. ........................................................................................................ 32

3.2. Revisión de metodologías para agentes. .......................................................... 33

2.1.6. Análisis ..................................................................................................... 37

2.1.7. Diseño ...................................................................................................... 40

2.1.8. Desarrollo ................................................................................................. 42

3.3. Modelo metodológico propuesto ....................................................................... 44

3.3.1. Conceptuación .......................................................................................... 46

3.3.2. Modelo de Comportamiento ...................................................................... 53

3.3.3. Modelo de Experiencia ............................................................................. 55

3.3.4. Modelo de Coordinación ........................................................................... 58

3.3.5. Modelo de Organización ........................................................................... 61

3.3.6. Modelo de Diseño ..................................................................................... 63

3.4. Aportes propios ................................................................................................ 68

4. API PARA IMPLEMENTACIÓN DE AGENTES/PERSONAJES69

4.1. Descripción ...................................................................................................... 69

4.1. Adaptación del API ........................................................................................... 70

4.1.1. Modelo base de Agente ............................................................................ 70

4.1.2. Modelo base del personaje ....................................................................... 72

4.1.3. Comportamientos independientes y pro-actividad ..................................... 73

4.2. Arquitectura de la Librería ................................................................................ 73

4.2.1. Capa de Renderizado ............................................................................... 74

4.2.2. Lógica de personaje ................................................................................. 74

4.2.3. Servicios ................................................................................................... 76

4.3. Uso de la librería .............................................................................................. 76

4.3.1. Follow ....................................................................................................... 76

4.3.2. Star Dialog Animation ............................................................................... 77

4.3.3. Third Person controller.............................................................................. 79

4. CASO DE ESTUDIO ............................................................... 81

5.1. Video juego de ejemplo .................................................................................... 81

5.2. Aplicación de la metodología ............................................................................ 81

5.2.1. Conceptuación .......................................................................................... 81

5.2.2. Modelo de Comportamiento .................................................................... 102

5.2.3. Modelo de Coordinación ......................................................................... 107

5.2.4. Modelo de Organización ......................................................................... 114

5.2.5. Modelo de Diseño ................................................................................... 114

5.3. Análisis de la aplicación del modelo metodológico al caso de estudio ............ 116

5.2.6. Ventajas ................................................................................................. 116

5.2.7. Desventajas ............................................................................................ 117

5. PRUEBA PRELIMINAR ................................. ........................118

a. Validación preliminar .......................................................................................... 118

5. CONCLUSIONES Y RECOMENDACIONES .................... .....121

6.1. Conclusiones .................................................................................................. 121

6.2. Recomendaciones .......................................................................................... 122

REFERENCIAS BIBLIOGRAFICAS ........................ ....................123

FICHA RESUMEN

ANTEPROYECTO DE TRABAJO DE GRADO DE MAESTRÍA TITULO: “Modelo metodológico para diseñar y construir perso najes en videojuegos” 1. ÉNFASIS: Ingeniería sistemas y computación 2. ÁREA DE INVESTIGACIÓN: Inteligencia Artificial 3. ESTUDIANTE: Jaime Adalberto López Vivas 4. CORREO ELECTRÓNICO: [email protected] 5. DIRECTOR: Andrés Adolfo Navarro Newball 6. CO-DIRECTOR(ES): 7. GRUPO QUE LO AVALA: DESTINO – Pontificia Universidad Javeriana 8. OTROS GRUPOS: GTI – Universidad del Cauca 9. PALABRAS CLAVE: Videojuegos, Agentes Inteligentes, Metodología, Modelo,

Personajes, Tres dimensiones. 10. CÓDIGOS UNESCO CIENCIA Y TECNOLOGÍA: 1203.04 Inteligencia Artificial -

1203.17 Informática - 1203.18 Sistemas de Información, Diseño Componentes, 11. FECHA DE INICIO: 22 de Noviembre de 2013 DURACIÓN ESTIMADA: 8 Meses

12. RESUMEN

Los juegos están presentes en nuestra vida desde temprana edad, es mediante ellos como conocemos y nos relacionamos con el mundo en nuestra infancia, en la actualidad los juegos han evolucionado haciendo uso de la tecnología computacional y son conocidos como videojuegos, su principal característica es que logran sumergirnos en mundos imaginarios, intentando que esta experiencia sea lo más creíble posible, de este modo se plantea un desafío inmenso, puesto que todos los elementos del juego deben ser lo más realistas posible. Uno de los principales elementos de un juego es sin duda sus personajes, ya sean jugadores o no jugadores (autónomos), cuando se construyen, estos deben estar fundamentados en tres dimensiones: social, física y psicológica, logrando una mayor inmersión, pero esta tarea no es fácil, y demanda superar un desafío de comunicación entre diseñadores y desarrolladores, adicionalmente la construcción de un personaje requiere realizar algoritmos muy complejos en funcionalidad y comportamiento, haciendo del desarrollo de videojuegos una actividad que no está al alcance de todos los desarrolladores de software. En este sentido el presente trabajo propone la creación de un modelo metodológico que permita facilitar el diseño y construcción de las tres dimensiones de un personaje, física, social y psicológica, a través de la especificación de un conjunto de pasos y modelos, que propicien un lenguaje común entre diseñadores y programadores de video juegos, permitiendo tener un marco de referencia documentable, repetible y trazable para la implementación de un videojuego. Palabras clave: Videojuegos, Agentes Inteligentes, Metodología, Modelo, Personajes, Tres dimensiones

ABSTRACT

Games are present in our life from an early age. It is by them that we know and relate to the

world in our childhood. Now games have evolved using computer technology and are known as

videogames. Their main feature is who we manage to immerse ourselves in imaginary worlds,

trying to make this experience as believable as possible. This possesses a huge challenge, since

all elements of the game should be as realistic as possible. One of the main elements of a game

is definitely its characters, whether players or non-players (self-governing), when constructed,

they must be based in three dimensions: social, physical and psychological, achieving greater

immersion, but this task is not easy, and demand brings the challenge of communication

between designers and developers. Morevover, the construction of a character requires complex

algorithms in functionality and performance, making the development of video games an activity

not available to all software developers. In this sense, we propose the creation of a

methodological model which can facilitate the design and construction of the three dimensions

of a character, physical, social and psychological, through the specification of a set of steps and

models that will foster common language between designers and developers of video games,

allowing to have a documentable, repeatable and traceable framework for the implementation of

a videogame.

Keywords: Videogames, Intelligent Agents, Methodology, Model, Characters, Three Dimensions.

1. INTRODUCCION

El juego es la actividad mediante la que se aprende a conocer el mundo y se desarrollan habilidades físicas y cognitivas [1]. Existen muchos juegos que van desde el simple uso de las manos, hasta construcciones más elaboradas a través de interfaces y dispositivos electrónicos conocidos como videojuegos. Un videojuego es un programa informático, creado expresamente para divertir, basado en la interacción entre una persona (jugador) y un aparato electrónico, el jugador toma un rol en el sistema mediante el cual se relaciona con los otros actores (personajes), tratando de superar una serie de obstáculos con miras a alcanzar unos objetivos planteados[2]. Entre más entretenido se pretende hacer un videojuego mayor debe ser su funcionalidad y comportamiento, convirtiendo en un software difícil de definir, diseñar e implementar, lo que hace al desarrollo de videojuegos en una tarea que requiere un alto grado de experiencia. El desarrollo de videojuegos implica conceptos profesionales de la ingeniería de software, con alta complejidad conceptual y alto nivel tecnológico, además de contar con un grupo interdisciplinario que incluye diseñadores, artistas, comunicadores, entre otros, haciendo aún más complejo su desarrollo. A lo anterior se suma el hecho de no contar con herramientas que permitan una comunicación entre los diferentes entes de manera que todos cooperen en dicho proceso [3]. Uno de los aspectos más complejos a la hora de definir un juego son sus personajes ya que estos cuentan con comportamientos no lineales cuya finalidad es simular acciones humanas[3]. En este sentido el presente proyecto pretende desarrollar una propuesta de un modelo metodológico que permita al grupo de desarrollo de un juego contar con procesos y modelos bien definidos garantizando una reducción significativa en complejidad en la definición, diseño y construcción de personajes, logrando una comunicación efectiva y basada en un lenguaje común que posibilite la interacción entre los diferentes actores en el proceso de construcción de un videojuego. El trabajo planteado no solo incluye aspectos de investigación sino también de innovación y desarrollo fusionando conceptos como los agentes inteligentes con tecnologías para la creación de juegos y sistemas de creación de interfaces en tercera dimensión.

Maestría en Ingeniería Jaime Adalberto López Vivas Énfasis en ingeniería de sistemas y computación


10

1.1. DEFINICIÓN DEL PROBLEMA DE INVESTIGACIÓN

1.1.1. PLANTEAMIENTO DEL PROBLEMA

El juego es una actividad presente en todos los seres humanos que ha sido identificada como un patrón fijo en el comportamiento de las personas y que cumple con una función primordial a lo largo del ciclo vital de cada individuo. Habitualmente se le asocia con la infancia [1], pero lo cierto es que se manifiesta a lo largo de toda la vida del hombre, incluso hasta su vejez [2]. Generalmente, el juego es relacionado con diversión, satisfacción y ocio, pero su trascendencia es mucho mayor, ya que a través del juego se transmiten valores, normas de conducta, se resuelven conflictos, se educa a los jóvenes y se desarrollan múltiples facetas de la personalidad, se dice que el juego es un ejercicio preparatorio para el desarrollo de funciones que son necesarias para la época adulta [1].

En la actualidad los juegos han evolucionado, ofreciendo nuevas formas de entretenimiento. Los “videojuegos” son el claro ejemplo de estos cambios. Un videojuego se puede describir como un programa informático, creado para divertir [3], basado en la interacción entre una persona y un aparato electrónico donde este se ejecuta. Estos recrean entornos virtuales en los cuales el jugador puede controlar a un personaje o cualquier otro elemento de dicho entorno, para conseguir uno o varios objetivos por medio de unas reglas determinadas. Estos son un medio de distracción con una gran popularidad, tanto así, que parte de las generaciones actuales buscan, durante su tiempo libre, distraerse en algún videojuego experimentando un mundo virtual y enfrentando experiencias y retos que normalmente no se presentan en la vida diaria [4]. Existen diferentes tipos de videojuegos, los cuales ayudan a los jugadores a que se desarrollen habilidades, destrezas e incluso puede influir en su comportamiento [5]. Dentro de todos los tipos se destacan los videojuegos de aventura [6], los cuales poseen características que llaman la atención de los jugadores; como argumentos bien elaborados, buenos efectos visuales y sonoros. También, la inmersión del jugador dentro de la historia, contienen un alto nivel de inteligencia artificial [7] y adicionalmente cuentan con personajes que deben ser atractivos al jugador ya que gran parte del tiempo de juego se basa en la interacción de estos con el usuario y con otros personajes mediante acciones y diálogos. Alos personajes se les debe asignar un papel que permita fijarle una identidad, y describir que acciones van a realizar para poder darle una personalidad que justifique sus actos, por ejemplo, si va a ser el héroe, la princesa, el villano, el tutor del héroe o el escudero1. También se les debe asignar características como nombre, Imagen, localización, relación con los demás personajes y definir los comportamientos con respecto a su entorno, dotando al personaje de acciones como la pro-actividad, reactividad y características sociales [8]. Entre más variedad y creatividad se les imprima a los personajes mayor será la riqueza y valor argumental que va a tener el juego, puesto que la historia es tan buena como sean los personajes. En los juegos los personajes pueden actuar de manera proactiva2, es decir, que son controlados automáticamente por inteligencia artificial u otras técnicas como las máquinas

1 Personajes propios de un juego de aventura 2 Personajes llamados PNJ (personajes no jugadores)



11

de estado finito, redes bayesianas o scripts3 para que puedan interactuar en un entorno [9]. Estas técnicas entregan a los personajes un número determinado de acciones y reacciones que tienen que ser previamente conocidas y programadas por el desarrollador, esto hace que el juego tenga poca jugabilidad porque una vez que el jugador ha explorado todas las alternativas pre-programadas, el juego deja de ser útil y por lo tanto entretenido [9]. Los personajes de los juegos también pueden trabajar de manera grupal o cooperativa, centrando la atención en cómo construir juegos basados en grupos de personajes que se interrelacionen entre sí brindando mayor dinamismo al juego, en este caso los personajes pueden tener influencia unos con otros, no sólo de manera explícita sino también por la actuación sobre el entorno, obligando a estudiar el entorno con detalle para detectar qué acciones realizadas por un personaje pueden afectar a otro, aumentando la complejidad del desarrollo enormemente, debido a que no existe ninguna metodología o modelo que permita un desarrollo grupal de personajes que se relacionan entre sí (solo existen técnicas para crear personajes individuales) [10]. En este sentido`, existen técnicas de inteligencia artificial que no han sido muy exploradas4 dentro del diseño de personajes de un videojuego, una de estas técnicas son los agentes software los cuales se acomodan en un entorno, el cual perciben y modifican a través del tiempo, mientras persiguen sus propios objetivos basados en su experiencia y/o aprendizaje [11]. Todas las propiedades que brindan los agentes (autonomía, reactividad, iniciativa, habilidad social, etc.) serían de gran ayuda en la construcción de personajes en un videojuego porque, no solo permiten modelar comportamientos sino que también ayudan a diseñar características sociales que exhiben los personajes, lo que facilita la comunicación de estos con su entorno [12], de esta manera surge la pregunta de investigación:¿Cómo se puede facilitar el diseño5 y creación de personajes en videojuegos a través del uso de tecnologías de agentes inteligentes?

3 Script: Un conjunto de comandos escritos en un lenguaje interpretado para automatizar ciertas tareas de aplicación. A veces, se utiliza también el término inglés "escenario". 4 No hay evidencias de su uso en la práctica para el desarrollo de personajes. 5 Considerando las tres dimensiones del personaje (Física, Psicológica y Social )



12

1.2. OBJETIVOS DE PROYECTO

1.2.1. OBJETIVO GENERAL

Desarrollar un modelo metodológico para diseñar y construir personajes de videojuegos, basado en las metodologías de diseño de agentes inteligentes.

1.2.2. OBJETIVOS ESPECÍFICOS

1. Proponer un modelo metodológico que permita diseñar y construir personajes en

videojuegos, basados en las metodologías y modelos existentes para agentes software, el cual debe soportar el diseño de las tres dimensiones del personaje (física, psicológica6, social).

2. Construir un API7 soportado en los modelos propuestos como un modulo software sobre una librería gráfica o un motor de juegos, el cual debe soportar el mapeo de las tres dimensiones del personaje a través de cuatro características: renderizado físico del personaje, comportamientos reactivos, comportamientos pro-activos y capacidad de comunicación.

3. Validar el modelo metodológico mediante la construcción de un nivel de demostración

de un juego que utilice la implementación de la metodología propuesta (agentes-personajes).

1.2.3. ALCANCES DEL TRABAJO

El alcance del proyecto comprende tres productos: • Modelo metodológico: Se entregará una secuencia de pasos que como mínimo deben

incluir:

o Conceptuación: se encargará de recopilar toda la información existente del dominio del problema, para describir la totalidad del problema de una forma muy general. Para ello se planea como mínimo la realización de un story-line descrito a través de escenas de cada personaje.

o Análisis : Se determinan todos los requisitos de los personajes partiendo del documento de conceptuación del video juego. En esta etapa se debe generar al menos un modelo del personaje y un modelo de comportamiento.

6 La psicología desde el punto de vista de las creencias, deseos e intenciones del personaje. 7 Application Programming Interface (Interfaz de Aplicación Programable) Librería Reutilizable



13

o Diseño : Especificación de los requisitos de la fase de análisis que se puede lograr mediante el desarrollo de un modelo de diseño, que podría incluir un modelo de arquitectura tanto de la red multiagente como de cada agente y un modelo de comunicación.

• Librería reutilizable que permite implementación de personajes en un juego para una

plataforma gráfica o motor de desarrollo de video juegos, dentro de la librería se debe permitir:

• Renderizado del personaje : Permite cargar y visualizar el personaje, con sus

características físicas, también permite ejecutar una serie de animaciones asociadas al mismo.

• Comportamientos reactivos y pro-activos : El agente-personaje actúa o ejecuta una seria de comportamientos que pueden ser disparados por:

o Un estímulo externo: La librería debe ofrecer la capacidad de tomar datos del mundo que rodea al agente, para usarlos en su proceso de deliberación8, estos datos se deben poder almacenar en un perfil del jugador.

o Estimulo interno: La librería permite mediante una interfaz proveedor conectar un mecanismo de deliberación, los mecanismos implementados a manera de ejemplo serán:

� Autómatas � Algoritmos genéticos

No obstante la interfaz debe permitir conectar otras técnicas de inteligencia. • Comunicación : Permite a un agente-personaje comunicarse con otros personajes9,

usando el estándar de comunicación (Fipa-ACL) [25], con lo cual se garantiza una ontología común para el intercambio de información.

• Validación: Se pedirá a un grupo, de máximo cinco estudiantes10 que usen la

metodología para modelar un personaje validando que el resultado es un personaje enmarcado en las dimensiones social, física y psicológica. El diseño de cada personaje debe ser evaluado teniendo en cuenta los siguientes criterios:

o Tiempo de diseño o Tiempo de implementación o Facilidad de uso de los modelos y pasos propuestos por la metodología o Percepción por parte del jugador que usa el personaje.

Para culminar la validación se debe construir Videojuego en un escenario de aventura11, con un nivel de demostración, al menos un personaje jugador y dos no jugadores, implementados usando el modelo metodológico y la librería reutilizable de personajes.

8 Este proceso permite que luego se dispare un comportamiento, si es necesario 9 Personajes Jugadores o no jugadores 10 Inscritos en carreras afines a computación o ingeniería de sistemas 11 Se escoge un video juego de aventura debido a que este en gran medida depende solo de sus personajes, a diferencia de otros juegos que dependen más del ambiente de juego.



14

1.3. JUSTIFICACIÓN

Con alrededor de 30 años de años de historia, los videojuegos se encuentra actualmente en pleno auge, registrando un crecimiento anual entre 9% y el 15%, en los últimos 25 años [13], dejando atrás otras industrias del mundo del entretenimiento como el cine, la televisión y la música. Esto es debido al gran impacto social y cultural, que ha permitido, ampliar su público objetivo, el cual inicialmente era limitado a la población infantil, convirtiéndose hoy por hoy en una atracción para personas de todas edades, por lo que es muy común ver países como Estados Unidos, donde se han alcanzado cifras que revelan que al menos uno de cada cuatro habitantes encuentra en ellos su principal fuente de diversión [13]. Pero construir un juego que resulte además de llamativo, divertido no es una tarea fácil. Para empezar, es necesario contar con un documento descriptivo, que contenga el concepto del juego en forma básica, a partir del cual el equipo de desarrollo, encaminará la evolución del proyecto (creación de la historia, guión, diseño de personajes), eliminando todos aquellos ítems que no aporten a la concepción del mismo, y refinando aquellos que son de gran importancia [14]. Ahora bien, este documento descriptivo es el encargado de guiar a cada uno de los miembros del equipo para alcanzar su objetivo, es por ello que los términos y/o diagramas aquí empleados deben ser entendibles para todo el grupo de trabajo. Sería conveniente tener un conjunto de técnicas o modelos que permitan la definición adecuada de aspectos complejos del juego: como el ambiente donde se desarrolla la historia y principalmente el comportamiento de los personajes debido a que son éstos los que van a garantizar el éxito o fracaso del juego [14]. Dichos modelos serian enfocados a facilitar la compresión de los pensamientos expresados, buscando unificar la concepción del equipo en lo concerniente al objetivo del proyecto; en este sentido, es posible apoyarse en el concepto de agente dado que posee características como reactividad, pro-actividad, habilidad social, entre otras, las cuales le permiten actuar de forma autónoma y flexible en un entorno [11]. Teniendo en cuenta que los personajes de un videojuego poseen varias de estas características es conveniente pensar en la integración de estos conceptos, permitiendo plasmar las interacciones que existen entre actores12, garantizando una mayor comprensión para los miembros del equipo de desarrollo. El trabajo centrado en el concepto de agente permite adaptar los modelos de diseño existentes para modelar los personajes de un juego, mejorando la comprensión de las características y comportamiento de los mismos. Durante el proceso de creación de juego los artistas y animadores, crean el arte del proyecto, imágenes, dibujos, animaciones, los personajes, los objetos, etc. todo debe quedar bien definido, los músicos, crean la banda sonora del juego y los efectos de sonido necesarios durante todo el proceso, en esta etapa, esto actores no trabajarán aislados, sino que en la mayor parte del tiempo, retroalimentarán a los desarrolladores con el material producido, es por esto que la comunicación y el documento de diseño se convierten en factores determinantes para el desarrollo de cualquier videojuego [14]. Una vez terminada la fase de especificación del juego se procede a trabajar en la parte operativa desarrollando componentes como en el motor del juego que es el núcleo software de un videojuego. Es común utilizar un motor ya existente, aprovechando mucho los

12 Personal encargado de desarrollar el juego ( Desarrolladores, Diseñadores Gráficos, Comunicadores, etc)



15

módulos ya construidos en lo que se refiere a gráficos, sonido, manejo de escena, etc. Existen unos elementos comunes a la mayoría de los motores de juego, pero algunos módulos deben ser manejados al momento de construir el juego, ya que es muy frecuente no encontrar elementos como por ejemplo los motores de sonidos, de física, de IA (Inteligencia Artificial), entre otros, los cuales son implementados en muy pocos motores de Juegos dada su complejidad. En la actualidad, los motores de juegos manejan diferentes técnicas de Inteligencia en sus motores como las redes neuronales y árboles de decisiones, las cuales permiten agregar complejidad a nivel general, pero no centrada en los personajes [15], en la actualidad no hay evidencias que muestren un mecanismo metodológico que permita la documentación y diseño de personajes, pero si se cuenta con metodologías para la especificación de agentes software que combinadas entre sí, pueden permitir el diseño de personajes basados en agentes y sus comportamientos brindándole características como la pro-actividad, reactividad y habilidades sociales. Una buena forma de probar si es posible diseñar y construir personajes basados en el concepto de agente, es la realización de un caso de estudio donde se implemente un juego basado en el diseño generado por el modelo metodológico, lo cual permitirá validar la conceptualización teórica planteada.



16

2. MARCO TEORICO

2.1. Estado del arte

Este ítem enumera los conceptos, principios teóricos y prácticos más importantes sobre el desarrollo de videojuegos, agentes software, motores de jugos etc., que serán usados para la realización de esta investigación.

2.1.1. Videojuegos

Los videojuegos son un medio de entretenimiento que ha ido abriendo camino en el mercado desde finales de los años 70 convirtiéndose en una de las más grandes y solventes industrias en el mundo del entretenimiento [13]. Pero, la evolución de los videojuegos crece a la par con la evolución del software y los avances tecnológicos en materia del hardware. Hoy en día existe una gran variedad de videojuegos, por lo que se vio la necesidad de crear una forma de clasificación para éstos de manera que pudieran ser agrupados a partir de distintos ejes como pueden ser: la temática, el argumento, la plataforma, entre otros [16]. Un género importante en el mundo de los videojuegos es el de aventura, ya que este puede ser visto como otro tipo de medio narrativo como los libros o las películas en los cuales el jugador adopta el papel de protagonista de una historia, viéndose obligado a sumergirse en el argumento de ésta, para lograr alcanzar los objetivos del juego [17]. En los juegos de aventura la historia forma parte de los elementos más importantes; sin embargo, para el filósofo Jung o Freud no podría existir una historia sino existen los personajes ya que una historia es una narración de los sucesos que ocurren a un determinado personaje en la búsqueda de una determinada solución simplificando un poco la definición [18]. Es por esto que para la creación de juegos de aventura debe existir un cuidado especial al crear los personajes. Sin dejar de lado los demás elementos indispensables para la creación de un videojuego como el motor de juegos la cual es “la maquinaria” que mueve el juego en materia de software [19]. Donde se pueden encontrar una gran cantidad de códigos que permitirán definir los sonidos, gráficos, entre otras muchas características del juego.

2.1.1.1. Historia de los Videojuegos La prehistoria de los videojuegos, se remonta a 1958. Bill Nighinbotthan presenta en una feria científica un aparato que permite, mediante unos potenciómetros, mover una pequeña raqueta en un tubo de rayos catódicos [16]. Basándose en este aparato, Nolan Bushnell (fundador de Atari) crea en 1972 un videojuego llamado Pong. Años más tarde, en 1976,



17

un empleado de Atari, Steve Wozniak ayudado por Steve Jobs, crean un videojuego llamado BreakOut. Dos años después, ambos dejarán Atari para crear Apple Computer y pasar a la historia de la informática. Después en 1978, Taito lanza al mercado el famoso Space Invaders. Este juego era capaz de almacenar las puntuaciones máximas, convirtiéndose en todo un clásico. En los siguientes años, comienzan a aparecer en el mercado nuevos videojuegos de excelente calidad como Donkey Kong, Frogger, Galaga, Pac Man, etc. [16] En los tiempos del MS-DOS la programación de videojuegos era bastante compleja, hacían falta grandes conocimientos de lenguaje ensamblador y de la estructura interna de la máquina, así como de la tarjeta de video y de sonido. Toda la programación se hacía directamente sobre el hardware [16]. Es fácil imaginar los inconvenientes, había que preparar el juego para que funcionara con muchos modelos de tarjeta gráfica y también para los diferentes modelos de tarjetas de sonido (Adlib, Gravis Ultrasound (GUS), Sound Blaster). Es decir, hacer un juego, por simple que éste fuera, requería un esfuerzo muy alto, sin contar con que no siempre toda la información necesaria para acceder al hardware estaba al alcance de todo el mundo [16].

2.1.1.2. Tipos de videojuegos En la actualidad existen una gran variedad de videojuegos, dentro de los cuales muchos comparten características fundamentalmente relacionadas con la temática principal, el argumento, la estructura del juego, la plataforma, las habilidades lúdicas perseguidas [20]. Los videojuegos que combinan estas características, reciben el nombre de híbridos. A continuación, se presenta una clasificación de los videojuegos con base a una propuesta hecha por el profesor Pere Marques Graells de la Universidad Autónoma de Barcelona en la cual se identifican seis tipos de videojuegos [21].

� Arcades: Los videojuego de este tipo son definidos como juegos de animación que requieren mucha rapidez de reacción. EL personaje central debe ir superando los distintos escenarios en los cuales el grado de dificultad incrementa. Es conveniente plantear una subdivisión en dos tipos de arcade diferentes: los juegos de plataformas y los juegos de acción, estos últimos también pueden ser subdivididos en First Person Shooter (FPS) y juegos de acción en tercera persona [21]. En los juegos de plataformas el personaje debe abrirse camino a través de los diversos escenarios atravesando obstáculos, saltando y eliminado o esquivando a aquellos “obstáculos” que impiden el progreso. A medida que el juego avanza el nivel de dificultad aumenta, lo cual suele ser reflejado en un el aumento en la velocidad y en los obstáculos, por lo que el jugador debe cada vez reaccionar de forma más rápida, por ejemplo Mario Bross, Prince Of Persia, etc. [20]. Los FPS son videojuegos de acción en primera persona en donde el usuario se integra con el personaje del juego. Lo que aparece en la pantalla o televisor es la mano del personaje portando el arma que lleve en ese momento. Estos juegos son de gran variedad temática y en la actualidad suelen ser desarrollados basados en un guion o historia cinematográfica. La base del desarrollo del juego es la supervivencia a lo largo de los diferentes niveles neutralizando a cualquier enemigo



18

que se interponga en el camino. Una de las características que determinan la calidad de este tipo de videojuego es la interacción con los escenarios. Cuantos más elementos del escenario puedan ser manipulados o destruidos por el personaje, mejor y más completo es considerado el juego, por ejemplo DOOM, Quake, etc. [21]. Los juegos de acción en tercera persona se diferencian de los anteriores en la forma de integración entre el jugador y el personaje. En este caso el jugador no alcanza un grado muy alto de identificación con el personaje. Debido a que el usuario tiene una visión completa del personaje en la pantalla, lo que le permite crear una concepción ajena sobre el actor. Juegos en los que la acción se ve relegada por la estrategia y el sigilo. Resultan algo más lentos de jugar y con una historia o guión más elaborados. Contienen un alto componente de plataforma, como Tomb Raider, Metal Gear Solid, etc. [21].

� Aventura y Rol. [20]: Aunque el profesor Marqués en esta clasificación los unifica dentro de la misma categoría, existen algunas diferencias entre estos dos tipos de juegos tanto en jugabilidad como en temática y la forma en que se relaciona el jugador con el videojuego. En los juegos de aventura el jugador protagoniza una historia en la que deben superarse pruebas, adquirir habilidades y descubrir paso a paso nuevos elementos hasta llegar al final del argumento. Los juegos de aventura son un tipo de programas de entretenimiento para computador, los cuales se caracterizan por introducir al jugador en mundo donde la investigación es la base del juego, y para alcanzar el objetivo del juego deberá explorar en su entorno, resolver puzzles (rompecabezas), interactuar con los demás personajes del juego y sobre todo estar muy enfocado en la narrativa (historia) la cual refleja los desafíos del juego. Es de notar que el término Juegos de Aventura no tiene una relación directa con los films o las novelas de aventura, por lo que no es indicativo del tema o contenido del juego. La mayoría de los juegos de aventura son juegos de computador, y aunque existen juegos de aventura para consola, no es común oír de ellos. Los juegos de aventura se enfocan en una historia, lo que les permite estar basados en distintos medios narrativos, tales como la literatura y las películas. Los juegos de aventura abarcan una gran cantidad de géneros literarios, entre ellos la fantasía, ciencia ficción, misterio, horror y comedia. Dentro de los títulos más nombrados en este género se encuentran Zork, King´s Quest, The Secret of Monkey Island, Gabriel Knight y Myst. Casi todos los videojuegos de aventura son diseñados para un jugador, dado que se hace tanto énfasis en la historia resulta realmente difícil diseñarlos de forma que se pueda jugar en multi-jugador. Este género alcanzó su máxima popularidad a finales de los años 80 y comienzos de los 90, además considerado por muchos técnicamente una de las clasificaciones más avanzadas en materia de videojuegos. En los juegos de Rol o RPG (Rol Player Game) las acciones y decisiones son tomadas en función de las propuestas del juego y de las acciones del resto de personajes. Se mantiene en todo momento un control exhaustivo de las características del personaje como las constantes vitales, habilidades, armas y poderes entre otras. Son juegos que por lo general manejan una temática mágica, y anacrónica. Su diseño propone una jugabilidad lenta. Una de sus principales diferencias con los juegos de acción es que sus luchas se desarrollan por turnos lo



19

que exige al jugador dedicar más tiempo a la planificación de una buena estrategia de ataque que a la acción en sí, como Final Fantasy.

� Simuladores[20]: Estos juegos se caracterizan por su gran veracidad y realismo sobre todo al tratarse de entornos y situaciones reales. Esto obliga al usuario a aplicar en ocasiones conocimientos específicos. El grado de integración del jugador en el entorno es variable, ya que la visión puede ser en tercera o en primera persona. Es común encontrar de todo tipo de simuladores desde aviones comerciales, de combate, autos, motos y muchos más. En la actualidad muchos simuladores se usan como mecanismo de preparación para distintas situaciones reales.

� Estrategia[21]: En este tipo de juegos se promueve la toma de decisiones, cálculos, razonamiento lógico, establecimiento de hipótesis, para conseguir un objetivo. Suelen ser de tema histórico y épico donde se recrean batallas entre distintas poblaciones. El jugador debe, a partir de unos pocos elementos de construcción y personajes, ir construyendo las estructuras necesarias para crear sus ejércitos y de esta manera enfrentarse a otros ejércitos. Existen dos tipos claramente diferenciados de juegos de estrategia: en tiempo real y por turnos. En los juegos en tiempo real todos los jugadores realizan sus acciones al mismo tiempo, por ejemplo Age Of Empires, StarCraft, etc. Mientras que en los juegos por turnos los jugadores van realizando sus diferentes movimientos uno detrás de otro, dentro de esta clasificación es posible encontrar juegos como Civilization y Populous.

� Deportes [21]: Los juegos de deportes siempre han tendido un gran éxito comercial. Estos videojuegos han evolucionado de basarse en el enfrentamiento entre dos equipos donde un partido decide el ganador, hasta los juegos actuales en donde el usuario puede gestionar todo un equipo como si fuera un presidente de un club deportivo donde tiene la posibilidad de tomar decisiones sobre inversiones, fichajes, traspasos y cesiones del mismo, incluso algunos de estos juegos han llegado a limitar la posibilidad de que el jugador participe en los partidos, dejando al computador o a la consola que calcule el resultado de un partido en función de cómo lo ha planteado tácticamente el usuario. De esta forma los juegos de deportes han encontrado una dualidad en su jugabilidad. Un tipo se basa en la gestión y organización de un club deportivo siendo más tranquilo y lento de jugar, y otros se ha dirigido hacia la simulación de partidos en donde el jugador participa activamente en los encuentros. Algunos títulos de gran éxito son PC Futbol, Pro Evolution Soccer, NBA.

� Puzzles y preguntas [21] : Este tipo de juegos estuvieron en auge durante un largo tiempo ya que sus necesidades graficas eran bajas lo que permitía a un gran número de usuarios acceder a ellos. Además, el mercado de los videojuegos no tenía aún el potencial que tiene actualmente. Pero con el paso del tiempo el público hacia el cual se enfocan estos videojuegos se ha ido reduciendo. Es preciso tener en cuenta, que estos videojuegos fueron los precursores de la industria de los videojuegos con títulos como Tetris, Tenis For Two o Comecocos, y aun siguen siendo utilizados en dispositivos de bajas capacidades graficas como dispositivos móviles o consolas de mano.



20

2.1.2. Personajes

Autores como William Archer [22] opinan, que la creación de personajes no puede ser regulada por recomendaciones teóricas, a pesar de que hoy en día es muy común encontrar una gran cantidad de manuales y guías para escribir historias, la creatividad no debe ser atada a un conjunto de reglas o pasos. Y no es lo que pretende este proyecto, dado que la idea es dar un enfoque “mostrar un camino a seguir” lo que no quiere decir que esta sea la única forma, es solo una opción para crear personajes en un videojuego de aventura. [22] En este proyecto se trabajara con personajes en tres dimensiones (3D), pero este concepto generalmente es asociado exclusivamente a la parte física del personaje en lo que se refiere a la altura, anchura y profundidad. El término de tres dimensiones también es empleado por algunos autores para dar una descripción detallada del personaje determinando su carácter físico, psicológico y sociológico, esta definición es aplicada a todos los personajes de un juego ya sea o no el personaje jugador [22].

• Fisiología del personaje: En esta dimensión se cubren los aspectos físicos detallando la apariencia y estado de salud del personaje. La apariencia física del personaje puede hacerlo ver y sentir seguro o inseguro en sus actividades, una persona que se encuentre sana reacciona de forma distinta a como reacciona una persona enferma ante la presencia de situaciones similares. Su estado salud genera una diferencia en su actitud hacia la vida. Ambos, la apariencia y la salud afectan su desarrollo mental, lo que, suele crear un complejo de superioridad o inferioridad en el personaje [23].

• Sociología del personaje: En esta dimensión se trata al personaje analizando su entorno. El comportamiento de las personas varía dependiendo de las características en las que se desarrolle su vida. El entorno de un personaje significa la vida en el hogar, el estado civil de los padres, la capacidad de obtención de ingresos, si es divorciado, viudo, compatible o incompatible. ¿De qué manera el personaje afecta a sus amigos, y cómo le afectan a él?, ¿Cuál es su actitud y aptitud en la escuela, sus materias favoritas?, etc. [23]

• Psicológica del personaje : Esta dimensión es el resultado de las dos dimensiones

anteriores. Aquí se da vida a las aspiraciones, frustraciones, temperamentos, actitudes, y complejos de los personajes. Para entender la acción de un personaje, se debe primero encontrar su motivación. Si se tiene un conocimiento íntimo en la formación en estos tres ámbitos puede obtenerse una idea de la motivación del personaje [23].

El grado de profundización que se debe alcanzar en estas dimensiones depende de la importancia del personaje en la historia. No es necesario ser tan detallista en un personaje que solo se presentará en una o dos escenas, mientras que el protagonista y actores principales deben tener toda la atención necesaria [23]. Existen diferentes tipos de personajes en un videojuego:



21

• Personaje jugador: Es el más importante del juego debido a que es el protagonista, es el más complicado y desafiante al momento de escribir la historia. Un personaje jugador o PJ (PC en inglés) es un personaje creado para ser controlado por el jugador, además, son los únicos con la capacidad de tomar decisiones según el criterio del jugador, en torno a ellos gira toda la acción del juego. Los PJ se crean a partir de los parámetros que los definen durante el transcurso del juego, estos van evolucionando, aprendiendo y obteniendo poderes (mientras que un personaje no jugador, al aparecer tan solo en un determinado momento del juego, no evoluciona a lo largo del tiempo). Los PJ tiene la posibilidad de tomar diferentes caminos que le llevarán hasta distintas metas, ésta es una de sus principales características, razón por la cual, los jugadores suelen acostumbrarse a cierto tipo de personaje, y al cambiar de juegos la mayoría tiende a elegir personajes de la misma raza o, al menos, de comportamientos o actitudes similares a las de aquellos con los que ya ha jugado [18].

• Personaje no jugador: Son los personajes controlados por el servidor o el computador. Conocidos comúnmente como NPC (Non Player Characters), los cuales tienen una misión específica dentro de la historia del juego, por ejemplo, es el mago que da respuestas para enigmas que se presentan en medio del juego, el rey que requiere de los servicios del protagonista, el aliado que conduce al protagonista por un gran misterio, y, por ultimo puede ser el villano de la historia al que el protagonista tarde o temprano derrotará [18].

• Personaje pivote: Es el personaje que lanza la acción entre el protagonista y el antagonista, es quien pone a la historia en movimiento porque crea el conflicto y hace que el juego cobre vida [18].

Cada uno de los tipos de personajes anteriores puede representar un papel que será de gran importancia para el desarrollo de la historia. Entre estos papeles se encuentran:

• El Héroe: Es el personaje con el que más se identifica las personas cuando leen, ven o juegan una historia. Normalmente suele ser porque el héroe es el protagonista, el más importante de la historia debido a que, esta se centra en los sucesos que le ocurren a este personaje [24].

• El Tutor del héroe: Todo héroe, sin importar las condiciones sociales y culturales en las que se encuentre, siempre va a encontrar en su camino a una figura sabia, anciana y que le enseñará cómo superar las mayores dificultades [24].

• La Princesa: La princesa es aquella figura que complementa al héroe. Considerada también la fuerza que motiva al héroe a superar todas las pruebas que se le interpongan. Es común ligarla al héroe en una relación sentimental, dejando una señal de romanticismo en la historia [24].

• El Villano: El MAL (con mayúsculas) es el comienzo de toda buena historia. El elemento maligno, el personaje contrario al héroe, que cambia el mundo del protagonista y tiene que luchar contra él [24].



22

2.1.3. Agentes Software

2.1.3.1. ¿Qué es un Agente? Aunque no hay una definición unificada en cuanto a qué es un agente, un intento de unificar los esfuerzos para el desarrollo de esta tecnología puede encontrarse en FIPA (Foundation for Intelligent Phisical Agents) [25] donde se define a los agentes como una entidad de software con un grupo de propiedades entre las que se destacan el ser capaz de actuar autónomamente en un ambiente, comunicarse directamente con otros agentes, estar condicionado por un conjunto de tendencias u objetivos, manejar recursos propios, ser capaz de percibir su ambiente y tomar de él una representación parcial, además, ser una entidad que posee habilidad y ofrece servicios, que puede reproducirse, etc. De forma general, varios autores reconocen en los agentes diversas propiedades, entre las que se destacan el ser autónomos, reactivos, pro-activos y tener habilidad social [25]. El Agente AIMA “Un agente es cualquier cosa que pueda ser vista percibiendo su entorno a través de sensores y actuado hacia el entorno a través de unos efectores.” [26] El Agente Maes “Los agentes autónomos son sistemas computacionales que habitan en entornos dinámicos complejos, percibiendo y actuando autónomamente en ese entorno, y realizan un conjunto de metas o tareas para las que han sido diseñados.” [27] El Agente KidSim “Definiremos un agente como una entidad software persistente dedicada a un propósito específico. La ‘persistencia’ distingue a los agentes de las subrutinas los agentes tienen sus propias ideas sobre cómo ejecutar tareas, sobre sus agendas. Con ‘propósito específico’ se distinguen los agentes de las aplicaciones multifunción, que son típicamente más pequeños.” [28] El Agente Hayes-Roth “Los agentes inteligentes realizan continuamente tres funciones: percibir condiciones dinámicas en el entorno, actuar afectando a las condiciones del entorno, y razonar para interpretar lo percibido; resuelven problemas, muestran interfaces y determinan acciones.” [29] El Agente IBM “Los agentes inteligentes son entidades software que llevan a cabo un conjunto de operaciones en beneficio de un usuario u otro programa con algún grado de independencia o autonomía, y haciendo esto, emplean algún conocimiento o representación de las metas y deseos del usuario.” [30] El Agente Wooldridge y Jennings “Es un hardware o más comúnmente un sistema software basado en computador que disfruta de las siguientes propiedades” [31]:

Autonomía: los agentes operan sin la intervención directa de personas u otros, y tienen algún tipo de control sobre sus actuaciones y estado interno. Habilidad social: los agentes interactúan con otros agentes (posiblemente humanos) vía algún tipo de lenguaje de comunicación de agentes. Reactividad: los agentes perciben el entorno o ambiente, (lo que representa la palabra físicamente, un usuario vía una interfaz de usuario, una colección de otros



23

agentes, Internet, o quizás todos ellos combinados), y responde rápidamente a cambios que ocurren en dicho entorno. Pro-actividad: los agentes no actúan simplemente en respuesta a su entorno, sino que son capaces de exhibir ‘comportamiento dirigido hacia el objetivo’, tomando la iniciativa”con ligeras modificaciones de enfoques, otros autores también reconocen estas propiedades.

2.1.4. Propiedades de los Agentes

• Inteligencia: Es difícil de definir con precisión. Cuando se aplica a los agentes, se podría definir la inteligencia como algunas capacidades de alto nivel, es decir, la capacidad del agente para razonar sobre su conocimiento, aprender e inferir nuevos conocimientos y planificar las acciones consecuentes para alcanzar sus objetivos. En este caso, la inteligencia tiene el mismo sentido que el término "inteligencia artificial" [32][33].

• Autonomía: Existen diferentes formas de entender el término "autonomía". En el

sentido más común (absoluto), la autonomía se refiere a lo impredecible del comportamiento del agente: cuanto más impredecible sea, más autonomía aparecerá. Sin embargo, la autonomía absoluta no se aplica muy bien a los agentes ya que, de acuerdo con la mayoría de definiciones, un agente debe servir para algunos propósitos que lo limitan. Un tipo más útil de autonomía es la "autonomía social", que se refiere a la autonomía del agente cuando es analizado en una sociedad de agentes. No obstante, las relaciones sociales más comunes como la cooperación, coordinación y el compromiso, limitan al agente. Finalmente, la ejecución de la autonomía se refiere a la capacidad del agente para elegir y llevar a cabo la acción adecuada en el momento oportuno (técnicas de planificación). De hecho, al diseñar un agente, se tiene que encontrar un fino equilibrio entre autonomía y servidumbre. Un nivel inferior puede consistir en un agente que represente a un usuario, como el bien conocido PDA (Asistente Personal Digital) [32][33].

• Racionalidad: Se aplica esencialmente a los agentes autónomos e inteligentes. Los

agentes racionales tienden a elegir y realizar acciones que maximicen su esperada utilidad en función de sus percepciones y de nuestro propio conocimiento. La racionalidad también implica que la acción elegida sea consistente con los deseos y creencias del agente [32][33].

• Movilidad: Es la capacidad que tiene un agente para iniciar su ejecución en

cualquier sitio, y desplazarse a otro entorno (llevando consigo datos y códigos) para continuar su ejecución [32]. El término "movilidad" dividió a la comunidad de agentes en dos escuelas: la de los que argumentan que la movilidad no es un aspecto esencial (la comunidad de multi-agentes DAI, esencialmente académicos) y la de los que afirman que los agentes móviles son el futuro de los agentes (comunidad de programadores orientados a objetos) [33]. La programación basada en agentes móviles genera un nuevo paradigma que realza la flexibilidad y eficacia del diseño



24

y ejecución de las aplicaciones distribuidas, y reduce el ancho de banda de red requerido[32]

• Comunicación: Es un aspecto crucial para un agente, que, por definición, tiene que

comunicarse durante su vida con la entidad en nombre de la que actúa, y con los otros agentes con los cuales necesita colaborar[32]. El nivel de interacción/comunicación depende en gran medida del nivel de conocimiento del agente, que se desenvuelve entre "datos", "información" y "conocimiento". Los datos se corresponden con el nivel más básico, que puede ser el contenido de una variable, un archivo, etc. La información está mucho más estructurada y puede consistir en la descripción de parte de un equipo de telecomunicación, un documento XML (eXtensible Markup Language) electrónico), o un correo electrónico (con datos asociados) [33]. El conocimiento consiste en información estructurada y reglas lógicas. Se pueden asociar con cada nivel de información los lenguajes de comunicación y protocolos adecuados. Por ejemplo, un agente puede usar FTP (Protocolo de Transferencia de Archivos) para enviar un archivo, o llamar al método de otro agente para obtener o transmitir información. Igualmente, el HTTP (HyperText Transfer Protocol) se puede utilizar para transmitir descripciones XML [32]

• Sociabilidad: los agentes son capaces de interactuar con otros agentes (humanos o no) a través de un lenguaje de comunicación entre agentes [33]

• Reactividad: los agentes son capaces de percibir estímulos de su entorno y reaccionar a dichos estímulos [32]

• Proactividad, iniciativa: los agentes no son sólo entidades que reaccionan a un estímulo, sino que tienen un carácter emprendedor, y pueden actuar guiados por sus objetivos [32]

• Veracidad: Suposición de que un agente no comunica información falsa a propósito [32]

• Benevolencia: Suposición de que un agente está dispuesto a ayudar a otros agentes si esto no entra en conflicto con sus propios objetivos. [33]

Finalmente, se pueden usar lenguajes para intercambiar información entre agentes que se encuentren basados en la Speech Acts Theory, como KQML/KIF (Knowledge Query and Manipulation Language/Knowledge Interchange Format) [KQML, KIF], o el lenguaje de comunicación de agentes FIPA (Formation for Intelligent Physical Agents) pueden ser usados. [25]

2.1.5. Metodologías de Agentes Las técnicas convencionales de ingeniería de software (Proceso Unificado), no tienen en cuenta las necesidades de especificación de los Sistemas Multi-agente, como la especificación de planificación de tareas, intercambio de información con lenguajes de



25

comunicación orientados a agentes, movilidad del código o motivación de los componentes del sistema. Por esta razón, se plantean nuevas metodologías basadas en agentes tales como: BDI, Vowel Engineering, MAS-CommonKADS, GAIA. Estas metodologías parten de un modelo informal en la mayoría de casos, de cómo debe ser un Sistema Multi-agente y dan guías para su construcción. Las primeras metodologías, consistían en una lista breve de pasos a seguir. En la actualidad, aunque es posible encontrar varios progresos en el intento de integrar metodologías orientadas a agentes con la ingeniería del software clásica, aún no se alcanza la madurez que se puede encontrar en metodologías convencionales como el Proceso Unificado. El motivo principal para esta falencia radica en que todavía no existen herramientas genéricas de soporte y un lenguaje para la especificación de los Sistemas Multi-Agentes que permitan trabajar de forma similar a como se trabaja en Rational Rose o Power Disegner. Algunas de las metodologías más usadas hoy en día son: 2.1.5.1. MaSE (Multi-agent systems Software Engineering) es una metodología basada en el ciclo de vida clásico del software, con un entorno propio de desarrollo (agentTool) el cual permite el análisis, diseño y construcción sistemas multi-agente heterogéneos [34]. Se concibe como una abstracción del paradigma orientado a objetos donde los agentes son especializaciones de objetos, en lugar de simples objetos, con métodos que pueden invocarse desde otros objetos. Los agentes se coordinan unos con otros vía conversaciones, pero no son considerados entes autónomos y sociales, sino simples procesos que se comunican para alcanzar metas individuales y del sistema. En MaSE los agentes son simplemente una abstracción conveniente, que puede o no poseer inteligencia. En este sentido, los componentes inteligentes y no inteligentes se gestionan igualmente dentro de la misma estructura [34]. Dado el enfoque inicial, los agentes se ven como especializaciones de objetos. MaSE se divide en dos fases principales las que a su vez se dividen en diferentes pasos los cuales son necesarios para su elaboración.

• Análisis :

Capturar los objetivos: En este paso se busca como tareas principales la identificación y estructuración de los objetivos principales del sistema, dejado de lado por el momento las actividades o desarrollos que permiten alcanzar dichos objetivos centrándose en su análisis y estructuración según su importancia[34]. Aplicar los casos de uso: En este paso se hace necesario definir los casos de uso para explicar el comportamiento deseado del sistema. Luego se procede a estructurar los casos de uso en diagramas de secuencia mostrando la secuencia de eventos entre roles y, como resultado, define la mínima comunicación necesaria entre ellos. Refinar roles: Es necesario asegurase de que todos los objetivos son tenidos en cuenta asignando un rol a cada uno, siendo desempeñado este último por al menos un agente en el diseño final. Pese a que, generalmente, cada objetivo es mapeado a un rol individual, existen situaciones en las que conviene asignar más de un objetivo a un mismo rol, por motivos de eficiencia. Este tipo de decisiones son basadas en conceptos clásicos de ingeniería del software como la cohesión



26

funcional, comunicacional, procedural o temporal. También podría ser por distribución de recursos o por cuestiones especiales de las interfaces. Finalmente, los roles son captados en el modelo de roles. Una vez obtenidos los roles, se procede a convertirlos en clases de agentes con su comportamiento interno y sus conversaciones entre ellos, este paso resulta ser uno de los más complejos de esta metodología. Para conseguir esto, se deben definir tareas de alto nivel que puedan ser transformadas en funcionalidades específicas de agentes. Estas funcionalidades nos ayudan a definir los componentes internos de los agentes y los detalles de las conversaciones en que participan. Todo esto queda reflejado en el modelo de roles detallado

• Diseño

Crear clases de agentes: Las clases de agentes son identificadas a partir de los roles y descritas en el diagrama de clases de agentes. Nuevamente, lo más común es establecer una correspondencia uno a uno entre roles y clases de agente. Sin embargo, el diseñador puede decidir unificar varios roles en una clase o crear varias clases de un mismo rol [34]. Una vez creado el diagrama de clases, la organización del sistema queda definida. En este punto es bueno fusionar roles que tengan en común un gran volumen de tráfico de mensajes para optimizar el sistema Construir conversaciones: Este paso se encuentra íntimamente ligado con el siguiente (Ensamblaje), específicamente una conversación consiste en dos diagramas de clases de comunicación, uno para el emisor y otro para el receptor. Un diagrama de clases de comunicación es un par de máquinas de estados finitos que definen una conversación entre dos clases agente participantes . Ensamblar clases de agentes: En este paso se crea el interior de los agentes. Este proceso se simplifica usando un lenguaje de modelado arquitectónico que combina la naturaleza abstracta de los lenguajes tradicionales de descripción arquitectónica con el leguaje de restricción de objetos, que permite al diseñador especificar detalles de bajo nivel Diseño del sistema: En esta fase se decide la configuración final del sistema a ser implementado. Hasta ahora en MaSE sólo se consideran sistemas estáticos, los móviles aun no es posible modelarlos. En MaSE se define la arquitectura global del sistema mediante diagramas de despliegue para mostrar el número, tipo y localización de los agentes. En este momento también se toman las decisiones de implementación que no se habían tomado antes, como el lenguaje de programación a usar o el “framework” para las comunicaciones

La herramienta agentTool es el software de soporte que actualmente implementa los siete pasos del proceso MaSE con soporte para transformar modelos de análisis en modelos de diseño. Permite crear de modo visual todos los diagramas del proceso de desarrollo, pudiendo realizar cualquiera de los 7 pasos en el orden que se prefiera (siempre respetando las dependencias entre unos y otros). Además, dispone de una base de conocimiento persistente, un verificador de conversaciones y generación automática de código.



27

Los estudios recientes sobre MaSE y agentTool se concentran en dar soporte a agentes móviles. El paso inicial para dar este soporte es el de incluir una actividad de movimiento que, básicamente, pide que el agente cambie de lugar. El proceso retorna verdadero o falso, que indica si el agente se ha movido o no. Este añadido a la fase de análisis permite al analista especificar cuándo debe ocurrir un movimiento, su lugar de destino, y saber si se ha podido realizar la operación [34] 2.1.5.2. GAIA GAIA es una metodología para el diseño de sistemas basados en agentes cuyo objetivo es obtener un sistema que maximice alguna medida de calidad global (no se llega a detallar cuál). GAIA pretende ayudar al analista a ir sistemáticamente desde unos requisitos iniciales a un diseño que esté lo suficientemente detallado como para ser implementado directamente. En GAIA se entiende que el objetivo del análisis es conseguir comprender el sistema y su estructura sin referenciar ningún aspecto de implementación. Esto se consigue a través de la idea de organización. Una organización en GAIA es una colección de roles, los cuales mantienen ciertas relaciones con otros y toman parte en patrones institucionalizados de interacción con otros roles. Los roles agrupan cuatro aspectos: responsabilidades del agente, los recursos que se le permite utilizar, las tareas asociadas e interacciones [35].

• Análisis GAIA propone trabajar inicialmente con un análisis a alto nivel. El objetivo de este análisis consiste en definir los elementos abstractos que conformarán el sistema, es decir, entender el sistema y su estructura sin entrar en detalles de implementación. En esta parte se obtendrá la visión de la organización como un conjunto de roles que tienen relación unos con otros, así como del entorno en el que esta embebido el sistema[35]. En este análisis se usan dos modelos:

Modelo de roles: Se utiliza para identificar los roles clave en el sistema junto con sus propiedades definitorias. Modelo de interacciones: Define las interacciones mediante una referencia a un modelo institucionalizado de intercambio de mensajes, como el FIPA-Request.

• Diseño

El diseño se puede subdividir en dos subfases: diseño de la arquitectura, que en gran medida corresponde a la fase abstracta del método y una diseño detallado, donde se pasa de la abstracción a la concreción, obteniendo modelos de bajo nivel fácilmente implementables como [35]: Modelo de agentes: define los tipos de agente que existen, cuántas instancias de cada tipo y qué papeles juega cada agente.

Modelo de servicios: identifica los servicios (funciones del agente) asociados a cada rol.

Modelo de conocidos: define los enlaces de comunicaciones que existen entre los agentes.



28

A partir de aquí, los autores de GAIA proponen aplicar técnicas clásicas de diseño orientado a objetos. Sin embargo, GAIA declara que queda fuera de su ámbito. Esta metodología sólo busca especificar cómo una sociedad de agentes colabora para alcanzar los objetivos del sistema, y qué se Requiere de cada uno para lograr esto último [35]. 2.1.5.3. MESSAGE MESSAGE trata de integrar resultados de las anteriores metodologías. Propone el análisis y diseño del SMA desde cinco puntos de vista para capturar los diferentes aspectos de un SMA [36]: Organización: que captura la estructura global del sistema. Tareas/Objetivos: que determina qué hace el SMA y sus agentes constituyentes en términos de los objetivos que persiguen y las tareas implicadas en el proceso. Agente: que contiene una descripción detallada y extensa de cada agente y rol dentro del SMA. Dominio: que actúa como repositorio de información (para entidades y relaciones) concernientes al dominio del problema; y el de Interacción, que trata las interacciones a distintos niveles de abstracción. Estos elementos están presentes en los dos modelos fundamentales que propone MESSAGE: el modelo de análisis y el modelo de diseño. El modelo de análisis se limita a generar modelos a partir de los meta-modelos. El modelo de diseño de esta metodología no llegó a concretarse completamente. Se decidió que el propósito del diseño sería producir entidades computacionales que representen el SMA descrito en el análisis. Por ello, cada artefacto producido en el análisis debería transformarse en una entidad computacional o varias cuyo comportamiento fuera el que se esperaba en el análisis. Esto significa que las entidades del análisis se deberían traducir a subsistemas, interfaces, clases, signaturas de operaciones, algoritmos, objetos, diagramas de objetos y otros [36]. MESSAGE aporta mejoras en cuanto a conceptos de ingeniería respecto de las alternativas existentes, entre ellas el desarrollo dentro de un paradigma de ingeniería del software (el Proceso Unificado), aportación de métodos para la traducción de entidades de análisis a entidades de diseño y guías para la generación de los modelos. Sin embargo, los objetivos de MESSAGE no se completaron totalmente. La integración con el Proceso Unificado no fue total, ya que las actividades definidas no se adecuaban a las necesidades reales y no se indicó cómo encajaban dentro de este proceso. Además, faltó trabajo en el estudio de las interdependencias entre los distintos modelos propuestos [36]. 2.1.5.4. INGENIAS Es una metodología creada a partir de la evolución de las ideas de MESSAGE. INGENIAS profundiza en los elementos mostrados en el método de especificación, en el proceso de desarrollo, además de incorporar nuevas herramientas de soporte y ejemplos de desarrollo [37]. INGENIAS, como MESSAGE, define un conjunto de meta-modelos (una descripción



29

de alto nivel de qué elementos tiene un modelo) con los que se debe describir el sistema. Los meta-modelos indican qué falta por describir: agentes aislados, organizaciones de agentes, el entorno, interacciones entre agentes o roles, tareas y objetivos. Estos metamodelos se construyen mediante un lenguaje de meta-modelado, el GOPRR (Graph, Object, Property, Relationship, and Role). En la construcción de estos meta-modelos se integran resultados de investigación en forma de entidades y relaciones entre entidades [37]. La instanciación de estos meta-modelos produce diagramas, los modelos, similares a los que se usa en UML, con la diferencia de que estos diagramas se han creado exclusivamente para definir el sistema multi-agente. El proceso de instanciación de los meta-modelos no es trivial. Existen muchas entidades y relaciones a identificar, además de dependencias entre distintos modelos. Por ello, INGENIAS define un conjunto de actividades cuya ejecución termina en un conjunto de modelos. Estas actividades a su vez se organizan siguiendo un paradigma de ingeniería del software, el Proceso Unificado. La ejecución de actividades para producir modelos se basa en la herramienta INGENIAS IDE, una herramienta para modelado visual. Esta herramienta almacena la especificación del sistema utilizando XML. Desde la especificación en XML, se plantea el procesarla [37]:

- Para generar código. Genera código rellenando plantillas de código con información de la especificación.

- Para generar la documentación. De una forma similar a la generación de código, se parte de plantillas de documentación que se completan utilizando información de los modelos Tanto la herramienta de análisis/diseño como el editor se pueden encontrar en http://ingenias.sourceforge.net. Desde esta web también se tiene acceso a ejemplos de especificación siguiendo la metodología.

2.1.5.5. MAS-CommonKADS La metodología MAS-CommonKADS está basada en CommonKADS, aportando una serie de modelos para desarrollar las fases de análisis y de diseño de sistemas multiagente. La principal característica es la incorporación de técnicas orientadas a objetos a CommonKADS, la cual es tomada como eje fundamental a lo largo de todo el proceso [38]. En MAS-CommonKADS se proponen diferentes puntos de vista del sistema a analizar, lo cual se traduce en diferentes fases, que a continuación se comentan brevemente. Conceptuación En la fase de conceptuación se analiza el sistema desde el punto de vista del usuario del sistema. Es una fase un tanto informal, donde se propone un análisis centrado en el usuario para la captura de requisitos. El empleo de los casos de uso es la técnica por la que se apuesta para la realización de esta fase. Organización El modelo de organización analiza, por una parte, la empresa (organización) en que va a ser introducido el sistema, y la posible repercusión del sistema en la empresa.



30

Por otra parte, el modelo de organización sirve para describir las relaciones de la sociedad multiagente entre sí y para con su entorno. Agente El modelo de agente describe las propiedades y características de cada agente. Es una de las fases más importantes, consta de una subfase de identificación de agentes (con diferentes opciones) y una subfase de descripción detallada de la que debe realizar cada agente. Tareas El modelo de tareas describe las funciones (o tareas) que desarrolla el sistema, en realidad son actividades relacionadas para alcanzar un objetivo. Este modelo se refina según la naturaleza de las tareas (cognitivas, comunicación hombre-máquina, comunicación entre agentes) en los modelos de experiencia, comunicación y coordinación, respectivamente a realizar posteriormente. Experiencia En este modelo se describe como se llevan a cabo tareas cognitivas. Es decir, aquellas tareas que requieren conocimiento para ser llevadas a cabo y que permitirán caracterizar al agente que desarrolle esa tarea como un sistema basado en el conocimiento. Para ello se realiza un modelado con KADS actualizado. Es el modelo que más diferencia esta metodología de otras, pues es claramente un elemento de la llamada ingeniería del conocimiento. Coordinación El modelo de coordinación desarrolla y describe las interacciones entre los agentes de un sistema multiagente. La idea del modelo es que los agentes ofrecen servicios para realizar tareas a otros agentes. El elemento principal del modelo es la conversación, de la cual derivan el resto de elementos como: protocolo, intervención, servicio, mensaje, etc. Este modelo está íntimamente ligado con el modelo de agente ya que existen interdependencias entre ambos. Diseño Describe las decisiones que deben tomarse para que el modelo definido en los modelos anteriores pueda ser implementado mediante un lenguaje de programación. En este modelo se desarrolla un diseño de la red, un diseño de los agentes y un diseño de la plataforma. El modelo de red proporciona a los agentes una visión uniforme de la red, donde entre otras cosas se determina la presencia o no de agentes auxiliares. El diseño de los agentes describe fundamentalmente la arquitectura seleccionada para cada agente. Finalmente, el diseño de la plataforma permite seleccionar el sistema operativo y la plataforma tanto software como hardware.



31

Esta secuencia de fases resulta bastante interesante al reunir técnicas típicas de ingeniería del software con técnicas de la ingeniería del conocimiento. Uno de los problemas que observamos en esta aproximación es la dificultad de su aplicación al igual que ocurre con CommonKADS.



32

3. MODELO METODOLÓGICO

3.1. Definición. Antes de presentar el resultado de la investigación se debe definir: “modelo metodológico” para clarificar la terminología adoptada en el proyecto. Un modelo metodológico puede definirse, en un sentido amplio en base al concepto de metodología, esto implica la definición de un conjunto de métodos o técnicas que ayudan en el desarrollo de un producto software, tal como señala Rumbaugh [39]: “Una metodología de ingeniería software es un proceso para la producción organizada del software, empleando una colección de técnicas predefinidas y convenciones en las notaciones. Una metodología se presenta normalmente como una serie de pasos, con técnicas y notaciones asociadas a cada paso... Los pasos de la producción del software se organizan normalmente en un ciclo de vida consistente en varias fases de desarrollo.” De acuerdo con Pressman [40], las principales actividades de una metodología son: • La definición y descripción del problema que se desea resolver. • El diseño y la descripción de una solución que se ajuste a las necesidades del usuario. • La construcción de la solución. • La prueba de la solución implementada. Entre los requisitos que debe cumplir una metodología se pueden citar los siguientes [41]:

• La metodología está documentada: el procedimiento de uso de la metodología está contenido en un documento o manual de usuario.

• La metodología es repetible: cada aplicación de la metodología es la misma. • La metodología es enseñable: los procedimientos descritos tienen un nivel

suficientemente detallado y existen ejemplos para que personal cualificado pueda ser instruido en la metodología.

• La metodología está basada en técnicas probadas: la metodología implementa procedimientos fundamentales probados u otras metodologías más simples.

• La metodología ha sido validada: la metodología ha funcionado correctamente en un gran número de aplicaciones.

• La metodología es apropiada al problema que quiere resolverse.



33

3.2. Revisión de metodologías para agentes. El primer paso para la adaptación de una metodología que permita la construcción de personajes fue la revisión de cada uno de los modelos de agentes, analizando sus ventajas y desventajas, encontrando la metodología que más se adapte a las características propias de los personajes en videojuegos de aventura. En la siguiente tabla se presentan las metodologías que fueron estudiadas para la investigación y se muestran los diferentes modelos que cada una de ellas posee:

METODOLOGIA DESCRIPCION MODELOS

MASE Se concibe como una abstracción del paradigma orientado a objetos donde los agentes son especializaciones de objetos. En lugar de simples objetos, con métodos que pueden invocarse desde otros objetos, los agentes se coordinan unos con otros vía conversaciones y actúan pro activamente para alcanzar metas individuales y del sistema.

� Capturar los objetivos: Es la primera fase de la metodología. Toma las especificaciones iníciales del sistema y las transforma en un conjunto de metas del sistema.

� Transformar metas en roles: En este paso las metas anteriormente estructuradas se transforman en una forma más útil para la construcción de sistemas MultiAgentes: los roles y sus tareas asociadas.

� Aplicar casos de uso: Tras la creación de los roles, se asocian las tareas para cada rol. Cada meta asociada a un rol puede tener tareas que definan los detalles de cómo se logra.

� Crear clases de Agentes: Llegada esta fase, las clases agente se identifican a partir de los roles. El resultado es el Diagrama de Clases Agente, que muestra las clases agente junto con las conversaciones que mantienen dichos agentes.

� Construir conversaciones: Una conversación bajo MASE define el protocolo coordinado entre dos agentes. La metodología define específicamente una conversación como dos Diagramas de Comunicación de Clases, uno para el iniciador de la conversación y otro para el que responde.

� Ensamblar clases de agentes: En esta etapa de MASE se construye la parte interna de una clase agente.



34


� Diseño del sistema: Es la fase final de la metodología MASE. En esta fase es donde se instancia las clases agente. Se utiliza un diagrama de desarrollo para mostrar el número, tipo y localidad de los agentes dentro del sistema.

GAIA GAIA es una metodología para el diseño de sistemas basados en agentes cuyo objetivo es obtener un sistema que maximice alguna medida de calidad global (no se llega a detallar cuál). GAIA pretende ayudar al analista a ir sistemáticamente desde unos requisitos iníciales a un diseño que, según los autores, esté lo suficientemente detallado como para ser implementado directamente.

� Roles: Los modelos de roles organizacionales describen de manera precisa todos los roles que constituyen la organización computacional, en términos de sus funcionalidades, actividades y responsabilidades, y los términos de sus protocolos y patrones de interacción.

� Interacciones: Corresponde a todos los principios, procesos, protocolos, estrategias de comunicación, políticas sociales y estructuras que permiten a los agentes transportar información

� Agentes: El modelo de agentes define el tipo de agentes que creará el sistema, tanto durante su desarrollo como durante la ejecución.

� Servicios: Identifica los servicios que son necesarios para llevar a cabo el rol del agente, como su nombre indica.

MESSAGE Propone el análisis y diseño del SMA desde cinco puntos de vista para capturar los diferentes aspectos de un SMA: el de Organización, el de Tareas/Objetivos, Los objetivos que persiguen y las tareas implicadas en el proceso; el de Agente, que contiene una descripción detallada y extensa de cada agente y rol dentro del SMA.

� Organización: captura la estructura global del sistema.

� Objetivos/Tareas: determina qué hace el SMA y sus agentes constituyentes en términos de los objetivos que persiguen y las tareas implicadas en el proceso.

� Agentes/Roles: contiene una descripción detallada y extensa de cada agente y rol dentro del SMA

� Interacción: trata las interacciones a distintos niveles de abstracción.

� Dominio: actúa como repositorio de información (para entidades y relaciones) concernientes al dominio del problema.

INGENIAS INGENIAS como evolución de las ideas de MESSAGE. INGENIAS

� Agentes: Se usa para describir agentes particulares



35


profundiza en los elementos mostrados en el método de especificación, en el proceso de desarrollo, además de incorporar nuevas herramientas de soporte y ejemplos de desarrollo.

excluyendo las interacciones con otros agentes. Se centra en la funcionalidad del agente y en el diseño de su control.

� Tarea: Se basa en encontrar las consecuencias que tiene la ejecución de tareas y por qué se deberían ejecutar. Justifica la ejecución de tareas basándose en objetivos.

� Interacciones: Define las interacciones entre los agentes o entre agentes y humanos, se definen a alto nivel, en diseño se detalla el protocolo de interacción.

� Entorno: Define las entidades del entorno del SMA con las que vaya a interactuar.

ZEUS La metodología ZEUS propone un desarrollo en cuatro etapas: el análisis del dominio, el diseño de los agentes, la realización de los agentes y el soporte en tiempo de ejecución. Las etapas soportadas por la herramienta son la de realización de los agentes y la de soporte en tiempo de ejecución. Las etapas anteriores se basan en el uso de roles para analizar el dominio y en su asignación a agentes.

� Roles: (Kendall) Cada rol describe una posición y un conjunto de responsabilidades en un cierto contexto. Los roles deben: - Ser modulares - Alta cohesión - No disponer de

responsabilidades extrañas - Ser completo (no triviales) - Bajo acoplamiento.

MAS – CommonKADS

Esta metodología extiende CommonKADS aplicando ideas de metodologías orientadas a objetos para su aplicación a la producción de SMA. La metodología CommonKADS gira alrededor del modelo de experiencia y está pensada para desarrollar sistemas expertos que interactúen con el usuario. De hecho considera sólo dos agentes básicos: el usuario y el sistema. MAS-CommonKADS extiende los modelos de CommonKADS para tener en cuenta la posibilidad de que dos o más componentes del sistema interactúen.

� Conceptuación: Permite obtener una primera descripción del problema y la determinación de los casos de uso que pueden ayudar a entender los requisitos informales y probar el sistema.

� Agentes: Específica las características de un agente: sus capacidades de razonamiento, habilidades, servicios, sensores, efectores, grupos de agentes a los que pertenece y clase de agente. Un agente puede ser un agente humano, software, o cualquier entidad capaz de emplear un lenguaje de comunicación de agentes.



36


� Tarea: Describe las tareas que los agentes pueden realizar: los objetivos de cada tarea, su descomposición, los ingredientes y los métodos de resolución de problemas para resolver cada objetivo.

� Experiencia: Describe el conocimiento necesitado por los agentes para alcanzar sus objetivos. Sigue la descomposición de CommonKADS y reutiliza las bibliotecas de tareas genéricas.

� Organización: es una herramienta para analizar la organización humana en que el sistema multiagente va a ser introducido y para describir la organización de los agentes software y su relación con el entorno.

� Diseño: Mientras que los otros cinco modelos tratan del análisis del sistema multiagente, este modelo se utiliza para describir la arquitectura y el diseño del sistema multiagente como paso previo a su implementación.

MASINA

(Multi Agent Systems in Automation). Esta metodología usa como base a MAS-CommonKADS, proponiendo algunas extensiones, modificaciones y sustituciones de los modelos definidos en MAS-CommonKADS. MASINA permite plasmar elementos fundamentales del área de SMA, como representar la noción de inteligencia en un agente (modelado de agentes inteligentes), a nivel colectivo, los mecanismos de coordinación entre agentes (planificación emergente, resolución de conflictos, etc.), la comunicación directa o indirecta, entre otras cosas.

� Agentes: describe las características de cada agente, con dos extensiones particulares, una que permitir el uso de modelos de referencia para especificar un agente dato, y otra para modelar los niveles de abstracción del Sistema Multi-agentes

� Tareas: representa las actividades realizadas por los agentes para alcanzar sus objetivos, en nuestra extensión es posible especificar tareas que requieren el uso de técnicas inteligentes, así como describir el macro algoritmo de la tarea

� Inteligencia: describe los conocimientos, mecanismo de aprendizaje y métodos de razonamiento necesarios para



37


que los agentes cumplan sus objetivos

� Comunicación: agrupa las interacciones en conversaciones y define los mecanismos para que esas interacciones se lleven a cabo coherentemente

� Coordinación: describe los actos de habla (interacciones).

Tabla 1 - Revisión de Metodologías

Después del estudio realizado a cada metodología se aplicaron los requisitos que debe cumplir cada una de las fases de todas las metodologías, obteniendo como resultado lo siguiente:

2.1.6. Análisis

Los criterios del Análisis incluyen: • Documentado: ¿el método de análisis es útil, y está bien documentado? METODOLOGIA DOCUMENTADO

MASE Esta metodología divide cada uno de los pasos del análisis en 3 etapas más en donde cada uno de los resultados de una etapa es la entrada de la siguiente, facilitando de esta manera definir cada una de las funcionalidades del sistema, se encuentra bien documentada y se explica con un ejemplo cada etapa [34] [45].

GAIA Maneja el concepto de roles con el fin de entender el sistema sin necesidad de hablar de la implementación. Se trabaja con la idea de organización. Pero le falta detalle al momento de definir cada proceso. [43]

MESSAGE El sistema es visto como un conjunto de organizaciones que interactúan con recursos, actores y otras organizaciones. La idea es ir aumentado el nivel de detalle a medida que se conoce más del sistema a modelar. Se encuentra poco documentado. [36]

INGENIAS INGENIAS dispone de una cantidad enorme de entidades y relaciones. Su uso mediante la herramienta de soporte INGENIAS IDE, se encuentra bien documentada por el equipo GRASIA [37]

ZEUS El análisis se debe a la voluntad del desarrollador Basado en el modelado de roles, utilizando diagramas de clase UML y patrones [48].

MAS-CommonKADS

Esta metodología está bien documentada [38] [49] [50] [51], es la primera en incorporar la idea de proceso de ingeniería con el enfoque de Pressman [40] y describe con detalle cómo se debe definir el sistema teniendo en cuenta las dependencias entre los modelos. En la fase de análisis de MAS-COMMONKADS propone seis modelos: Conceptuación, Agentes, Tareas, Coordinación, Experiencia, Organización [38]



38

METODOLOGIA DOCUMENTADO

MASINA La fase de análisis de MASINA reduce a cinco los modelos propuestos en MAS-CommonKADS, los cuales se consideran necesarios para describir las características básicas de los SMA. MASINA hace uso de los modelos de agente, tareas, comunicación, coordinación y sustituye el modelo de experiencia de MAS-CommonKADS por el modelo de inteligencia. [52]

Tabla 2 – Análisis (Documentada)

• Dominios: ¿a qué dominios y problemas se aplica este método?

METODOLOGIA Dominios

MASE Esta metodología fue diseñada específicamente para modelar Sistemas Multiagente heterogéneos [34]. En ella se contempla a los agentes como entidades no necesariamente deben tener inteligencia que surgen como una especialización de los objetos, por lo cual, las técnicas que utiliza MaSE Provienen del paradigma orientado a objetos. [41]

GAIA Permite el modelado de sistemas de agentes heterogéneos y ayudar a pasar desde unos requisitos iníciales a un diseño que es lo suficientemente detallado como para ser implementado directamente. [43]

MESSAGE Se utiliza para construcción de SMA, y con una variación permite el manejo de sistemas en tiempo real. [36]

INGENIAS Se aplica a una gran variedad de problemas, puesto que combina el esfuerzo metodológico con el desarrollo de la herramienta[37].

ZEUS Es una herramienta para construir aplicaciones multi-agente colaborativas, Provee un entorno integrado para el desarrollo rápido de sistemas. [48]

MAS-CommonKADS

Al igual que CommonKADS fue desarrollada para sistemas expertos que interactúen con el usuario, la extensión MAS-CommonKADS permite tener en cuenta la posibilidad de que dos o más componentes del sistema interactúen entre sí formando un sistema multiagente. [38]

MASINA Una Metodología para Especificar Sistemas Multi-agentes, donde se utilizan técnicas inteligentes para la realización de tareas [42]

Tabla 3 – Análisis (Dominios)

• Facilidad de uso: ¿es el método de análisis fácil de comprender y de aplicar?

METODOLOGIA FACILIDAD DE USO

MASE Es fácil de entender debido a que maneja conceptos de rol y etapas similares a RUP, como en la creación de los casos de uso, también utiliza diagramas de interacción de UML aunque menos detallados [41].

GAIA Maneja el paradigma orientado a objetos y el concepto de rol. [43]

MESSAGE Los modelos son fáciles de entender ya que están basados en UML y están hechos de una forma visual. [36]

INGENIAS Es un esfuerzo arduo, para poder entenderlo, para aplicarlo pero después de comprenderlo, resulta muy completo y eficiente. [37]



39


ZEUS El método es arbitrario, y escogido por el desarrollador, puesto que se limita a estudiar cómo agrupar la funcionalidad del sistema dentro de cada rol [48]

MAS-CommonKADS

La información que hay que obtener se expresa con lenguaje natural, por lo que permite modelar diversos tipos de aplicaciones, pero le falta incluir formalismos que logren una definición más precisa y menos ambigua del SMA [38]

MASINA Al igual que MAS-CommonKADS, La información que hay que obtener se expresa con lenguaje natural, por lo que permite modelar diversos tipos de aplicaciones, pero le falta incluir formalismos que logren una definición más precisa y menos ambigua del SMA [42].

Tabla 4 – Análisis (Facilidad de uso)

• Ampliamente usada: ¿A sido utilizada en diferentes aplicaciones y funcionó

correctamente? METODOLOGIA AMPLIAMENTE USADA

MASE MaSE es una metodología académica que cuenta con el soporte de la Fuerza Aérea de los Estados Unidos. Una de sus aplicaciones fue la realización del proyecto “El Escondite” [53] [34].

GAIA GAIA cuenta con un grupo de investigación (Grupo de Ambientes Inteligentes Adaptativos) dedicado a ampliar la experiencia de esta metodología a partir de la realización de varios proyectos de investigación basados en esta metodología [43]

MESSAGE Esta metodología ha sido utilizada para el desarrollo de aplicaciones de telecomunicaciones en proyectos como: KIMSAC [54], AMASE [55], ABROSE [56], entre otros [36]

INGENIAS En el sitio web del GRASIA se encuentran listados varios proyectos en los que se trabaja con esta metodología, pero no se han publicado resultados. [37]

ZEUS En la actualidad existen grupos que trabajan con esta metodología e en sus proyectos como Citeseer [57]. Donde se encontraron los proyectos bien definidos pero no se encontraron resultados concretos [52]

MAS-CommonKADS

Esta metodología ha sido aplicada con éxito en varios proyectos de investigación, en diferentes campos, tales como la gestión inteligente de red (proyecto CICYT TIC94-0139 PROTEGER, Sistema Multiagente para Gestión de Red y Servicios) [50] y el desarrollo de aplicaciones con sistemas híbridos (proyecto ESPRIT-9119 MIX, Integración Modular de Sistemas Basados en Conocimiento Simbólicos y Conexionistas)[50]. Además, otros proyectos que se han llevado acabos en la Universidad Politécnica de Madrid.[38]

MASINA Entre los proyectos en los cuales se ha usado esta metodología es importante referenciar Definition of a Verification Method for the MASINA Methodology, pero no se encontraron resultados relacionados con dichos proyectos [42].

Tabla 5 – Análisis (Ampliamente Usada)

• Argumentada: ¿Las bases teóricas provienen de fundamentos probados o

metodologías más simples?



40

METODOLOGIA ARGUMENTADA

MASE Cuenta con el soporte de la fuerza aérea de los Estados Unidos, diseñada para modelar sistemas multiagente heterogéneos [34]. Las técnicas utilizadas se basan en el paradigma orientado a objetos [41].

GAIA Se basa en el paradigma orientado a objetos. [43]

MESSAGE Es una metodología resiente pero no se basa en ninguna metodología anterior. [36]

INGENIAS Esta metodología se encuentra fundamentada en MESSAGE. [37]

ZEUS Toma como base algunos de los conceptos de UML. Además se basa en conceptos muy comunes para el software como modularidad, alta cohesión, bajo acoplamiento, entre otros. [48]

MAS-CommonKADS

La metodología MAS-CommonKADS es una extensión de la metodología CommonKADS para modelar SMA, agregando aspectos de las metodologías orientadas a objetos como OMT, Ingenieria de Software Orientada a Objetos (OOSE) y Responsibility Driving Design (RDD). [38]

MASINA Esta metodología se encuentra fundamentada Mas-CommonKads. [42]

Tabla 6 – Análisis (Argumentada)

De acuerdo a la investigación realizada en cuanto al análisis se puede ver que la metodología que tiene mejor definido su proceso de análisis es MAS-CommonKADS , debido a que se encuentra mejor documentada, fuertemente argumentada apoyada en técnologias de desarrollo de software amplimanete conocidas y/o estándares de facto, la tabla siguiente muestra los resultados, obtenidos para el criterio de análisis:

METODOLOGIA ANALISIS

MASE 3 GAIA 2.5

MESSAGE 2 INGENIAS 3.2

ZEUS 1.5 MAS-CommonKADS 4.5

MASINA 2.5*

Tabla 7 – Evaluación Metodológica Análisis

2.1.7. Diseño

Los criterios de Diseño incluyen:

• Documentada: ¿el método de diseño es útil y está bien documentado? ¿Existen herramientas para apoyar el proceso de diseño?



41

METODOLOGIA DOCUMENTADA

MASE Existen diferentes artículos en donde se realizan todas las etapas del diseño para resolver un problema en particular. Cuenta con una herramienta de soporte llamada AgentTool.[34].

GAIA Falta detalle al momento de definir cada proceso. Aunque el impacto de esta metodología es notable cabe mencionar la ausencia de una herramienta de soporte para ella. [43]

MESSAGE Falta estereotipar el diseño. No posee una herramienta de soporte. [36] INGENIAS Muy documentado y respaldado por el grupo GRASIA. La herramienta

INGENIAS IDE. [37] ZEUS El método es arbitrario, y escogido por el desarrollador. Se encuentra

soportada en el entorno de desarrollo con su mismo nombre (ZEUS) [48]

MAS-CommonKADS

Muy documentado en la tesis doctoral de Carlos Ángel Iglesias Fernández, y posterior mente por otros estudios, Según la web de MAS-CommonKADS existen herramientas de soporte desarrolladas dentro del proyecto. Estas herramientas aparecen bajo el epígrafe MAST (MultiAgent Systems Tool). [38] Sin embargo, la única que se puede descargar no es una herramienta para apoyo al análisis y diseño, sino un conjunto de arquitecturas y frameworks de agentes. [38]

MASINA Poco documentada, se espera la liberación de la metodología por completo. Hasta el momento no cuenta con una herramienta definida. [42]

Tabla 8 – Diseño (Documentada)

• Facilidad de uso: ¿el método de diseño es fácil de comprender y de aplicar? METODOLOGIA FACILIDAD DE USO

MASE Es fácil de comprender porque se basa en los elementos descritos como agentes y sigue utilizando diagramas del UML como el diagrama de despliegue donde se representan los diferentes agentes, sus comunicaciones y su distribución física. [41]

GAIA Esta metodología se basa en la identificación de los roles principales que aparecen en el sistema, entendiendo rol como una descripción abstracta de la función esperada de una determinada entidad. [43]

MESSAGE Aunque esta metodología se basa en UML resulta algo complejo dado que no se ha terminado de concretar. [36]

INGENIAS El método está bien guiado para su entendimiento y tiene excelente enfoque para su aplicabilidad [37]

ZEUS El modelado de roles, propuesto no profundiza en la aplicación de la herramienta dentro del proceso de desarrollo. El ámbito de la metodología se limita a estudiar cómo agrupar la funcionalidad del sistema dentro de cada rol, dejando aparte consideraciones acerca de cómo organizar las tareas, definir las ontologías y las dependencias sociales, aspectos que son modelables dentro de la herramienta. [48]

MAS-CommonKADS

La información obtenida es expresada con lenguaje natural, lo que facilita en gran medida su comprensión y aplicación. [38]



42


MASINA Comparte con Mas-CommonKADS sus ventajas y desventajas al momento de ser aplicada en la fase de diseño.[42]

Tabla 9 – Diseño (Facilidad de uso)

• Validada: ¿A sido utilizada en diferentes aplicaciones y funciono correctamente?

METODOLOGIA VALIDADA

MASE Es una metodología académica que cuenta con el soporte de la Fuerza Aérea de los Estados Unidos. Donde una de sus aplicaciones fue la realización del proyecto “El Escondite” [53] [34].

GAIA GAIA cuenta con un grupo de investigación (Grupo de Ambientes Inteligentes Adaptativos [57]) dedicado a ampliar la experiencia de esta metodología a partir de la realización de proyectos de investigación basados en esta metodología [43]

MESSAGE Esta metodología ha sido utilizada para el desarrollo de aplicaciones de telecomunicaciones en proyectos como: KIMSAC[54], AMASE [55], ABROSE [56], entre otros [36].

INGENIAS En el sitio web del GRASIA se encuentran listados varios proyectos en los que se trabaja con esta metodología, pero no se han publicado resultados. [37]

ZEUS En la actualidad existen grupos que trabajan con esta metodología e en sus proyectos como Citeseer [57]. Donde se encontraron los proyectos bien definidos pero no se encontraron resultados concretos [48].

MAS-CommonKADS

Esta metodóloga ha sido aplicada con éxito en varios proyectos de investigación, en diferentes campos, tales como la gestión inteligente de red (proyecto CICYT TIC94-0139 PROTEGER, Sistema Multiagente para Gestión de Red y Servicios) [50] y el desarrollo de aplicaciones con sistemas híbridos (proyecto ESPRIT-9119 MIX, Integración Modular de Sistemas Basados en Conocimiento Simbólicos y Conexionistas). Además, otros proyectos que se han llevado acabos en la Universidad Politécnica de Madrid.[38]

MASINA Entre los proyectos en los cuales se ha usado esta metodología es importante referenciar Definition of a Verification Method for the MASINA Methodology, pero no se encontraron resultados relacionados con dichos proyectos. [42]

Tabla 10 – Diseño (Validada)

2.1.8. Desarrollo

Los criterios de Desarrollo incluyen:

• Completitud: ¿cuán útiles son las herramientas de desarrollo proporcionadas?



43

METODOLOGIA COMPLETITUD

MASE Proporciona una herramienta llamada AgentTool. En la cual se puede trabajar las fases de análisis y diseño[41]

GAIA No cuenta con una herramienta propia para desarrollo. [43]

MESSAGE No cuenta con una herramienta propia para desarrollo. [36]

INGENIAS Contiene una herramienta denominada INGENIAS IDE, que permite la generación de código. [37]

ZEUS Las Herramientas de desarrollo no se han liberado. [48]

MAS-CommonKADS

La metodología no cuenta con una herramienta de desarrollo liberada, pero se han definido un conjunto de un conjunto de arquitecturas y frameworks de agentes, que sirven de soporte a su desarrollo. [38]

MASINA Las Herramientas de desarrollo no se han liberado. [42]

Tabla 11 – Desarrollo (Completitud)

• Facilidad de uso: ¿son las herramientas de desarrollo y los lenguajes fáciles de utilizar? ¿-Es popular el lenguaje utilizado?


MASE Dispone de un lenguaje de especificación basado en UML+OCL (Object Constraint Leguage), lo que evidencia mucho acercamiento a los conceptos orientados a objetos, asumiendo al agente como un ”objeto mejorado” el cual puede contar con inteligencia o no. [41]

GAIA No tiene herramienta para desarrollo. [43]

MESSAGE No tiene herramienta para desarrollo. [36]

INGENIAS Posee un manual el cual es muy completo pero extremadamente extenso, esta herramienta es promovida por el grupo GRASIA, el cual actualiza constantemente la información sobre la herramienta. [37]

ZEUS El uso de esta herramienta es bastante complejo dado que necesita un gran conocimiento de los desarrolladores en cuanto al tema de agentes se refiere. [48]

MAS-CommonKADS

Herramientas en desarrollo no se ha liberado [38]

MASINA Herramientas en desarrollo no se ha liberado. [42]

Tabla 12 – Desarrollo (Complejidad) Una vez revisadas las metodologías se realiza una ponderación para encontrar una metodología que sirva de base para la realización del proyecto. En esta ponderación las calificaciones pueden tomar valores entre 0 y 5, cero significa que no cumple con los requisitos de la etapa necesarios y 5 indica que cumple completamente con las características evaluadas.

METODOLOGIA ANALISIS DISEÑO DESARROLLO PROMEDIO

MASE 3 3.5 2.5 3 GAIA 2.5 2.5 0 1.7

MESSAGE 2 1 0 1



44

INGENIAS 3.2 3.5 3.5 3.4 ZEUS 1.5 1.5 4.3 2.4

MAS-CommonKADS 4.5 4.5 2* 3.7 MASINA 2.5* 2.5* 0* 1.7

Tabla 13 – Evaluación Metodológica

* No se ha liberado por completo. La Tabla 13 – Evaluación Metodológica, muestra que la metodología con el más alto ponderado es MAS-CommonKADS, la cual se toma como base para el desarrollo del proyecto, es muy importante tener en cuenta que no se cierra la posibilidad de utilizar algunas de las características de las otras metodologías puesto que lo que se busca es hacer una propuesta metodológica que permita una adecuada construcción de personajes en videojuegos de aventura.

3.3. Modelo metodológico propuesto El modelo metodológico para la construcción de personajes se desarrolló mediante el estudio e investigación de las metodologías más importantes para la construcción de agentes [38] , como resultado de dicho estudio se escogió como base la metodología MAS-CommonKADS, en este apartado se revisará cada uno de los elementos, modelos, diagramas etc., con el fin de entenderlos y extenderlos cubriendo las necesidades presentadas en este proyecto. MAS-CommonKADS es una extensión metodológica de la ya conocida CommonKADS [38], la cual se enfoca en la construcción de sistemas expertos. La extensión orientada a agentes aprovecha los principios del paradigma orientado a objetos que tienen ya una buena base con diferentes metodologías. Esta propuesta metodológica ha sido la primera en plantear la integración del SMA con un modelo de ciclo de vida de software, más concretamente el espiral dirigido por riesgos. El modelo de ciclo de vida para el desarrollo de sistemas multiagente sigue las fases de [38]: Conceptuación: Se encarga de recopilar toda la información existente del dominio del problema con el fin de organizarla, para describir la totalidad el problema de una forma muy general y usando lenguaje natural.

Análisis : Se determinan todos los requisitos del sistema partiendo del enunciado del problema (para nuestro el caso de GAME-MAS-COMMON-KADS se debe partir del documento de conceptuación del video juego.) Diseño : especificación de los requisitos de la fase de análisis que se puede lograr mediante el desarrollo del modelo de diseño. Se determinan las arquitecturas tanto de la red multiagente como de cada agente. Las fases enunciadas anteriormente están compuestas por los siguientes modelos [38]:



45

Figura 1 – Modelos MAS-CommonKADS Modelo de Agente (AM) : Específica las características de un agente: sus capacidades de razonamiento, habilidades, servicios, sensores, efectores, grupos de agentes a los que pertenece y clase de agente. Un agente puede ser un agente humano, software, o cualquier entidad capaz de emplear un lenguaje de comunicación de agentes [38].

Modelo de Organización (OM) : Es una herramienta para analizar la organización humana en que el sistema multiagente va a ser introducido y describe la organización de los agentes software y su relación con el entorno [38]. Modelo de Tareas (TM): Describe las tareas que los agentes pueden realizar: los objetivos de cada tarea, su descomposición, los elementos y los métodos de resolución de problemas para resolver cada objetivo [38]. Modelo de la Experiencia (EM): Describe el conocimiento necesitado por los agentes para alcanzar sus objetivos. Sigue la descomposición de CommonKADS y reutiliza las bibliotecas de tareas genéricas [38]. Modelo de Comunicación (CM): Describe las interacciones entre un agente humano y un agente software. Se centra en la consideración de factores humanos para dicha interacción [38]. Modelo de Coordinación (CoM): Desarrolla y describe las interacciones entre los agentes de un sistema multiagente. La idea del modelo es que los agentes ofrecen servicios para realizar tareas a otros agentes [38].

MODELO DE EXPERIENCIA

MODELO DE COMUNICACION

MODELO DE TAREAS

MODELO DE COORDINACION

MODELO DE DISEÑO

MODELO DE AGENTE

MODELO DE ORGANIZACION

Pertenece A

Interactúa con otros agentes

Realizado en

Realiza Razona

Interactúa con humanos



46

Modelo de Diseño (DM): Mientras que los otros seis modelos tratan del análisis del sistema multiagente, este modelo se utiliza para describir la arquitectura y el diseño del sistema multiagente como paso previo a su implementación [38]. En el siguiente apartado se revisaran más a fondo cada una de las fases y los modelos de la metodología escogida y la adaptación a las diferentes necesidades de este proyecto.

3.3.1. Conceptuación

Esta sección, se encarga de recopilar toda la información existente del dominio del problema con el fin de organizarla de forma tal que queden sentadas todas las bases para la construcción. Teniendo en cuenta que se encarga de formalizar todas las ideas que se encuentren sin formalizar sobre la construcción, esta fase describe la totalidad el problema de una forma muy general y usando lenguaje natural [38], en esta etapa se define a gran escala las características generales del juego, la cuales forman la base para todo el proceso de construcción de videojuegos. Existen varios temas acerca del videojuego que deben estar bien definidos antes de iniciar con la construcción con el fin de prevenir la generación de ambigüedades en futuras fases. Esta es la razón por la cual el desarrollo de esta fase es de suma importancia ya que constituye los cimientos de toda la construcción del videojuego. Para ello en esta fase se definen varias tareas, a partir de la integración de los resultados obtenidos de estas tareas se logra concebir la creación del Documento de Conceptuación del Videojuego (Documento entregable de esta fase), entre las tareas específicas de esta fase se han definido las siguientes: 3.3.1.1. Storyline En este apartado debe hacerse una descripción general de la historia en la que se centra el videojuego, esta tarea permitirá obtener una vaga idea de su concepción [16]. Pude entenderse como una representación general en la cual se resumen los hechos más relevantes que se llevaran a cabo durante el transcurso del videojuego, este en la mayoría de los caso se construye en forma de cuento o historia para facilitar su comprensión, como lo aconsejan Autores [16] [41] [42]. 3.3.1.2. Análisis del Argumento Base Una vez definido el storyline se realiza una descripción formal, la cual tiene una estructura orientada a un guion cinematográfico, comic u obra de teatro [43] y facilita la definición de cada una de las acciones los personajes dentro de la historia, es de resaltar que estas acciones son definidas desde un punto de vista literario [39] y se definen usando una secuencia de escenas. La Tabla 14 - Descripción de Escena sirve como guía para realizar la descripción de cada una de las escenas dentro del análisis del argumento.

• Caso: Se define una numeración que permita seguir la secuencia en que se ejecutan las escenas.

• Controles: deben listarse los controles que se encuentran habilitados durante la ejecución de la escena.



47

• Pantalla: Descripción en lenguaje natural, de la imagen mostrada durante la escena.

• Notas: Se detallan las actividades de particular importancia durante esta escena. • Acciones: Se describen los actos más importantes que tiene lugar durante el tiempo

en que transcurre la escena. • Hit de Caso: Son declarados en lenguaje natural los eventos de mayor importancia

en la escena. • Restricciones y Posiciones del Mapa: Si existe, se presenta una imagen

descriptiva del mapa y la ubicación de los objetos en él. • Personajes del Módulo: Son listados todos personajes que tiene puesta en escena

durante este periodo. • Diálogos Fijos: Se relatan las conversaciones entre los personajes durante el

transcurso normal de la escena. • Diálogos Libres: Se presentan un conjunto de diálogos alternativos en caso de

existir una variante en el curso normal de la escena.

ESCENA CASO: CONTROLES: PANTALLA: NOTAS: ACCIONES: HITS DE CASO: RESTRICCIONES Y POSICIONES DEL MAPA:

PERSONAJES DEL MODULO: DIALOGOS FIJOS: DIALOGOS LIBRES:

Tabla 14 - Descripción de Escena

3.3.1.3. Definición de Reglas Cada juego cuenta con un conjunto de reglas las cuales enmarcan y estructuran su definición, estas pueden ser definidas como pautas abstractas encargadas de la descripción funcional del sistema. Las reglas permiten establecer cualidades particulares asociadas a un juego, estas operan estableciendo un límite a las actividades que pueden desarrollar los jugadores dentro del juego obligándolos a tomar caminos específicos para llegar a los jugadores y garantizando que todos tomen el mismo camino [44]. Las siguientes características se encuentran presentes en las reglas de un videojuego:

- Explícitas e inequívocas: Son completas reglas que carecen de ambigüedad, tienen

que ser totalmente explícita y se deben extender en detalles de lo que transmitir [44]. - Compartidas por todos los jugadores : En un juego con muchos jugadores es

necesario que todos compartan el mismo número de reglas [44].



48

3.3.1.4. Definición del Mundo El mundo de juego, está compuesto por todos los elementos que forman parte de las distintas escenas dentro del videojuego. Es necesario realizar una descripción detallada del mundo, alturas, los distintos objetos, además de la ubicación de cada uno de los personajes dentro del mundo, si es posible se podría definir hasta, el esquema de luces y sombras usado. [44]. 3.3.1.5. Casos de Uso de los Personajes Una actividad de un personaje, se representa a través de un caso de uso, describiendo las posibles interacciones o usos de un usuario y/o agente con el sistema. Los usuarios y/o agentes del sistema se denominan actores, y representan a las entidades externas al sistema. Los casos de uso se pueden combinar, indicando que un caso de uso extiende otro caso o usa un caso previo. Para este proyecto, el objetivo es identificar las acciones que realizan los personajes del videojuego descritas en la historia del videojuego, es por esto que no se trabajara con actores sino con personajes. El análisis mediante casos de uso sigue unos pasos para lograr su identificación, estos han sido adaptados para lograr identificar las actividades que realizan los personajes [45]:

• Identificar los personajes: Interesa identificar los papeles que desempeñan los elementos que interactúan dentro del videojuego. Cada papel se considera un personaje diferente. Normalmente este proceso requerirá varias iteraciones.

• Identificar los casos de uso: en este caso, las actividades realizadas por los personajes. Para esto, podemos hacernos las siguientes preguntas: ¿Cuáles son las principales tareas o funciones realizadas por cada personaje? ¿Qué información del entorno adquiere, produce o cambia cada personaje? ¿Informa algún personaje al videojuego sobre cambios externos en el entorno del videojuego? ¿Qué información desea cada personaje del entorno del videojuego? ¿Desea algún personaje ser informado de cambios inesperados?

• Agrupar los casos de uso: si parecen variaciones del mismo tema (por ejemplo: ’Pelear usando arma’, ’pelear usando las manos’, ’pelear usando las piernas’).

• Determinar las interacciones de cada caso de uso identificado: En particular, el personajes que inicia cada caso de uso, si hay precondiciones que deben ser ciertas para que un caso de uso pueda comenzar, y la conclusión lógica de la transacción.

• Describir los casos de uso: Los casos de uso se suelen describir informalmente empleando lenguaje natural o derivaciones de la notación gráfica propuesta por Jacobson [45].

• Considerar la mayor cantidad de excepciones que pueden ocurrir al llevar a cabo una transición y especificar cómo afectan al caso de uso.



49

• Buscar relaciones entre casos de uso: factorizar partes comunes e indicar si un caso de uso agrega las interacciones de otro (relación “usa”) o añade información de otro caso (relación “extiende”).

3.3.1.6. Ciclo de Desarrollo de los Casos de Uso A continuación se muestran los diferentes ítems que se deben desarrollar para definir la etapa de conceptuación dentro de la metodología MAS-CommonKADS [38]:

• Identificación de los personajes (actores) • Descripción de los actores • Identificación de los casos de uso • Descripción de los casos de uso

Para esta metodología se adaptaron cada una de las actividades de la metodología orientándolas hacia la identificación de los personajes, utilizando cada una de las características más importantes, complementándolas con conceptos de otros autores e identificando las funciones realizadas por los personajes que representaran los casos de uso.

Identificación de Personajes Se describe cada uno de los atributos que deben tener los personajes al momento de identificarlos [18]:

• ID: código con el que se identifica al personaje, debe ser único y es escogido libremente.

• Nombre: identificación del personaje con una cadena de texto corta, debe ser única. • Personajes con los que interactúa: personajes con los cuales tiene una

interacción durante la realización de la historia. • Comportamiento: reacciones generales que debe tener el personaje. • Tipo: principal, secundario, extra. • Referencias cruzadas: relación de este artefacto con los creados anteriormente.

IDENTIFICACION PERSONAJES/AGENTES

Id Nombre Personajes con los que interactúa:

Descripción: Tipo: Referencias cruzadas

Tabla 15 – Identificación Personaje/Agente

Descripción de los Personajes



50

Se describen más a fondo las características de los personajes aumentando algunos atributos importantes para la definición del personaje [18]:

• ID: Código con el que se identifica al personaje, debe ser único y es escogido libremente.

• Nombre: identificación del personaje con una cadena de texto corta, debe ser única.

• Personajes con los que interactúa: descripción corta en lenguaje natural de los personajes con los que interactúa.

• Comportamiento: descripción de las diferentes reacciones del personaje ante diferentes situaciones o demás personajes.

• Dimensión física o fisiológica: sexo, edad, descripción física (peso, altura), apariencia, defectos deformidades, enfermedades);

• Dimensión social: clase social, ocupación, educación, religión, raza, nacionalidad, filiación política;

• Dimensión psicológica: historia familiar, Vida sexual, autoestima, actitud frente a la vida, habilidades, cualidades, I. Q.

• Tipo: descripción del tipo al que pertenece (principal, secundario, extra).

• Metas: o Motivación: razón por la cual el personaje quiere o necesita lograr el objetivo o Intención: describe si el personaje tiene una buena o mala finalidad. o Objetivo: meta a lograr u objeto a obtener por el personaje

• Evolución: acciones presentadas a lo largo de la historia que podrían cambiar

actitudes o comportamientos del personaje.

• Referencias cruzadas: relación de este artefacto con los creados anteriormente.



51

DESCRIPCION PERSONAJES/AGENTES ID: Nombre: Personajes con los que interactúa:

Comportamiento: Dimensión física o fisiológica: Dimensión social: Dimensión psicológica: Tipo: Metas: Motivación: Intención: Objetivo:

Evolución: Referencias cruzadas:

Tabla 16 - Descripción Personaje/Agente

Identificación de los casos de uso de los personaje s Se describen cada uno de los atributos de las actividades que desarrollan los personajes [45]:

Representación Textual Id: código con el que se identifica la actividad, debe ser único y es de nombrado libre. Nombre de la Actividad: identificación con cadena de texto de la actividad. Personajes: lista de los personajes, en la cual se indica quien se inicia la actividad. Resumen: síntesis de la actividad. Referencias Cruzadas: relación de este artefacto con los creados anteriormente.

CASOS DE USO Id: Nombre de la Actividad:

Personajes: Resumen: Referencias Cruzadas:

Tabla 17 – Caso de Uso



52

Representación gráfica Con esta representación se explica gráficamente un conjunto de casos de uso del videojuego, los personajes y la relación entre estos y los casos de uso, a continuación se presentan los símbolos con los que se van a representar cada uno de los objetos del análisis [45]:

Personaje -Agente Jugador -Agente Relación Caso de Uso

Tabla 18 – Representación Gráfica Casos de Uso

El objetivo de esta representación es ofrecer un diagrama contextual que permite conocer rápidamente los personajes del sistema y las formas básicas en que se utilizan.

Descripción de los casos de uso Se describen más a fondo cada uno de los atributos de las actividades, aumentado algunos importantes [45], tiene dos tipos

Representación textual • Id: código con el que se identifica la actividad, debe ser único y es de libre nombrado. • Nombre de la Actividad: identificación con cadena de texto de la actividad. • Personajes: lista de los personajes, en la cual se indica quien se inicia la actividad. • Precondiciones: condición que debe ser cierta para que la actividad puede cumplirse. • Resumen: breve descripción de la secuencia de interacciones entre los personajes. • Tipo: clasificación de las actividades en:

o Primarias: representan las actividades comunes más importantes. o Secundarios: representan actividades menores o raros. o Opcionales: representan actividades que pueden no abordarse.

• Curso normal de los eventos: Descripción detallada e informal de las interacciones, referenciando las posibles excepciones.

• Excepciones: Descripción de cada comportamiento inesperado y los posibles caminos que puede tomar.

• Postcondiciones: Descripción de las condiciones finales una vez se cumpla el caso de uso.

• Referencias Cruzadas: relación de este artefacto con los creados anteriormente.

<<Tipo de relación>>



53

DESCRIPCION CASOS DE USO Id: Nombre de la Actividad: Precondiciones: Personajes: Resumen: Tipo: Curso normal de los eventos:

Excepciones: Post -condiciones: Referencias Cruzadas:

Tabla 19 – Descripción Caso de Uso - Representación textual

3.3.2. Modelo de Comportamiento Este modelo ha sido construido a partir del tercer modelo de la metodología MAS-CommonKADS (modelo de tareas) el cual tienen como objetivo identificar las tareas que estos realizan, respectivamente. En el caso de los videojuegos centraremos la atención en analizar los comportamientos para cada uno de los personajes. A este nuevo modelo se le denominó modelo de comportamiento [38]. En este modelo realizaremos el mapeo de los casos de uso a comportamientos, tomaremos como comportamientos base las propiedades de reactividad, proactividad y habilidad social, debido a que a lo largo del desarrollo de la historia del videojuego, el personaje/agente debe ser flexible y adaptarse a los cambios que ocurren en su entorno, apoyados en las investigaciones de Wooldrige y Jennings [38] podemos definir: • Comportamiento Reactivo: es aquel agente que mantiene una interacción constante con

su ambiente, y responde a los cambios que ocurren en este (en un tiempo en el que la respuesta es útil).

• Comportamiento Proactivo: es el hecho de que un agente tome la iniciativa, sea

mediante sugerencias o acciones anticipadas para alcanzar sus objetivos. • Comportamiento social: en agentes es la habilidad de interactuar con otros agentes (y

posiblemente con humanos) por medio de algún tipo de lenguaje de comunicación de agentes, y quizás cooperar con otros.

A continuación se presenta la descripción de algunos atributos importantes al mapear cada caso de uso: 3.3.2.1. Representación Textual ID: Identificador para cada caso de uso. Comportamiento: Nombre del comportamiento Caso de uso: El nombre del caso uso que está relacionado con el comportamiento.



54

Tipo: pueden ser: • Reactivo: se describe la reacción que lo dispara. • Proactivo: tiempo de duración y/frecuencia. • Social: agentes relacionados.

Referencias Cruzadas: relaciones con los artefactos realizados anteriormente.

COMPORTAMIENTO Id: Comportamiento: Caso de uso: Tipo: Referencias Cruzadas:

Tabla 20 – Comportamiento

3.3.2.2. Notación gráfica Los diagramas de interacción son una buena forma de realizar una representación gráfica que describe el curso particular de los eventos de un caso de uso [45], los jugadores que interactúan directamente con el videojuego y los eventos generados por los personajes. En este diagrama el tiempo avanza de arriba hacia abajo, y el ordenamiento de los eventos debería seguir el orden indicado en el caso de uso. En este caso las interacciones también determinan el comportamiento de los personajes/agentes mostrando cuál es su reacción cuando actúan sobre ellos. Y cómo el comportamiento va a estar en función de los objetivos de los personajes/agentes y las tareas a ejecutar, se puede concluir que existe un importante vínculo entre interacciones y tareas.

Figura 2 – Diagramas de Interacción de personajes

OBJET

O

OBJET

O



55

Figura 3 – Diagramas de Interacción de jugadores

3.3.3. Modelo de Experiencia El modelo de experiencia es el encargado de administrar el conocimiento de los personajes y del videojuego en general, es a partir de esté, que se define el grado de dificultad del juego, determinando el comportamiento de los distintos actores del juego dependiendo de las acciones realizadas por el jugador. En la actualidad se propone definir la técnica o técnicas de inteligencia necesarias para desarrollar el video juego de manera independiente, sin casarse con ninguna en específico, la definición puede hacerse en lenguaje natural. Se llevará a cabo una introducción a las diferentes técnicas de Inteligencia Artificial teniendo en cuenta que algunas se adaptan con mucha más facilidad que otras a los videojuegos, aunque todas podrían ser utilizadas para este fin, pero es de aclarar que no es objetivo de este proyecto ahondar en este tema dada la complejidad del mismo. Se define como opcional el carácter de esté modelo dado a que existen muy variadas y complejas formas abarcar él tema [46]. Hoy en día, las técnicas de Inteligencia Artificial están siendo utilizadas para el desarrollo de videojuego para que aborden el tema de la dificultad, pero, ¿que podría ser considerado como Inteligencia artificial en un videojuego? “es la simulación por computadora de comportamientos inteligentes” [47], es necesario aterrizar el significado de inteligencia el cual podría ser tomado como “el comportamiento que exhibe una gran capacidad de adaptación y resolución de problemas”, o “la conducta más próxima a la de los seres humanos” [47]. Aunque los humanos no siempre nos comportemos de una forma brillante,

OBJET

O

OBJET

O



56

hay cualidades en nuestro comportamiento que nos hacen inteligentes. En los juegos es muy normal que se tome como referencia la primera definición de inteligencia lo que produce resultados completamente irreales. (Esto se puede ilustrar en el problema de búsqueda de ruta del punto A al Punto B, en la Figura 4 – Búsqueda, que evite los obstáculos. Existen muchos algoritmos que dan una correcta solución a este problema, analizando el mapa y trazando un camino que conecte ambos puntos y además evite los obstáculos, y algunos hasta determinaran el camino más corto. Pero, esta actitud es irrealista al comparada con los seres humanos, debido a que nosotros normalmente no trazamos rutas sumamente óptimas y a menudo cometemos errores muy complejos recorriendo laberintos (por ejemplo un humano podría ir desde A hasta B siguiendo la trayectoria solida (no esquivaría los obstáculos sino que se desplazaría sobre ellos) argumentando que no tenía un conocimiento previo del camino. Pero si un juego utilizara esté método podría ser algo muy inteligente pero no muy realista. Se debe tener un grado razonable de imperfección al momento incorporar la Inteligencia Artificial, de modo que no resulte frustrante para el jugador humano)) [47].

Figura 4 – Búsqueda Es prudente no olvidar que lo llamativo de un juego son sus retos y por lo mismo debemos tener claro que estos necesitan cierta inteligencia (sin exagerar) lo que dará ese grado de dificultad que genera un atractivo en el jugador. Al observar series de aventura como India Jones es de notar que los enemigos solo poseía una estrategia (como robots) y al jugador conocerla y derrotarlo ya no significaba un reto para ellos volver a enfrentarlos, perdiendo el interés por el juego [47]. Así, la IA busca generar equilibrio entre la conducta que le permita ser a la vez tanto evolucionada como sofisticada, y un comportamiento que sea más o menos humano (en el sentido menos óptimo de la palabra). Existen varias técnicas que pueden ser utilizadas para asegurar que la IA no es sólo "la solución del problema de los robots", sino que además suministran la cantidad correcta de complejidad para desafiar y cautivar al jugador [19]. 3.3.3.1. Estructura de un sistema de IA Se pueden plantear dos formas generales de ver la inteligencia artificial de un juego [47]. La primera y la más común es el agente, que es prácticamente un juego de personajes del mundo. Normalmente se trata de enemigos, pero también puede ser personajes no-jugador, compañeros, o cualquier ser animado en el campo. Para este tipo de entidades, debe seguir una estructura biológica, de modo que sea posible modelar estos comportamientos de una



57

manera realista. Si se estructuran estos sistemas de manera similar al cerebro humano, es fácil identificar los siguientes cuatro elementos o normas[47]:

• Sensor o sistema de entrada • Memoria de trabajo • Razonamiento y el análisis básico • Acción o el sistema de producción

Existen casos en los que no es necesario utilizar todos estos elementos dependiendo específicamente de la aplicación, pero es común encontrarlos a todos en todas las entidades. Al cambiar la naturaleza de cada uno de los componentes, pueden ser implementados distintos enfoques. 3.3.3.2. Máquinas de Estado Finito Las máquinas de estado finito podrían ser definidas como un formalismo que consiste en dos conjuntos [47]:

• Un primer conjunto que representa los escenarios o configuraciones dentro de los que se puede sumergir la IA.

• Un segundo conjunto de transacciones que son las condiciones que conectan los estados en forma dirigida.

Básicamente, un sistema de máquinas de estado representa el cerebro de la entidad como un grupo de posibles acciones (estados) y la forma de cambiar de una acción a otra. Las máquinas de estado finitos son una de las técnicas más utilizadas para la creación de juegos con Inteligencia Artificial, ya que estas pueden ser vistas como el cerebro de una entidad virtual, que describe diferentes acciones usando estados y encadenando ésos con transacciones de manera significativa [47]. Muchos videojuegos utilizan esta técnica desde hace mucho tiempo debido a que son intuitivos, fáciles de codificar, de buen desempeño y pueden representar una amplia gama de comportamientos. 3.3.3.3. Lógica Difusa Es un tipo de lógica que no se centra en reconocer valores verdaderos y falsos. Más bien, utiliza expresiones que no son totalmente ciertas ni totalmente falsas, es decir, esta lógica se aplica a conceptos que pueden tomar un valor cualquiera de veracidad dentro de un conjunto de valores que oscilan entre dos valores (la verdad absoluta o la falsedad total) [47]. Al hablar de difuso se hace referencia al objeto que se está estudiando el cual expresa la falta de definición del concepto al cual se aplica. La lógica difusa permite tratar con información imprecisa, como el peso medio o temperatura alta, en términos de conjuntos borrosos que se combinan en reglas para definir acciones: por ejemplo si la temperatura es muy alta enfriar mucho [47]. De esta manera los sistemas basados en lógica difusa combinan variables de entrada, definidas en términos de conjuntos difusos, por medio de grupos de reglas que producen uno o varios valores de salida.



58

3.3.3.4. Algoritmos Genéticos Un algoritmo genético es una técnica de programación la cual toma su comportamiento de la evolución biológica y lo utiliza como estrategia para resolución de problemas. Dado un problema específico a resolver, la entrada del algoritmo genético es un conjunto de soluciones potenciales a ese problema, codificadas de alguna manera, y una métrica llamada función de aptitud que permite evaluar cuantitativamente a cada candidata [47]. Estas candidatas pueden ser soluciones que ya se sabe que funcionan, con el objetivo de que el algoritmo genético las mejore, pero se suelen generar aleatoriamente. Luego el AG evalúa cada candidata de acuerdo con la función de aptitud. En un acervo de candidatas generadas aleatoriamente, por supuesto, la mayoría no funcionarán en absoluto, y serán eliminadas. Sin embargo, por puro azar, unas pocas pueden ser prometedoras -pueden mostrar actividad, aunque sólo sea actividad débil e imperfecta, hacia la solución del problema [47]. Estas candidatas prometedoras se conservan y se les permite reproducirse. Se realizan múltiples copias de ellas, pero las copias no son perfectas; se introducen cambios aleatorios durante el proceso de copia. Luego, esta descendencia digital prosigue con la siguiente generación, formando un nuevo acervo de soluciones candidatas, y son sometidas a una ronda de evaluación de aptitud. Las candidatas que han empeorado o no han mejorado con los cambios en su código son eliminadas de nuevo; pero, de nuevo, por puro azar, las variaciones aleatorias introducidas en la población pueden haber mejorado a algunos individuos, convirtiéndolos en mejores soluciones del problema, más completas o más eficientes. De nuevo, se seleccionan y copian estos individuos vencedores hacia la siguiente generación con cambios aleatorios, y el proceso se repite. Las expectativas son que la aptitud media de la población se incrementará en cada ronda y, por tanto, repitiendo este proceso cientos o miles de rondas, pueden descubrirse soluciones muy buenas del problema [47]. Un buen uso de esta tecnología en los juegos es para simular entornos artificiales. En lugar de mantenimiento de los mismos elementos del medio ambiente una y otra vez, puede crear elementos (como pequeños programas) para evolucionar más fuertes, más inteligentes, más rápidos y elementos (u objetos) que puede interactuar con el medio ambiente y usted [47]. El uso de redes neuronales y algoritmos genéticos para el aprendizaje, y los árboles de decisión y los autómatas son utilizados para definir el comportamiento de los personajes, pero esto no significa que es necesario utilizarlo en todos los juegos que se creen. Además, es importante tener en cuenta que estos no son los únicos campos de la inteligencia artificial, existen varios más, muchos no se mencionaron debido al enfoque de este proyecto, lo que no les resta importancia.

3.3.4. Modelo de Coordinación El modelo de coordinación permite profundizar en las interacciones entre los personajes/agentes, que se agrupan en conversaciones [18]. Se define una conversación como un conjunto de interacciones iniciadas con el fin de alcanzar un objetivo. Cada interacción entre dos personajes/agentes se realiza mediante el envío de un mensaje que



59

tiene asociado un acto de habla. En una conversación podemos distinguir los siguientes papeles desempeñados por los agentes: inicíador, agente que inicia la conversación; y participantes, agentes involucrados en la conversación. Se pueden identificar dos razones para iniciar una conversación [38]: necesitar ayuda o proporcionar ayuda. De la misma manera, un agente puede responder a una conversación por dos causas: suministrar ayuda o aceptar ayuda. Esta ayuda o petición de cooperación puede ser de dos tipos: intercambio de información o solicitud de realización de una tarea. Si se asume que los agentes no son altruistas, la petición de ayuda conllevará un coste, y la oferta de servicios será asimilable a la publicidad, donde los agentes compiten por la atención del usuario [38]. Las conversaciones se pueden tipificar de tres formas: Por la forma como se elabora la conversación • Conversaciones primitivas: Se dice que una conversación es primitiva cuando sólo el

agente iniciador de la conversación envía un mensaje y recibe (o no) una respuesta a dicho mensaje.

• Conversaciones complejas. El resto de conversaciones se denominan complejas, y suelen requerir el conocimiento de un protocolo que rija la conversación.

Por el número de participantes • Conversaciones bilaterales: es realizada entre dos agentes. • Conversaciones multilaterales, entre más de dos agentes. Por la forma como se inician • Primarias si son iniciadas directamente por el agente. • Secundarias si se inicia como resultado de otra conversación. El modelo de coordinación se estructura en torno a los conceptos de agente/personaje y tareas (casos de uso) e introduce los siguientes conceptos:

• Mensaje: estructura de datos que intercambian los agentes para comunicarse. • Acto de habla: intención del emisor del mensaje al transmitir el contenido del

mensaje. • Servicio: prestación realizada por un agente para satisfacer las necesidades de otro

agente. • Intervención: intercambio de un mensaje entre un agente y otro agente. Puede haber

tres tipos de interacciones básicas: síncrona (bloqueante hasta recibir respuesta), asíncrona (sin respuesta) y diferida (envío no bloqueante y recepción de respuesta).

• Conversación: conjunto de interacciones cuyo fin es la realización de un servicio. Se distinguen dos tipos de conversaciones: conversaciones de información y conversaciones de servicio. Las conversaciones de información tienen como objetivo informar a un agente de algún hecho u obtener una determinada



60

información (consulta). Las conversaciones de servicio tienen como objetivo la realización de un servicio.

• Protocolo: normas asociadas a las conversaciones. Un protocolo determina las interacciones que se llevan a cabo en una conversación.

3.3.4.1. Conversación Las conversaciones son el elemento central del modelo de coordinación debido a que la existencia del resto de entidades de este modelo depende de la existencia de una conversación a la que están ligadas. Una conversación es un conjunto de interacciones cuyo fin es la consecución de un objetivo. Si un agente es capaz de mantener varias conversaciones simultáneas, creará un ejemplar de la entidad conversación para cada conversación activa. Si sólo es capaz de mantener una conversación, sólo podrá tener un ejemplar de conversación activo.

• ID Mensaje: Identificador único para los mensajes. • Per-formativa: Tipo de mensaje que se está enviando. • Agente Emisor: Nombre del agente que emite el mensaje. • Agente Receptor: Nombre del agente que recibe el mensaje. • Agente a quien se enviaría Respuesta: Nombre del agente a quien se debe

responder. • Contenido: Describe la información que se va a enviar. • Lenguaje: Nombre del sistema en que se encuentra expresado el mensaje.

(español) • Codificación: Define el tipo de codificación usado en este mensaje. • Ontología: Elementos de entendimiento común y compartido del dominio, que

definen el lenguaje o sintaxis de comunicación entre agentes, dándole sentido a la comunicación.

CONVERSACION

ID Mensaje Per-formativa Agente Emisor Agente Receptor Agente a quien se enviaría Respuesta

Contenido: texto a enviar Lenguaje Codificación Ontología

Tabla 21 – Conversación

Para realizar las interacciones entre personajes/agentes, se debe tener en cuenta la comunicación entre ellos, ya que es la clave para obtener todo el potencial del paradigma de agentes. Los agentes emplean un lenguaje de comunicación (ACL – Agent Communication Language) para comunicar información y conocimiento y de esta manera realizar tareas que un solo agente no podría realizar.



61

3.3.4.2. Notación grafica Para poder establecer una conversación entre agentes es necesario definir previamente el protocolo que se va a seguir durante la conversación, un protocolo de interacción es una descripción detallada del tipo y orden de los mensajes involucrados en una conversación entre agentes. Un agente puede participar simultáneamente en múltiples diálogos con diferentes agentes y con diferentes protocolos de interacción. Para esta propuestá metodológica se escogió el protocolo FIPA contract net; la siguiente imagen muestra el formato básico de comunicación entre los personajes usando este protocolo.

Figura 5 – Protocolo de comunicación entre personajes

Figura 6 – Protocolo de comunicación entre personajes y jugadores

Las siguientes imágenes muestran los diferentes hilos de interacción que se pueden presentan entre los agentes usando el protocolo FIPA contract net:

Figura 7 – Mensajes

concurrentes: los tres mensajes serán enviados al otro agente

Figura 8 – Mensajes con decisión inclusivo: máximo n mensajes serán enviados al

otro agente

Figura 9 – Mensajes con decisión exclusivos: solo se envía uno de los mensajes

3.3.5. Modelo de Organización

C

C

C

C

CA-

CA-

CA-

CA-

CA-

CA-

CA

CA

CAx



62

El modelo de organización permite el modelado de las relaciones estáticas entre personajes/agentes. Este modelo describe tanto la organización del jugador, como la sociedad de personaje/agentes. Definiendo las relaciones fijas existentes entre los diversos agentes software que constituyen el sistema. Para ello es necesario tener una clara definición de la relación de herencia entre agentes. Como se mencionó anteriormente en los modelos orientados a objetos basados en clases la relación de herencia significa que la clase derivada hereda los atributos y métodos de la clase madre. Pero el caso de estudio actual está enfocado hacia los personajes/agentes por lo que es necesario definir la relación de herencia entre clases de agentes, entendiendo que, una clase agente es la generalización de un conjunto de agentes con la misma arquitectura, en la cual se definen los servicios (tanto los ofrecidos como los requeridos), las habilidades, los sensores y actuadores, creencias y objetivos compartidos por este tipo de agentes. La relación de herencia se puede evidenciar fácilmente cuando tenemos un conjunto de agentes/personajes los cuales comparten objetivos, creencias, planes y servicios propios de una misma clases, pero necesitamos que a un agente/personaje en especial se le puedan agregar objetivos, planes y servicios particulares, basados en la historia. A continuación, se recomiendan un conjunto de situaciones en las cuales es necesario desarrollar un ejemplar del modelo de organización, debido a las sociedades agente/personaje [43]:

• Cuando sean identificados varios agentes/personajes con características en común, de forma que sea posible determinar las relaciones de herencia.

• Cuando los agentes/personaje interactúan con el entorno, de manera que sea posible modelar los objetos del entorno y su interacción con los agentes/personajes.

• Cuando sean encontrados agentes/personajes en los cuales se pueden determinar una relación de autoridad, que simbolice poder o estructura entre los agentes/personajes, esta relación debe hallase reflejada en el modelo.

• Cuando sean identificados grupos o coaliciones de agentes/personajes o de clases agente/personaje, la estructura y relaciones de estos grupos debe mostrarse reflejada en el modelo.

• Cuando sean encontradas relaciones entre agentes/personajes y agente/jugador es preciso modelar dicha relación.

3.3.5.1. Notación Grafica Se usa la misma notación gráfica propuesta por MAS-COMMON-KADS para mostrar las relaciones entre los agentes como lo muestra la Figura 10 – Notación Grafica del Modelo de organización . Las asociaciones entre los agentes y otros son empleadas para describir relaciones de autoridad o poder. La relación de grupo se realiza encerrando a varios agentes en una caja o mediante la creación de una agregación, y colocando los elementos del agente que representa al grupo.



63

En la representación del agente mostramos la parte interna o estado mental y/o la parte externa que es la relación con el entorno y resto de agentes). Por último, otros objetos relevantes del problema debe ser mostrados en el diagrama usando la notación de OMT.

Agente Objeto Herencia Grupo

Asociación Agregación

Figura 10 – Notación Grafica del Modelo de organiza ción

3.3.6. Modelo de Diseño Se presenta el modelo de diseño el cual tiene como objetivo principal la descripción de los componentes de los distintos modelos de la etapa de análisis de forma tal que se facilite su definición en un lenguaje de programación. Para el modelo de diseño de Mas-CommonKADS existen tres clases de decisiones de diseño: diseño de la red, el cual permite a los agentes tener una concepción uniforme de la red, diseño de agentes, donde los agentes son descompuestos en subsistemas, y el diseño de la plataforma, donde se recogen las decisiones de Hardware y Software, documentando decisiones de bajo nivel sobre el lenguaje de implementación seleccionado. Pero, para este proyecto no se usará la decisión de diseño de la red, esto, teniendo en cuenta que para los Juegos de Aventura el uso de la red (multi-jugador) se hace extremadamente complejo debido a la estrecha dependencia entre el juego y la historia [17]. 3.3.6.1. Diseño de Agentes En este ítem, se realizará la documentación de las distintas funciones de cada módulo que deben ser implementadas según la arquitectura seleccionada para el agente. Para llevar a cabo esta tarea será necesario el uso de la Tabla 22 – Componentes de diseño del

Agente Objetivos Creencias Planes

Servicios Sensores Actuadores

Objeto Atributos Métodos



64

agente definida a partir de los principales característica de diseño de agentes considerados en la metodología Mas-CommonKADS:

• Sistema-Personaje/Agente: El sistema agente representa un agente que va a ser implementado y está siendo diseñado. Puede corresponderse con uno o varios ejemplares del modelo de agente.

o Nombre: Se define el nombre del agente, haciendo alusión al ejemplar del modelo de agente desarrollado.

o Arquitectura: Tipo de arquitectura del agente. o Lenguaje: Nombre del lenguaje de descripción de agente empleado, por

ejemplo ADL. o Subsistema: Subsistemas asignados al agente.

SISTEMA PERSONAJE/AGENTE

Id: Nombre del Personaje/Agente:

Arquitectura: Lenguaje: Subsistemas: Referencias Cruzadas

Tabla 22 – Componentes de diseño del agente

• Subsistema : Subsistema o módulo de un agente.

o Nombre: Nombre del subsistema que se está diseñando. o Tipo: Tipo de subsistema. Distinguimos varios tipos: de interacción con el

usuario (derivado del modelo de comunicación), de comunicación con el resto de agentes (derivado del modelo de coordinación), de interacción con el exterior (derivado del modelo de agente, tarea y coordinación), de ejecución de tareas (derivado del modelo de tareas y agente), de planificación y reacción (agrupa los planes para alcanzar los objetivos asignado y responder a los estímulos recibidos y enviados en el módulo de interacción con el exterior). Estos módulos son muy dependientes de la arquitectura de agente seleccionada.

o Funcionalidades: Descripción de las funcionalidades implementadas. o Implementa : Tareas implementadas (del modelo de tareas). o Diseño-Detallado : Nombre de la entidad Diseño-Detallado en que se

describe el subsistema.

SUBSISTEMA PERSONAJE/AGENTE Id: Nombre del Subsistema:

Funcionalidades: Implementa: Diseño -Detallado: Referencias Cruzadas:



65

Tabla 23 – Componentes de diseño del subsistema

• Diseño detallado subsistema Descripción en un lenguaje de diseño detallado de un subsistema de un Personaje/Agente.

o Nombre : Nombre del subsistema que se está diseñando. o Lenguaje: Lenguaje de diseño detallado empleado. o Descripción : Referencia a la descripción del subsistema empleando el

lenguaje de diseño detallado.

DISEÑO DETALLADO DEL SUBSISTEMA PERSONAJE/AGENTE Id: Nombre del Subsistema: Arquitectura: Lenguaje: Descripción: Referencias Cruzadas:

Tabla 24 –Diseño detallado

3.3.6.2. Diseño de Plataforma El propósito del diseño de la plataforma es permitir la documentación de las decisiones de bajo nivel acera del lenguaje de implementación seleccionado, el software y el hardware empleado y los usuarios finales del sistema. En la Tabla 25 – Plantilla: Plataforma , se plasman los principales componentes del diseño de la plataforma considerados en la metodología Mas-CommonKADS:

• Plataforma: La plataforma recoge todas las decisiones del entorno de implementación y operación del sistema multi-agente.

o Nombre: Nombre de la plataforma o sistema en que se está diseñando. o Descripción: Justificación de las decisiones tomadas. o Lenguaje: Nombre de los lenguajes de implementación empleados. o Hardware Requerido: Requisitos del hardware en que se desarrolla el

sistema (tipos de máquinas, conexiones, etc.). o Software Requerido: Requisitos de configuración software en que se

desarrolla la plataforma (sistema operativo, nombres de las aplicaciones, versiones, etc.).

o Usuario: Usuarios de la plataforma, extraídos de los modelos de agente de la organización.

PLATAFORMA

Id: Nombre de la Plataforma:

Descripción: Lenguaje: Hardware:



66

Software: Usuario: Referencias Cruzadas:

Tabla 25 – Plantilla: Plataforma

Se debe tener en cuenta que MAS - CommonKADS precisan la existencia de dos grandes niveles para la abstracción del diseño de sistemas multi-agentes, que son:

• Nivel de programación de agente: El cual tiene como objetivo la definición de la forma detallada posible de la conducta de cada uno de los componentes de la arquitectura del agente mediante el uso de un lenguaje de un lenguaje de programación de agentes.

• Nivel de descripción de agente: En este nivel se utiliza un lenguaje el cual describe

los componentes del agente pero sin especificar como son realizados estos, debido a que esta labor se realiza en lenguaje de implementación.

A continuación, se presentan un conjunto de actividades que deberán ser considerados para la creación del modelo de diseño. Se debe realizar un diseño de los Personajes/Agentes, definiendo la arquitectura adecuada para cada uno, y por último el diseño de la plataforma de los agentes.

Pasos para el diseño de Personajes/Agentes

• Determinación de la arquitectura de los agentes: El objetivo de este paso es establecer cuál es la arquitectura adecuada para cada Personaje/Agente. A partir de la cual obtenemos la descripción de la arquitectura del agente, en sus respectivas plantillas. Aun cuando, no se ha definido una forma de determinar que tal o cual arquitectura es la mejor para tal o cual agente, existen varios aspectos que podrían ser de mucha ayuda en esta labor, como:

o Aspectos derivados de las plataformas disponibles para la arquitectura: los recursos o normas de la organización pueden requerir que los agentes sean programados en un lenguaje o con unos protocolos determinados [38].

o Necesidad de deliberación y reacción: los agentes con capacidades de razonamiento y/o reacción frente al entorno deberán ser modelados con una arquitectura que facilite estas características. La cuestión de utilizar una arquitectura puramente reactiva, puramente deliberativa, o una híbrida, puede basarse en la experiencia de los desarrolladores [38].

o Necesidad de paralelismo en la ejecución de acciones: un aspecto relevante

para la selección de una arquitectura es si un agente queda bloqueado o no al realizar una tarea [38].



67

o Problemas de tiempo real: también debemos tener en cuenta si necesitamos que se garantice un tiempo de ejecución para las tareas realizadas por el agente [38].

o Necesidad de movilidad: otro aspecto a tener en cuenta es la necesidad de movilidad de los agentes para trabajar con recursos de otras máquinas [38].

• Diseño detallado de los módulos: Con este paso lo que busca es una visión detallada

y específica de cada Personaje/Agente y de los principales módulos. Es muy común el uso de un lenguaje de agentes para su especificación.

Pasos para el diseño de la plataforma Basándose en el diseño, la arquitectura de agente seleccionada y en los requisitos no funcionales, se lleva a cabo la selección del sistema operativo y de la plataforma software y hardware. Las tres decisiones están relacionadas, por lo que no se impone un orden entre ellas.

• Selección del lenguaje de implementación: En esta paso se documentan las razones por las cuales se selecciona determinado lenguaje de implementación. Basados en un diseño validado de agentes. Existen varias razones determinantes al momento de la elección del lenguaje como lo son:

o Política general de la organización, recursos disponibles, interoperabilidad

con otros sistemas de la organización y previsión de su desarrollo en años posteriores [38].

o Experiencia de los programadores [38].

o Disponibilidad de plataformas multiagente para la arquitectura de agente deseada en ese lenguaje [38].

• Selección de los recursos software: El objetivo de este paso es la documentación de la selección de recursos software. La selección de recursos software está basada en el estudio de las herramientas disponibles en la organización o si existe la necesidad de adquirir nuevas para realizar los agentes. De cada herramienta deberemos indicar el nombre, requisitos software y hardware, la versión y las condiciones de operación.

• Selección de los recursos hardware: En esta actividad se centra en documentar el hardware necesario para ejecutar el sistema multiagente desarrollado. Deberá documentarse qué hardware es empleado para ejecutar el sistema multiagente y en qué plataformas hardware se puede ejecutar el sistema desarrollado.



68

3.4. Aportes propios Para la correcta definición de cada uno de los modelos, fue de vital importancia la inclusión de una fase de conceptualización la cual involucra varios artefactos, que están orientados a la captura de requisitos, y se usa como punto de partida, y línea base contra la cual se debe verificar si los demás artefactos coinciden con la idea inicial planteada. Se realizó la adaptación del modelo de comportamiento, a partir del modelo de tareas del agente, esto con el objetivo de generar el conjunto de comportamientos reactivos, proactivos y sociales, que debe tener cada personaje, y mapearlos a código para que sean ejecutados de acuerdo al modelo de experiencia quien es el que determina cómo y en qué momento se debe hacer uso de cada comportamiento programado para el personaje. Se modificó el modelo el modelo de conocimiento abriéndolo a la especificación de cualquier técnica de inteligencia artificial que permita administrar los comportamientos de los personajes, dado a que dentro del modelo de coordinación ya se debe haber definido la ontología común que permite tanto el almacenamiento del conocimiento como su transferencia. El modelo de comunicación se le dio un sentido más amplio al no solo comunicar agentes o en este caso personajes no jugadores, sino también personas o personajes no jugadores, ampliando las comunicaciones entre entidades computacionales y humanos. Se propusieron adicionalmente a la notación textual una sintaxis de notación gráfica, con una serie de iconos propios que permiten entender mejor los modelos cuando se hace un trabajo interdisciplinario. A todas las plantillas de los modelos se le adicionó un esquema de trazabilidad, el cual permite enlazar a través de las referencias cruzadas los artefactos, de esta forma si se necesitase hacer un cambio en un artefacto se debe revisar las dependencias para garantizar que el cambio sea consistente con los elementos que se encuentra relacionado.



69

4. API PARA IMPLEMENTACIÓN DE AGENTES/PERSONAJES

4.1. Descripción El uso de agentes software se ha masificado puesto que son usados en una gran variedad de videojuegos, debido a las ventajas sustanciales que ofrecen, también están tomando relevancia los SMA, lo que ha llevado a generar un nuevo enfoque o paradigma para analizar, diseñar e implementar sistemas software complejos. Los SMA están formados por grupos o comunidades de agentes que pueden estar o no relacionados de manera jerárquica, es decir pueden comportarse como sociedades o simular sistemas sociales complicados [58]. Pero esta tecnología está muy limitada ya que los avances se encuentran desarrollados en su mayoria en tecnologías Java, las plataformas que los soportan se basan en los estándares de la Foundation for Intelligent Physical Agents (FIPA) [59], lo que dificulta el trabajo al tratar de usarla para trabajar con sistemas más específicos como los video juegos, es por ello que debido a la naturaleza del proyecto y a su desarrollo se usó Unity [60] como librería gráfica, y como lenguaje de desarrollo C# para controlar los scripts del juegos, haciendo uso de las potencialidades del framework de .NET [61]. Una vez sentadas las restricciones que se tenían para la implementación de la librería se tomó el trabajo realizado en “Agentes Inteligentes para adaptar la presentación de contenidos para cursos de educación en línea – STI+AI” [11] , puesto que en este trabajo fue desarrollada una librería preliminar para el control del ciclo de vida de agentes, la figura siguiente muestra un esquema del trabajo con la librería mencionada.



70

Figura 11 – Modelo de la librería de agentes usada en STI+AI Esta librería preliminar permite la creación de contenedores, agentes y comportamientos, pero no permite el almacenamiento de estados ni considera la deliberación para la ejecución de agentes, también carece de un sistema de registro de excepciones que facilite encontrar errores tanto en tiempo de desarrollo como de despliegue, esta característica es muy importante porque un error ocurrido al interior de una conversación no se ve reflejado directamente sobre la interfaz de usuario debido a que la comunicación se realiza usando mensajes asincrónicos e hilos de programación que ofuscan los errores presentados y que dificultan la detección de inconvenientes 4.1. Adaptación del API La idea de realizar un api para la construcción de actores en un juego basada en una librería para la creación de agentes requiere de la adaptación de los elementos genéricos a un esquema particular de personajes para juegos de tipo aventura. Para llevar a cabo este objetivo se modificaron los siguientes elementos:

4.1.1. Modelo base de Agente El modelo base del agente, fue modificado para realizar la adición de tres módulos que permiten realizar: deliberación interna de un agente para realizar la ejecución de un comportamiento en particular dentro del conjunto de comportamientos creados, almacenamiento de estado (con persistencia mediante formato xml) y por ultimo un módulo para control de registro de excepciones cuya notificación puede ser enviada por diversos métodos (e-mail, archivos planos, etc.).

Agente 2

Mensaje ACL

Contenedor

Plataforma

Agente n

Agente 1

Comportamien to

Agente 3



71

Figura 12 – Modelo de Agente mejorado Comportamiento de Control (Nuevo): Permite implementar un mecanismo de control deliberativo basado en el modelo de experiencia para elegir el comportamiento a ejecutar basado en el estado actual y en la experiencia almacenada en el mismo estado. Es mediante este mecanismo que se implementa la pro-actividad del agente. Lista de comportamientos : Posibilita la creación de un conjunto de conductas que ejecuta el agente ya sea de manera proactiva (activadas por el comportamiento de control) o de manera reactiva (activadas por la comunicación o acción de otro agente o el entorno) Cola de mensajes: Almacena los mensajes enviados por los agentes que se encuentran en el mismo entorno de ejecución. Es importante aclarar que estos mensajes no son iguales a los enviados de un objeto a otro en el sentido estricto de la programación orientada a objetos sino que constituyen actos de habla y que siguen el estándar y las instrucciones de comunicación de FIPA. Identificador del agente: Mediante este atributo los agentes pueden enviar y recibir mensajes mediante el directorio facilitador que se ha implementado en la plataforma, la nomenclatura recomendada para nombrar un agente es NombreAgente@ContenedorDelAgente. Estado del agente (Nuevo): Este elemento permite almacenar estructuras complejas que representen no solo el estado sino también la experiencia adquirida por el agente dotándolo de mayor inteligencia y dinamismo.

Cola de mensajes

ID Agente@Contenedo r

Comportamiento 1

Comportamiento 2

Comportamiento …

Comportamiento de Control Deliberativo

Estado

Registro de Excepciones <<Escuchador>>

Envió de Notificaciones



72

Registro de excepciones (Nuevo): Permite realizar un registro mediante un log de errores, esto facilita no solo el trabajo en la etapa de codificación sino que permite encontrar situaciones inesperadas en la ejecución, lo que redunda en un sistema de agentes con mayor calidad. Envió de notificaciones (Nuevo): Posibilita el almacenamiento de las excepciones registradas mediante el modulo anterior pero desacopla el sistema de almacenamiento usado, lo que permite enviarlas a través de e-mail o registrarlas en un disco, etc. 4.1.2. Modelo base del personaje Una vez realizados las mejoras en la clase base del agente se debía crear un componente que no solo representara cualquier tipo de agente sino un personaje para los videojuegos es así como nace la clase Personaje, que tiene una relación de herencia directa con el modelo de agente.

Figura 13 – Modelo de personaje Modelo 3D: Representa un sistema que permite el dibujado de un objeto grafico en un plano en 3 Dimensiones, controlando la posición, desplazamiento, rotación, manejo objetos envolventes para manejo de colisiones entre objetos.

Control de modelo 3D: Permite controlar la entrada de información que efectúa el movimiento del agente no solo para personajes jugadores sino también para personajes no jugadores.

Procesador de Animaciones

Cola de mensajes

ID-Personaje@Contenedor

Comportamiento 1

Comportamiento 2

Comportamiento …

Comportamiento de Control Deliberativo

Estado

Registro de Excepciones <<Escuchador>> Envió de Notificaciones

Animación 1

Animación 2

Animación …

Control de modelo 3D

Modelo 3D



73

Procesador de animaciones: Funcionalidad creada para extender los agentes ofreciendo un procesador que transforma modelos Simples 3D en Modelos Animados para permitir al desarrollador mayor facilidad al reproducir una animación. Esta librería está estrechamente relacionado con los comportamientos puesto que son estos quienes usan las animaciones para representar el estado en el que se encuentra un personaje.

Animaciones : Modulo mediante el cual se da la sensación de movimiento a los personajes cuando están ejecutando un comportamiento, es importante resaltar que dentro de un comportamiento se pueden ejecutar varias animaciones. 4.1.3. Comportamientos independientes y pro-activid ad Las tareas que realiza un agente se estructuran en comportamientos, que permiten que el agente sea implementado como un hilo (thread) de control. Estos comportamientos se desacoplan del API logrando una mayor flexibilidad en la implementación mediante el uso de delegados y eventos. La programación basada en comportamientos debe realizar los siguientes pasos:

• Determinar qué debe ser capaz de hacer el agente. • Asociar cada funcionalidad con un comportamiento y un conjunto de animaciones. • Programar el comportamiento de control. • Enlazar la funcionalidad programada al delegado del comportamiento. • Dejar que la API programe la ejecución del comportamiento, basado en los estados

del agente.

Se puede pensar que los comportamientos como hilos de ejecución, sin embargo, a diferencia de los hilos estos no se ejecutan en cada momento, es tarea del programador definir un adecuado comportamiento de control que le permitan al programador de tareas (scheduling) ejecutar una acción según las necesidades del personaje. El scheduling de la librería permite que cada agente se equipare únicamente a un único hilo de control, lo que posibilita el ahorro de procesador y memoria. 4.2. Arquitectura de la Librería El desarrollo de la librería para el control del ciclo de vida de personajes se realizó mediante la construcción de 3 capas: renderizado, lógica del personaje y servicios. Este desarrollo representa un factor de gran utilidad en la construcción, dado que permite la división de responsabilidades, flexibilidad, escalabilidad y descomposición de las capas en otras menos densas. La Figura 14 – Arquitectura del API para personajes muestra la arquitectura desarrollada para la Librería.



74

Figura 14 – Arquitectura del API para personajes

4.2.1. Capa de Renderizado Esta capa permite realizar toda la parte gráfica relacionada con el personaje, realiza la carga de modelos y animaciones, controlando la forma como se dibujan los objetos mediante las matrices de proyección, vista y mundo. Se encarga también de aplicar los efectos de texturas y de luz para el objeto así como de identificar que objetos del mundo se encuentran cerca, bien sea para realizar una colisión e impedir el paso o para lanzar una conversación. Esta capa también es la encargada de realizar las transformaciones requeridas en el modelo como escalar, rotar, trasladar. Además permite la aplicación de efectos como el de niebla, que permite que no se dibujen los objetos hasta no estar a una distancia corta de ellos, minimizando la carga de dibujado para la tarjeta gráfica. Todo este módulo es soportado sobre el motor de Unity, lo que posibilita no solo el dibujado en equipos de escritorio sino también en consolas, que son más atractivas para los jugadores. 4.2.2. Lógica de personaje Esta capa concentra sus esfuerzos en ofrecer los servicios para que el personaje controle sus comportamientos, y está conformada por los siguientes módulos:

4.2.2.1. Controlador de mensajes Este módulo se basa en la teoría de actos de habla para agentes y permite realizar conversaciones primarias. Las conversaciones son iniciadas directamente por el agente, mientras que las conversaciones secundarias, se inicia como resultado de otra conversación. La Tabla 26 - Lista de instrucciones de comunicación que soporta la API. Muestra las primitivas que se pueden usar.



75

INSTRUCCIONES PROPÓSITO

Accept_Proposal Informa que se acepta la conversación previa para la realización de una acción.

Agree Informa que se acepta la acción.

Cancel Informa que se debe cancelar la acción.

Call_for_Proposal Informa sobre el llamado a una oferta de acción.

Confirm Confirma la realización de la acción.

Disconfirm No confirma la realización de la acción.

Failure Informa si se presenta un fallo.

Inform Mensaje de información.

Inform_If Mensaje de información previo a una pregunta.

Inform_Ref Mensaje de información previo a una conversación.

Not_Understood Informa que el mensaje no se ha comprendido.

Propagate Permite identificar cuáles son los agentes a los cuales debe ser propagado el mensaje.

Propose Informa el propósito de una acción.

Proxy Informa el Agente objetivo del mensaje.

Query_If Respuesta a una pregunta.

Query_Ref Respuesta a una referencia.

Refuse Denegación a la petición y explicación de la denegación.

Reject Rechazo de la petición.

Proposal Oferta de acción.

Request Respuesta a una acción.

Request_When Petición cuando se realiza una acción.

Request_Whenever Petición siempre que se realice una acción.

Subscribe Suscripción a un servicio.

Tabla 26 - Lista de instrucciones de comunicación q ue soporta la API

4.2.2.2. Gestor de comportamientos Permite a un personaje ejecutar una serie de acciones de manera proactiva y reactiva, de la misma manera que los seres vivos realizan diferentes acciones cuando se enfrentan a estímulos diversos. Este módulo permite al personaje gestionar de forma explícita diferentes comportamientos y tiene tres aspectos principales: • La definición de comportamientos alternativos para el personaje • Un comportamiento de control que otorga las condiciones particulares que deben

producir un cambio de comportamiento • Los mecanismos que producen el cambio.



76

4.2.2.3. Controlador de animaciones Este módulo permite disparar animaciones basadas en esqueletos y huesos para un modelo 3D, El desarrollo de este componente se hizo a apoyado en las funciones propias de Unity

4.2.2.4. Script utilitarios Este módulo fue construido para generar script de acciones comunes, como presentar diálogos e iconos en pantalla, revisar las colisiones de 2 personajes, etc. 4.2.3. Servicios Esta capa ofrece asistencia a los módulos que se encuentran sobre la capa de servicios, los principales servicios son:

• Persistencia basada la hidratación y des-hidratación del estado de los personajes con en estándares XML y XSD.

• Configuración del registro de excepciones y módulo de registro basado en Enterprise Library.

• Listener para registro de excepciones en formato plano o envío por correo electrónico.

4.3. Uso de la librería Dentro de la librería se desarrollaron varios scripts implementados en C# los cuales pueden reusarse en cualquier juego de estrategia, para ello simplemente se deben arrastrar a los elementos dentro del juego configurando las propiedades que cada uno recibe como parámetro dentro de la interfaz de desarrollo de Unity, los ítems subsecuentes mostraran el nombre de algunas de estas funcionalidades y las propiedades que reciben como parámetro. 4.3.1. Follow Este script permite que a un personaje no jugador se le active un comportamiento que sigue al personaje jugador a través de un terreno, detectando las alturas y haciendo la ruta más óptima posible evitando los obstáculos del mundo. Pasos de configuración

1. Fijar el Tag del personaje jugador a Player en las propiedades del personaje.



77

2. Crear un Cubo (Game object) que debe contener el personaje, el cual se usará como contenedor para detectar cuando el Jugador este cerca.

3. Establecer en BoxColider del cubo la propiedad isTrigger en True

4. Desactivar para este cubo la opción MeshRender para que no se visualice

5. Arrastrar el script Follow al cubo y fijar la propiedad Animation Object arrastrando el personaje que deseamos que siga al jugador.

4.3.2. Star Dialog Animation Este script permite que a un personaje no jugador se le active un comportamiento que sigue al personaje jugador a través de un terreno, detectando las alturas y haciendo la ruta más óptima posible evitando los obstáculos del mundo. Pasos de configuración 1. Crear un Cubo (Game object) que debe contener el personaje, el cual se usará como

contenedor para detectar cuando el Jugador este cerca.



78

2. Establecer en BoxColider del cubo la propiedad isTrigger en True

3. Desactivar para este cubo la opción MeshRender para que no se visualice

4. Arrastrar el script StarDialogAnimation al cubo y fijar las propiedades Animation Object arrastrando el personaje que deseamos que dialogue con el jugador, fijamos las propiedades DialogTexture, y DialogTexture Side, con las imágenes que queramos que salgan de fondo de la conversación, la propiedade Avatar y Avatar side, con los iconos de los personajes a Dialogar, en Main Camara se debe arrastrar la cámara configurada en el juego

5. La propiedad ShowDialog se puede establecer desde código fuente para mostrar las

conversaciones, las cuales también deben ser configuradas a nivel de código, un ejemplo de ello se puede ver a continuación en el método de inicialización.



79

void Start () {

Messages [0] = new ACLMessage (@"Pitagoras: ¡Hey tu ! ¿Estás perdido?...", true ); Messages [1] = new ACLMessage (@"Jack: No sé dónde me encuentro… al parecer estoy en el mismo sitio de antes,.. pero todo es diferente." , false ); Messages [2] = new ACLMessage (@"Pitagoras: ¿Te pue do ayudar en algo?", true); Messages [3] = new ACLMessage (@"Jack: Tengo mucha sed, ¿Puedes ofrecerme algo para saciar mi sed?", false ); Messages [4] = new ACLMessage (@"Pitagoras: ¡Claro que si!, solo que en este pueblo, todos somos amantes de las matemáticas, y si quiere s algo debes demostrarme que eres uno ¡de los nuestros!", true ); Messages [5] = new ACLMessage (@"Pitagoras: Yo te d aré una serie de sumas y restas, y por cada una de ellas iré llenando un vaso si acier tas en todas te daré un vaso lleno, el cual te dará energía para que continúes tu recor rido.", true ); Messages [6] = new ACLMessage (@"Jack: Acepto el re to ¡Adelante!", false );

}

4.3.3. Third Person controller Este script permite que a un personaje jugador ser controlado mediante el teclado y que se pueda mover por todo el terreno de juego, haciendo colisiones y respondiendo a las leyes de la gravedad. Pasos de configuración 1. Al personaje se deben adicionar 2 scripts, ThirdPersonController y ThirdPersonCamera

2. Se deba adicionar el componente Character Controller, el cual gráficamente debe contener al personaje para que sea mediante este que controle, las colisiones y las alturas del mapa

3. Por último se debe adicionar el componente Animation y ubicar cada posición del vector de animaciones, las animaciones correspondientes a estado estático, caminar y saltar.



80



81

4. CASO DE ESTUDIO

5.1. Video juego de ejemplo A continuación se presentan los aspectos que se tuvieron en cuenta para un caso de estudio propuesto, para el mejor entendimiento e implementación de los pasos y modelos de la metodología propuesta. El título del video juego es Jack y las Matemáticas, será implementado como un nivel demostrativo, caracterizado exploración de un mundo en tres dimensiones, la solución de rompecabezas y la interacción con personajes, no jugadores.

5.2. Aplicación de la metodología

5.2.1. Conceptuación

5.2.1.1. StoryLine Se planteó una historia corta, para cubrir el nivel de demostración del juego, el cual tenía como restricción tener un personaje jugador, y dos personajes agentes, el guion propuesto se basa en la siguiente historia:

Todo comienza en un pequeño pueblo llamado “Tales de Mileto”, En donde 500 años atrás quedó congelado Jack nuestro protagonista; un niño de la antigüedad de aproximadamente 10 años, destinado a adaptarse a un nuevo mundo y aprender muchas cosas, el pueblo de “Tales de Mileto” es conocido porque sus habitantes, eran descendientes directos del matemático del mismo nombre del pueblo; Tales habría demostrado teoremas geométricos sobre la base de definiciones y premisas con ayuda de reflexiones sobre la simetría, este legado volvió muy particulares a sus habitantes, por cuanto usabas analogías y juegos matemáticos para relacionarse. En Tales de Mileto, existe una montaña conocida como el cerro de “Eudoxo de Cnidos” es la más alta del pueblo, su cima está cubierta con una espesa nieve, un día muy soleado



82

parte de esta nieve se derritió y dejo a la vista a Jack quien había quedado en estado criogénico, muy aturdido, lentamente comienza a recuperar la movilidad de su cuerpo y comienza a explorar la montaña bajando para poder encontrar algo de comida, se encuentra con mucha hambre, al bajar de la montaña se da cuenta que existen una especie de “malocas” o “cavernas” hechas de madera de donde salen algunos habitantes del pueblo, el primero en encontrarse es a “Pitágoras de Samos”, quien es un señor muy bajito y se dedica a destilar las bebidas del pueblo, es muy inteligente, viste siempre una camiseta de color azul, no tiene cabello, pero tiene una frondosa barba; Jack lo ve y se la acerca, para intentar comunicarse con él y Pitágoras ofrece ayudarlo con un poco de líquido para beber, pero para ello le plantea un primer juego, el cual debe ganar y recibirá su recompensa, Pitágoras le explica primero a Jack como se realizan sumas y restas, con una serie de ejemplos, y luego procede a indicar el reto, que consiste en que el menciona una serie de sumas y restas, el niño debe seleccionar una serie de respuestas de un conjunto que posibilidades, las operaciones cada vez se deben hacer más rápido, y completar un total de 20 operaciones, que van haciendo llenar un vaso de líquido. Jack muy hábilmente resuelve todos los problemas, y recibe su recompensa, lo que le da la suficiente energía para seguir explorando el mundo, continúa por un camino de piedra, por donde encuentra un caballo llamado “Liu Hui”, es un hermoso corcel blanco con café, quien se encariña con Jack y de manera autónoma toma la iniciativa de acompañarlo en su camino, explorando el pueblo, juntos continúan por el camino de piedra hasta llegar a la casa de “Apolonio de Perge” quien es el constructor del pueblo, tiene siempre a la mano su herramientas de trabajo, es muy amable, y le plantea a Jack que le puede dar algo de comida para recuperar energías, pero para ello debe poder completar un juego que se denomina la construcción del muro piramidal de sumas, en este juego que hay que completar los huecos del muro con el número correcto de forma que los dos números de la base sumen el número que tienen por encima, por tanto hay que hacer restas y comprobaciones en forma de suma para dar con el número que falta en cada casilla del muro piramidal matemático, Jack muy hábilmente resuelve el reto y recibe su recompensa, la cual le da mucha más energía, para explorar el siguiente nivel.

5.2.1.2. Análisis de argumento base Los elementos que se encuentren en el mundo como cercas, carretas barriles, serán obstáculos para el juego, cuando un personaje se acerque a otro, la cámara deberá acercarse con el fin de ver más detalles sobre la conversación.

ESCENA: Inicio CASO: SC.1

CONTROLES: Arriba : Desplazamiento hacia adelante Abajo : Desplazamiento hacia atrás Izquierda : El personaje de desplaza a su costado izquierdo. Derecha : El personaje de desplaza a su costado derecho Shift : El personaje corre más rápido cuando se mantiene presionado mientras se camina. Espacio: El personaje puede saltar

PANTALLA: Jack en el escenario de juego, en la cumbre de la montaña “Eudoxo de Cnidos”

NOTAS: - La vida del personaje disminuye a medida que pasa el tiempo, por lo que debe superar los retos para no morir.



83

ESCENA: Inicio ACCIONES: - Jack debe bajar de la montaña y encontrar alimento o bebida.

HITS DE CASO: Jack puede divisar desde esta altura todo el pueblo de “Tales de Mileto”

RESTRICCIONES Y POSICIONES DEL

MAP|A:

PERSONAJES DEL

MODULO: Jack

DIALOGOS FIJOS: Antes de iniciar el recorrido y sin necesidad de que El jugador presione algo • Jack: ¿En dónde me encuentro?, estoy muy mareado… tengo

mucha hambre, voy a buscar algo de comida. • En este momento Jack puede seguir caminando

DIALOGOS LIBRES:

Ninguno

Tabla 27 – Escena Inicio

ESCENA: Buscando a Pitágoras de Samos

CASO: SC.2 CONTROLES: Arriba : Desplazamiento hacia adelante

Abajo : Desplazamiento hacia atrás Izquierda : El personaje de desplaza a su costado izquierdo. Derecha : El personaje de desplaza a su costado derecho Shift : El personaje corre más rápido cuando se mantiene presionado mientras se camina. Espacio: El personaje puede saltar Escape: Se puede salir de los diálogos



84

ESCENA: Buscando a Pitágoras de Samos PANTALLA: Jack en la casa de Pitágoras de Samos, donde se encuentran algunos

barriles y una carreta de transporte de bebidas. NOTAS: - La sangre del personaje disminuye a medida que pasa el tiempo,

por cuanto debe encontrar algo de comer o beber. ACCIONES: - Pitágoras de Samos se acerca a Jack y le ofrece su ayuda.

HITS DE CASO: - Cuando Jack sea divisado por Pitágoras de Samos este de manera autónoma se acercará a él, cuando este a una distancia prudente, iniciara un dialogo.

- Una vez termine los diálogos se debe disparar un mini juego en 2D que le permite a Jack obtener por cada operación matemática acertada un poco de líquido.


MAPA:

PERSONAJES DEL

MODULO: Jack Pitágoras de

Samos

DIALOGOS FIJOS: Una vez Jack y Pitágoras estén cerca • Pitágoras: ¡Hey tu! ¿Estás perdido? • Jack: No sé dónde me encuentro… al parecer estoy en el mismo

sitio de antes,.. pero todo es diferente. • Pitágoras: ¿Te puedo ayudar en algo? • Jack: Tengo mucha sed, ¿Puedes ofrecerme algo para saciar mi

sed? • Pitágoras: ¡Claro que si!, solo que en este pueblo, todos somos

amantes de las matemáticas, y si quieres algo debes demostrarme que eres uno ¡de los nuestros!

• Pitágoras: Yo te daré una serie de sumas y restas, y por cada una de ellas iré llenando un vaso si aciertas en todas te daré un vaso lleno, el cual te dará energía para que continúes tu recorrido.



85

ESCENA: Buscando a Pitágoras de Samos • Jack: Acepto el reto ¡Adelante!

DIALOGOS LIBRES:

Si después del reto, Jack se acercase de nuevo a Pitágoras, se desencadenara el dialogo: - Pitágoras: ¡ Espero todo salga bien en tu recorrido!.

Tabla 28 – Escena Buscando a Pitágoras de Samos

ESCENA: Encontrando a Liu Hui CASO: SC.3

CONTROLES: Arriba : Desplazamiento hacia adelante Abajo : Desplazamiento hacia atrás Izquierda : El personaje de desplaza a su costado izquierdo. Derecha : El personaje de desplaza a su costado derecho Shift : El personaje corre más rápido cuando se mantiene presionado mientras se camina. Espacio: El personaje puede saltar Escape: Se puede salir de los diálogos

PANTALLA: Jack, recorre el camino de piedra hasta una elevación de tierra donde encuentra un aljibe, una carreta, una cerca y el caballo Liu Hui.

NOTAS: - La sangre del personaje disminuye a medida que pasa el tiempo, por cuanto debe encontrar algo de comer o beber.

ACCIONES: - Jack se acerca al caballo y este reacciona con unos relinches, al terminar “el dialogo”, el caballo continúa acompañando a Jack en su recorrido.

HITS DE CASO: - El caballo después de terminado el dialogo debe seguir a una distancian muy cercana a Jack en todo los recorridos que haga a partir de que se realice el contacto y se dispare el dialogo.



86

ESCENA: Encontrando a Liu Hui RESTRICCIONES Y POSICIONES DEL

MAPA:

PERSONAJES DEL

MODULO: Jack Liu Hui

(Caballo)

DIALOGOS FIJOS: Una vez Jack y Liu Hui estén cerca • Jack: Que bonito caballo. • Liu Hui: iiiiihhhhiiiiiihhhh • Jack: Me gustaría tener uno como tú. • Liu Hui: iiiiihhhhiiiiiihhhhhhiiiiiiiiiiiiiiiii • Jack: Debo continuar mi camino, estoy aún muy débil, ¿Me

acompañas? • Liu Hui: iiiiihhhhiiiiiihhhh

DIALOGOS LIBRES:

Si después del reto, Jack se acercase de nuevo a Liu Hui, se desencadenara el dialogo: - Liu Hui: iiiiihhhhiiiiiihhhhhhiiiiiiiiiiiiiiiii

Tabla 29 – Escena Encontrando a Liu Hui

ESCENA: Buscando a Apolonio de Perge

CASO: SC.4 CONTROLES: Arriba : Desplazamiento hacia adelante

Abajo : Desplazamiento hacia atrás Izquierda : El personaje de desplaza a su costado izquierdo. Derecha : El personaje de desplaza a su costado derecho Shift : El personaje corre más rápido cuando se mantiene presionado mientras se camina. Espacio: El personaje puede saltar Escape: Se puede salir de los diálogos



87

ESCENA: Buscando a Apolonio de Perge PANTALLA: Jack, recorre el camino de piedra desde el sitio donde esta Liu Hui

hasta encontrar la casa de Apolonio de Perge NOTAS: - La sangre del personaje disminuye a medida que pasa el tiempo,

por cuanto debe encontrar algo de comer o beber. ACCIONES: - Apolonio de Perge está caminando por el lugar, cerca de su casa

y Jack se aproxima y Apolonio le ofrece ayudarlo. HITS DE CASO: - Apolonio ofrece a Jack comida a cambio de superar un reto que él

ha denominado, el muro de las matemáticas, donde Jack debe completar los huecos de la pared con el número correcto de forma que los dos números de la base sumen el número que tienen por encima, por tanto hay que hacer restas y comprobaciones en forma de suma para dar con el número que falta en cada casilla del muro piramidal matemático


MAPA:

PERSONAJES DEL

MODULO: Jack Apolonio de

Perge

DIALOGOS FIJOS: Una vez Jack y Apolonio de Perge estén cerca • Jack: ¡ Hola!, ¿Puedes ayudarme?, tengo mucha hambre y

quisiera comer algo y recuperar energía. • Apolonio: ¡ Hola!, Claro que sí, te puedo dar un delicioso

emparedado de jamón, pero solo si logras resolver un acertijo matemático que yo denomino, el muro de las matemáticas

• Jack: Cuéntame, ¿De qué se trata? • Apolonio: Yo te mostraré un muro piramidal donde cada ladrillo

debe tener un número, no todos los ladrillos están numerados, tú me ayudaras a numerarlos, completando con el número correcto



88

ESCENA: Buscando a Apolonio de Perge de forma que los dos números de la base sumen el número que tiene el ladrillo por encima.

• Jack: Acepto el reto ¡Adelante! DIALOGOS

LIBRES: Si después del reto, Jack se acercase de nuevo a Apolonio, se desencadenara el dialogo: - Apolonio : ¡Espero todo salga bien en tu recorrido!.

Tabla 30 – Escena Buscando a Apolonio de Perge

5.2.1.3. Definición de reglas El videojuego contiene 3 retos a cumplir y tiene un carácter progresivo; el sistema se plantea de tal manera que el usuario pueda fácilmente pasar las pruebas, sin ningún orden en específico, aunque tiene un mapa con una línea base que debería el usuario seguir, pero tiene límites en su movilidad más allá de las fronteras del mismo, que se delimitaron con montañas, altas. Se propuso un modelo de alcanzar pruebas, es decir: que al resolver cualquier prueba, se mostrará un icono en la parte superior con la información de la prueba superada, y un número que indica el número de pruebas faltantes a superar.

Navegación La Interfaz de juego debe tener elementos como un Mini-mapa, indicador de tiempo, indicador de vida, indicador de puntajes Y un inventario (Donde indique que pruebas se superaron y cuantas son faltantes). Los textos de soporte y los diálogos deben ser desplegados en popups, Que son tanto a pantalla completa como a modo de etiquetas (juegos RPG) respectivamente. Al inicio del nivel debe salir un texto que contextualice al jugador, así mismo cada prueba debe tener un texto a pantalla completa que contextualice al jugador; a modo de “objetivos de la misión” (como en los juegos de estrategia en modo “historia”). La navegación debe ser simple, con pantallas automáticas. Los textos de soporte no pueden ser obviados, es obligatorio verlos, mientras los diálogos y las secuencias de imágenes se secuencian por medio del clic izquierdo del mouse ó por una tecla especial.

Controles Las entradas deben ser totalmente controlables sólo con el teclado. Ya que no amerita el uso de más entradas puesto que la complejidad en el manejo es relativamente sencilla. Inicialmente: Los controles de desplazamiento: La Figura siguiente muestra los botones del teclado que permiten controlar los movimientos de Jack sobre el terreno.



89

Figura 15 – Controles de desplazamiento

Estados Del Personaje - El único personaje jugador es Jack, y puede realizar movimientos en todas las

direcciones de la pantalla. Tanto horizontal, vertical como diagonal (por ejemplo: superior + izquierda).

- El movimiento de los diálogos se muestra mientras los diálogos son dispuestos en la pantalla (sin importar el personaje que está hablando) acompañados de una cara ilustrada del personaje que habla.

- Jack puede saltar obstáculos, o cuando necesite escalar alguna montaña o terreno elevado.

5.2.1.4. Definición del mundo

Para el videojuego “Jack & Las matemáticas” – nivel demostrativo, se define un terreno abierto porque los sucesos definidos tienen lugar en el pueblo y todos los escenarios planteados se llevan a cabo al aire libre en el pueblo “Tales de Mileto” La figura siguiente muestra un boceto del terreno en el cual se enfatiza su sistema montañoso (alturas), y los diferentes caminos del pueblo.

Figura 16 – Mapa del terreno



90

Figura 17 – Bocetos del terreno El terreno cuenta con los siguientes objetos que son considerados para el jugador como obstáculos al momento de desplazarse, entre los cuales se tiene:

- La casa de Pitagoras de Samon - El caballo Liu Hui - La casa de Apolonio de perge - Cercas - Piedras - Arboles - Barriles - Aljibe

Una vista superior del terreno se debería de ver así:



91

Figura 18 – Terreno de juego

5.2.1.5. Identificación de Personajes A partir de la comprensión del storyline, se encontraron los siguientes personajes:

IDENTIFICACION PERSONAJES/AGENTES Id PJ.01 Nombre JACK Bocetos

Personajes con los que interactúa:

- Pitágoras de Samos - Liu Hui - Apolonio Perge

Descripción: Jack es el personaje-jugador, esto lo convierte en el personaje principal de la historia, este personaje es la representación del usuario en el juego; Dentro de juego tiene 3 retos: Un Juego de sumas y restas propuesto por Pitágoras, encontrar a Liu Hui, y pasar el juego del muro piramidal de Apolonio. Tiene un nivel de sangre que va disminuyendo a medida que pasa el tiempo, y solo puede ser llenado cuando bebe o come algo.

Tipo: Principal Referencias cruzadas SC.1, SC.2, SC.3, SC.4

Tabla 31 – Identificación de Jack

IDENTIFICACION PERSONAJES/AGENTES Id PNJ.01 Nombre Pitágoras de Samos



92

IDENTIFICACION PERSONAJES/AGENTES Bocetos


- Jack

Descripción: Pitágoras de Samos es un personaje no jugador, tiene un comportamiento autónomo, ya que al divisar a Jack, se acerca a ofrecerle su ayuda, luego le plantea un juego de sumas y restas, por medio del cual al obtener una respuesta correcta se llenaría un vaso de líquido para que Jack lo beba y gane energía para continuar su recorrido.

Tipo: No Jugador - Agente autónomo Referencias cruzadas SC.2

Tabla 32 – Identificación de Pitágoras de Samos

IDENTIFICACION PERSONAJES/AGENTES Id PNJ.02 Nombre Liu Hui Bocetos


- Jack

Descripción: Liu Hui es un caballo silvestre que se encuentra en una de las escenas del juego, y que se encariña con el personaje jugador, a partir del primer contacto de ellos, el caballo pasa de un comportamiento reactivo



93

IDENTIFICACION PERSONAJES/AGENTES a un comportamiento autónomo siguiendo a Jack en todo su recorrido.

Tipo: No Jugador - Agente reactivo y autónomo Referencias cruzadas SC.3

Tabla 33 – Identificación de Liu Hui

IDENTIFICACION PERSONAJES/AGENTES Id PNJ.03 Nombre Apolonio Perge Bocetos


- Jack

Descripción: Apolonio de Pierge es el constructor del pueblo y siempre tiene una herramienta a la mano, ofrece algo de comida a Jack, a cambio de que supere en reto que él ha denominado el muro piramidal matemático.

Tipo: No Jugador - Agente reactivo Referencias cruzadas SC.4

Tabla 34 – Identificación Pitágoras de Samos

5.2.1.6. Descripción de los Personajes A continuación es necesario profundizar en los comportamientos y funciones de cada uno de los personajes.

DESCRIPCION PERSONAJE JACK ID: DPJ.01 Nombre: Jack



94

DESCRIPCION PERSONAJE JACK Boceto:


- Pitágoras de Samos - Liu Hui - Apolonio Perge

Comportamiento: - Responde eventos de teclado - Caminar - Saltar - Dialogar con otros personajes

Dimensiones Física – Social - Psicológica:

Jack es un niño de 10 años, viene de 500 años en el pasado, siempre carga un canasto de mimbre en su espalda con unos troncos, tiene un pantalón con tirantes, es un aventurero, y le gusta mucho relacionarse con otras persona, no tiene miedo a pedir ayuda y a cercarse tanto a personas como animales, le gustan mucho los caballos.

Tipo: Principal Referencias cruzadas: SC.1, SC.2, SC.3, SC.4 PJ.01

Tabla 35 – Descripción Jack

DESCRIPCION PERSONAJE PITÁGORAS DE SAMOS

ID: DPNJ.01 Nombre: Pitágoras de Samos



95

DESCRIPCION PERSONAJE PITÁGORAS DE SAMOS Boceto:


- Jack

Comportamiento: - Caminar - Acercarse a Jack - Dialoga con Jack - Disparar mini-juego


Pitágoras de Samos es el destilador ve bebidas del pueblo tiene aproximadamente unos 35 años, siempre tiene una camisa de color, azul, no tiene cabello pero tiene una frondosa barba, es muy amable y al ver a Jack se la acerca para ofrecerle ayuda si el pasa uno de los retos del juego

Tipo: Principal Referencias cruzadas: SC.2, PJ.01

Tabla 36 – Descripción Pitágoras de Samos

DESCRIPCION PERSONAJE LIU HUI

ID: DPNJ.02 Nombre: Liu Hui Boceto:



96

DESCRIPCION PERSONAJE LIU HUI


- Jack

Comportamiento: - Caminar - Dialoga con Jack - Seguir a Jack


Liu Hui es un caballo silvestre que se encuentra en una de las escenas del juego, y que se encariña con el personaje jugador, a partir del primer contacto de ellos, el caballo pasa de un comportamiento reactivo a un comportamiento autónomo siguiendo a Jack en todo su recorrido.

Tipo: Principal Referencias cruzadas: SC.3, PNJ.03

Tabla 37 – Descripción Liu Hui

DESCRIPCION PERSONAJE APOLONIO PERGE

ID: DPNJ.03 Nombre: Apolonio Perge Boceto:



97

DESCRIPCION PERSONAJE APOLONIO PERGE


- Jack

Comportamiento: - Caminar - Acercarse a Jack - Dialoga con Jack - Disparar mini-juego


Apolonio Perge es el constructor del pueblo, no tiene cabello, siempre tiene una herramienta a la mano, es apasionado de las matemáticas y de los juegos de completar, por eso ha inventado un juego denominado el muro piramidal matemático, mediante el cual le plantea a Jack un reto para ofrecerle algo de comer y de esta forma pueda recuperar energía.

Tipo: Principal Referencias cruzadas: SC.4, PNJ.03

Tabla 38 – Descripción Apolonio de Perge

5.2.1.7. Identificación de los casos de uso de los personajes

Caminar

Liu Hui

Acercarse a Jack Seguir a

Jack



98

Figura 19 – Diagrama de casos de uso del juego En este ítem se realizara una breve descripción de las actividades realizadas por los personajes.

CASOS DE USO

Id: CU.01 Nombre de la Actividad:

Caminar

Personajes: Jack – Pitágoras – Apolonio - Liu Hui Resumen: Los personajes pueden desplazarse por el terreno, haciendo la

detección de la altura del mismo. En el caso de Jack este comportamiento es controlado por eventos de teclado, en el caso de los otros personajes el comportamiento es disparado a través del comportamiento de control.

Referencias Cruzadas:

SC.01, SC.02, SC.03, SC.04, PJ.01, PNJ.01, PNJ.02, PNJ.03

Tabla 39 – Caso de Uso Caminar

CASOS DE USO Id: CU.02 Nombre de la Actividad:

Dialogar – Dialogar con Jack

Personajes: Jack – Pitágoras – Apolonio - Liu Hui Resumen: Los personajes pueden mantener un dialogo, solo Personajes

Jugadores con Personajes no Jugadores, y viceversa. Referencias Cruzadas:


Tabla 40 – Caso de Uso Dialogar

CASOS DE USO

Id: CU.03

Jack Pitágoras

Apolonio

Lanzar Mini-Juego

Dialogar con Jack Dialogar

Saltar



99

CASOS DE USO Nombre de la Actividad:

Saltar

Personajes: Jack Resumen: Jack puede saltar obstáculos a través de eventos del teclado Referencias Cruzadas:


Tabla 41 – Caso de Uso Saltar

CASOS DE USO


Seguir a Jack

Personajes: Liu Hui Resumen: El caballo contiene un comportamiento que es disparado a

través de un dialogo, el caballo permanece a una distancia corta de Jack, después de este contacto.

Referencias Cruzadas:

SC.03, PJ.01, PNJ.02

Tabla 42 – Caso de Uso Seguir a Jack

CASOS DE USO


Lanzar un mini juego

Personajes: Pitágoras – Apolonio Resumen: Pitágoras y Apolonio, después de realizar un dialogo con Jack,

lanzan un reto que es representado por un mini juego. Referencias Cruzadas:

SC.02, SC.04, PJ.01, PNJ.01, PNJ.03

Tabla 43 – Caso de Uso Lanzar un mini juego

CASOS DE USO


Acercarse a Jack

Personajes: Pitágoras Resumen: Pitágoras al ver a Jack a una distancia lejana decide acercarse

de forma autónoma a él, desde donde se disparará un dialogo. Referencias Cruzadas:

SC.03, PJ.01, PNJ.02

Tabla 44 – Caso de Uso acercarse a Jack

5.2.1.8. Descripción de los casos de uso



100

Se describen a fondo cada uno de los atributos de las actividades desarrolladas en los casos de uso:

DESCRIPCION CASOS DE USO Id: DCU.01 Nombre de la Actividad: Caminar Personajes: Jack – Pitágoras – Apolonio - Liu Hui Resumen: Los personajes pueden desplazarse por el terreno,

haciendo la detección de la altura del mismo. En el caso de Jack este comportamiento es controlado por eventos de teclado, en el caso de los otros personajes el comportamiento es disparado a través del comportamiento de control.

Tipo: Primario Curso norm al de los eventos:

1. Se genera un estímulo; en caso de Jack es realizado por un evento del teclado, para los personajes no jugadores este se genera por un comportamiento reactivo o autónomo.

2. Se valida que la posición deseada esté libre de algún obstáculo (mediante colisiones)

3. El personaje se mueve a la posición deseada. 4. Se carga la animación de caminar.

Excepciones: Si el personaje encuentra un elemento del juego no puede pasar a través de él

Post -condiciones: La posición del personaje cambia, de acuerdo al movimiento realizado (izquierda, derecha, adelante, atrás)

Referencias Cruzadas: SC.01, SC.02, SC.03, SC.04, PJ.01, PNJ.01, PNJ.02, PNJ.03, CU.01

Tabla 45 – Descripción caso de Uso Caminar

CASOS DE USO

Id: DCU.02 Nombre de la Actividad:

Dialogar – Dialogar con Jack

Personajes: Jack – Pitágoras – Apolonio - Liu Hui Resumen: Los personajes pueden mantener un dialogo, solo Personajes

Jugadores con Personajes no Jugadores, y viceversa. Tipo: Primario Curso normal de los eventos:

1. Mediante el proceso de colisiones se determina si un personaje jugador está cerca de un personaje no jugador

2. Se valida el estado del personaje no jugador mediante la experiencia almacenada

3. De acuerdo al estado de personaje no jugador se lanza el dialogo configurado para este estado.


Post -condiciones: El estado de personaje cambia, por lo tanto la experiencia del mismo.

Referencias Cruzadas: SC.01, SC.02, SC.03, SC.04, PJ.01, PNJ.01, PNJ.02, PNJ.03, CU.02



101

Tabla 46 – Caso de Uso Dialogar

CASOS DE USO Id: DCU.03 Nombre de la Actividad:

Saltar

Personajes: Jack Resumen: Jack puede saltar obstáculos a través de eventos del teclado Tipo: Primario Curso normal de los eventos:

1. Se genera un evento de teclado (salto) 2. Se genera un cambio en la posición de altura del jugador. 3. Se dispara la animación correspondiente al salto. 4. Se determina la nueva posición de acuerdo a la altura del

terreno o al obstáculo a saltar. Excepciones: Si el personaje encuentra un elemento del juego no puede

pasar a través de él Post -condiciones: La posición del personaje cambia, de acuerdo al movimiento

realizado Referencias Cruzadas: SC.01, SC.02, SC.03, SC.04, PJ.01, PNJ.01, PNJ.02, PNJ.03,

CU.03

Tabla 47 – Caso de Uso Saltar


Seguir a Jack

Personajes: Liu Hui Resumen: El caballo contiene un comportamiento que es disparado a

través de un dialogo, el caballo permanece a una distancia corta de Jack, después de este contacto.

Tipo: Primario Curso normal de los eventos:

1. Se genera estimulo después de un dialogo, cambia el estado de Liu Hui.

2. Al cambiar la posición de Jack 3. Se recalcula la posición de Liu Hui 4. Se dispara el caminar. 5. Se incrementa el número de pruebas superadas


Post -condiciones: El estado del personaje no jugador cambia y por lo tanto su experiencia.

Referencias Cruzadas: SC.03, PJ.01, PNJ.02, CU.04

Tabla 48 – Caso de Uso Seguir a Jack


Lanzar un mini juego



102

CASOS DE USO Personajes: Pitágoras – Apolonio Resumen: Pitágoras y Apolonio, después de realizar un dialogo con Jack,

lanzan un reto que es representado por un mini juego. Tipo: Primario Curso normal de los eventos:

1. Después de un dialogo y cambio de estado del personaje no jugador

2. Se dispara un juego en 2D. 3. El jugador interactúa con el juego. 4. Por cada respuesta correcta se incrementa la sangre de

Jack 5. El jugador finaliza el juego 6. Si el juego se completó se incrementa el número de

pruebas superadas. Excepcio nes: Si el jugador genera un evento de teclado (ESC) se termina el

mini juego y la prueba no queda superada. Post -condiciones: El estado del personaje no jugador cambia y por lo tanto su

experiencia. Referencias Cruzadas: SC.02, SC.04, PJ.01, PNJ.01, PNJ.03, CU.05

Tabla 49 – Caso de Uso Lanzar un mini juego

CASOS DE USO

Id: DCU.06 Nombre de la Actividad:

Acercarse a Jack

Personajes: Pitágoras Resumen: Pitágoras al ver a Jack a una distancia lejana decide acercarse

de forma autónoma a él, desde donde se disparará un dialogo. Tipo: Primario Curso normal de los eventos:

1. Mediante el manejo de colisiones se realiza un chequeo de la posición del jugador con respecto al personaje.

2. Si la posición está dentro del rango definido como cercana 3. Se altera el estado para seguir a Jack 4. Al cambiar la posición de Jack 5. Se recalcula la posición de Liu Hui 6. Se dispara el caminar. 7. Una vez encontrados los personajes, se genera el dialogo

y se altera, el estado del personaje. Excepcion es: Si el personaje encuentra un elemento del juego no puede

pasar a través de él Post -condiciones: El estado del personaje no jugador cambia y por lo tanto su

experiencia. Referencias Cruzadas: SC.03, PJ.01, PNJ.02, CU.06

Tabla 50 – Caso de Uso acercarse a Jack

5.2.2. Modelo de Comportamiento Dentro del modelo de comportamiento vamos a diseñar la interacción de los comportamientos o tareas a ser programados para cada uno de los agentes/personajes



103

5.2.2.1. Notación textual

COMPORTAMIENTO Id: CMP.01 Comportamiento: Caminar Caso de uso: Caso de uso Caminar Tipo: Reactivo Referencias Cruzadas: SC.02, SC.04, PJ.01, PNJ.01, PNJ.03, CU.01,

DCU.01

Tabla 51 – Comportamiento Caminar

COMPORTAMIENTO Id: CMP.02 Comportamiento: Dialogar Caso de uso: Caso de uso Dialogar Tipo: Reactivo Referencias Cruzadas: SC.01, SC.02, SC.03, SC.04, PJ.01, PNJ.01,

PNJ.02, PNJ.03, CU.02, DCU02

Tabla 52 – Comportamiento Dialogar

COMPORTAMIENTO Id: CMP.03 Comportamiento: Saltar Caso de uso: Caso de uso Saltar Tipo: Reactivo Referencias Cruzadas: SC.01, SC.02, SC.03, SC.04, PJ.01, PNJ.01,

PNJ.02, PNJ.03, CU.03, DCU.03

Tabla 53 – Comportamiento Saltar

COMPORTAMIENTO Id: CMP.04 Comportamiento: Seguir a Personaje Caso de uso: Caso de uso Seguir a Jack Tipo: Reactivo Referencias Cruzadas: SC.03, PJ.01, PNJ.02, CU.04, DCU.04

Tabla 54 – Comportamiento Seguir personaje

COMPORTAMIENTO Id: CMP.05 Comportamiento: Lanzar minijuego Caso de uso: Caso de uso Lanzar minijuego Tipo: Reactivo



104

COMPORTAMIENTO Referencias Cruzadas: SC.03, PJ.01, PNJ.02, CU.05, DCU.05

Tabla 55 – Comportamiento Lanzar minijuego

COMPORTAMIENTO Id: CMP.06 Comportamiento: Acercarse a Jack Caso de uso: Caso de uso Acercarse a Jack Tipo: Reactivo Referencias Cruzadas: SC.03, PJ.01, PNJ.02, CU.06, DCU.06

Tabla 56 – Comportamiento Acercarse a Jack

5.2.2.2. Notación gráfica

Figura 20 – Diagramas del comportamiento caminar



105

Figura 21 – Diagramas del comportamiento saltar

Figura 22 – Diagramas del comportamiento Dialogar



106

Figura 23 – Diagramas del comportamiento seguir a p ersonaje

Figura 24 – Diagramas del comportamiento de lanzar mini-juego



107

Figura 25 – Diagramas del comportamiento acercarse a Jack

5.2.3. Modelo de Coordinación El modelo de coordinación nos permite diseñar los mensajes que permiten la interacción y negociación entre los agentes/personajes, a continuación se listan los mismos: La primera conversación es informativa y corresponde al inicio del juego

CONVERSACIÓN CNV.01 ID Mensaje MSJ.01 Per-formativa Inform Agente Emisor Jack Agente Receptor Usuario Agente a quien se enviaría Respuesta - Contenido ¿En dónde me encuentro?, estoy muy

mareado… tengo mucha hambre, voy a buscar algo de comida.

Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.

Tabla 57 – Mensaje MSJ.01 de conversación CNV.01



108

La segunda conversación se desencadena al encontrarse Jack con Pitágoras de Samos

CONVERSACIÓN CNV.02 ID Mensaje MSJ.02 Per-formativa Accept_Proposal Agente Emisor Pitágoras Agente Receptor Jack Agente a quien se enviaría Respuesta Pitágoras Contenido ¡Hey tu! ¿Estás perdido?. Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


CONVERSACIÓN CNV.02 ID Mensaje MSJ.03 Per-formativa Request Agente Emisor Jack Agente Receptor Pitágoras Agente a quien se enviaría Respuesta Jack Contenido No sé dónde me encuentro… al parecer estoy

en el mismo sitio de antes,.. pero todo es diferente.


lenguaje natural.


CONVERSACIÓN CNV.02 ID Mensaje MSJ.03 Per-formativa Request Agente Emisor Jack Agente Receptor Pitágoras Agente a quien se enviaría Respuesta Jack Contenido No sé dónde me encuentro… al parecer estoy

en el mismo sitio de antes,.. pero todo es diferente.


lenguaje natural.




109

CONVERSACIÓN CNV.02

ID Mensaje MSJ.04 Per-formativa Proposal Agente Emisor Pitágoras Agente Receptor Jack Agente a quien se enviaría Respuesta Pitágoras Contenido ¿Te puedo ayudar en algo? Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


CONVERSACIÓN CNV.02 ID Mensaje MSJ.05 Per-formativa Inform_If Agente Emisor Jack Agente Receptor Pitágoras Agente a quien se enviaría Respuesta Jack Contenido Tengo mucha sed, ¿Puedes ofrecerme algo

para saciar mi sed? Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


CONVERSACIÓN CNV.02 ID Mensaje MSJ.06 Per-formativa Request Agente Emisor Pitágoras Agente Receptor Jack Agente a quien se enviaría Respuesta Pitágoras Contenido ¡Claro que si!, solo que en este pueblo, todos

somos amantes de las matemáticas, y si quieres algo debes demostrarme que eres uno ¡de los nuestros!


lenguaje natural.


CONVERSACIÓN CNV.02 ID Mensaje MSJ.07 Per-formativa Request



110

CONVERSACIÓN CNV.02 Agente Emisor Pitágoras Agente Receptor Jack Agente a quien se enviaría Respuesta Pitágoras Contenido ¡Claro que si!, solo que en este pueblo, todos

somos amantes de las matemáticas, y si quieres algo debes demostrarme que eres uno ¡de los nuestros!


lenguaje natural.


CONVERSACIÓN CNV.02 ID Mensaje MSJ.08 Per-formativa Inform Agente Emisor Pitágoras Agente Receptor Jack Agente a quien se enviaría Respuesta Pitágoras Contenido Yo te daré una serie de sumas y restas, y por

cada una de ellas iré llenando un vaso si aciertas en todas te daré un vaso lleno, el cual te dará energía para que continúes tu recorrido.


lenguaje natural.


CONVERSACIÓN CNV.02 ID Mensaje MSJ.09 Per-formativa Confirm Agente Emisor Pitágoras Agente Receptor Jack Agente a quien se enviaría Respuesta Pitágoras Contenido Acepto el reto ¡Adelante! Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.

Tabla 66 – Mensaje MSJ.09 de conversación CNV.02 La tercera conversación se desencadena al encontrarse Jack con el caballo Liu Hui

CONVERSACIÓN CNV.03 ID Mensaje MSJ.10



111

CONVERSACIÓN CNV.03 Per-formativa Inform Agente Emisor Jack Agente Receptor Liu Hui Agente a quien se enviaría Respuesta Jack Contenido Que bonito caballo. Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


CONVERSACIÓN CNV.03 ID Mensaje MSJ.11 Per-formativa Accept_Proposal Agente Emisor Liu Hui Agente Receptor Jack Agente a quien se enviaría Respuesta Liu Hui Contenido iiiiihhhhiiiiiihhhh Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


CONVERSACIÓN CNV.03 ID Mensaje MSJ.12 Per-formativa Inform Agente Emisor Jack Agente Receptor Liu Hui Agente a quien se enviaría Respuesta Jack Contenido Me gustaría tener uno como tú. Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


CONVERSACIÓN CNV.03 ID Mensaje MSJ.13 Per-formativa Inform Agente Emisor Jack Agente Receptor Pitágoras Agente a quien se enviaría Respuesta Jack Contenido Iiiiihhhhiiiiiihhhhhhiiiiiiiiiiiiiiiii Lenguaje Español Codificación Lenguaje natural



112

CONVERSACIÓN CNV.03 Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


CONVERSACIÓN CNV.03 ID Mensaje MSJ.12 Per-formativa Inform Agente Emisor Jack Agente Receptor Liu Hui Agente a quien se enviaría Respuesta Jack Contenido Debo continuar mi camino, estoy aún muy débil,

¿Me acompañas? Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


CONVERSACIÓN CNV.03 ID Mensaje MSJ.13 Per-formativa Inform Agente Emisor Liu Hui Agente Receptor Jack Agente a quien se enviaría Respuesta Liu Hui Contenido Iiiiihhhhiiiiiihhhh Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.

Tabla 72 – Mensaje MSJ.13 de conversación CNV.03 La cuarta conversación se desencadena al encontrarse Jack con Apolonio Perge

CONVERSACIÓN CNV.04 ID Mensaje MSJ.14 Per-formativa Accept_Proposal Agente Emisor Jack Agente Receptor Apolonio Agente a quien se enviaría Respuesta Jack Contenido ¡Hola!, ¿Puedes ayudarme?, tengo mucha

hambre y quisiera comer algo y recuperar energía.


lenguaje natural.




113

CONVERSACIÓN CNV.04

ID Mensaje MSJ.15 Per-formativa Request Agente Emisor Apolonio Agente Receptor Jack Agente a quien se enviaría Respuesta Apolonio Contenido ¡Hola!, Claro que sí, te puedo dar un delicioso

emparedado de jamón, pero solo si logras resolver un acertijo matemático que yo denomino, el muro de las matemáticas


lenguaje natural.


CONVERSACIÓN CNV.04 ID Mensaje MSJ.16 Per-formativa Inform Agente Emisor Query_If Agente Receptor Apolonio Agente a quien se enviaría Respuesta Jack Contenido Cuéntame, ¿De qué se trata? Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


CONVERSACIÓN CNV.04 ID Mensaje MSJ.17 Per-formativa Inform Agente Emisor Apolonio Agente Receptor Jack Agente a quien se enviaría Respuesta Apolonio Contenido Yo te mostraré un muro piramidal donde cada

ladrillo debe tener un número, no todos los ladrillos están numerados, tú me ayudaras a numerarlos, completando con el número correcto de forma que los dos números de la base sumen el número que tiene el ladrillo por encima.

Lenguaje Español Codificació n Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.




114

CONVERSACIÓN CNV.04 ID Mensaje MSJ.18 Per-formativa Confirm Agente Emisor Jack Agente Receptor Apolonio Agente a quien se enviaría Respuesta Jack Contenido Acepto el reto ¡Adelante! Lenguaje Español Codificación Lenguaje natural Ontología No aplica. Porque se encuentra codificada en

lenguaje natural.


5.2.4. Modelo de Organización Para el modelo de organización del caso de estudio los agentes pueden organizarse en 3 grupos, los agentes jugadores, agentes no jugadores que disparan mini juegos y agentes animales, de esta forma el modelo de organización se podría ver la siguiente forma, la cual permite re-utilizar funcionalidades y comportamientos:

Figura 26 – Modelo de organización

5.2.5. Modelo de Diseño Presentamos el modelo de diseño para describir los componentes de los distintos modelos facilitando su definición en un lenguaje de programación.



115

5.2.5.1. Diseño de Agentes

SISTEMA PERSONAJE/AGENTE Id: AG.01 Nombre del Personaje/Agente: Jack Arquitectura Jugador Lenguaje C# - Unity Sub-Sistema Asociado el sistema:

Thrid Person Controller Referencias Cruzadas SC.1, SC.2, SC.3, SC.4 PJ.01

Tabla 78 – Arquitectura Jack

SISTEMA PERSONAJE/AGENTE

Id: AG.02 Nombre del Personaje/Agente: Pitágoras Arquitectura Deliberativo Lenguaje C# - Unity Sub-Sistema Asociado el sistema:

Game2D Referencias Cruzadas SC.2, PJ.02

Tabla 79 – Arquitectura Pitágoras

SISTEMA PERSONAJE/AGENTE Id: AG.03 Nombre del Personaje/Agente: Liu Hui Arquitectura Reactivo Lenguaje C# - Unity Sub-Sistema Ninguno Referencias Cruzadas SC.3, PNJ.03

Tabla 80 – Arquitectura Liu Hui

SISTEMA PERSONAJE/AGENTE Id: AG.02 Nombre del Personaje/Agente: Aplonio Arquitectura Deliberativo Lenguaje C# - Unity Sub-Sistema Asociado el sistema:

Game2D Referencias Cruzadas SC.4, PNJ.03

Tabla 81 – Arquitectura Apolonio



116

5.2.5.2. Diseño de la plataforma

PLATAFORMA Id: PL.01 Nombre de la Plataforma:

PAUnit

Descripción: Para la implementación de los agentes se desarrolló una API explicada en el Capitulo 4.

Lenguaje: C# Hardware: • Procesador Pentium a 2100MHz

• Sistema Operativo Windows o Consola.

• Recomandado 2GB

• 500 MB de disco duro disponible

• Monitor 1024x768 a 32 bits.

Software: MonoDevelop C# Usuario: Jack – Pitagoras – Apolonio – Lui hui Referencias Cruzadas:

Tabla 82 – Diseño de la lataforma

5.3. Análisis de la aplicación del modelo metodológ ico al caso de estudio Después de haber aplicado la metodología a un caso de estudio real, hacer una análisis de su aplicación desglosándolo en ventajas o beneficios y desventajas o tropiesos al seguir el modelo propuesto.

5.2.6. Ventajas Productividad Cuando la producción de software se trabaja alrededor necesidades puntuales de negocio, en este caso videojuegos, implica la gestión de conocimiento multidisciplinario en etapas simultáneas; el modelo metodológico propuesto sirve para enfocar la atención en los entregables por disciplina en momento que se necesita e inmediatamente liberar los recursos para que puedan moverse a otros proyectos, Comunicación Al Aplicar un sistema de modelos contra personas que ejecutan tareas simplifica la distribución y entrega de información, al conocer de ante mano los modelos propuestos, todos los miembros del equipo entienden la información que se registra en la documentación del proyecto. Gestión de conocimiento



117

Al tener la información del proyecto en documento común el conocimiento comienza a tener estructura, el equipo completo va a generar un comportamiento distinto, se agilizan sus procesos y por consiguiente los niveles de calidad y satisfacción del producto aumentan, ya que se tiene información histórica, que sirve como base para próximas implementaciones, cuando se tiene toda la información, la planeación y elaboración de estrategias se hace de forma más certera, ya que toda la memoria que se ha venido almacenando con el tiempo, facilita la definición de nuevos videojuegos

5.2.7. Desventajas Dependencia El modelo propuesto sigue una serie de fases, procesos, actividades las cuales deben seguir su aplicación en sentido estricto, lo cual podría limitar la creatividad de los implicados en el proyecto y limita el desarrollo debido a que se debe esperar el desarrollo de una fase para continuar con la siguiente, lo que se define en cada etapa es inamovible y hasta que no finaliza con éxito una etapa no se pasa a la siguiente.



118

5. PRUEBA PRELIMINAR

a. Validación preliminar Se realizó una prueba con 5 estudiantes de especialización de la Universidad del Cauca, se les pidió que tomarán la metodología y el caso de estudio presentado, así como la librería reutilizable para construir un prototipo de un juego, y luego evaluarán los ítems:

• Tiempo de diseño • Tiempo de implementación • Facilidad de uso de los modelos y pasos propuestos por la metodología • Percepción por parte del jugador que usa el personaje.

Figura 27 – Estudiantes en validación preliminar



119

Figura 28 – Estudiantes en validación preliminar

La prueba duro aproximadamente 5h, tiempo con el que se disponía de los estudiantes, se propusieron varios juegos interesantes y 4 de ellos lograron llegar a la implementación de los mismos, de manera muy rápida.

Figura 29 – Vista de uno de los juegos desarrollado s



120

Se realizó la evaluación de acuerdo a un criterio 0 a 5 donde, cero corresponde a la puntuación más baja o insatisfecho, y 5 a la puntación más alta o satisfecho La evaluación fue tabulada de la siguiente forma:

PLATAFORMA Estudiante Tiempo de

diseño

Tiempo de implementación

Facilidad de uso de los modelos

y pasos propuestos por la metodología

Percepción por parte del jugador que

usa el personaje.

Cesar Julian Rivera 5 5 5 5 Edison Arley Plaza 4 3 5 4 Fabian Ruano 4 5 5 4 Jhon Emanuel Zuñiga 3 2 5 3 Andrés Ruiz 4 4 5 5 Promedio 4 3,8 5 4,2

Tabla 83 – Tabulado de datos de la validación Los resultados muestran que los estudiantes tuvieron un nivel de aceptación superior, a la metodología y en tan solo 5 horas pudieron crear un juego demostrativo, usando tanto la metodología como la construcción de la librería, debido a la motivación que se generó en ellos, como trabajo futuro, se propusieron la terminación de los juegos y apoyados en el uso de la metodología. Algunos de los comentarios que se recibieron de la metodología fueron

Estudiante Cesar Julian Rivera Me pareció muy buena puesto que siempre es bueno tener un mecanismo

a seguir para que el desarrollo se vuelva menos artesanal. Edison Arley Plaza Me gusto que no solo se queda en la parte de teoría sino que llega hasta

la etapa de desarrollo lo cual la hace muy completa Fabian Ruano Me facilito muchas el concentrarme en los personajes que en el caso de

los juegos de aventura es lo principal Jhon Emanuel Zuñiga Al tener tantos procesos el análisis y el diseño es extenso, y me falto un

poco de tiempo. Andrés Ruiz Fue muy fácil construir la versión del juego en tampoco tiempo con lo que

ya ofrecía el sistema

Tabla 84 – Comentarios de los asistentes Es importante destacar que esta solo es una prueba preliminar debido a la cantidad de estudiantes y no se podría tomar como una prueba concluyente, sin embargo nos aproxima a una idea en cuanto a la aceptación y facilidad de uso de la metodología.



121

5. CONCLUSIONES Y RECOMENDACIONES

6.1. Conclusiones La metodología Mas-CommonKADS presenta la estructura y las bases teóricas necesarias para construir una propuesta metodológica que permita el modelado y diseño de videojuegos de aventura en 3D basado en Agentes Software. Teniendo en cuenta que su etapa de conceptualización se define con base en el lenguaje natural, Mas-CommonKADS ofrece la posibilidad de integración de varias de las tareas necesarias para crear de videojuegos que usualmente son desarrollados por personal con un enfoque artístico. La propuesta metodológica planteada en este proyecto, construida con base en la metodología MAS-CommonKADS, presenta los argumentos suficientes para ser tomada en cuenta al momento de realizar el desarrollo de un videojuego de aventura en 3D. Este trabajo constituye una contribución al área de desarrollo de videojuegos, ya que ofrece los componentes teóricos y prácticos que facilitan la construcción de videojuegos de aventura 3D, al incorporar las características de los agentes software a los personajes de los videojuegos. La API construida a partir de la metodología propuesta para la implementación Agentes/Personajes se encuentra basada en los protocolos de comunicación de FIPA para agentes, lo cual permite dotar a los personajes de un juego de características como: reactividad, proactividad y habilidad social. Esto reduce la complejidad al momento de codificar nuevos juegos de aventura 3D basados en agentes, y soportados sobre el framework para la construcción de videojuegos. A pesar de que la industria de los videojuegos ha sido catalogada como una de las mayores recaudadoras del mundo del entretenimiento en los últimos años, resulta notable la reducida cantidad de información formal relacionada con el desarrollo de videojuegos, desde una perspectiva que permita abordar las diferentes tareas del equipo de trabajo. Este proyecto plantea una propuesta metodológica donde se incluyen tanto productos y conceptos del equipo artístico como del equipo de desarrollo del juego, facilitando la comunicación entre los miembros del equipo. En este sentido, es importante resaltar que el proceso de desarrollo de un videojuego es una tarea multidisciplinaria, en la cual, no solo es necesario contar con el trabajo de un equipo de desarrolladores, sino que también es necesario el apoyo de personal con



122

conocimiento en áreas como: Comunicación Social, Música, Diseño Gráfico, entre otras, dependiendo la magnitud del desarrollo. Los procesos planteados en la propuesta metodológica permiten la integración de los productos desarrollados por los miembros del equipo de desarrollo, facilitando la comprensión en el momento de implementar el videojuego. Se pudo dar respuesta a la pregunta “¿Cómo se puede facilitar el diseño y creación de personajes en videojuegos a través del uso de tecnologías de agentes inteligentes? “, dado que la metodología fue validada preliminarmente y realizando la implementación de 5 niveles demostrativos en un tiempo corto (3 horas aproximadamente), usando no solo las ventajas del modelo metodológico sino también la librería propuesta, facilitando el análisis, diseño e implementación.

6.2. Recomendaciones

Si se planea trabajar en el desarrollo de videojuegos en especial de aventura en 3D, la propuesta metodológica planteada en este proyecto, debería pensarse en la creación de una herramienta gráfica que sirva de apoyo en el modelado de los distintos artefactos de análisis y diseño planteados. Igualmente se debe investigar acerca de los protocolos de comunicación de agentes que soportan el servicio de transporte de mensajes por la red, con el fin de conseguir los personajes creados en la plataforma se comuniquen con otros personajes logrando la creación de juegos de uso masivo a través de internet. Si se desea abordar trabajos relacionados con la construcción de un videojuego es recomendable la creación de un grupo de trabajo interdisciplinario, que permita realizar una correcta etapa de conceptualización del juego ya que de este trabajo depende el éxito o fracaso del mismo.



123

REFERENCIAS BIBLIOGRAFICAS

[1] Lupu, E. Study regarding the impact of motion games in the intellectual-motric development of preschool

children. (2011). 2nd World Conference on Psychology, Counselling and Guidance, (pp. 1209—1214 ). Petroleum-Gas University, Bucharest Bvd. Romaniaa.

[2] Abdullah Al Mahmuda, Omar Mubina, Suleman Shahidb, Jean-Bernard Martensa. Designing social games for children and older adults: Two related case studies. (2010). Entertainment Computing, (pp. 147—156). University of Tilburg, Tilburg, The Netherlands.

[3] Noh, S.S. & Hong, S.D. & Park, J.W. Using a Game Engine Technique to Produce 3D Entertainment Contents. (2006). ICAT '06: Proceedings of the 16th International Conference on Artificial Reality and Telexistence — Workshops, (pp. 246—251). Washington, DC, USA: IEEE Computer Society.

[4] Huai-Che Lee Inst. for Inf. Ind., Cshinchu Chia-Ming Chang ; Jui-Shiang Chao ; Wei-Te Lin. Realistic Character Motion Response in Computer Fighting Game. (2007). Multimedia, 2007. ISM 2007. Ninth IEEE International Symposium, (pp. 246—251). Washington, DC, USA: IEEE Computer Society.

[5] Jessica M. Jerabecka, Christopher J. Ferguson. The influence of solitary and cooperative violent video game play on aggressive and prosocial behavior. (2013). Computers in Human Behavior, (pp. 2573—2578). United States.

[6] Canovas, Guillermo. Videojuegos, menores y responsabilidad de los padres. (2005). Estudio realizado por

protégeles. Safer Internet Programme – Comisión europea. [7] Dragert, C. Kienzle, J. ; Verbrugge, C. Reusable components for artificial intelligence in computer games.

(2012). Games and Software Engineering (GAS), 2012 2nd International Workshop. (pp. 35—41). Zurich, Switzerland.

[8] Hartsook, K. Zook, A. ; Das, S.; Riedl, M.O. Toward supporting stories with procedurally generated game

worlds. (2011). Computational Intelligence and Games (CIG), IEEE Conference. (pp. 297—304). Atlanta, GA, United States.

[9] Yuan Hong. Zhen Liu. A Preliminary Research on Decision Model Based on Bayesian Techniques for an

NPC in Computer Games. (2010). Computational Intelligence and Design (ISCID), 2010 International Symposium – Volume 2. (pp. 240—243). Hangzhou. China.

[10] Chandler, Rafael. It Builds Character: Character Development Techniques in Games. (2005). Gamasutra

The Art & business of Making Games. United States.

[11] Lopez. Jaime Adalberto, Botina .Yuli Margarita. Vidal. Juan Carlos, Niño. Miguel Angel. Intelligent Agents in on-line Education. (2006. Euro American Conference on Telematics and Information Systems EATIS2006. (pp.114—121). Universidad Autónoma de Bucaramanga. Colombia.

[12] Ferber, J. y Gutknecht, O. A Meta-Model for the Analysis and Design of Organizations in Multi-Agent

Systems. (1998) Proceedings of the Third International Conference on Multi-Agent Systems ICMAS98,Paris. Francia.



124

[13] André Marchanda, Thorsten Hennig-Thurau. Value Creation in the Video Game Industry: Industry Economics, Consumer Benefits, and Research Opportunities. (2013). Journal of Interactive Marketing. (pp. 141—157). University London, UK.

[14] Yanli Wang; Feng Wang ; Yun Cheng ; Chengling Zhao ; Zhongmei Zheng. The study of characters design

in PRG educational games. (2009). Computer Science and Information Technology, ICCSIT 2nd IEEE International Conference. (pp. 44—47 ). Beijing. China.

[15] Y.Y. Ng, C.W. Khong, H. Thwaites. A Review of Affective Design towards Video Games. (2012). Procedia -

Social and Behavioral Sciences. (pp. 687—691). Antalya, Turkey [16] Crawford, Chris. The Art of Computer Games. Washington: Washington State University Vancouver, 2000.

[17] Tanguay, David. A guide to create the ideal adventure game. California: Adventure Classic Gaming, 2006.

[18] Egri, Lajos. Art of Creative Writing. Ohio: UArt, 1998.

[19] Zerbst, Stefan y Düvel, Oliver. 3D Game Engine Programming. Boston. Series Editor, 2004.

[20] Feil, John y Scattergood, Marc. Beginning Game Level Desing. Boston : Thomson Course Technology PTR,,

2005.

[21] Carrasco Polaino, Rafael. Propuesta De Tipología Básica De Los Videojuegos De PC Y Consola. 7, Villanueva. ICONO 14, 2006, Vol. I.

[22] Archer William, Play-Making, A Manual of Craftsmanship, Capitulo 5, 1913

[23] Freitas Sara, Maharg Paul. Digital Games and Learning. A&C Black, 2011

[24] Freeman David, Creating emotion in games: the craft and art of Emotioneering, Computers in Entertainment

(CIE), v.2 n.3, July 2004

[25] FIPA Abstract Architecture Specification. Foundation for Intelligent Physical Agents. 2002

[26] Russell, S. J. and Norvig P., “Artificial Intelligence: A Modern Approach”, Englewood Cliffs, NJ: Prentice Hall, 1995.

[27] Maes, P., “Artificial Life Meets Entertainment: Life like Autonomous Agents”, Communications of the ACM,

Vol. 38, Nº. 11, pp. 108-114, 1995.

[28] Smith, D. C., A. Cypher and J. Sphorer., “KidSim: Programming Agents Without a Programming Language”, Communication of the ACM, Vol. 37, Nº. 7, pp. 55-67, 1994.

[29] Hayes-Roth, B., “An Architecture for Adaptive Intelligent System”, Artificial Intelligence: Special Issue on

Agents and Interactivity, 72, pp. 329-365, 1995.

[30] Giret Adriana, Insfrán Emilio, Pastor Oscar, Cernuzzi Luca: OO-METHOD para el desarrollo de Sistemas de Agentes. Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia, España. 2000.

[31] Wooldridge, M. and Jennings N. R., “Agent Theories, Architectures, and Languages: a Survey”, in

Wooldridge and Jennings Eds., Intelligence Agents, Berlin: Springer-Verlag, Vol. 1, Nº 22, 1995.

[32] Russell, Stuart. Inteligencia Artificial: un enfoque moderno. México. Prentice - Hall, 1996.

[33] Jennings, Nicholas. Wooldridge, Michael. Intelligent Agents: Theory and Practice Manchester : Knowledge Engineering Review, 1994.

[34] DeLoach, Scott. Analysis and Design using MaSE and AgentTool. Ohio MAICS, 2001. Vol. XII.



125

[35] Wooldridge, Michael. Jennings, Nicholas y Kinny, David. The Gaia Methodology for Agent-Oriented Analysis and Design. 27, Boston: Kluwer Academic Publishers, 2000, Vol. I.

[36] Caire, G., Leal, F., Chainho, P., Evans, R., Garijo, F., Gomez-Sanz, J. J., Pavon, J., Kerney, P., Stark, J.,and

Massonet, P. Eurescom P907: MESSAGE - Methodology for Engineering Systems of Software Agents. 2002.

[37] Gómez-Sanz, J. Modelado de Sistemas Multi-Agente. PhD thesis, Departamento de Sistemas Informáticos

y Programación, Universidad Complutense Madrid, 2002.

[38] Iglesias Fernández, Carlos Ángel. Definición de una Metodología Para el Desarrollo de Sistemas Multiagente. Madrid-España: Universidad Politécnica de Madrid, 1998.

[39] Rumbaugh, J, y otros. Object-Oriented Modeling and Design. Prentice-Hall, 1991.

[40] Pressman, Roger. Ingeniería del Software. Mexico : Mac Graw Hill, 2005.

[41] Samara Ruiz, Maria Eguimendia. Metodología para sistemas multiagente, MaSE. Vol. 1. 2005

[42] Aguilar, J. Hidrobo, F. y Cerrada M. A Methodology to Specify Multiagent Systems. Lecture Notes in Artificial

Intelligence, 4496:92–101, 2007.

[43] Ouarda Bourass, Miguel Angel Almasa. Metodologia GAIA. 0506. Revista TAIA, Vol. 1.

[44] Salen, Katie. Zimmerman, Eric. Rules of Play: Game Design Fundamentals. The MIT Press, 2004

[45] Larman, Craig. UML y Patrones. Prentice Hall. 2003.

[46] Kirmse, Andrew. Game Programming Gems 4. Massachusetts. Charles River Media.

[47] Bourg, David y Seeman, Glenn. AI for Game Developers . United States : O’Reilly Media, 2004.

[48] Collis, Jaron y Divine, Ndunu. ZEUS Technical Manual. Estados Unidos: British Telecommunication plc., 1999.

[49] Vicente J. Julián Inglada, Vicente Juan Botti Navarro, Desarrollo de sistemas multi-agente en tiempo real,

Revista Iberoamericana de Inteligencia Artificial. No.18, pp. 51-63. ISSN: 1137-3601. – 2003

[50] Gómez Sanz, Jorge J. Metodologías para el desarrollo de sistemas multi-agente, Facultad de Informática, Universidad Complutense, Avda. Complutense Madrid, ISSN: 1137-3601, 2003

[51] Henao Cálad Mónica, CommonKADS-RT: Una Metodología para el Desarrollo de Sistemas Basados en el

Conocimiento de Tiempo Real, Tesis doctoral, Valencia, España. Abril de 2.001

[52] Nwana, Hyacinth, Ndumu, Divine y Lee, Lyndon. ZEUS: An Advanced Tool-Kit for Engineering Distributed Multi-Agent Systems. CiteSeer.IST. 2007

[53] Ierache, Jorge Salvador. Elaboracion de una aproximacion metodologica para el desarrollo de software

orientado a sistemas multiagente. Madrid-España : s.n., 2003.

[54] Patricia Charlton, Yan Chen, Fredrik Espinoza, Abe Mamdani, Olle Olsson, Jeremy Pitt,Fergal Somers, and Annika Waern. An open agent architecture supporting multimediaservices on public information kiosks. In Proceedings of PAAM’97, London, U.K 1997).

[55] AMASE: Agent-based Mobile Access to Information Services [En línea] 18 de Diciembre de 2001.

[56] ABROSE: A Co-operative Multi-Agent Based Framework for Electronic Marketplace 18 de Diciembre de

2001.



126

[57] Chess D., Harrison C., Kershenbaum A, “Mobile Agents: Are They A Good Idea?”. IBM Research Division. T. J. Watson Research Center. 1995.

[58] Dautenhahn, K.; Bond, A.H.; Canamero, L.; Edmonds, B. Socially Intelligent Agents Creating Relationships

with Computers and Robots Series: , Vol. 3 ISBN: 978-1-4020-7057-0

[59] Ferreiro Barreiro, Divina. Estandar FIPA "Foundation For Intelligent Physical Agents". Vigo : s.n., 2002.

[60] Smart, P. R., Scutt, T., Sycara, K., & Shadbolt, N. R. (in press) Integrating ACT-R Cognitive Models with the Unity Game Engine. In J. O. Turner, M. Nixon, U. Bernardet & S. DiPaola (Eds.), Integrating Cognitive Architectures into Virtual Character Design. IGI Global, Hershey, Pennsylvania, USA. 2016

[61] Mayay, Israel. Aplicación con lenguaje C# de entretenimiento basado en Unity 3D. 2011.

modelo metodológico para diseñar y coontruir personajes en

Documents