DESARROLLO DE PERSONAJES NO JUGABLES PARA UN JUEGO DE LUCHA PROGRESIVA MEDIANTE MÁQUINAS DE ESTADO FINITO. José Mario Pérez Cotes

UNIVERSIDAD MILITAR NUEVA GRANADA DESARROLLO DE PERSONAJES NO JUGABLES PARA UN JUEGO DE LUCHA PROGRESIVA MEDIANTE ´ MAQUINAS DE ESTADO FINITO Jos´e

1 downloads 32 Views 21MB Size

Recommend Stories


Subespacio generado por un conjunto finito de vectores (envoltura lineal de un conjunto finito de vectores)
Subespacio generado por un conjunto finito de vectores (envoltura lineal de un conjunto finito de vectores) ´ 1. Listas de vectores. Listas de vectore

Barbie girls. de Mario Cantú Toscano. Personajes: Bibi Chiquis Nené
Barbie girls de Mario Cantú Toscano Personajes: Bibi Chiquis Nené Acto único Al fondo del escenario hay tres cajas de muñecas Barbie de gran tamaño

DISEÑO DE UNA MATRIZ PROGRESIVA PARA CHAPA
Memoria “DISEÑO DE UNA MATRIZ PROGRESIVA PARA CHAPA” PFC presentado para optar al título de Ingeniero Técnico Industrial especialidad MECÁNICA por Ma

Desarrollo del juego de baloncesto
Deportes de cesta. Basquetball. Basket. Basquetbol. Reglas y juego. Instalaciones. Baloncesto femenino

Story Transcript

UNIVERSIDAD MILITAR NUEVA GRANADA

DESARROLLO DE PERSONAJES NO JUGABLES PARA UN JUEGO DE LUCHA PROGRESIVA MEDIANTE ´ MAQUINAS DE ESTADO FINITO

Jos´e Mario P´erez Cotes

UNIVERSIDAD MILITAR NUEVA GRANADA FACULTAD DE INGENIER´IA PROGRAMA DE INGENIER´IA EN MULTIMEDIA ´ D.C. BOGOTA 2012

UNIVERSIDAD MILITAR NUEVA GRANADA

DESARROLLO DE PERSONAJES NO JUGABLES PARA UN JUEGO DE LUCHA PROGRESIVA MEDIANTE ´ MAQUINAS DE ESTADO FINITO

Jos´e Mario P´erez Cotes

Trabajo de Desarrollo tecnol´ogico presentado como requisito parcial para obtener el t´ıtulo de: INGENIERO EN MULTIMEDIA

Director Eduard Leonardo Sierra Ball´ en Ingeniero de Sistemas

UNIVERSIDAD MILITAR NUEVA GRANADA FACULTAD DE INGENIER´IA PROGRAMA DE INGENIER´IA EN MULTIMEDIA ´ D.C. BOGOTA 2012

Nota de Aceptaci´ on

Director

Jurado

Jurado

Comentarios

Fecha: 30 de Noviembre de 2012

CONTENIDO p´ ag.

LISTA DE TABLAS

10

LISTA DE FIGURAS

12

´ 1 INTRODUCCION 1.1 Planteamiento . . . . . . . . . 1.2 Objetivo General . . . . . . . 1.2.1 Objetivos Especificos . . . . 1.3 Organizaci´on del Documento .

. . . .

17 17 18 18 18

. . . . . . . . . . . . . . . . .

19 19 19 21 23 24 26 27 30 30 31 31 32 32 34 35 35 37

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 MARCO DE REFERENCIA 2.1 Inteligencia Artificial (IA) . . . . . . . . . . . . . . . . . . 2.1.1 Inteligencia Artificial en Videojuegos . . . . . . . . . . . 2.1.2 Metas de la IA de un Juego . . . . . . . . . . . . . . . . 2.1.3 Modelo Inteligencia Artificial (IA) en Videojuegos . . . . 2.1.4 Inteligencia Artificial en Personajes No Jugables (NPC) 2.2 Maquinas de Estados Finitos (FSM) . . . . . . . . . . . . 2.2.1 Dise˜ no y An´alisis de las FSM . . . . . . . . . . . . . . . 2.2.2 Tabla de Estados y Transiciones . . . . . . . . . . . . . . 2.2.3 Debilidades de las FSMs . . . . . . . . . . . . . . . . . . 2.3 Juegos de Lucha Progresiva (Beat ’em up) . . . . . . . . . 2.3.1 Tem´atica e Influencia . . . . . . . . . . . . . . . . . . . . 2.3.2 Subg´eneros . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Caracter´ısticas Principales de los Beat ’em up . . . . . . 2.3.4 Elementos de la Jugabilidad . . . . . . . . . . . . . . . . 2.3.5 Elementos para un Juego Equilibrado . . . . . . . . . . . 2.3.6 Elementos de Inteligencia Artificial . . . . . . . . . . . . 2.3.7 T´ecnicas de IA m´as Usadas para los Beat ’em up . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . .

3 ESTUDIO DEL COMPORTAMIENTO DE LOS NPCs EN JUEGOS DE LUCHA PROGRESIVA 39

´ CONCEPTUAL 4 DEFINICION 4.1 Idea Principal . . . . . . . . . . . 4.2 Concepto . . . . . . . . . . . . . 4.2.1 Titulo y Sinopsis del Juego . . 4.2.2 Metas Est´eticas . . . . . . . . 4.2.3 Arte Conceptual . . . . . . . . 4.2.4 Competencia . . . . . . . . . . 4.2.5 G´enero . . . . . . . . . . . . . 4.2.6 Audiencia . . . . . . . . . . . . 4.2.7 Plataforma Objetivo . . . . . . 4.2.8 Caracter´ısticas Clav´e . . . . . . 4.2.9 Reglas de Juego . . . . . . . . . 4.2.10 Control . . . . . . . . . . . . . 4.2.11 Acciones del Jugador . . . . . . 4.2.12 C´amara . . . . . . . . . . . . . 4.2.13 Mundo del Juego . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

43 43 43 43 44 44 44 44 45 45 45 45 48 48 49 49

˜ DEL JUEGO Y DISENO ˜ DE LA IA 5 DISENO 5.1 Dise˜ no del Juego . . . . . . . . . . . . . . . . . . . 5.1.1 Personajes . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Diagramas de Plan del Juego/Game Layout . . . 5.1.3 Dise˜ no del Escenario/Level Layout . . . . . . . . 5.1.4 Gui´on Gr´afico/Story Board . . . . . . . . . . . . 5.2 Dise˜ no de la IA . . . . . . . . . . . . . . . . . . . . 5.2.1 Diagramas de Flujo/Game Flow . . . . . . . . . . 5.2.2 Dise˜ no de las M´aquinas de Estado Finito . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

51 51 51 51 52 52 54 54 57

. . . . . .

63 63 66 68 69 69 70

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

6 RESULTADOS 6.1 Resultados de las FSMs . . . . . . . . . 6.2 Resultados del Prototipo . . . . . . . . . 6.3 Pruebas del Prototipo . . . . . . . . . . 6.4 Resultados de las Pruebas del Prototipo 6.4.1 Resultados de la Muestra . . . . . . . 6.4.2 Resultados del Prototipo . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

7 CONCLUSIONES

77

BIBLIOGRAF´IA

79

˜ DE PERSONAJES A DISENO A.1 Personajes Controlados por el Jugador . . . A.2 Personajes Controlados por la Computadora A.2.1 Personajes aliados . . . . . . . . . . . . . A.2.2 Enemigos Principales . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

83 83 83 83 84

A.2.3 Enemigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˜ DE LAS FSMS DE LOS NPCs B DISENO B.1 Dise˜ no de la FSM del NPC Novia . . . . . . B.2 Dise˜ no de la FSM de los NPCs Enemigos . . B.3 Tablas de las FSMs de los NPCs . . . . . . B.3.1 Tabla de la FSM del NPC Novia . . . . . B.3.2 Tabla de la FSM de los NPCs Enemigos . B.3.3 Diagramas de M´aquinas de Estado . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

´ C IMPLEMENTACION C.1 Proceso de Modelado y Rigg de Personajes . . . . . . . . . C.2 Desarrollo del Juego . . . . . . . . . . . . . . . . . . . . . C.2.1 Organizaci´on del proyecto . . . . . . . . . . . . . . . . . C.3 Programaci´on del Juego . . . . . . . . . . . . . . . . . . . C.3.1 Objetos y Scripts Encargados de las Funciones Generales C.3.2 Scripts de las C´amaras Principales . . . . . . . . . . . . C.3.3 Scripts de los Objetos . . . . . . . . . . . . . . . . . . . C.3.4 Scripts de los Personajes . . . . . . . . . . . . . . . . . . C.4 Organizaci´on de la Escena en Unity . . . . . . . . . . . . . C.5 Implementaci´on de las FSMs de los NPCs . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . .

. . . . . . . . . .

84

. . . . . .

87 87 92 100 100 101 106

. . . . . . . . . .

109 109 111 111 117 118 120 121 121 128 133

LISTA DE TABLAS p´ ag. 2.1 5.1 5.2

Adaptaci´on de la Tabla de estados y transiciones de [5], basada en la FSM de la Figura 2.2 de [52]. . . . . . . . . . . . . . . . . . . . . . . . . . .

30

Tabla de estados y transiciones de la FSM que representa al NPC Novia. . Tabla de estados y transiciones de la FSM que representa al NPC Enemigo en un nivel jer´arquico superior. . . . . . . . . . . . . . . . . . . . . . . Tabla de estados y transiciones de la FSM que pertenece al s´ uper estado No Golpeado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

B.1 Tabla de estados y transiciones de la FSM que representa al NPC Novia. . B.2 Tabla de estados y transiciones de la FSM inicial del NPC Enemigo sin niveles jer´arquicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3 Tabla de estados y transiciones de la FSM que representa al NPC Enemigo en un nivel jerarquico superior . . . . . . . . . . . . . . . . . . . . . . . B.4 Tabla de estados y transiciones de la FSM que pertenece al s´ uper estado No Golpeado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

101

5.3

59 61

103 104 106

LISTA DE FIGURAS p´ ag. 2.1

2.2

2.3

2.4 2.5 4.1 4.2 5.1 5.2

5.3

5.4

5.5 5.6

Imagen del modelo de una IA extra´ıda y traducida del libro “Artificial intelligence for games” de MILLINTONG, IAN, FUNGE, JOHN p´agina 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejemplo de FSM basada en UML sacada y traducida del libro Artificial Intelligence For Games de Ian Millintong P´agina 310. El estado inicial es En Guardia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejemplo de un FSM basada con c´ırculos sacada y traducida del libro Introduction to Game AI de Neil Kirby P´agina 45. El estado inicial es el que est´a encerrado en doble circulo en este caso Ocultarse. . . . . . . . . . Dise˜ nos de FSM de un fantasma del juego PacMan. . . . . . . . . . . . . . Ejemplo modificado de [2], muestra como el desarrollador puede mezclar papeles y clases para crear un enemigo . . . . . . . . . . . . . . . . . .

23

27

28 29 37

Botones que va a usar el jugador durante el juego, su funcionalidad, y la forma en que est´an distribuidos los botones en cada dispositivo de entrada. 48 Boceto del Nivel, como debe ser visualizado por la c´amara. . . . . . . . . . 49 Bocetos de los personajes, basados de acuerdo a su descripci´on f´ısica, y el arte conceptual definido. . . . . . . . . . . . . . . . . . . . . . . . . . . Plan del juego que muestra las acciones que pueden realizar los NPCs. Cada texto en el gr´afico sirve para explicar una parte del juego. Estos textos est´an conectados por flechas que indican la direcci´on de navegaci´on a trav´es del juego. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Boceto en vista de p´ajaro del nivel, que muestra la distribuci´on de los elementos. Al lado izquierdo se observa la referencia visual de los colores o materiales que debe tener el ambiente. . . . . . . . . . . . . . . . . . . Una muestra de un panel del gui´on gr´afico NPC. En la parte superior se encuentra una barra que indica el escenario en el que se encuentra el jugador, debajo de este esta una pantalla donde se muestra de diferentes formas como el jugador libera a la Novia. La parte inferior del panel se encuentra una descripci´on de lo que sucede en la pantalla. . . . . . . . Este diagrama es el encargado de ejecutar la IA de los NPCs, las f´ısicas, y la comunicaci´on del jugador con el personaje principal para que pueda jugar. Diagrama FSM del NPC Novia de la Tabla 5.1. . . . . . . . . . . . . . . .

52

53

54

55 56 59

5.7

6.1 6.2 6.3 6.4 6.5 6.6 6.7

6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16

6.17 6.18 B.1 B.2 B.3 B.4 B.5

Diagrama de estados de los NPC Enemigos. Los estados que est´an por fuera del s´ uper estado llamado No Golpeado representan visualmente a la Tabla 5.2; mientras que los estados que se encuentran dentro de No Golpeado son una representaci´on visual de la Tabla 5.3. . . . . . . . . . Estados de la FSMs del NPC Novia que se implementaron en Unity3D. . . Estados de la FSMs del NPC enemigo que se implementaron en Unity3D. . Los nuevos estados implementados en la segunda versi´on del prototipo. . . Primera versi´on del prototipo sin el acabado gr´afico . . . . . . . . . . . . . Segunda versi´on del prototipo con el acabado gr´afico. . . . . . . . . . . . . Gr´afico de resultados de la edad de la poblaci´on. . . . . . . . . . . . . . . . Pruebas alfa realizadas el d´ıa de ingenier´ıa en multimedia con estudiantes y un docente, quienes probaron el prototipo con las tres formas de control que se especificaron para el juego. . . . . . . . . . . . . . . . . . . . . . Gr´afico de resultados de que tanto tiempo juegan los encuestados. . . . . . Gr´afico de resultados de como se autoclasifica la poblaci´on dentro de las categorias de jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gr´afico de resultados de los juegos que m´as juegan dentro de la poblaci´on. Gr´afico de resultados de las acciones de los NPCs que logro observar la poblaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gr´afico de resultados de los impedimentos que evitaron que el usuario pudiese presenciar todos los comportamientos de los NPCs. . . . . . . . . . Gr´afico de resultados del campo de visualizaci´on de la c´amara. . . . . . . . Gr´afico de resultados con respecto al grado de dificultad del juego. . . . . . Gr´afico de resultados de las personas que experimentaron la meta est´etica del humor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gr´afico de resultados de los usuarios que consideraron que los comportamientos de los NPC enemigos entran en la categor´ıa de un cl´asico Beat ’em up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gr´afico de resultados de los comportamientos que afectaron la experiencia de juego del usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gr´afico de resultados de las combinaciones de control m´as c´omodas seg´ un la poblaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

El jugador puede liberar al NPC Novia con cualquier tipo de golpe. . . . . NPC Novia regresando a la silla, mientras los enemigos caen o mueren. . . NPC Novia observa al jugador, mientras los agentes lo persiguen. . . . . . NPC Novia lanzando el objeto. . . . . . . . . . . . . . . . . . . . . . . . . NPC Novia llorando, mientras los NPCs enemigos evitan que el jugador despierte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.6 NPC Novia secuestrada por un NPC enemigo. . . . . . . . . . . . . . . . . B.7 Los NPCs enemigos entrando al campo de combate. . . . . . . . . . . . . . B.8 NPC Enemigo reubic´andose. . . . . . . . . . . . . . . . . . . . . . . . . . .

62 64 65 66 67 67 68

69 69 70 70 71 72 72 73 73

74 75 75 88 89 89 91 91 92 94 95

B.9 B.10 B.11 B.12

NPCs enemigos atacando al jugador. . . . . . . . . . . . . . . . . . . . NPC enemigo golpeado por el jugador. . . . . . . . . . . . . . . . . . . Diagrama FSM del NPC Novia de la Tabla B.1. . . . . . . . . . . . . . Diagrama FSM de los NPC Enemigos que representan visualmente a Tabla B.3 y Tabla B.4 . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . las . .

C.1 Personaje de prueba con rigg final y los ciclos de animaci´on que van a realizar todos los personajes del prototipo. . . . . . . . . . . . . . . . . . . . . . C.2 Proceso visual que se le realiz´o a cada personaje del prototipo. . . . . . . . C.3 Personaje de prueba con rigg final . . . . . . . . . . . . . . . . . . . . . . . C.4 Carpetas principales que almacenan los recursos de todo el proyecto. . . . C.5 Carpeta encargada de almacenar las escenas del juego. . . . . . . . . . . . C.6 Carpeta encargada de almmacenar los modelos importados desde blender. . C.7 Modelo FBX de prueba del personaje principal. . . . . . . . . . . . . . . . C.8 Modelo FBX de prueba del personaje Novia. . . . . . . . . . . . . . . . . . C.9 Modelo FBX de prueba del personaje Encapuchado. . . . . . . . . . . . . . C.10 Modelo FBX de prueba de la botella. . . . . . . . . . . . . . . . . . . . . . C.11 Modelo FBX del plano exportado desde Blender. . . . . . . . . . . . . . . C.12 Plano que genera Unity por defecto. . . . . . . . . . . . . . . . . . . . . . C.13 Carpeta encargada de almmacenar los sonidos. . . . . . . . . . . . . . . . . C.14 Carpeta encargada de almacenar las texturas del juego. . . . . . . . . . . . C.15 Im´agenes vectorizadas en Inkscape que hacen parte del HUD. . . . . . . . C.16 Material empleado para el portarretrato del personaje principal. . . . . . . C.17 Material empleado para las barras de vitalidad de los personajes. . . . . . C.18 Prefabricado de la botella con el script enlazado que le corresponde. . . . . C.19 Prefabricado del enemigo con los scripts enlazados que le corresponde. . . . C.20 Carpeta encargada de almacenar los scripts del juego. . . . . . . . . . . . . C.21 GameObject encargado de contener el script Juego. . . . . . . . . . . . . . C.22 GameObject encargado de contener el script que crea los enemigos. . . . . C.23 C´amara principal de la escena PrimerNivel. . . . . . . . . . . . . . . . . . C.24 C´amara principal de la escena Perdiste. . . . . . . . . . . . . . . . . . . . . C.25 Carpeta encargada de almacenar los scripts de los personajes del juego. . . C.26 Muestra de el personaje principal con su tag (etiqueta) llamado “Jugador” C.27 Personaje tiene asignado el CharacterController apenas se ejecuta el script Personaje Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.28 Personaje tiene asignado el BoxCollider apenas se ejecuta el script Personaje Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.29 Personaje tiene asignado el AudioSource apenas se ejecuta el script Sonidos Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.30 Personaje Jugador tiene asignado un BoxCollider con la etiqueta Collider Jugador en la parte con la que ejecuta el ataque en este caso en la mano derecha. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97 99 107 108 109 110 111 112 112 113 113 113 113 114 114 115 115 115 116 116 116 116 117 118 118 119 120 120 121 122 122 123 124

125

C.31 Personaje Jugador tiene asignado un BoxCollider con la etiqueta Collider Jugador en la parte con la que ejecuta el ataque en este caso en el pie izquierdo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.32 Personaje Enemigo tiene asignado un BoxCollider con la etiqueta Collider Enemigo en la parte con la que ejecuta el ataque en este caso en la mano izquierda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.33 Scripts enlazados al personaje que maneja el jugador. . . . . . . . . . . . . C.34 Scripts enlazados al personaje enemigo que maneja la computadora . . . . C.35 Scripts enlazados al personaje novia que maneja la computadora. . . . . . C.36 Distribuci´on de elementos en la escena llamada PrimerNivel desde una vista de p´ajaro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.37 Objetos que hacen parte del HUD, y son visualizados por otra c´amara. . . C.38 C´amara encargada de visualizar los objetos que est´an en la capa llamada HUD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.39 BoxColliders encargados de indicar cuando la c´amara debe moverse. . . . . C.40 BoxColliders encargados de indicar el l´ımite hasta donde puede desplazarse el generador de enemigos. . . . . . . . . . . . . . . . . . . . . . . . . . C.41 BoxColliders encargados de evitar que los personajes se salgan del escenario, excepto a los NPC que secuestran a la novia. . . . . . . . . . . . . . . . C.42 BoxCollider encargados de indicar cuando los personajes est´an dentro del campo de combate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.43 BoxCollider encargados de indicar donde deben aparecer los personajes en caso de que atraviesen el escenario si llegan a fallar las colisiones con los l´ımites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.44 BoxColliders encargados de enviar a los personajes al punto de aparici´on en caso de que traspasen el escenario. . . . . . . . . . . . . . . . . . . . . . C.45 Ejemplo de la estructura de c´odigo de las FSMs de los NPCs del prototipo del juego. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

125

126 126 127 128 129 129 130 130 131 131 132

132 133 133

´ 1. INTRODUCCION Este proyecto de grado se enfoca en la importancia que tiene la Inteligencia Artificial dentro de los videojuegos, pues ella es uno de los elementos que necesita un videojuego para que este sea interactivo y a la vez entretenido. Gracias a los avances tecnol´ogicos en los motores de renderizado, f´ısicas, din´amicas, e iluminaci´on; la mayor´ıa de los juegos electr´onicos han alcanzado un nivel visual asombroso, donde algunos se aproximan al hiperrealismo [45]. Es por esta raz´on, que se prev´e que poco a poco los videojuegos no van a competir por su calidad visual, sino por la experiencia de juego que ofrezcan. Es aqu´ı cuando los desarrolladores reconocen la necesidad de hacer narrativas y dise˜ nos que den origen a juegos atractivos [50]. Lo anterior en t´erminos de desarrollo se soporta con Inteligencia Artificial que se implemente de tal manera que haga que la m´aquina de respuestas de juego a las acciones del jugador cada vez m´as interesantes, desafiantes, en resumen, divertidas. Parte de esto se da en el dise˜ no de agentes inteligentes que tomen diferentes papeles dentro del juego, estos agentes son denominados Personajes No Jugables (conocidos como NPCs, acr´onimo debido a sus posibles nombres en ingl´es: Non-Player Characters, Non-Person Characters o Non Playable Characters [60]) [45]. Se espera que estos NPCs sean agentes con un nivel de Inteligencia Artificial cada vez mayor por no decir casi humano, pues la industria de los videojuegos es altamente competitiva, donde el componente esencial de esta competencia es la tecnolog´ıa. As´ı es como la Inteligencia Artificial es a menudo mencionada como la pr´oxima tecnolog´ıa que mejorar´ıa y determinar´ıa la calidad de los videojuegos [50].

1.1

Planteamiento

Teniendo en cuenta la importancia de la Inteligencia Artificial dentro de los videojuegos, con este proyecto se pretende realizar el prototipo de un Personaje No Jugable (NPC) para un juego de acci´on del g´enero de lucha progresiva o de desplazamiento lateral (conocidos popularmente como Beat ’em up), mediante el uso de M´aquinas de Estados Finitos, considerada como una de las t´ecnicas de Inteligencia Artificial para videojuegos, y que a su vez tambi´en es considerada una herramienta efectiva de an´alisis de Inteligencia Artificial (IA) para videojuegos. Pues dicha t´ecnica consiste en la descomposici´on del comportamiento del agente en fragmentos que sean f´acilmente manejables o en “estados” que trabajan en conjunto mediante las transiciones que existen entre ellos, responsables de que exista el cambio entre un estado a otro [5].

1.2

Objetivo General

El objetivo principal de este proyecto es desarrollar un prototipo de un Personaje No Jugable (NPC), para un juego de lucha progresiva o de desplazamiento lateral (Beat ’em up), que posea una IA que le permita interactuar y desempe˜ narse adecuadamente en un campo establecido mediante el uso de una M´aquina de Estado Finito (FSM, abreviaci´on en ingl´es de Finite State Machine)

1.2.1

Objetivos Especificos

• Definir los requisitos de un prototipo de juego de lucha de desplazamiento lateral para definir las acciones del NPC. • Dise˜ nar y construir un prototipo de juego de lucha progresiva en donde se observar´a el funcionamiento de la FSM. • Dise˜ nar las acciones que va a realizar el NPC, para luego implementarlas en la FSM. • Implementar el NPC en el juego de lucha progresiva, para poner a prueba el funcionamiento de la FSM.

1.3

Organizaci´ on del Documento

Este informe final est´a organizado en cinco partes que explican el proyecto y temas relacionados con este. La primera parte del documento se presentan con detalle los marcos de referencia, o conceptos base para la inteligencia artificial del juego y el g´enero. La segunda parte se explica unas observaciones m´as detalladas que se realizaron al g´enero. La tercera parte muestra como se defini´o conceptualmente el juego. La cuarta parte se explica las etapas de dise˜ no, la quinta parte consiste en resultados y las pruebas del proyecto; finalmente se presentan las conclusiones de todo el proceso para la realizaci´on del proyecto.

18

2. MARCO DE REFERENCIA 2.1

Inteligencia Artificial (IA)

Seg´ un Russel y Norving [58] a lo largo de la historia del desarrollo de la Inteligencia Artificial (IA) se pueden identificar diferentes categor´ıas de definici´on de la misma. Estas definiciones pueden agrupar en cuatro enfoques de desarrollo de sistemas de inteligencia artificial de acuerdo con lo que buscan emular, estas son: sistemas que piensan como humano; sistemas que piensan racionalmente; sistemas que act´ uan como humanos; y sistemas que act´ uan racionalmente. Por otro lado, algunos expertos de IA encuentran que la inteligencia requiere conciencia, donde las emociones forman parte de la inteligencia. Mientras que otros dicen que es la habilidad para resolver un problema que requiere de inteligencia (Aritm´etica, Clasificar, Buscar, etc.) [52]. Donde la IA debe tener la capacidad de aprender y adaptarse [4]. Pero hay muchas cosas en que las computadoras no son buenas, pero que para nosotros son triviales: reconocimiento de rostros familiares, hablar nuestro lenguaje propio, decidir qu´e hacer a continuaci´on y ser creativos. Esto son el dominio de la IA: tratar de averiguar qu´e tipo de algoritmos que son necesarios para demostrar estas propiedades. Estas m´ ultiples definiciones y reflexiones respecto de lo que es inteligencia artificial, son de corte acad´emico, motivadas por diferentes campos de estudio como la filosof´ıa, la psicolog´ıa, y la ingenier´ıa [5], y dan un panorama amplio de la misma.

2.1.1

Inteligencia Artificial en Videojuegos

Es importante diferenciar la inteligencia artificial acad´emica de la que se tiene en videojuegos. Seg´ un Rouse III [57] la IA en juegos a diferencia de la que es usada en las investigaciones acad´emicas, no consiste en la habilidad del computador para enga˜ nar al jugador, y que este piense que est´a jugando contra otra persona. En lugar de eso, los desarrolladores de videojuegos se refieren al c´odigo encargado de controlar el juego, es el coraz´on y el alma del mismo [55], esto incluye agentes inteligentes que asuman el papel de personajes tales como: enemigos, aliados, y otros personajes con los que puede o no interactuar el jugador en el entorno. Estos agentes se denominan Personajes No Jugables (NPCs) dando la impresi´on de que toman decisiones inteligentes cuando tienen m´ ultiples elecciones que pueden escoger en una situaci´on dada, resultando en comportamientos [59] y acciones que pueden ser observadas por el jugador [48], las cuales pueden ser l´ogicas o al azar; cualquiera que sea el caso, el c´odigo que controla esas reacciones [57], generan una ilusi´on de inteligencia haciendo al juego m´as inmersivo, m´as desafiante, y por lo tanto m´as divertido, con el objetivo de que el jugador se

suspenda de la realidad por un tiempo [4], todo esto es definido como la IA del juego [57]. Los desarrolladores de videojuegos est´an interesados en las aplicaciones de IA desde el punto de vista de la ingenier´ıa para construir algoritmos que sirvan para superar el vasto n´ umero de desaf´ıos t´ecnicos que el dise˜ nador de videojuegos debe balancear como: jugabilidad, aspecto visual, animaci´on, audio [59], y los comportamientos que hagan que un agente act´ ue como un Personaje No Jugable que parezca un humano o un animal. Los algoritmos son extra´ıdos de la investigaci´on acad´emica, donde los investigadores son encargados de esta labor [52]. Se debe tener en cuenta que a diferencia de la IA acad´emica, los programadores de IA en videojuegos deben trabajar con recursos limitados, debido a que la cantidad de ciclos de procesamiento y memoria, var´ıan de plataforma en plataforma. Esto provoca que ´el programador tenga un compromiso que a menudo tiene que ser con la finalidad de obtener un nivel aceptable de rendimiento [5]. Como no se debe generalizar, es necesario determinar [56]: • Que comportamientos son los que realmente necesita la IA del juego, y en qu´e circunstancias se debe producir [56]. • Las mec´anicas del juego que har´an feliz al jugador, y como la IA puede apoyarlas [56]. • Que se espera de la IA, y a su vez seleccionar la herramienta que realmente necesita [56]. Para exprimir todo el potencial de la IA de un juego, debe ocurrir una simbiosis con el dise˜ no del videojuego. Para que esto ocurra, ´el dise˜ nador de videojuegos debe pensar m´as all´a en dise˜ nar una narrativa y una jugabilidad lineal [56]. Para ello ´el dise˜ nador debe planificar el comportamiento de los personajes, pensando en c´omo se deben comportar, y como deben reaccionar [57]. Muchos programadores creen que la creaci´on de la IA es un problema t´ecnico que puede ser resuelto con habilidades de programaci´on, pero es m´as que eso [59]. La parte dif´ıcil para crear la IA de un juego se encuentra en el dise˜ no del comportamiento de los enemigos que proporcionar´a un desaf´ıo interesante para el jugador [57]. Esto no es sobre la historia, es sobre la jugabilidad [56]. Algunos desarrolladores de juegos modernos clasifican otras a´reas del juego como IA: sistemas para evitar la colisi´on, la interfaz usuario, el sistema de animaciones, y los algoritmos de colisi´on. En pocas palabras el t´ermino IA ser´ıa un apodo de desarrollo del videojuego. En cierto punto, estos elementos a˜ naden algo al mundo de la IA, y si se hacen mal, el juego parecer´a “tonto,” pero ellos no son el sistema primario de IA en el juego [59]. En el caso de las f´ısicas de un juego, si una roca debe o no caer de un acantilado, no es IA. La roca no tiene opciones para elegir, no es libre para tomar una decisi´on ya que siempre alguna fuerza de cierta magnitud la empujara al precipicio 20

[48]. La IA de un juego es la que toma decisiones inteligentes cuando hay m´ ultiples opciones para escoger. Esta IA tiene una relaci´on estrecha con lo que es definido como un personaje basado en comportamientos inteligentes [59]. Las t´ecnicas de IA en videojuegos est´an clasificadas de dos maneras: determinista y no determinista [4]. • Determinista: Son el pan y la mantequilla de la IA en los videojuegos [4]. Son t´ecnicas o comportamientos predecibles [60], f´aciles y r´apidos de entender, probar, implementar, y depurar. Su desventaja es que no facilitan el aprendizaje o la evoluci´on del NPC, haciendo que el juego tenga m´as probabilidades de volverse predecible despu´es de jugar un poco, por lo tanto, no habr´a mucha rejugabilidad [4]. • No Determinista: Son comportamientos impredecibles, por lo tanto, los desarrolladores son cuidadosos a la hora de usarlos, ya que estos otorgan largos periodos de desarrollo dependiendo del m´etodo que se emplee: red neuronal, t´ecnica bayesiana, o algoritmo gen´etico. Un ejemplo de esta clase de comportamiento seria: un NPC aprendiendo a adaptarse a las t´acticas de pelea de un jugador. La ventaja de este tipo de IA es que facilita el aprendizaje o evoluci´on, permitiendo que exista rejugabildad [4].

2.1.2

Metas de la IA de un Juego

Cada jugador posee expectativas diferentes de lo que le puede encontrar en la variedad de juegos que existen, esto hace que el juego posea sus propias expectativas de lo que debe hacer la IA para atraer al jugador, de todas formas existe una lista general de objetivos que aplican para cualquier IA, estas metas cambian de importancia de acuerdo con lo que se tiene previsto en el juego [57]: • Desafiar al jugador: La IA debe entretener [5], ya que el juego es un producto de entretenimiento que promueve placer al jugador [48]. Los juegos exitosos hacen su trabajo muy bien: entretienen al jugador [5], ya que le proveen una gran cantidad de retos [57]. Para lograr esto se debe dise˜ nar una IA que ofrezca un buen desaf´ıo (haci´endola superior frente al jugador mediante el uso de la ventaja num´erica, o otorg´andole mucha fuerza) pero que a su vez pierda. Esto permite que el jugador se sienta a´gil, astuto, y poderoso [5], ya que ha superado un obst´aculo aparentemente insuperable, sinti´endose como una estrella de Hollywood [57]. Algunos desarrolladores no est´an de acuerdo con ese “desequilibrio” y quieren hacer una IA m´as humana [57]. Pero aqu´ı realmente lo importante es que la IA ofrezca un desaf´ıo sin importar el m´etodo que se emplee [48], m´as no en hacer el mejor c´odigo, o en crear un agente que no recurra al enga˜ no (darle superioridad al NPC sin emplear t´ecnicas avanzadas de IA), el videojuego no es un banco de pruebas de t´ecnicas de IA [59]. 21

El desaf´ıo debe aplicarse a una amplia audiencia, desde novatos, hasta jugadores expertos. Los primeros desean ganar la mayor parte del tiempo, mientras que los segundos desean tener una batalla casi desesperante hasta cuando ellos cambian el rumbo del combate vi´endose m´as superiores [56]. Para eso la IA del juego necesita manejar diferentes niveles de dificultad, para que el usuario sienta el reto adecuado [59]. La parte dif´ıcil de esto no es hacer que la IA gane o pierda mucho, sino que el NPC oponente se vea cre´ıble [56]. El dise˜ nador de juegos tiene la responsabilidad de concebir cuidadosamente la IA, para asegurarse que aquellos que la implementan tengan un entendimiento de que la IA se crea para desafiar con ´exito y entretener al jugador. El desaf´ıo es la meta principal para la IA en cualquier juego. Sin la creaci´on de un desaf´ıo de alg´ un tipo, el juego pasa a ser una pel´ıcula interactiva [57]. • No hacer cosas tontas: Para evitar este problema, la IA debe tener un dominio solido de lo que puede ser obvio para el jugador (cuando no puede evadir un obst´aculo, o cuando cae directo a un acantilado). Solo una IA tonta es aceptable de acuerdo con el tipo de cosa que represente en el mundo o historia del juego [57]. S´ı el jugador enfrenta a NPCs que representan otra forma de vida (monstruo, extraterrestres, humanoides), un poco de acciones irracionales pueden ayudar a que el oponente se vea mucho m´as realista, cre´ıble, e interesante para combatir [57]. • Ser impredecible: En todo arte el espectador desea que lo sorprendan, es una caracter´ıstica del ser humano ser impredecible (aunque no siempre[56]). El videojuego puede hacer esto mediante su historia, sus niveles, sus personajes, u otros elementos; pero si la IA logra ser esto, el juego adquiere m´as valor en la caracter´ıstica de rejugabilidad [57]. Una de las formas para ser impredecible, es usando el azar [57], pero el juego debe conservar cierto aspecto de ser predecible, para que el jugador pueda figurar estrategias con algo de tiempo y pueda contrarrestar al oponente [56]. La imprevisibilidad de la IA de un NPC no debe entrar en conflicto con las metas de otra IA, seleccionando algo al azar completamente err´oneo, puede arruinar el reto, o en caso de que ayude al jugador puede arruinar la victoria, haciendo que este se suspenda del juego [57]. • Asistir a la Narrativa: En lugar de contar la historia con secuencias animadas, se puede narrar de forma din´amica haciendo que el jugador realice acciones que afecten el a´nimo de los NPCs para as´ı influir y averiguar la historia del juego [57]. • Crear un mundo viviente, y el ambiente de los NPCs: La IA y la forma del escenario son elementos que est´an fuertemente ligados. Los NPCs no pueden actuar en un entorno vac´ıo, es necesario establecer en donde act´ ua y que hace en ese ambiente. 22

Los NPCs no solo son oponentes, ellos pueden representar cualquier forma de vida (p´ajaros, insectos, pueblerinos, etc.) que realice una actividad simple. Esto hace al mundo del juego m´as cre´ıble ya que todos los seres humanos estamos acostumbrados a estar rodeados de organismos vivientes que piensan por s´ı mismos, y se comportan de forma interesante [57].

2.1.3

Modelo Inteligencia Artificial (IA) en Videojuegos

Seg´ un Ian Millintong los juegos modernos poseen un modelo de IA donde la gesti´on de su ejecuci´on est´a dividido en tres secciones como se ve en la Figura 2.1. IA obtiene determinado tiempo de procesador

Interfaz del mundo

IA obtiene esta información

Gestión de Ejecución IA en Grupo

Estrategia

Creación de contenidos

IA Personaje

Scripting

Toma de decisiones Movimiento

Animación

otras tecnologías relacionadas con la IA

Físicas

acciones de la IA en pantalla

Figura 2.1: Imagen del modelo de una IA extra´ıda y traducida del libro “Artificial intelligence for games” de MILLINTONG, IAN, FUNGE, JOHN p´agina 9. • Algoritmos de Movimiento o Locomoci´ on: Representan los aspectos m´as mec´anicos de movimiento del agente [5]. Es cualquier acci´on que pueda realizar un NPC como: atacar al jugador [52], dirigirse al jugador, desplazarse de un punto “A” a un punto “B” [5], trazar su ruta, evadir obst´aculos. Dentro de estos se incluye las animaciones, y las f´ısicas [52]. • Algoritmos de Toma de decisiones: Es elegir su pr´oxima acci´on. Por ejemplo: un requisito para tener un combate cuerpo a cuerpo es estar cerca del oponente [52]. Esta es la parte responsable del comportamiento del agente para elegir sus metas y decidir qu´e plan seguir [5]. • Algoritmos de estrategia: Son m´etodos que usan los personajes en grupo [52]. Aqu´ı se produce el comportamiento que describe donde el agente debe moverse 23

y que tan r´apido lo debe hacer. Algunos de los comportamientos que los NPC pueden realizar individualmente son: buscar, huir, llegar, perseguir, evadir, vagar, evadir obst´aculos, evitar pared, interceptar, esconderse, seguir ruta, contrarrestar persecuci´on. Tambi´en posee algunos comportamientos encargados de dirigir la IA en grupo, estos son: separaci´on, alineamiento y cohesi´on; combinados pueden generar el flocado (en ingl´es Flocking behavior, movimiento sincronizado de las aves en vuelo) [5]. Alrededor de esos tres elementos todo es un conjunto adicional de la infraestructura. No todos los juegos requieren todos los niveles de IA. Los juegos como ajedrez, solo requieren el nivel de estrategia; las fichas de juego no toman decisiones y no necesitan preocuparse sobre su movimiento [52]. Si el juego tiene NPCs, entonces se necesita evaluar si el agente actuara solo o en grupo para a˜ nadir el elemento que necesite para controlarlo. En donde se deber´a explicar lo m´as detalladamente posible la IA de cada uno [53]. La IA genera los comportamientos dando varios resultados orientados, y estos, pueden decir que el mundo del juego se refiere principalmente al campo de la conducta de la ciencia de la IA. Pero solo nos interesa como el sistema es responsable de generar esto. Solo nos concierne en como el sistema act´ ua, no como este piensa. Por lo tanto, son puramente decisiones del comportamiento, tales como atacar un oponente, navegar el terreno, usar elementos del ambiente, y muchos otros pueden ser consideradas mejores decisiones para el sistema de IA del juego [59]. La IA en juegos, no siempre est´a interesado en dar al NPC un nivel intelectual humano [4]. La IA del juego est´a enfocada en las acciones “humanas”, con muy pocas dependencias sobre toda racionalidad [59]. Los NPCs pueden ser cualquier cosa [53], desde criaturas no humanas como dragones, roedores, robots o incluso roedores. Por ese motivo la IA del juego necesita un modelo de alto y bajo desempe˜ no de tareas humanas, en lugar de una rigurosa b´ usqueda hacia la mejor decisi´on todo el tiempo [59]. Es cierto que la IA del juego es a menudo llamada a resolver f´acilmente problemas complejos, se puede emplear la IA en intentar darle al NPC la apariencia de tener diferentes personalidades, o de retratar emociones o varias disposiciones por ejemplo: asustado, agitado, alegre y as´ı sucesivamente. ¿Adem´as, quien ha dicho que siempre se debe hacer un NPC inteligente? Hacer alg´ un NPC tonto a˜ nade variedad y riqueza en el contenido del juego [4]. Esto es para una raz´on de entretenimiento por su puesto [59].

2.1.4

Inteligencia Artificial en Personajes No Jugables (NPC)

NPC (en ingl´es Not Player Character o Non Player Controlled. Ambas sirven para describir que es un NPC, y son b´asicamente lo mismo [60]) son definidos como cualquier cosa en el juego que no sea el jugador humano. Sin embargo, por lo general, el t´ermino se refiere a los personajes con los que el jugador interact´ ua dentro del juego [59]. Es un sistema que act´ ua todo el tiempo situado en cualquier parte del mundo del juego [5], para ello toma informaci´on de los datos del juego, determinando que acciones hacer 24

bas´andose en esa informaci´on, para poderlas llevar a cabo [52]. Son los agentes que poseen un grado de movimiento aut´onomo [5]. Los NPCs existen para enriquecer el juego, ofreciendo una experiencia interesante al jugador, en especial los que son para una sola persona. En el caso de los oponentes, estos deben ser dignos competidores [56], con la habilidad de responder y ajustar sus movimientos de forma acorde [5]. Los NPC se pueden trabajar como agentes manejados por comportamientos. Para ello se deben definir metas de los agentes, estas se pueden comprender como una necesidad que desea satisfacer en ese momento. Estas metas se dividen de forma jer´arquica dividiendo toda l´ogica o el comportamiento general en peque˜ nos fragmentos [5]. La jerarqu´ıa est´a compuesta por: metas a nivel abstracto, metas compuestas, y metas at´omicas [5]. • Metas At´ omicas: Definen una tarea, un comportamiento o acci´on simple, tal como buscar la posici´on o recargar el arma [5]. • Metas Compuestas: Son formadas por varias submetas, que pueden ser a at´omicas o compuestas al mismo tiempo, definiendo una jerarqu´ıa anidada. Describen tareas m´as complejas como construir una f´abrica de armas, o retirarse y cubrirse [5]. • Metas de Nivel Abstracto: Es una necesidad o un deseo que se puede satisfacer a partir de una serie de patrones. Este nivel abstracto est´a compuesto por diferentes acciones de menor nivel jer´arquico [5]. Ejemplo: Metas de Nivel Abstracto → necesidad → ir al cine. Metas Compuestas → tareas complejas → dejar la casa, viajar al cinema, entrar al cine. Metas At´ omicas → tareas simples de la tarea “dejar la casa” → caminar al armario, abrir la puerta del armario, cambiarse la chaqueta, ponerse la chaqueta, caminar a la cocina, ponerse los zapatos, abrir la puerta, caminar afuera [5]. Existen herramientas para implementar la IA de los NPC, se dividen en dos categor´ıas [56]: • Comandos de IA de los NPC: Los comandos son acciones o habilidades que puede realizar un agente en el juego y estos pueden ser aplicados en cualquier g´enero, existe una gran lista de ellos: destruirse, invulnerable, detenerse, congelado, ceguera, insensatez, sordo, duplicar, olvidar, reiniciar, modificar estado, seleccionar objetivo, cambiar velocidad del juego, teletransportar Jugador, teletransportar la IA, perseguir, cambiar los controles del jugador, generar objetos. Para finalizar esta lista es solo un punto de partida, ya que el dise˜ nador puede crear muchos m´as de estos comandos dependiendo de las necesidades de la IA del juego [56]. 25

• Herramientas de diagn´ ostico de IA: Son empleadas para observar el estado interno de la IA y de los elementos que percibe en cualquier momento. Todos estos diagn´osticos aparte de que son simples de implementar, ayudan a ahorrar muchas horas en tiempo de desarrollo, pruebas y depuraci´on. Estas herramientas son: identificaci´on, estad´ısticas, estados, visores de b´ usqueda, visor del movimiento de ruta computarizada, visor de informaci´on t´actica, visor de objetivo actual, visor de dise˜ no especificado de rutas de patrulla, visor de informaci´on del l´ıder, visor de sensor de conocimiento, visor de problemas de comandos de audio y animaci´on, visor de animaci´on actual, visor de comandos del jugador, estructura de datos t´actica y estrat´egica, mostrar arco de fuego considerado, mostrar trazadores [56]. Cada diagnostico se debe realizar de forma independiente, para tener el problema dividido en muchas partes [56]. En los juegos para una sola persona, en el momento en que el NPC es visto como un remplazo de otros jugadores humanos, es necesario examinar que es lo que espera un jugador humano cuando juega con otras personas [56]. Esto no significa que debe tener la capacidad de enfrentarse con cualquier situaci´on que se le plantee (aunque podr´ıa ser uno de sus objetivos) [5], en todo caso existen algunos elementos que pueden ayudar a hacer al agente un remplazo de otro jugador humano [56]: • Apoyo: Se da cuando el jugador debe manejar muchos personajes, para ello necesita la ayuda de la IA para poder enfrentar otra IA. La comunicaci´on del jugador con sus aliados no humanos se realiza mediante comandos activados por alg´ un bot´on [56]. • Sorpresa: Se puede lograr de muchas formas: desinformando un poco al jugador; usando trucos como darle a la IA informaci´on del jugador (posici´on, salud, armas,[4], el momento en que presiona el bot´on, etc.[59]) o darle superioridad en alg´ un aspecto, que le otorgan ventaja [48][56], donde la IA se convierte en un oponente que no toma decisiones sino que simplemente usa los recursos de los que dispone por su cuenta [59]; el uso de comportamientos emergentes (seg´ un George B. Dyson Dyson en su libro Darwing Among the Machines:The Evolutionof Global Intelligence, Perseus Book Group, p9, 1997. Son comportamientos que no se programan directamente, sino que emergen, dando la impresi´on de que son desarrollados por s´ı mismos), una de las alternativas para generarlos es usando el azar; la estupidez artificial, donde el NPC realiza una acci´on que se ve mal para el jugador humano, pero que este trata de imitar, aunque esto es denominado algunas veces como “estupidez cre´ıble” [56].

2.2

Maquinas de Estados Finitos (FSM)

Es la t´ecnica m´as usada en este tipo de toma de decisiones [52]. Una m´aquina de estado finito (FSM, abreviaci´on en ingl´es de Finite State Machine). Es una m´aquina 26

que tiene un n´ umero finito de estados [60] que est´an conectados en una gr´afica por un conjunto de transiciones [56] entre estos estados [48]; la transici´on posee condiciones que al cumplirse le permiten participar [59]. El estado actual determina como la maquina debe comportarse [4]. S´ı el juego determina que la condici´on de una transici´on se cumple, El personaje cambia de estado mediante la transici´on del estado objetivo [52]. Las FSMs ocupan exactamente solo un estado en alg´ un momento del juego [56]. Aunque las FSMs han existido por mucho tiempo, ellas todav´ıa son bastante comunes y u ´tiles en los juegos modernos. El hecho de que ellas sean relativamente f´aciles de entender, implementar, y depurar, contribuyen a su frecuente uso en el desarrollo de juegos [4]. Las acciones son manejadas en estados. Las transiciones dan el mecanismo de cambiar de condiciones. La parte de la inteligencia depende de la calidad del ajuste entre el mundo simulado, los estados seleccionados, y las transiciones. La inteligencia esta en los estados y las transiciones [48].

2.2.1

Dise˜ no y An´ alisis de las FSM

Una de las mejores formas de dise˜ nar una FSM, es presentando los estados y transiciones como un dibujo [48]. Estas pueden ser basadas en UML (Unified Modeling Language, Lenguaje de Modelo Unificado) en un formato de diagrama de estados, es una notaci´on est´andar usada a trav´es de la ingenier´ıa de software. Los estados son representados por cajas con esquinas curvadas. Las transiciones son flechas etiquetadas por la condici´on que las activa. Las condiciones se contienen en corchetes. Y un c´ırculo s´olido que tiene una transici´on sin un condicional que apunta al estado inicial que se introducir´a cuando la m´aquina de estado se ejecuta por primera vez, como en la Figura 2.2 [52].

Figura 2.2: Ejemplo de FSM basada en UML sacada y traducida del libro Artificial Intelligence For Games de Ian Millintong P´agina 310. El estado inicial es En Guardia. La Figura 2.2 muestra una simple FSM con tres estados: En guardia, Pelear, y Escapar. Donde cada estado tiene su propio conjunto de transiciones. El c´ırculo solido de la 27

imagen tiene solo una transici´on sin una condici´on. El punto de transici´on al estado inicial que se introducir´a cuando la m´aquina de estado se ejecuta por primera vez. Tambi´en, los estados pueden ser representados por c´ırculos como en la Figura 2.3 (o cualquier forma geom´etrica como esta en la Figura 2.4), y las transiciones siguen siendo flechas. Otra manera de representar un estado inicial es mediante c´ırculos dobles, en el caso de la Figura 2.3 es el estado Ocultarse. Cada transici´on es una flecha con el texto que muestra que la activa [48].

Figura 2.3: Ejemplo de un FSM basada con c´ırculos sacada y traducida del libro Introduction to Game AI de Neil Kirby P´agina 45. El estado inicial es el que est´a encerrado en doble circulo en este caso Ocultarse. El modelo de inteligencia de la Figura 2.3, las transiciones dependen si el monstruo puede ver al jugador, o el valor de la salud del monstruo. ¿Qu´e tan inteligente es el modelo? Es inteligente, pero no lo suficiente. El monstruo inicia escondi´endose y ataca cuando ve al jugador. Un monstruo poderoso enfrent´o de nuevo a un d´ebil o inexperto jugador, resultando en una victoria r´apida para el monstruo, cuando ´el regresa a esconderse, s´ı se inicia otro combate y tiene una salud baja, este escapa. Si el monstruo no se cura y logra evadir al jugador con ´exito, se logra esconder. ¿Qu´e sucede si el jugador est´a vagando y siendo observado por el monstruo? y el monstruo tiene poca vida. Pues el monstruo ira a atacar al jugador y a su vez se escapa cuando se da cuenta de que tiene poca vida. Como no es perfecta la m´aquina hubiera sido mejor si el monstruo en esta condici´on permaneciera oculto [48]. La forma en que se puede representar el comportamiento de un NPC, en una FSMs puede ser diferente. En la Figura 2.4 se representa la l´ogica de un fantasma del juego Pacman. Donde la gr´afica con m´as estados tiene en cuenta m´as situaciones como: ¿Qu´e debe hacer el NPC del fantasma cuando muere? ¿Qu´e debe hacer el NPC del fantasma cuando nace? Adem´as de ser un m´etodo de programaci´on para implementar la IA, las FSMs son una efectiva herramienta de an´alisis [48]. Ellas presentan una forma simple y l´ogica para controlar el comportamiento de la IA [4]. Antes de usar una FSM, el programador puede preguntarse,“¿Puedo romper la IA en breves estados independientes?” Con el 28

(a) Dise˜ no de David M. Bourg. Estado inicial Vagar. Traducido de [4].

(b) Dise˜ no de Brian Schwab. Estado inicial Nacer. Traducido de [59].

Figura 2.4: Dise˜ nos de FSM de un fantasma del juego PacMan.

29

fin de responder esa pregunta, el programador de IA debe primero solidificar su idea de lo que debe hacer la IA. Es imperativo saber que debe hacer la IA antes de la implementaci´on puede ser selectivo. El acto de determinar si una FSM es apropiada es tarea del programador de la IA, ya que es el primero en definir como va a ser la IA [48]. Las FSMs probablemente tienden a ser implementadas en muchos juegos sin que el desarrollador sea consiente de que realizo un modelo de una FSM [4]. La idea detr´as de una FSM, es descomponer los comportamientos de un objeto en “trozos” o estados f´acilmente manejables [5].

2.2.2

Tabla de Estados y Transiciones

Es un mecanismo para organizar estados y estados afectados por transiciones [5]. Estado Actual Condicional En Guardia Ve un enemigo peque˜ no En Guardia Ve un enemigo grande Pelear Pierde la pelea Escapar Escapa

Estado Transici´ on Pelear Escapar Escapar En Guardia

Tabla 2.1: Adaptaci´on de la Tabla de estados y transiciones de [5], basada en la FSM de la Figura 2.2 de [52].

2.2.3

Debilidades de las FSMs

Con esta t´ecnica el comportamiento de un NPC (sea un monstruo, o una persona) debe dividirse en pocos estados. Esta t´ecnica no es adecuada para simular un personaje complejo que puede estar furioso, con pereza, y aburrido al mismo tiempo [48]. Las transiciones est´an conectadas directamente y deben asumir un contexto determinado; no se pueden usar partes de una FSM para resolver un problema diferente, a menos que se halla dise˜ nado de esa manera [6]. Aunque la dura codificaci´on de las m´aquinas de estado es f´acil de escribir, ellas tienen una dificultad notoria para el mantenimiento. Las m´aquinas de estado en juegos pueden a menudo pueden ser bastante grandes, y esto puede parecer como un c´odigo feo y sucio [52]. Al primer vistazo se ve razonable, pero cuando se empiezan a a˜ nadir m´as estados y condiciones, esta corta estructura empieza a tomar forma de un fideo largu´ısimo, haciendo el flujo del programa dif´ıcil de entender, creando y depurando una pesadilla. Adem´as esto es inflexible y dif´ıcil de extender m´as all´a del alcance del dise˜ no original. A menos que el dise˜ no de la maquina sea implementar un simple comportamiento (o que el programador sea un genio), lo primero que se debe hacer son los ajustes del agente, para hacer frente a circunstancias imprevistas, antes de perfeccionar el comportamiento para obtener el resultado que se tiene pensado conseguir cuando se planea la FSM [5]. 30

Muchos desarrolladores, sin embargo, encuentran que el inconveniente principal es la necesidad de los programadores para escribir los comportamientos de la IA para cada personaje diferente. Esto implica una necesidad para recompilar el juego cada vez que el comportamiento cambia. Mientras el comportamiento puede no ser un problema para el guionista del juego, para los que est´an involucrados en el desarrollo esto puede llegar a ser cr´ıtico en un juego m´as grande, ya que toma muchos minutos u horas para reconstruirlo [52].

2.3

Juegos de Lucha Progresiva (Beat ’em up)

Tambi´en conocidos como Brawlers, son juegos donde uno o varios jugadores deben enfrentarse a un gran n´ umero de oponentes controlados por computadora usando alg´ un estilo de combate cuerpo a cuerpo. En algunos juegos deben recorrer el escenario, mientras que otros es un espacio cerrado donde deben sobrevivir [44][49][59]. Este fue el primer g´enero de juegos de peleas, que floreci´o inicialmente en los Arcade (m´aquinas recreativas) como simples side-scrollers (juegos de desplazamiento lateral o progresivos) [59], es por ese motivo que se caracterizan por tener un control f´acil de aprender; un alto grado de dificultad (ya que en esa ´epoca el objetivo de la m´aquina era hacer perder al jugador muchas veces para que este ingresara moneditas, y ya era decisi´on del usuario si aceptaba el reto de dominar el juego o no); una historia simple, pues estaban m´as enfocados en la jugabilidad logrando una gran variedad en la interacci´on, de vez en cuando mezclando caracter´ısticas de otros g´eneros, por lo general se desarrollaban en ambientes urbanos, aunque algunos lo hac´ıan desde lugares futuristas hasta escenarios fant´asticos-medievales; cada juego trataba de mantenerse simple con el fin de que el juego fuese accesible para un p´ ublico m´as amplio. Con su ´exito en los Arcades paso a encontrarlo tambi´en en las consolas caseras [44].

2.3.1

Tem´ atica e Influencia

La tem´atica de estos juegos es variada. Inicialmente en los a˜ nos ochenta estaban inspirados en pel´ıculas de artes marciales chinas. Luego se enfocaron en ambientes urbanos, involucrando temas de venganza y lucha contra el crimen como en algunas pel´ıculas de la ´epoca. The Warriors de 1979 fue una fuerte influencia en el g´enero. Despu´es cualquier cosa que fuese popular a finales de los ochenta y comienzos de los noventa, pod´ıan servir como base para un Beat ’em up, ya fuese una pel´ıcula, historieta o dibujo animado. Con el paso del tiempo se fueron tomando otros tipos de fuente de inspiraci´on como: escenarios hist´oricos, de ciencia ficci´on, animaci´on japonesa, ambientes de fantas´ıa, juegos de mesa como Calabozos y Dragones, y pel´ıculas de terror. En pocas palabras cualquier cosa puede servir como base para realizar un buen Beat ’em up [44]. 31

2.3.2

Subg´ eneros

Son g´eneros que comparten las ra´ıces de los Beat ’em up, solo que cuentan con ligeras diferencias haciendo que se les llame de otro modo, los m´as sobresalientes son: • Hack and Slash: A veces se usa para denominar algunos juegos de rol donde se usaba el l´apiz y papel, u otros juegos similares a Gauntlet. Sin embargo, en relaci´on con el g´enero Beat ’em up, el Hack and Slash se refiere a cualquier Beat ’em up donde los protagonistas usan armas blancas en lugar del combate cuerpo a cuerpo, un ejemplo claro es el juego Golden Axe [44]. • Clones de los Dynasty Warriors: Debido a que el juego Dynasty Warriors 2, ha sido muy popular por su enfoque en el combate en campos abiertos contra una enorme cantidad de enemigos distribuidos por toda la pantalla, dando la sensaci´on al jugador de destruir ej´ercitos. Muchos juegos han imitado este estilo de Beat ’em up como la serie de juegos Ninety-Nine Nights, Spartan: Total Warrior, Kingdom Under Fire: Crusaders (que incorpora tambi´en estrategia en tiempo real y elementos de juegos de rol), y sobre todo Sengoku considerado una copia descarada de los Dynasty Warriors [44]. • Clones de los Devil May Cry: Los juegos como Ninja Gaiden, Bayonetta, God of War y otros t´ıtulos han adquirido un estilo similar de dise˜ no del juego Devil May Cry, y son a menudo considerados como los mejores juegos de combate orientados en el mercado actual. Los juegos de este estilo son muy diferentes a los Beat ’em ups tradicionales, ya que incorporan muchos elementos de otros g´eneros (acci´on, aventura, rol, acertijos, uno que otro terror y supervivencia), pero la cualidad de los Beat ’em up como: el sistema de combos, y los combates cuerpo a cuerpo contra una gran cantidad de enemigos; hace que sean considerados como Beat ’em ups [44]. • Beat ’em up en Primera Persona: A diferencia de los Beat ’em up que suelen ser en Tercera persona (donde la c´amara visualiza al personaje principal, y todo lo que lo rodea). La perspectiva que estos manejan es siendo los ojos del personaje principal, algo muy com´ un para los juegos de disparos o shooters. Los juegos que han experimentado con esta modalidad son: Breakdown, The Chronicles of Riddkick: Escape from Butcher Bay, y Condemned: Criminal Origins [44].

2.3.3

Caracter´ısticas Principales de los Beat ’em up

Al existir muchos juegos que pertenecen al g´enero de Acci´on que se mezclan entre s´ı (como juegos de disparo de tercera persona, con juegos de pelea), existe una serie de caracter´ısticas que hacen que las personas puedan identificar al g´enero [59]: • Simplicidad: Por lo general tiene que ser un juego simple y directo, haciendo que el jugador se encuentre inmerso en una situaci´on llena de mucha acci´on, 32

oblig´andolo a presionar r´apidamente los botones para que el personaje realice movimientos que eliminan r´apidamente a sus contrincantes [1]. • Control y F´ acil Aprendizaje: Los movimientos que posee el jugador deben ser f´aciles de aprender, incluyendo los movimientos especiales, estos deben responder de acuerdo a la reacci´on del jugador junto con una animaci´on que indique el cambio de acci´on, ayudando al jugador mantenerse atento del instante en que presiona el bot´on, para que pueda realizar combos de forma din´amica [1][53]. • Escenarios: Cada lugar debe contar con el espacio suficiente para que el jugador se pueda mover libremente y pueda enfrentar a sus adversarios c´omodamente. Algunos escenarios pueden contar con obst´aculos o elementos que hagan da˜ no a los luchadores [1]. • Buen Aspecto Visual y Sonoro: Esto es importante ya que debe tener buenos efectos especiales (flash en los impactos, explosiones) que deslumbren al jugador, y los peleadores deben estar detallados para que sean atractivos a los ojos del jugador pues son el centro de atenci´on [1]. • Animaciones: Seg´ un Ed Boon (desarrollador de Mortal Kombat), es el elemento m´as cr´ıtico que puede hacer “sentir” el juego grandioso o espantoso. Cuando el jugador presiona un bot´on de ataque, su personaje necesita comenzar su animaci´on de ataque inmediatamente. El jugador necesita ver a su personaje reproduciendo la animaci´on en el instante que presiono el bot´on. Un retraso de unos cuantos fotogramas pueden hacer la diferencia entre una respuesta durante el combate y hacer sentir lento el juego [1]. • Historia: Ed Boon dice que la historia debe ser contada r´apidamente pues los jugadores le prestaran muy poca atenci´on, es necesario llevarla siempre a la acci´on, para que de esta forma sea m´as emocionante la experiencia que se le pueda ofrecer en dos o tres minutos de juego [1]. • Desventaja num´ erica: Siempre el jugador estar´a en una situaci´on donde tiene que enfrentarse a m´as de dos NPCs, incluso cuando enfrenta a jefe de la etapa, ya que este llamar´a a sus aliados para que lo ayuden [44]. • Armas: A pesar de que el combate cuerpo a cuerpo es el aspecto dominante, algunos juegos ofrecen una gran variedad de armas (ya sea cualquier tipo de arma de fuego, incluyendo tambi´en armas blancas) que pueden ser usadas por el jugador o los NPC [44][49]. • Juego cooperativo o multijugador: Algunos juegos permiten que dos o hasta seis jugadores se colaboren para poder pasar el juego. En algunos casos se pueden da˜ nar entre aliados (ya sea jugador o NPC) [44][49]. 33

• Diferentes tipos de personajes jugables: Los jugadores pueden elegir varios tipos de personajes que posean una caracter´ıstica que lo haga u ´nico, por ejemplo: puede haber un personaje que sea muy fuerte pero muy lento, o tal vez uno r´apido pero d´ebil, o uno totalmente balanceado. Todo con el fin de que el jugador encuentre su estilo de juego [44][1]. • Objetos que recuperan la salud: Usualmente se encuentran en alg´ un obst´aculo rompible (canecas, barriles, estatuas, etc.), por lo general suele ser comida, en otros casos un botiqu´ın, aunque tambi´en depende del contexto en que se maneje la historia del juego, por ejemplo en los medievales son pociones [44][49].

2.3.4

Elementos de la Jugabilidad

Son las formas de interacci´on m´as comunes que puede hacer el jugador dentro de esta clase de juegos: • Variedad Ofensiva: Por lo general el personaje cuenta con ataques de m´ ultiples golpes, ataques mientras saltan, puede lanzar objetos y enemigos cuando los agarra, realizar un movimiento donde ataca 360 grados, como tambi´en realizar golpes traseros [44]. • 4 Formas de movimiento: A diferencia de los juegos cl´asicos 2D de pelea y plataforma, donde se mueven en dos direcciones (derecha, izquierda), en los Beat ’em ups 2D el personaje puede moverse libremente en 4 direcciones (derecha, izquierda, frente, fondo), d´andole al juego una perspectiva semiisom´etrica [44]. • Combos, y Otros Elementos de Juegos de Pelea Uno a Uno: Desde la aparici´on de Street Fighter 2, los Beat ’em ups han tomado elementos del g´enero de peleas uno a uno como los movimientos especiales, bloqueos, contra ataques, en especial el sistema de combos [44]. Estos consisten en secuencias de movimientos que permiten al jugador realizar otras acciones. Por ejemplo: si el jugador presiona izquierda una vez el personaje se mueve a esa direcci´on caminando, pero si presiona izquierda dos veces seguidos puede desplazarse mediante un bote a la izquierda [53]. • Lanzar Enemigos: Es necesario que el jugador pueda lanzar ya sean enemigos u objetos, para poder mantener a distancia a sus oponentes y de esta forma acabar uno por uno lo m´as r´apido posible [44]. • Ataque de 360 Grados que Drenan la Vitalidad del Jugador: Es un elemento muy frecuente en este g´enero. Donde un solo ataque puede da˜ nar simult´aneamente a varios enemigos, restando un poco de vitalidad del jugador [44]. 34

2.3.5

Elementos para un Juego Equilibrado

Estos elementos ayudaran al dise˜ nador o desarrollador del juego a hacer un juego balanceado para cualquier tipo de jugador: • Controlar el apetito del jugador: Es importante que elementos que sirven para recuperar la vitalidad, sean pocos y deben aparecer en el momento menos esperado, estando siempre disponible en el momento que el jugador lo necesite [44]. • Control de masas: Todos los enemigos trataran de rodear al jugador, estos de una u otra forma pueden ser contrarrestados ya sea lanzando un solo enemigo a un conjunto de estos, o mediante un movimiento especial que acabe con todo lo que est´a rodeando al personaje principal [44]. • Atacar a los Jefes con Precauci´ on: En caso de que el juego posea alg´ un jefe de etapa, se deben hacer lo suficientemente fuertes para forzar al jugador a ser precavido, y que emplee alguna t´actica [44]. • Infinidad de Combos son el Mejor Aliado: Cuando ´el jugador est´a aplicando un combo el enemigo suele estar en un estado de par´alisis durante un segundo, lo que permite al jugador eliminar r´apidamente a su contrincante [44]. • El Entorno y las Armas: Hacer un entorno donde el jugador pueda estar en desventaja y al mismo tiempo lo pueda aprovechar, combinando la variedad de armas que se le puede dar, permite que el jugador pueda acabar de diversas maneras al enemigo [44].

2.3.6

Elementos de Inteligencia Artificial

Este g´enero se caracteriza por poseer un gran n´ umero de componentes controlados por la IA. Algunos de los elementos de uso com´ un en este g´enero son: enemigos, sistemas de colisi´on, c´amaras y elementos de acci´on y aventura [59]. 2.3.6.1

Enemigos

Los enemigos de los Beat ’em up por lo general suelen ser sencillos, ya que por lo general tratan de rodear al jugador, estos enemigos cuentan con una cantidad limitada de movimientos simples, como pu˜ nos o patadas [59]. En los juegos de acci´on los enemigos se pueden separar en diferentes grupos, tomando en cuenta su papel dentro del juego, como se pueden clasificar, y su objetivo en el juego [2]: • Rol Dentro del Juego: Dentro de los juegos de acci´on todos los enemigos se pueden dividir sus papeles en cuatro funciones principales: Enfatizados, Ejecutores, Casuales y Desafiantes [2]: 35

– Enfatizados: Son enemigos que pueden ser vencidos de dos formas, la correcta y la incorrecta. Estos dan la libertad al jugador para acabarlos de la manera que mejor le parezca. Si lo hace de la forma correcta recibir´a una recompensa mayor, si lo hace de la incorrecta no ser´a penalizado [2]. – Ejecutores: A diferencia de los anteriores, estos solo pueden ser vencidos con un solo m´etodo, y poseen un papel fundamental que es ense˜ nar al jugador por la fuerza. Son empleados en los tutoriales, o en el momento en que el jugador debe aprender a usar alguna habilidad [2]. – Desafiantes: Son los enemigos dif´ıciles, usualmente son los jefes de cada etapa. Su papel consiste en forzar al jugador para que use todos los recursos que dispone a la mano para poderlo derrotar [2] [59]. – Simple: Son los enemigos m´as sencillos del juego (desde el aspecto visual, hasta la forma de vencerlos), estos pueden ser derrotados de cualquier manera al igual que los enfatizados, la u ´nica diferencia es que cualquier m´etodo es el correcto [2]. • Clasificaci´ on: En los juegos de acci´on, un elenco balanceado de enemigos ayuda a hacer al juego m´as diverso. En ´epocas pasadas la clasificaci´on era simple y concreta como “flaco,”“medio,” y “gordo” [2]. A medida que pasa el tiempo en los Beat ’em ups se puede encontrar una variedad de clases de enemigos, las que m´as resaltan son: – Enemigo Est´ andar: Es el enemigo m´as d´ebil de todos, no posee ninguna habilidad especial, algunas veces suelen tener alguna arma en su poder [49]. – Enemigo R´ apido: Este enemigo da la impresi´on de moverse como boxeador, es bastante r´apido a la hora de lanzar golpes [49]. – Enemigo Gordo: Se caracterizan por hacer embestidas [49]. – Enemigo Musculoso: Suele ser hacer mucho da˜ no, y cubrirse de vez en cuando [49]. – Enemigo Acr´ obata: Se desplaza por el escenario mediante acrobacias, algunos poseen cuchillos o bombas de petr´oleo, otros poseen garras [49]. – Enemigo Artista Marcial: Se caracteriza por dominar alg´ un arte marcial, los m´as predominantes son karatekas y los ninjas [49]. Es importante resaltar que el desarrollador puede clasificar como quiera a los enemigos, y puede realizar combinaciones entre clases y papeles ayudando a hacer el juego m´as variado Figura 2.5 [2]. • Objetivo Dentro del Juego: cada cosa debe servir a un prop´osito dentro del juego. Si no se puede explicar porque el NPC debe existir en menos de dos sentencias, lo m´as seguro es que el jugador no va a disfrutar venci´endolo. Los 36

Figura 2.5: Ejemplo modificado de [2], muestra como el desarrollador puede mezclar papeles y clases para crear un enemigo enemigos deben tener alg´ un m´etodo para enga˜ nar al jugador, ya sea una habilidad o una forma de reaccionar [2]. 2.3.6.2

Sistema de Colisi´ on

Las colisiones nunca deben estar basadas en la f´ısica, si no en datos detallados como la cantidad de golpes que puede sentir de nuevo, la animaci´on que se reproduce por el impacto que va a la mano de un efecto sonoro y uno visual, la cantidad de tiempo que requiere para ejecutar otro movimiento despu´es de haber realizado otro [59]. 2.3.6.3

C´ amara

En los juegos 3D de pelea es un problema poder ubicarla, al igual que en juegos de plataforma 3D. Se debe tener un buen algoritmo de sistema de seguimiento, y a su vez esta debe visualizar en gran parte el escenario de combate para que ´el jugador este atento de los enemigos que le rodean, y no se pueda perder la acci´on en ning´ un momento [59].

2.3.7

T´ ecnicas de IA m´ as Usadas para los Beat ’em up

Los juegos de pelea por lo general no son tan complejos en cuanto a c´odigo. Su desarrollo depende mucho del dise˜ no que se realice, haciendo que las t´ecnicas de IA asociadas a ellos sean m´as orientadas para dise˜ nar la implementaci´on. Las m´as comunes son: 37

• M´ aquinas de Estados Finitos de NPCs para Beat ’em up: Usualmente los juegos est´an basados en estados, el NPC al estar en un estado quieto, puede pasar a un estado da˜ nado mediante una colisi´on. Esta t´ecnica ofrece al desarrollador una estructura suficiente para a˜ nadir complejidad sin dolores de cabeza en el mantenimiento. Tambi´en hace que el NPC sea manejado mediante datos de alguna forma, facilitando la observaci´on de cambios de estados durante las pruebas del juego [59]. • Sistema de Manejo de Datos: En los juegos de pelea uno a uno, se emplea una gran variedad de personajes, movimientos, bloqueos, lanzamientos y combos. Para tener un control adecuado en caso de que se maneje un sistema de colisiones complejos (donde cada parte del cuerpo posee un a´rea de colisi´on), se pueden usar tablas de datos detallando la animaci´on que debe reproducir si con alguna de estas a´reas se recibe un impacto, o si est´a bloqueando, o haciendo cualquier cosa. Estas tablas pueden describir la “personalidad” de cada peleador, mediante listas de valores de los movimientos y combos, que tan agresivo esta el jugador, y cualquier cosa sobre el personaje [59]. • Sistema de Scripts: Son muy u ´tiles para las cinem´aticas que ocurren en lugares predefinidos del juego. Sirven para contar una historia o para indicar si el personaje gan´o o perdi´o una pelea, ya que son comportamientos guiados, y trabajan muy bien en lugares predefinidos ayudando a que la experiencia de juego sea m´as emocionante para el jugador. Esta t´ecnica se puede implementar con una FSM en caso de que el juego lo requiera [57][59].

38

3. ESTUDIO DEL COMPORTAMIENTO DE LOS NPCs EN JUEGOS DE LUCHA PROGRESIVA En este cap´ıtulo se presentaran las conclusiones acerca de un estudio realizado para comprender las caracter´ısticas y los comportamientos de los NPC en los juegos de lucha progresiva. Fueron observados varios juegos que fuesen considerados cl´asicos y populares, para poder determinar el comportamiento de los NPCs en este proyecto. Estos juegos fueron: • Renegade (1987) de TAITO para Nintendo. • River City Ransom (1989) de TECHNOS JAPAN CORP para Nintendo. • La franquicia de videojuegos conocida como Final Fight desarrollada por Capcom que comprende: Final Fight 1 (1989, 1994) Super Nintendo; Mighty Final Fight (1993) para Nintendo; Final Fight 2 (1993) para Super Nintendo; y Final Fight 3 (1995) para Super Nintendo. • La franquicia de videojuegos conocida como Street of Rage desarrollada por SEGA para Sega Mega Drive o Sega Genesis, que comprende: Street of Rage 1 (1991); Street of Rage 2 (1992); y Street of Rage 3 (1994). • The Combatribes (1992) de TECHNOS INC para Super Nintendo. • Ghost Chaser (1994) de BANPRESTO para Super Nintendo. • Tokyo Beat Down (2009) de TAMSOFT para Nintendo DS. Las conclusiones acerca de las observaciones que se realizaron en cada uno fueron las siguientes: • Patr´ on de movimiento de los enemigos: Fue necesario observar como los enemigos se mov´ıan por el escenario, y como estos se aproximaban al jugador, para resolver una serie de inquietudes que se presentaron como: – ¿Qu´ e hacen los NPC cuando est´ an alineados al jugador por el eje X?: Se observ´o en algunos juegos los agentes trataban de interceptar al jugador, cambiando su valor en el eje X, en otros casos el agente trataba de igualar la posici´on del jugador.

– ¿Los Agentes emboscan al Jugador?: En algunas situaciones dos enemigos trataban de rodear al jugador, en caso de que se encontrara en una esquina los dos se ubicaban al frente mientras que el resto se quedaban quietos. En otros juegos los agentes siguen su rutina de forma individual, donde tratan de atacar al jugador por el frente, o por la espalda. – ¿Qu´ e hacen que los agentes cuando son arrinconados por el Jugador?: Se observ´o que en los escenarios limitados, los NPC tratan de salir de ah´ı, en otros casos ignoran ese hecho y siguen atacando normalmente. – ¿C´ omo los NPC se aproximan al jugador?: Por lo general se observ´o que trataban de igualar la posici´on del jugador cuando estaba lejos, ya fuera movi´endose por el eje horizontal y luego el vertical o viceversa, o en los dos simult´aneamente. En otros casos se mov´ıan al azar por un momento y luego decid´ıan perseguir. • Patr´ on de combate de los enemigos: Las inquietudes que se plantearon acerca de las acciones que realizan los enemigos para atacar fueron las siguientes: – ¿El ritmo de ataque de los NPC?: El tiempo de ataque de cada NPC es aleatorio, algunas veces pueden atacar continuamente, en otros casos deciden atacar una sola vez y moverse aleatoriamente. En otras situaciones solo decide atacar al jugador cuando esta dentro de su rango de ataque, en otras condiciones toma la decisi´on de ir por un arma para luego atacar sin descanso. La forma de atacar varia del tipo de enemigo. – ¿Los NPC hacen alguna acci´ on cooperativa para poder atacar?: Se observ´o que en algunos juegos los enemigos cuando rodeaban al jugador, uno de ellos ejecutaba un agarre por la espalda mientras que el otro atacaba por el frente. En la mayor´ıa de juegos los agentes atacan de forma individual e incluso ignoran el hecho de que pueden ocasionarle da˜ no a sus aliados. – ¿Los NPC tienen acciones de defensa?: Las acciones de defensa var´ıan de juego en juego, de lo que se logr´o observar, algunos agentes poseen la capacidad de evadir una patada voladora, otros se cubren con los brazos en momentos aleatorios ya sea cuando el jugador este cerca o lejos. Existen casos particulares donde los NPC solo se cubren cuando el personaje se levanta del suelo con un contraataque. – ¿Los NPC realizan acciones a larga distancia?: En la mayor´ıa de Beat ’em ups el jefe final porta un arma de larga distancia, mientras que en otros juegos algunos enemigos suelen usar ataques a´ereos o lanzar objetos, o poseen alg´ un arma de fuego para realizar el ataque. La condici´on para realizarlo puede ser que el jugador se encuentre dentro del rango de mira del NPC, o puede hacerlo aleatoriamente. – ¿C´ omo los NPC entran a la acci´ on o al campo de batalla?: Esto depende mucho de la forma del escenario. Pero por lo general suelen llegar 40

por los “l´ımites” de la etapa, de todas formas en los juegos donde se recorre el escenario, existe la particularidad de que los NPCs pueden estar esperando al jugador y se activan cuando este est´a lo suficientemente cerca de ellos. • ¿C´ omo funciona la c´ amara? y ¿Cu´ al es la Forma de los Escenarios?: Fue necesario realizar esta observaci´on ya que la IA y los escenarios poseen una relaci´on muy estrecha, debido a que ese es el espacio en el que se va a actuar el NPC. Tambi´en se analiz´o el comportamiento de la c´amara pues gracias a ella se va a poder presenciar todos los comportamientos, y es importante que el jugador pueda observar toda la acci´on de forma c´omoda. Se pudo observar que la c´amara funciona dependiendo de la forma del escenario: s´ı el espacio es cerrado, la c´amara seguir´a al jugador por el centro del nivel y dejara de seguirlo cuando se encuentre en los bordes de este. En los escenarios donde se hacen recorridos amplios, la c´amara sigue al jugador y se detiene cuando va a ocurrir un enfrentamiento bloque´andole el paso hasta que derrote a todos los enemigos. • ¿C´ omo es el control en estos juegos?: Ya que se est´a desarrollando un prototipo de un Beat ’em up se debe saber c´omo suelen ser los controles en esta clase de juegos. Lo que se comprob´o, es que el control debe ser extremadamente simple para que el jugador pueda manejar al personaje con facilidad, por lo general se usaban las flechas direccionales para que el personaje principal se desplazara, un bot´on de ataque y otro para saltar, y mediante combinaciones de estos 3 botones se realizaban movimientos especiales. Aunque exist´ıan juegos donde ten´ıan m´as de 3 botones pero que ejecutaban acciones que se pod´ıan realizar mediante combinaciones. • ¿C´ omo es la interfaz gr´ afica de usuario en estos juegos? y ¿Qu´ e clase de informaci´ on es la m´ as importante?: En todos los juegos la informaci´on m´as importante es el estado de salud del jugador que se despliega en un HUD (HeadUp display), informaci´on que se muestra todo momento en la pantalla mientras se juega. En juegos m´as avanzados se visualiza el estado de salud de los enemigos, y dependiendo del reto le colocan al jugador el tiempo que le queda para recorrer el escenario, y el puntaje que lleva acumulado. • ¿Ejecutan alg´ un comportamiento cuando reciben un impacto?: En todos los juegos que se observaron, los agentes a la hora de recibir un golpe que se considerar´ıa leve, se quedaban paralizados por una cierta cantidad de tiempo para que el jugador pudiera ejecutar una combinaci´on de golpes. Los NPCs pod´ıan salir volando a causa de un golpe final del combo o una patada voladora, al estar en el aire ten´ıan la posibilidad de impactar con otros NPC enemigos. • ¿Los NPC ejecutan alguna acci´ on especial dependiendo de su vitalidad?: Solo en algunos juegos los NPC escapaban de la batalla cuando se encontraban d´ebiles, mientras que en otros casos los enemigos eran cobardes por defecto 41

y escapaban sin importar como estuviera su vitalidad. Exist´ıan agentes que antes de morir realizaban un ataque suicida que pod´ıa ocasionar da˜ no. En la carpeta de anexos llamada “JuegosObservados” podr´a encontrar los videos de cada juego en los que se realizaron las observaciones con m´as detalle.

42

´ CONCEPTUAL 4. DEFINICION Este cap´ıtulo contiene todos los elementos que pertenecen a la definici´on conceptual y de los requisitos del prototipo de juego de lucha progresiva, donde se definieron las acciones del NPC, que es el primer objetivo espec´ıfico que se plante´o en el proyecto. Basado en el marco de referencia y el estudio del comportamiento de los NPCs en los juegos de lucha progresiva se hizo una definici´on conceptual donde se mencionaron los aspectos m´as esenciales que conforman el juego, los cuales se explicar´an a continuaci´on.

4.1

Idea Principal

La idea principal del juego consiste en un side-scroller beat ’em up o juego de lucha progresiva llamado “EL DEMOLEDOR Y LOS AMOS DEL COMBATE,” donde el jugador maneja a un experto en el combate cuerpo a cuerpo, que debe enfrentar a varios enemigos simult´aneamente para evitar que secuestren a la novia del protagonista, la cual estar´a en el escenario observando todos los acontecimientos, y ayudando al jugador cuando este se encuentre en peligro, adem´as de ser el soporte vital del protagonista.

4.2 4.2.1

Concepto Titulo y Sinopsis del Juego

• EL DEMOLEDOR Y LOS AMOS DEL COMBATE • El Demoledor es un maestro en los combates cuerpo a cuerpo, este acaba de ganar el campeonato de Los amos del combate frente al temible y poderoso Coloso, obteniendo el trofeo, y una gran cantidad de dinero, el cual usa para construir su propio sitio de entrenamiento junto a su novia. En la noche anterior del d´ıa de inauguraci´on, Coloso decide atacar el lugar, contratando a una organizaci´on criminal conocida como Los encapuchados, para secuestrar a la novia de El Demoledor, arrebatarle el trofeo, y de esa manera poder herir el orgullo del campe´on. El h´eroe debe enfrentarlos en su sitio de entrenamiento para evitar que su enemigo logre lo que se propone. Dentro de la carpeta anexo llamada “Narrativa,” se encuentra un documento que explica con m´as detalle c´omo se formul´o la historia del juego.

4.2.2

Metas Est´ eticas

Las respuestas emocionales o metas est´eticas que se establecieron como soporte principal para poder desarrollar la IA de los NPCs, y todas las caracter´ısticas del juego fueron las siguientes [46]: • Desaf´ıo: Como se mencion´o con anterioridad la IA de todo juego debe ofrecer un desaf´ıo. Para lograr esto se estableci´o que el jugador debe proteger a alguien por un tiempo indefinido. • Nostalgia: El objetivo de esta meta est´etica es reforzar la idea de que las reglas de juego que manipulan la IA de los oponentes, deben ser la de un Beat ’em up, esto combinado con la tem´atica deben hacer que un jugador de los a˜ nos 80-90 vuelva a vivir la acci´on que ofrec´ıan los cl´asicos pertenecientes al g´enero. En caso de que sea un jugador de la nueva generaci´on, esta meta est´etica sirve para introducir este tipo de juego a nuevas generaciones, para que vivan la misma acci´on que experimentaron los jugadores de anta˜ no. • Humor: Se desea a˜ nadir un contenido humor´ıstico, para que el juego sea atractivo para personas de diferentes rangos de edades.

4.2.3

Arte Conceptual

A partir de las metas est´eticas se estableci´o el arte conceptual de la siguiente forma [46]: La apariencia de los escenarios y la vestimenta de los personajes va a ser semejante a la de los a˜ nos 70-80, como en las pel´ıculas de artes marciales, para que el jugador tenga una sensaci´on pr´oxima a la nostalgia de c´omo eran los beat ’em up de anta˜ no. La forma f´ısica de los personajes va a ser completamente desproporcionada, exagerandoles algunas parte del cuerpo d´andoles una apariencia caricaturesca que ayude hacerlos ver graciosos, para que el jugador experimente un poco de humor.

4.2.4

Competencia

La competencia es bastante amplia, y m´as dentro de los juegos que pertenecen al g´enero de acci´on, ya que este se subdivide en varios subg´eneros, donde los m´as sobresalientes, son los juegos de disparo en primera persona, los Beat ’em ups de la nueva generaci´on, que son completamente en 3D y que a su vez est´an siendo mezclados con el g´enero de Rol.

4.2.5

G´ enero

Es un Side Scroller Beat ’em up, o juego de lucha de desplazamiento lateral en tercera persona, para un solo jugador, con gr´aficos 3D y tratando de conservar la forma de juego de los cl´asicos del g´enero en 2.5D. 44

4.2.6

Audiencia

Para un p´ ublico mayor de 12 a˜ nos, de cualquier parte del mundo. Especialmente para aquellos amantes de los juegos de acci´on, y amantes de los Side Scroller Beat ’em up que quieran vivir de nuevo una experiencia que ofrecen los cl´asicos, pero con gr´aficos 3D. Seg´ un el Art´ıculo 9 de la ley No. 1554 del 9 de Julio del 2012, la audiencia que se estableci´o para Colombia es para personas mayores de 18 a˜ nos [7].

4.2.7

Plataforma Objetivo

El prototipo del juego se desarroll´o para los computadores con sistema operativo Windows, es para una sola persona, por lo tanto, no requiere jugar en l´ınea.

4.2.8

Caracter´ısticas Clav´ e

1. A pesar de poseer gr´aficos 3D, conservara el estilo de jugabilidad de los cl´asicos juegos de lucha progresiva 2.5D para los amantes del g´enero. 2. El personaje nunca pierde vidas cuando su barra de vitalidad esta baja. El jugador tiene un n´ umero ilimitado de oportunidades siempre y cuando, logre recuperar la conciencia, y alcance evitar que secuestren a la novia del protagonista. 3. Los objetos que sirven para recuperar la vitalidad, no se encuentran en baldes, ladrillos y cajas, sino que la novia, lanzara estos objetos cuando sienta que su protector est´a a punto de quedar inconsciente.

4.2.9

Reglas de Juego

En esta parte se definen los comportamientos que necesita la IA del juego, y las circunstancias en que se debe producir, para hacer feliz al jugador, y como son apoyadas por la IA [56]: • Al iniciar el juego, el jugador debe estar en la pantalla de men´ u donde tiene tres opciones que consisten en jugar, ver las instrucciones del juego, y salir del juego. • Cuando el jugador da en el comando jugar, la IA, las f´ısicas del juego, empiezan a funcionar. El personaje jugable en ese momento ya puede ser manejado por el jugador. • Todos los personajes interact´ uan dentro del espacio de combate que en este caso es el gimnasio. • Los dos personajes que vera inicialmente el jugador, son El Demoledor y la novia. • La primera acci´on que realiza la Novia es caer al suelo y regresar a la silla. 45

• La primera acci´on que realiza El Demoledor, es estar en la posici´on de reposo, que se ejecuta en cualquier momento cuando el jugador no presiona ning´ un bot´on, o no haya recibido ning´ un golpe de cualquier calibre. • Los enemigos nacen fuera del gimnasio. Al nacer se desplazan hacia a la entrada del campo de combate. El punto que genera los enemigos se mueve al azar dentro del tama˜ no de la entrada. • El jugador puede controlar a El Demoledor mediante tres dispositivos de entrada que son: el control, el teclado, y una combinaci´on de teclado y mouse. • El jugador mientras maneja a El Demoledor, debe enfrentar a varios enemigos de la organizaci´on Los encapuchados con: pu˜ nos y patadas voladoras, para tratar de evitar que capturen a la novia, y tambi´en evitar no quedar inconsciente, para no perder el juego. • Cuando secuestran a la novia (es decir cuando la sacan del escenario), y El Demoledor esta a´ un consiente. El jugador no perder´a el juego, y puede seguir luchando hasta cuando el personaje principal lo noqueen. • El Demoledor queda fuera de combate, cuando su barra de vitalidad este vac´ıa. • Cuando El Demoledor est´a noqueado, y la novia a´ un no ha sido sacada del escenario. El jugador puede despertarlo, llenando una barra presionando varias veces el bot´on con el que se ataca. • El Demoledor puede realizar un ataque diferente siempre y cuando se mantenga golpeando a alg´ un enemigo. • El Demoledor puede realizar una patada voladora cuando est´a saltando. • El n´ umero m´aximo de enemigos que puede enfrentar el jugador, es cuatro. Cuando un enemigo es destruido, el sistema creara otro que remplazara al que fue demolido. • Los enemigos son demolidos, cuando su barra de vitalidad esta vac´ıa. Los oponentes saldr´an volando en direcci´on opuesta del personaje principal, reproduciendo una animaci´on donde caen golpeados, y cuando tocan el suelo desaparecen. • Los Enemigos dan puntos cuando son golpeados y demolidos. • Los peleadores que en este caso son El Demoledor y cualquier enemigo, al recibir un golpe, se reduce su vitalidad y quedan paralizados por un breve momento. El tiempo de par´alisis de cada personaje es variable. • Cuando los peleadores reciben un golpe fuerte, que en este caso es una patada voladora, o la finalizaci´on de un ataque consecutivo de golpes, aparte de recibir una gran cantidad de da˜ no, saldr´a a volar por los aires. 46

• Los enemigos atacan cuando el jugador est´a dentro de su rango de ataque, y cuando golpean a El Demoledor, pueden realizar diferentes tipos de golpes. • Cuando el jugador esta inconsciente, y la novia est´a sentada en la banca llorando, puede ser raptada por alg´ un enemigo. • Los enemigos pueden elegir al azar si raptar a la novia, o evitar que el jugador se levante, cuando este queda inconsciente; aunque por lo general se tomara como prioridad raptar a la novia. • Cuando la novia ya se encuentra en los brazos de alg´ un enemigo, el resto ir´a por el jugador para evitar que recupere la conciencia. • El enemigo que tiene a la novia raptada, si alcanza la entrada saldr´a con ella del escenario y no regresara nunca. En caso de que a´ un se encuentre dentro del escenario y el jugador logre darle un golpe de cualquier calibre, el enemigo soltara a la novia. • La novia cuando no est´a sentada, siempre tratara de regresar a la banca. • La novia llorara al jugador, cuando a´ un no la ha raptado ning´ un enemigo, y el jugador se encuentra inconsciente. • La novia cuando est´a sentada en la banca, y el jugador se encuentra consciente, siempre lo estar´a observando. • Cuando el jugador tiene una vitalidad que se considere como riesgo de salud, la novia lanzara una botella para que recupere la vitalidad, siempre y cuando no halla ninguna otra botella dentro del campo de combate. El valor de riesgo de salud es decidido al azar entre un rango de valores menores a cuarenta o cincuenta, dependiendo de lo que elija el sistema cuando se inicia el juego. • El jugador puede recoger la botella, siempre y cuando se encuentre cerca de ese objeto y presione el bot´on de ataque. • Las botellas que lanza la novia se clasifican de tres maneras: Botella peque˜ na que cura de cinco a diez puntos; botella mediana que cura de veinte a cuarenta puntos; y botella grande que puede curar de cincuenta a cien puntos. Las clasificaciones y los rangos de valores son definidos al azar cuando se crea la botella. • La novia pataleara cuando un enemigo la tiene raptada. • La novia cuando es sacada del escenario no aparecer´a m´as, y el jugador no podr´a recibir m´as botellas ni podr´a despertar en caso de que quede inconsciente. • El jugador debe Demoler a los enemigos en una cantidad ilimitada de tiempo; el juego no tiene final si no hasta cuando el jugador pierde. 47

DispositivosódeóEntrada

Control

TecladoóyóRatón

BotonesóDireccionales:óHacenóqueóelóhéroeóseó desplaceóaólaódirecciónóqueóindiquenólasóflechasM BotónódeóAtaque:óHaceóqueóelóhéroeólanceógolpesM Síóseómantieneópresionadoócargaóunaóbarraóqueóaló llenarlaóyóalósoltaróelóbotónóejecutaóunógolpeópoderosoM BotónódeóSalto:óHaceóqueóelóhéroeósalteM

Control

Esc

W A

S

D

R 6

select

Tecladoó BotónódeóSaltoóyóDireccionales:óHaceóqueóelóhéroeó seódesplaceóaólaódirecciónóqueóindiquenólasó flechasómientrasósaltaM BotónódeóAtaqueóyóSalto:óHaceóqueóelóhéroeó realiceóunaópatadaóvoladoraMóSíópresionaóalgunoó deólosódireccionalesóseódesplazaráM

5 7

Menú 8

start

9

E C

T W

Esc

Menú

Control

Figura 4.1: Botones que va a usar el jugador durante el juego, su funcionalidad, y la forma en que est´an distribuidos los botones en cada dispositivo de entrada. • Cuando el jugador pierde, es llevado a una pantalla que muestra el puntaje que alcanzo. esta tiene un bot´on que lo env´ıa de nuevo al juego principal para que intente de nuevo hacer m´as puntos.

4.2.10

Control

El jugador puede controlar al personaje principal mediante tres dispositivos de entrada diferentes: control, teclado, y una combinaci´on de teclado y rat´on juntos. En cada forma se establecieron tres botones para ejecutar las acciones (direccionales, bot´on de salto, y bot´on de ataque), manteniendo un control simple en las tres formas, algo caracter´ıstico del g´enero (Figura 4.1).

4.2.11

Acciones del Jugador

• Navegar por las pantallas. • Manejar al Personaje principal llamado El Demoledor. • El personaje principal camina cuando el jugador presiona un bot´on direccional (arriba, abajo, izquierda, derecha), y se desplaza a la direcci´on correspondiente. Se detiene cuando el jugador presiona un bot´on de ataque. No puede desplazarse m´as all´a de los l´ımites del escenario. • Saltar, cuando el jugador presiona el bot´on de salto, se puede desplazar por el aire cuando el jugador presiona alg´ un bot´on direccional. • distintas formas de lanzar golpes cuando el jugador presiona el bot´on de ataque continuamente y golpea a un oponente. • Cargar un golpe poderoso que genera una onda expansiva cuando mantiene presionado el bot´on de ataque hasta cuando se llene la barra de poder, cuando se 48

indique que esta al m´aximo y el jugador deja de presionar el bot´on de ataque se ejecuta la acci´on. El personaje no se puede mover cuando este cargando el ataque. • Patada voladora cuando presiona el bot´on de ataque mientras esta en el aire. Si el jugador ha presionado alg´ un bot´on direccional antes de lanzar la patada, el personaje se desplazara hacia la direcci´on que se le abra indicado, pero hasta cuando haya ca´ıdo al suelo no se le puede seguir indicando a donde ir. • Despertar, cuando el personaje principal queda inconsciente el jugador puede reanimarlo cuando llene una barra de poder con el bot´on de ataque. Esa barra de poder aparecer´a siempre y cuando la novia no la hayan sacado del escenario, de lo contrario esta se vaciara y har´a perder al jugador.

4.2.12

C´ amara

La c´amara ser´a en tercera persona, eso quiere decir que mostrar´a al personaje, y casi todo lo que lo rodea. La c´amara tratar´a de mantener centrado al jugador para que este pueda observar con mayor facilidad todo lo que lo rodea. S´ı el jugador se encuentra lejos de los bordes del escenario la c´amara se mover´a para seguirlo. En caso de que se encuentre cerca de los bordes del escenario, la c´amara se mantendr´a fija como muestra Figura 4.2.

Figura 4.2: Boceto del Nivel, como debe ser visualizado por la c´amara.

4.2.13

Mundo del Juego

Son todos los niveles que existen en el juego [53]. Este prototipo posee un solo escenario que es el Gimnasio, el cual es un espacio un poco amplio pero limitado, con una sola entrada donde ingresaran y saldr´an los enemigos. Definido todo lo que uno considera necesario para el juego, se puede pasar a la siguiente etapa para poder construir el prototipo.

49

50

˜ DEL JUEGO Y DISENO ˜ DE LA IA 5. DISENO En este cap´ıtulo se explica el proceso de dise˜ no general del proyecto. El cap´ıtulo se encuentra dividido en dos partes donde se explica el dise˜ no de varios elementos del juego, y la segunda secci´on se habla del dise˜ no de la IA de los NPCs.

5.1

Dise˜ no del Juego

En este cap´ıtulo se explicara c´omo se dise˜ no´ el prototipo de juego de lucha progresiva que corresponde a la primera parte del segundo objetivo del proyecto.

5.1.1

Personajes

Los personajes que participan en este juego son: El Demoledor como personaje principal, que es un joven experto en el combate cuerpo a cuerpo; la Novia como personaje de apoyo, encargada de darle bebidas para refrescarlo, y como fuente de vitalidad y fuerza del h´eroe; los Encapuchados como enemigos que enfrenta el jugador constantemente, tienen un rol simple, ya que son enemigos que el jugador puede derrotar de cualquier forma; y Coloso como villano principal, quien desempe˜ na un papel pasivo dentro del juego (Figura 5.1). Para el dise˜ no de los personajes se hizo una descripci´on f´ısica y psicol´ogica a cada uno a partir de la historia en la que se desenvuelven sin tomar en cuenta el arte conceptual, esto permite que se pueda aplicar diferentes estilos tomando como base las descripciones. Luego de tener descritos los personajes, se realizaron los bocetos de acuerdo con lo que se estableci´o en el arte conceptual, dando como resultado a personajes desproporcionados y casi caricaturescos, para as´ı reforzar la meta est´etica del humor [54]. Para leer la descripci´on de cada personaje, vea el cap´ıtulo anexo llamado “Dise˜ no de Personajes”. En la carpeta anexo llamada “Bocetos” se puede encontrar todos los bocetos que se realizaron para el juego.

5.1.2

Diagramas de Plan del Juego/Game Layout

Estos dise˜ nos son una referencia que explica de forma r´apida como trabaja ciertas partes del juego como: los personajes, los elementos controlados por el jugador, las a´reas o niveles, las pantallas o cualquier informaci´on importante del juego. En este caso se hicieron gr´aficas de los siguientes procesos [54][53]: la forma de navegar por las pantallas, el orden que se ejecutan las acciones dentro del nivel, las acciones que puede ejecutar el personaje principal, la novia y los enemigos (Figura 5.2).

Figura 5.1: Bocetos de los personajes, basados de acuerdo a su descripci´on f´ısica, y el arte conceptual definido. Aparte de mostrar el funcionamiento del juego, tambi´en sirven como un dise˜ no inicial de una FSM y una primera muestra del arte conceptual que se desea ver en el juego [54]. Dentro de la carpeta anexo llamada “PlandelJuego” se puede encontrar los diagramas que se realizaron para el plan del juego.

5.1.3

Dise˜ no del Escenario/Level Layout

Es necesario tener una idea concreta del escenario, debido a que este tiene un v´ınculo muy fuerte con la IA del juego [43], pues dependiendo de la forma que posea el lugar, se debe dise˜ nar una IA que funcione con respecto a este [57]. A partir de la descripci´on, la tem´atica, y las reglas del juego, se hizo una Plantilla del Escenario (Level Layout), que muestra c´omo van a estar distribuidos todos los elementos que se encuentran dentro de este, y la forma del escenario desde una perspectiva de p´ajaro. Luego se escogi´o una foto de referencia para tener una idea visual de las texturas y los colores que estar´an presentes en el lugar (Figura 5.3) [1].

5.1.4

Gui´ on Gr´ afico/Story Board

Debido a que una descripci´on escrita de las reglas y la interacci´on del juego no son suficientes, ya que muchos conceptos o secuencias de un videojuego son dif´ıciles de 52

Figura 5.2: Plan del juego que muestra las acciones que pueden realizar los NPCs. Cada texto en el gr´afico sirve para explicar una parte del juego. Estos textos est´an conectados por flechas que indican la direcci´on de navegaci´on a trav´es del juego. 53

Figura 5.3: Boceto en vista de p´ajaro del nivel, que muestra la distribuci´on de los elementos. Al lado izquierdo se observa la referencia visual de los colores o materiales que debe tener el ambiente. comunicar, o de recordar; fue necesario hacer un gui´on gr´afico (Story Board) que representara de forma visual el funcionamiento de cada parte del juego, haciendo el problema m´as manejable [53][54]. Las a´reas del juego en las que se emplearon storyboard fueron: uno para explicar la navegaci´on del juego, que muestra el funcionamiento y las conexiones de las pantallas; otro que muestra el funcionamiento de la c´amara del juego; otro que muestra con que elementos pueden colisionar los personajes y que sucede cuando tienen contacto; otro para visualizar las acciones que puede realizar el personaje que controla el jugador; y por u ´ltimo el gui´on gr´afico donde se puede observar el funcionamiento de la IA de los NPCs aliados y enemigos (la Figura 5.4, es un panel de ese gui´on gr´afico). En la carpeta de anexo se encuentra otra llamada “StoryBoard”, esta contiene los story board de cada parte del juego que se acaba de mencionar.

5.2

Dise˜ no de la IA

En este cap´ıtulo se explicara c´omo se dise˜ naron las acciones de los NPC, o la IA de estos, lo cual corresponde a la primera parte del tercer objetivo del proyecto.

5.2.1

Diagramas de Flujo/Game Flow

Para facilitar el entendimiento, del proceso interno que se realiza dentro del juego se hizo un diagrama de flujo, donde cada caja de texto al igual que los gr´aficos anteriores, representan o describen acciones, y decisiones, de lo que suceden en el juego. Este u ´nico diagrama se segment´o de la siguiente manera (Figura 5.5): Dentro de la carpeta de anexos llamada “DiagramadeFlujo,” se encuentra un diagrama de flujo m´as grande que muestra todo el proceso interno del juego como: funcionamiento del men´ u, funcionamiento principal del juego, y el de la IA de cada NPC. En esa misma 54

Figura 5.4: Una muestra de un panel del gui´on gr´afico NPC. En la parte superior se encuentra una barra que indica el escenario en el que se encuentra el jugador, debajo de este esta una pantalla donde se muestra de diferentes formas como el jugador libera a la Novia. La parte inferior del panel se encuentra una descripci´on de lo que sucede en la pantalla.

55

Juego

Escena Intro ¿ usuario ingresa una entrada?

NO usuario ingresa

una entrada=falso

Termina la Secuencia Animada

SI

Inicializar el Combate Pausa=falso

NO

¿ pausa=verdadero?

SI

IA Novia Enemigos

NO

Menú de Pausa Continuar Ayuda Salir

Manipular accionesde movimiento deljugador,Colisiones, Físicas,etc.

Mostrar el Juego

NO

¿ Jugador inconciente ?

¿ Novia en el escenario?

SI

SI

Termina el Juego

Figura 5.5: Este diagrama es el encargado de ejecutar la IA de los NPCs, las f´ısicas, y la comunicaci´on del jugador con el personaje principal para que pueda jugar.

56

carpeta se encuentra otra carpeta llamada “GameFlowPorPartes” donde el diagrama de flujo est´a dividido en varias im´agenes.

5.2.2

Dise˜ no de las M´ aquinas de Estado Finito

Para Dise˜ nar las FSMs, fue necesario revisar las actividades que realizan los NPC definidas en las reglas de juego y que a su vez estaban presentadas visualmente en el StoryBoard y los planos del juego de los NPCs. Se usaron metas manejadas por comportamientos donde la l´ogica se divide en: metas abstractas, metas compuestas, y metas at´omicas. Los estados se trabajaron como metas abstractas, ya que representan las necesidades de los NPCs [5]: • Metas de Nivel Abstracto/Estados del NPC Novia – Regresar a la Silla. – Observar al Jugador. – Lanzar Objeto para Recuperar la Vitalidad del Jugador. – Llorar. – Raptada. – Salir del Escenario. • Metas de Nivel Abstracto/Estados del NPC Enemigo – Entrar al Escenario. – Moverse por el Escenario. – Burlarse. – Asombrarse. – Atacar al Jugador. – Raptar a la Novia. – Evitar que el Jugador Despierte. – Golpeado. – Cayendo Golpeado. – Saliendo del Escenario. – Sale del Escenario. A cada estado se le hizo una descripci´on detallada indicando que condici´on lo activa, con que estados est´a conectado, y la actividad que debe realizar el NPC mientras esta en ese estado. El plan de acciones que posee cada estado est´a compuesto por tareas simples que son de nivel at´omico; y tareas complejas que son de nivel compuesto que representan 57

patrones conformados por una serie de submetas que pueden ser de niveles at´omicos o compuesto simult´aneamente, y que se desempe˜ nan en un orden determinado [5][60]. Se hizo un listado de las acciones indicando a qu´e nivel pertenecen cada una y el orden en que se ejecutan, para tener mayor facilidad a la hora de hacer la implementaci´on. A medida que se describ´ıan los estados se fueron construyendo las tablas y diagramas de cada FSM de los NPCs del juego. Existen varias formas para representar una FSMs, en este proyecto se us´o el UML [52], ya que fue m´as c´omodo indicar cu´ales eran los estados iniciales y cu´ales eran los estados finales de cada m´aquina, ya que la mejor forma de representar una FSM es mediante un dibujo [48]. La FSM de la Novia qued´o organizada como se puede observar en la Tabla 5.1 y el diagrama de estados se puede observar en la Figura 5.6. Estado Actual Regresar a la Silla Observar al Jugador

Observar al Jugador Lanzar Objeto

Llorar Llorar Raptada Raptada

Condicional Raptada es falso y sentada es verdadero Vitalidad del jugador en riesgo y objeto en escena es falso Vitalidad del jugador menor o igual a cero Objeto en escena es verdadero o vitalidad del jugador mayor a salud en riesgo Vitalidad del jugador mayor a cero Raptada es verdadero y sentada es falso Raptada es falso y sentada es falso En el escenario es falso

Estado Transici´ on Observar al jugador Lanzar Objeto

Llorar Observar al Jugador

Observar al jugador Raptada Regresar a la Silla salir del Escenario

Tabla 5.1: Tabla de estados y transiciones de la FSM que representa al NPC Novia. A diferencia de la FSM de la Novia, la FSM del NPC enemigo se trabaj´o como una FSM jer´arquica, debido a que la mayor´ıa de estados estaban conectados a los estados Golpeado, Cayendo, Morir, y Sale del Escenario. As´ı que fue necesario crear un s´ uper estado llamado No Golpeado que almacenara todos esos estados que establec´ıan conexiones con los estados mencionados anteriormente, de esta manera, se evitaba estar haciendo evaluaciones con cada estado. En cada FSM el estado inicial se indic´o con un c´ırculo blanco con borde rojo. Mientras que el estado final se indica mediante el c´ırculo negro con borde rojo. 58

FSMNovia Inicia Regresar a la Silla

Raptada == Falso y Sentada == Verdadero

Vitalidad del Jugador < salud en riesgo y Objeto en escena == Falso

Observar al Jugador

Lanzar Objeto Objeto en escena == Verdadero o Vitalidad del Jugador > salud en riesgo

Vitalidad del Jugador > 0

Vitalidad del Jugador 0

Vitalidad del Jugador

Get in touch

Social

© Copyright 2013 - 2024 MYDOKUMENT.COM - All rights reserved.