Dead Channel






      "The sky above then port was the color of television, 
       tuned to a dead channel..."
      Neuromancer


23 September, 2007

Modelos de juegos XI: licencias

Escrito a las 18:30 en la categoría: Juegos, Modelos de juego

Hace tres semanas que no escribo, y es que hace tres semanas que me mudé y ando corto de tiempo, tengo que organizarme mejor. El caso es que no puedo asegurar la continuidad de estos artículos, o no por lo menos con la frecuencia y extensión de antes. Pero aun así quería hacer una pequeña reflexión sobre un tema que está siempre en boca de todos en mi nuevo trabajo: las licencias.

Una licencia es una autorización de una empresa o marca concretas para utilizar su material gráfico o sonoro, su marca o sus personajes dentro de un videojuego. En este mundo, como en todo el campo del entretenimiento y la publicidad en general, las licencias son un tema esencial. Si disponemos de una licencia, como por ejemplo Pokemon, Superman, Dragon Ball o Mikey Mouse, o la voz de Bruce Willis o Jim Carrey (o a Al Pacino al completo, como hemos visto recientemente en Scarface), tenemos aseguradas una gran cantidad de ventas y espectación por parte de los fans de estos personajes. Así mismo, siempre se tiende a relacionar la calidad de la licencia con la calidad del juego (”si es de Mario tiene que ser bueno…”) Con lo que el mismo juego, a no ser que sea un juego rompedor o realmente original y llamativo, cosechará muchas más ventas si cuenta con personajes o ambientación ya conocidos por el público. Todos sabemos que la gran mayoría de los juegos derivados de las películas de animación son el mismo plataformas de siempre con nuevos personajes, pero aun así los hacen, porque los niños los piden y el juego sale rentable.

Entonces está claro que una licencia asegura unas ventas, pero ¿Es siempre necesaria? ¿Debemos relajarnos si tenemos una y hacer un juego más flojo? ¿Resuelve la licencia todos los problemas? Vayamos analizando estas preguntas:

No siempre es necesaria una licencia. Es más, si todos los juegos utilizaran una ambientación o unos personajes ya inventados, nunca innovaríamos. Hay licencias y mundos que han surgido de los videojuegos y no al revés. Ejemplo de ello es Tomb Raider, Super Mario, Final Fantasy, Resident Evil, Silent Hill, Doom, etc… Estos juegos marcaron un hito por su excelencia y crearon su propio club de fanáticos. Todos podemos conseguir esto, aunque está claro que es el reto más difícil. Crear un icono, un personaje o un mundo imperecederos es una difícil tarea, ya que nadie tiene la fórmula para conseguirlo.

Entonces, es más fácil con una licencia,si la tenemos ¿podemos respirar tranquilos? No. Muchas veces tenemos que tener cuidado. Hay algunas que pueden ser muy exigentes, o puede que no se adapten a nuestras necesidades o expectativas. Como ya he comentado otras veces, el jugador siempre se crea una imagen de lo que va a jugar, y si hay algo que marque un papel decisivo es la existencia o no de una ambientación conocida. Si nuestro juego se basa en Mortadelo y Filemón, no podremos hacer un drama ni thriller detestivesco serio. Tendremos que hacer comedia. No tiene sentido hacer un juego infantil con los personajes de Trainspotting. Y lo que es más, la licencia exigirá cosas de nuestro juego. La empresa o marca en cuestión exigirá determinadas pautas, mecánicas de juego e incluso un argumento concreto, con lo que estaremos mucho más restringidos artísticamente hablando. Por lo tanto la licencia no es la solución a todos nuestros problemas, ni nos permite hacer cualquier patata y ponerla en el mercado con total impunidad (nadie mayor de 12 años quiere los juegos basados en las pelis de Pixar o de Dreamworks…) Sumado a todo esto tenemos el coste económico que representa.

En otras palabras, una licencia asegura un público a costa de dirigir nuestro juego. Pero, así como en el cine las secuelas y precuelas atestan las carteleras, las licencias copan casi la totalidad del mercado de los videojuegos. ¿Es demasiado arriesgado tratar de innovar? ¿Nos estamos acomodando tras todas esas grandes creaciones de hace una o dos décadas? ¿O simplemente le damos al público lo que demanda?

26 August, 2007

Modelo X: Sistemas conversacionales

Escrito a las 20:14 en la categoría: Juegos, Modelos de juego

Enlazando con uno de los apartados de la anterior entrega, los diálogos, hoy voy a tratar de responder lo mejor que sepa a la primera petición que he recibido sobre la serie “Modelos de juegos”. La sugerencia en cuestión la hizo [Fonet] mediante un privado en el foro de Stratos hace ya más de dos semanas. Le dije que le respondería tras publicar lo que tenía entre manos y, con las vacaciones, ese momento se ha alargado hasta hoy. No me enrollo más y paso a la petición y a la respuesta (a lo CPI :)):

[Fonet] escribió:
Estaria bien desglosar las aventuras graficas levemente (en general, nada de SCUMM) y un poco mas a fondo los sistemas de conversacion (Ya sea por frases a lo Monkey Island o por temas a lo Broken Sword), ya que veo que es el punto complejo de este genero.

Este es un tema que yo mismo me he planteado varias veces ya que las aventuras gráficas (AG) son un género que me encanta. Hace poco, cuando comencé con un amigo a desarrollar una pequeña AG que ahora mismo está parada en el cajón de “Cuando alguien se ponga conmigo”, le metí mano al engine Wintermute y me pareció una solución bastante lógica la que le daba. Primero que todo, si quieres crear una AG y no necesitas crear todo el código para sentirte bien como persona, sino que de verdad te quieres dedicar al argumento, los diálogos, los personajes y demás, debes usar esta herramienta. Wintermute nos provee de un montón de comodidades para crear nuestra aventura e incluso sin saber programar podremos escribir los diálogos y las acciones con un poco de ayuda de los tutoriales que adjunta el programa. Para los que seáis más hardcore y os gustaría programar por completo una aventura o una herramienta conversacional (tal vez para un bot o para otros fines, luego volveré sobre esta parte…) sigamos.

En Wintermute la técnica utilizada es simple y a la vez efectiva: los diálogos funcionan exáctamente de la misma forma que una mákina de estados de las que expliqué la implementación hace varias entregas. Tenemos un switch, un montón de frases con sus identificadores guardadas en memoria, y dependiendo de la entrada del jugador (1, 2, 3, 4, etc al elegir la frase o el icono temático o la imagen de un objeto del inventario…) se ejecuta un case que a su vez dentro tendrá, o bien una serie de impresiones en pantalla con la conversación, o una llamada a una función que gestionará el nuevo sub-diálogo. Además en Wintermute se añade la posibilidad de declarar una variable de estado que indica si esa rama del diálogo ha sido o no elegida con anterioridad, y en caso afirmativo podemos elegir entre permitir o no que se muestre más veces en ese diálogo o en todo el juego. Para muestra un botón:

function dialogoCaracol()
{
  var Responses;
  var selected;
	
  var loop = true;
	
  Game.StartDlgBranch(\"dialogCaracol\");
	
    // Preparamos las respuestas para poder referenciarlas luego fácilmente
    Responses[0] = \"Buenas, soy ornitopato y quiero ser un gran detective\";
    Responses[1] = \"Vengo a resolver EL ASESINATO MISTERIOSO\";
    Responses[2] = \"Disculpe buen tendero, ¿sabe dónde está la pollería de Alcatraz?\";
    Responses[3] = \"Mi Mamá me ha dicho que los caracoles son la representación del mal\";
	Responses[4] = \"¿Qué cosas vendes en la tienda?\";
	Responses[5] = \"Mmmhn... en realidad no quería hablar con usted\";
	
  while(loop){
	
    // fill the response box
    Game.AddResponseOnce(0, Responses[0]);
    Game.AddResponseOnceGame(1, Responses[1]);
    Game.AddResponseOnce(2, Responses[2]);
    Game.AddResponseOnceGame(3, Responses[3]);
    Game.AddResponse(4, Responses[4]);
    Game.AddResponse(5, Responses[5]);
	
    // let the player choose one
    selected = Game.GetResponse();
	
    // let the actor say the selected sentence
    // (that's why I use the array for storing the sentences)
    actor.Talk(Responses[selected]);
	
    //El caracol responde en función de lo que le hayamos dicho
	switch(selected){
	
	case 0: dialDetective();
			break;
	
	case 1: dialAsesinato();
			break;
	
	case 2: dialAlcatraz();
			break;
	
	case 3: this.Talk(\"¿Tú eres un hijo de pata verdad?\");
			actor.Talk(\". . .  \");
			break;
	
	case 4: dialQueVendes();
			break;
	
	case 5: loop = false;
			break;
	}
  }
	
  Game.EndDlgBranch();
}

En ese trozo de código se implementa la primera lista de opciones del primer diálogo de nuestra aventura, como veréis hay “cases” en los que se desarrolla un pequeño diálogo y otros en los que se invoca a una función, que tendrá el mismo esqueleto que esta y que gestionará esa rama de diálogo. De esta forma vamos creando el árbol de diálogo de forma relativamente cómoda. Para saber más sobre diagrámas o máquinas de estado podéis ir al artículo que me referí arriba clickando AQUÍ.

Una cosa a tener en cuenta en esta forma de implementar los diálogos es que el texto que los conforman se encuentra dentro del mismo código. Esto es un inconveniente a la hora de localizar el juego a otros idiomas. Por tanto, si queremos hacer las cosas bien tendremos que cambiarlo. En Wintermute este problema se soluciona con una herramienta que se encarga, a posteriori, de sacar todas las líneas de diálogo del código y crear un fichero independiente. Pero claro, eso es para que el desarrollador no tenga que mancharse las manos. Si queremos hacerlo nosotros, será mucho más fácil preverlo y crear un archivo con todo el texto que queramos localizar y un identificador para cada linea independiente. Esto podemos hacerlo en un archivo texto plano, en un archivo binario o, preferiblemente, en un XML, que nos permitiría escribir las frases en distintos idiomas como atributos de un mismo identificador o tener varios archivos en los que guardar identificadores y frases con su correspondiente predicado de idioma. En cualquier caso, yo no sé mucho de XML y no me voy a meter por ahí, la idea es esa.

Podríamos tener, por ejemplo, un archivo Español.txt en el que guardemos los trozos de texto uno debajo de otro separados por ‘;’ (para poder usar retornos de carro dentro de los textos) y otro llamado English.txt en el que los textos esté guardados en el mismo orden, solo que en este idioma. A la hora de comenzar el juego pediríamos al jugador elegir el lenguaje del juego y cargaríamos un archivo u otro en función de la elección, asignando un identificador ordinal sucesivo a cada texto.

Esto puede resultar pesado a la hora de escribir el código ya que el resultado será un montón de instrucciones con identificadores que apuntan a los distintos textos de nuestro archivo. Y tenemos otro problema. Necesitamos algún sitio donde tener escrito previamente todo el diálogo de forma comprensible, ya que esta forma de referenciarlo no nos permitirá seguirlo con facilidad. Este problema se va a presentar siempre, usemos la técnica que usemos, a no ser que creemos nosotros mismos una herramienta que nos solucione la conversión. Que yo sepa esa herramienta aún no existe, y si alguien la conoce me encantaría que comentara con un link o algo de información ;) Pero podemos hablar de como sería la ayuda ideal a la hora de escribir los diálogos.

Nosotros, como ayuda poco costosa de construir, simplemente nos inventamos un sistema de colores y punteros para poder dintinguir las distintas ramas de diálogo conforme las escribíamos en una hoja de cálculo. Pero la herramienta ideal a la que me refiero sería una aplicación que nos permitiera ir creando el árbol de diálogo fácilmente y luego lo convirtiera ella misma en el código necesario.

canvas de la herramienta ideal

En el dibujo, el diálogo de arriba en un formato más fácil de seguir.

La herramienta debería permitir en cada rama de diálogo, pulsar sobre ella e ir creando nuevos cuadros de diálogo y nuevas hebras con facilidad. Así como identificar a qué personaje consiste cada línea (en el ejemplo todas las frases son del protagonista menos la subrayada que pertenece al caracol maligno), de forma que luego la aplicación tuviera toda la información necesaria para construir el código y los archivos de localización.

No es un trabajo sencillo y sobre todo necesitaríamos definir muy finamente cómo debe ser una salida estandar, es decir, cómo serían los archivos de diálogos de forma que luego pudieran utilizarse desde el juego como si de una librería o una clase se tratara.

Con todas estas fantasías y propuestas le doy fin a este artículo que ya se está alargando demasiado. Creo que he recorrido los principales baches o inconvenientes que nos podemos encontrar a la hora de implementar los diálogos en una aventura, un juego de rol o cualquier otro juego que utilice un sistema conversacional con posibilidad de elección (si el jugador no puede elegir solo tendremos que poner las frases o lanzar los archivos de audio con el tiempo suficiente para que el jugador los lea, uno tras otro y punto.) Haré un pequeño resumen para atar cabos:

* Los diálogos suelen tener que escribirse, al menos, dos veces. Una en la que los creamos sobre papel o un formato electrónico cómodo para nosotros y otra cuando los codificamos. Lo ideal sería escribirlos una vez en una herramienta cómoda que hiciera el trabajo sucio de copiar-pegar al código por nosotros.

* De cara a la localización, el texto debería guardarse en archivos independientes del código que permitan traducir el texto sin tener que tocar los fuentes.

* Tenemos que tener siempre en cuenta y apuntar a qué diálogo dentro del juego pertenece el texto que escribimos, así como a qué rama dentro de esa conversación y a qué personaje de los involucrados. Es importante que todo esté bien apuntado ya que luego a la hora de implementar serán todo identificadores y código.

Escribir los diálogos es, sin duda, la parte más divertida de desarrollar una aventura así que todas estas operaciones no son tan tediosas como puede parecer. Yo me lo pasé muy bien escribiendo los diálogos que tenemos y espero continuarlos pronto (algún día). Pasarlos al código no era tan divertido, pero con Wintermute sí que ves rápidamente el resultado, lo que es muy de agradecer. Los diálogos son una forma divertida (y poco costosa en comparación con otras como las animaciones o los distintos vestuarios) de infundir vida a un personaje de juego, así que ánimo a todos aquellos que hayan pensado meterle mano al tema. Al principio puede parecer confuso, pero ya veréis cómo gana el juego cuando vuestro PJ empiece a soltar frases divertidas, ingeniosas o estúpidas como respuesta a las acciones o a los propios PNJs. ;)

Enlaces relacionados:
Página oficial de Wintermute

21 August, 2007

Modelos IX: Ideando un juego

Escrito a las 16:50 en la categoría: Juegos, Modelos de juego

En la entrega anterior hablé de la historia, los personajes y los ingredientes necesarios para crear un guión atractivo al jugador. Para que eso se convierta en un juego tenemos que pensar ahora en la jugabilidad. En los obstáculos y pruebas (de destreza e inteligencia básicamente) que pondremos al jugador para ir avanzando por nuestra historia.

Dentro de la jugabilidad o gameplay tendremos en cuenta el género elegido (el jugador espera algo del género del juego igual que lo espera de las historias, si vendemos el juego como un shooter no podemos hacer que medio juego se desarrolle sin dar ni un solo tiro). Así, en un juego de rol (RPG- Rol Playing Game), que es en lo que dije que me centraría en esta entrega, hay varias cosas que no debemos olvidar:

- Debe haber combates. Bien a espada, con algún tipo de magia o armas de fuego.
- EL jugador debe estar dotado de algún sistema de recompensa por experiencia de juego que le permita mejorar las habilidades de su personaje.
- Debe haber diálogos (al menos algo).

Estos son los elementos que yo considero mínimos en un RPG. Las formas de implementarlos pueden ser muy variadas y ahora veremos algunas, así como otros componentes que pueden alargar o hacer más interesante nuestro juego.

Combates: suelen ser la forma principal de entretenimiento y consumo de tiempo en un RPG. Por tanto debemos procurar que sean lo suficientemente divertidos y variados para que el jugador no se aburra de estar horas matando monstruos para limpiar una mazmorra (o para atravesar un desierto marciano lleno de espeluznantes alienígenas).

La variedad es la parte más fácil. La conseguimos añadiendo nuevas armas. Las más potentes estarán escondidas en lugares de difícil acceso o disponibles en tiendas a precios en consonancia con su poder. Las demás se las iremos suministrando al jugador conforme avance por el juego. Bien al eliminar a un nuevo enemigo que utilizaba esa arma, como recompensa ofrecida por un PNJ al jugador tras conseguir una misión que se le había encargado o simplemente distribuidas por las zonas por las que debe pasar el jugador para completar el mapa. También podemos añadir nuevos combos o técnicas que el jugador podrá aprender o conseguir gastando puntos de experiencia (luego hablo de eso).

La diversión requiere de nuevo de ese poquito de “chispa” que debemos proveer a toda obra de arte. Para que un combate sea divertido, debe de ser fluido, el jugador debe de saber lo que está haciendo y además debe poder emplear varias técnicas a su antojo y combinarlas o enlazarlas. De esta forma las distintas combinaciones harán el combate menos repetitivo. Parece una tarea fácil, pero ajustar la velocidad, las animaciones, el número de llaves, los controles necesarios, la clasificación de las armas (y por tanto su comportamiento) requiere de muchas horas de juego, testeo, ensayo error, rectificaciones y sobre todo aceptar que muchas cosas estarán mal y tendremos que escuchar opiniones negativas y repetir el ciclo a ser posible varias veces. Como ejemplo, el sistema de combate de Blade (the edge of darkness) me pareció magistral, el más fluido y preciso y controlado que he visto, sin duda una referencia aunque el juego decepcionara en ventas (lo que yo creo que se debe a la austeridad de sus mapas y a la ausencia de una historia más atractiva y más PNJs amigos…)

Como ya dije antes, el combate no tiene que limitarse a combate con armas cuerpo a cuerpo. Podemos introducir armas a distancia, armas de fuego, magia, armas futuristas, poderes psíquicos o lo que se nos ocurra…

Recompensas: Es algo también básico de los juegos de rol. El jugador espera ganar puntos, dinero o bienes por cada combate en el que resulte vencedor, misión conseguida o nivel superado. Los puntos nos servirán para luego canjearlos y mejorar las habilidades del personaje en el manejo de las armas, su agudeza visual o sus opciones de diálogo. El dinero y/o los bienes para canjearlos por otros bienes (armaduras, joyas, armas, un objeto necesario para una misión, comida, etc) Ésta es una mecánica relativamente fácil de introducir y que a algunos jugadores les resulta tan atractiva o más que el combate. En este caso también necesitaremos testeo y algunas pruebas para establecer el coste y la recompensa de cada acción, pero debería resultar más fácil que en el caso anterior a no ser que nuestro juego se base en gran medida en el trueque, el regateo, el comercio a lo largo de los pueblos y cosas así. Como ejemplo en este apartado tenemos en general los MMO y en especial Ultima Online. Este juego siempre ha sido una referencia en juegos de rol y sobre todo en compra-venta entre jugadores y transformación de materias primas en bienes. En WOW se ha alcanzado el punto de que los jugadores pagan dinero real por bienes en el juego. Otro ejemplo de comercio, esta vez en una campaña individual, puede ser Fable. Pero en este caso de un comercio no muy bien ajustado. En este juego podías comerciar entre los pueblos y sacar un dinero con la diferencia de precios, así como comprar las tiendas o el bar (después de hacer desaparecer a su dueño) Pero hacía falta emplear demasiado tiempo y esfuerzo en viajar y aprenderse las mercancías para que realmente mereciera la pena hacerlo a la vez que avanzamos en la aventura. Para sacar provecho a este aspecto del juego había que dedicarse a él casi por entero, lo que no lo hacía muy atractivo a no ser que seamos unos auténticos freaks del comercio.

Diálogos: Son los conductores de la historia. Si un juego tiene muy poco diálogo podemos sospechar que su guión no es muy profundo ni rebuscado (aunque puede que no sea así y utilice las imágenes o pequeñas animaciones para ir guiándonos, pero por este método es mucho más difícil conseguir profundidad). Los diálogos tendrán lugar con PNJs bien amigos o enemigos y deben dar varias opciones que varíen en el tono o la actitud para que el jugador pueda elegir con la que se identifique o con la que identifique a su personaje. Además es interesante ofrecer, cuanto menos, la sensación de que la elección de diálogo condiciona la respuesta y por tanto el futuro de la aventura. En la entrega anterior comentasteis que las varias alternativas en la historia o incluso varios finales son muy interesantes y estoy totalmente de acuerdo. Los diálogos son una forma de conseguirlos. Por supuesto no son la única. También podemos ofrecer varias alternativas de acabar una misión con sus respectivas repercusiones e incluso condicionar la historia por el combate (algo más peligroso y menos habitual, pero que bien hecho puede ser interesante) Por ejemplo, imaginemos una misión que pueda resultar en varias ramas de historia distinta:

En nuestra aventura en Marte, mientras viajabas hacia el oeste en busca de un recambio de batería de energía solar para tu pueblo, te desvías un poco para pasar por un poblado en el que hay un familiar que tal vez te ofrezca alimento para el viaje a buen precio. Al llegar resulta que su hija está muy enferma y necesita atención constante. Tu reconoces la enfermedad y sabes la cura y donde conseguirla, pero también sabes que es cara. Se te presentan varias alternativas que marcarán la actitud de tu personaje y la de algunos PNJs hacia él: puedes pedir a tu tío el comerciante el dinero y comprarla en la botica en la que sabes que está, seguro que tu tío te dará algo a cambio por el porte y por salvarle la vida a tu prima. Pero también podrías pedirle el dinero y luego robar la medicina, ganarías doblemente. O tal vez podrías comprarla con tu dinero y luego cambiársela a tu tío por comida, tal vez le saques así más partido aunque tu tío te odie por regatear con la vida de su hija. A lo mejor planeas robarla pero los guardias te descubren y te meten una paliza de escándalo tras la que, para cuanto te has recuperado, tu prima ha muerto…

Podemos introducir tantas opciones como queramos y cada una podrá traer (o no) sus repercusiones. En general añadir opciones de juego es costoso y no reporta una vida más larga a la campaña, si no que mejora la experiencia de juego y la rejugabilidad. Pero si añadimos varias opciones debemos asegurarnos de que el jugador nota que ese no era el único camino y que la historia podría ser de otra forma y además debemos hacerlo con suficiente frecuencia y con suficientes repercusiones como para que el jugador desee realmente jugar la aventura de nuevo. Varios finales pueden ser una buena opción, pero no la única. De nuevo pondré a Fable como juego del que aprender de los errores. En este juego la única diferencia de ser bueno a ser malo es que la gente te corea o te abuchea, pero no cambia la historia ni las misiones apenas. Solo a veces es más incómodo estar en los pueblos si eres malo y en general ganas menos experiencia, lo que hace el juego más aburrido. Como contra ejemplo pondré a OutCast, un juego mucho menos conocido pero que años antes que Fable ya llevó a cabo de forma muchísimo mejor el mismo comportamiento. En Outcast si atacabas o traicinabas la confianza de los habitantes del mundo en el que te encontrabas inmerso (esclavos de un imperio) la aventura se convertía en una odisea en la cual los esclavos te delataban a los guardias, se negaban a venderte nada o a darte información y desconfiaban de ti. Por otro lado tu misión en teoría no tenía nada que ver, tu ibas a buscar un aparato de tecnología perdido y podías encontrarlo por la fuerza, buscando a tu rollo o preguntando y ayudando a los aldeanos. Pero el hecho de que recordaran tus acciones y te las tuvieran en cuenta te hacía sentirte realmente dentro de un poblado y un mundo vivo y no de un videojuego donde un montón de monigotes te corean al pasar porque tu percentil de bondad es superior a 70.

Cada apartado requiere de tiempo para ser implementado y para ser probado y ajustado, y en general es difícil que nuestro juego destaque en todos ellos. Pero siempre hay que tenerlos en cuenta para cumplir unos mínimos en cada uno de ellos y centrarnos en el que queramos que sea el punto fuerte de nuestro juego. Vosotros ¿qué aspecto preferís en un juego de rol? ¿Creéis que me dejo algún punto importante? ¿Cual es vuestro juego de rol favorito y por qué? Vuestros comentarios siempre son enriquecedores ;)

5 August, 2007

Modelos de juego VIII: Ideando historias

Escrito a las 21:21 en la categoría: Juegos, Modelos de juego

Voy a salirme un poco del código para hablar durante un par de capítulos de la idea y el diseño del juego. Con los pocos algoritmos que hemos visto hasta ahora, y un poco de lógica y variables de control podemos atacar gran cantidad de modelos de juegos sin problemas en cuanto a implementación de la mecánica. Pero escribir un juego no es solo ponerse a picar código. Para que un juego sea más que un simple clon, otro más del montón, hay que trabajar también en las demás áreas. Esto es: el guión, los gráficos, el sonido, los diálogos, la caracterización de personajes… etc. Voy a dedicar un par de articulillos a como afrontar estos problemas, y luego seguiré con los algoritmos. Ahora mismo quiero mascar este área.

Bien, antes de nada, identifiquemos los juegos que necesitarán más parte creativa y en cuales podemos prescindir de muchos pasos:

Si estás empezando y quieres hacer un juego sencillo, en un plazo de tiempo corto, deberías plantearte un juego de puzzles, un arcade o un clon de un juego antiguo sencillo (véase pong, arcanoid, come cocos, space invaders, etc) En estos géneros no necesitas guión ni diálogos, los personajes pueden ser muy sencillos, cuando los hay, y con unos
cuantos sonidos vas servido. Es una buena opción si quieres aprender aspectos de programación y, como ya he dicho, para tener algo en poco tiempo. Incluso así, si eres bueno y tu juego gusta, puedes salir bien parado, siempre pondré el ejemplo del Tetris o del Zuma.

Si ya superaste esa fase, quieres afrontar un desarrollo a largo plazo e incluso puede que tengas un equipo o un par de amigos dispuestos a afrontar el largo desarrollo contigo, puedes plantearte otros géneros. Como la aventura gráfica, el rol, o la estrategia, y otros* Estos géneros, por definición, están cojos si no cuentan con un buen guión, con diálogos, misiones concretas, gran cantidad de niveles y personajes… Por lo tanto, requieren de mucho más trabajo “no código”.

* (de los MMO ya se habla bastante en el foro. Yo lo considero un género para auténticos valientes o para gente con un equipo detrás, ya que hay que tener en cuenta otros muchos aspectos más allá de los que ya he mencionado, como el aspecto multijugador, el tener servidores con capacidad suficiente disponibles, un software bien optimizado al menos en cuanto a comunicaciones, mantenimiento de cuentas de usuario, generar suficiente contenido en los servidores para tener entretenidos a los pjs, controlar las trampas, etc, etc…)

Tomemos por ejemplo, los juegos de rol. En mi opinión son el género más completo, ya que cuentan con diálogos como las aventuras, con personajes que evolucionan y se equipan, historias elaboradas, e incluso, muchas veces, sistemas de combate táctico. Veamos en qué tendríamos que pensar a la hora de desarrollar un juego de rol:

Lo primero que tenemos que pensar es en la historia. Esto incluye la ambientación, los personajes, los motivos de la campaña (objetivos globales, como salvar a la princesa o conseguir el tesoro de Smauhg el dragón o cosas así…) enemigos, etc. Vayamos detallando:

  • La ambientación del juego es algo esencial. Tenemos que decidir qué tipo de juego será, como estamos hablando de grupos con pequeño presupuesto, innovadores y emprendedores, por favor, eludamos el universo AD&D y derivados. Para buscar inspiración nos vale todo: el cine, el teatro, la música, la literatura, la moda. Por ejemplo, mirando la cartelera, podíamos hacer un juego de rol del mundo subterráneo de las ratas, podemos tener alcantarillas, zonas mas campestres, depuradoras, sótanos… en cada zona podemos buscar enemicos (bichos mutantes bajo el polígono industrial, aves rapaces, gatos y zorros en las zonas de campo, competidores como los topos o los urones…) podemos crear sociedades, ciudades, etc. Pero no me gustan las ratas, podíamos hacerlo de ciencia ficción, en la campus alguien habló de marte y la terraformación, ¿Qué tal un juego de rol en un marte en terraformación, donde el oxígeno o las plantas son las monedas de cambio y las distintas ciudades-tribus tienen misiones que cumplir y alienígenas o rebeldes con los que luchar? Y si no nos gusta algo tan innovador y queremos apostar sobre más seguro siempre podemos elegir un estilo medieval pero reformarlo, por ejemplo un juego de rol basado en Aquelarre en lugar de en AD&D o uno basado en la España del Siglo de Oro… Lo importante es ofrecer algo diferente pero que suene familiar y atractivo, ¿y eso cómo se consigue? Vamos al siguiente paso.
  • Una vez escogida la ambientación, lo cual deberemos tener en cuenta siempre para ir elaborando material gráfico y sonoro e ir haciendo los bocetos dentro de este estilo (casas, ciudades, interiores, campo abierto ¿Cómo queremos ambientarlo todo? no será lo mismo el estéril Marte en terraformación que el bello Siglo de Oro…) Pensemos ahora en el guión. Hay unos mínimos que todo guión debe cumplir, a saber:

  • Tiene que haber, al menos, una pareja, y deben pasarlo mal :P Parece una tontería, pero si no hay una dama que rescatar o con la que casarse, una bruja a la que derrotar de la que de repente tu personaje se enamora o cosas así, ya estamos perdiendo puntos. Es inevitable que estas historias centren la atención del jugador y lo hagan querer saber como acaba todo. Así que no lo olvides, al menos una pareja. Pueden ser inocentes a lo mario-princess, evidentes como George Stobbart y la francesita o una búsqueda eterna como la de Manny Calavera, eso ya a tu elección.
  • Debe haber un némesis. Un enemigo absoluto o varios. Puede ser también una organización, una banda o un pueblo, pero siempre habrá un jefe y debemos poder identificar a alguien como el malo al que queremos matar. Si de camino nos saca de nuestras casillas con su maldad suprema (cual caracol) mejor. Hay malos inocentes, como el Dr. Robotnic, pero si son crueles, megalómanos y egocéntricos, como LeChuck, Darth Vader, George Bush Kane (Command and conquer) mejor. A veces algunos juegos le han dado la vuelta a la tortilla, en Overlord o Dungeon Keeper tú eres el malo maloso y el objetivo es destruir todo lo bueno y honorable, pero al final es lo mismo, tener un némesis.
  • Deberías tener, al menos, un gran amigo. Lo de los héroes solitarios está bien a veces, pero un gran amigo simpático y bonachón que te saca las castañas del fuego cuando hace falta (Glotis, Wally, Cuervo, Luigi, etc) tabién ayuda a crear un vínculo con el juego.
  • Debe haber recompensas intermedias, cambios de guión, pero no deben ser demasiado inesperados. El jugador siempre se irá formando una idea de hacia donde va y porqué, si el final es demasiado distinto de lo imaginado se sentirá estafado o defraudado, hay que dar cosas inesperadas dentro de lo razonable y lo lógico. Por ejemplo, en el juego de Marte, si todo son tribus no podemos meter una fase en la que nos tengamos que enfrentar con miles de soldados imperiales de un momento para otro. Si el enemigo es un imperio esos soldados deben estar presente siempre, y si son rebeldes o ladrones, procura que sean más o menos fuertes, pero no que sean millones…
  • Debemos representar distintas actitudes y formas de ser en los personajes, de forma que haya variedad como en la realidad (no vale que todos sean unos tíos cachas super valientes aunque algo toscos con las damas) y que cada jugador pueda sentirse reflejado o identificado con alguno de los personajes de la historia,así como identificar a personas que conozca en otros. Esto es más fácil de lo que parece, simplemente asocia tú también a cada personaje con alguien que hayas conocido o conozcas, exagéralo un poco y haz que ese personaje actúe en consecuencia a la personalidad que le has asignado.
  • Con esos elementos podemos montar el guión, ahora solo necesitamos un poco de arte para que estos personajes cobren vida tanto en los gráficos como en los diálogos y en el sonido. Conseguir un personaje consistente y adecuado a su historia es difícil y lo suyo es que lo escribamos todo, hagamos bocetos, los enseñemos a algunos amigos y comprobemos que todo va encajando en la ambientación. Hablando del guión hemos tratado también el tema de los personajes, veamos que más nos queda. Tenemos un guión, personajes, unos objetivos generales. Nos queda la verdadera historia.

  • Para conseguir sus objetivos y derrotar a los malos el personaje deberá pasar por una serie de aventuras (no vale el caso ese de “- Tienes que subir al castillo, matar al dragón y rescatar a la princesa. - Vale, lo hago, ahora ¿qué?”) Puede que necesitemos viajar a un lugar lejano y para ello conseguir un barco o un avión. Tal vez íbamos a comerciar con un pueblo lejano y por el camino unos vimos que unos bandidos llevaban prisionera a una muchacha preciosa y nos sentimos forzados a seguirlos. Y si mientras los seguimos nos metemos en mitad de un campo de batalla o les perdemos la vista en un pueblo enorme y debemos buscar por él… Mil cosas. Id construyendo una historia. Su longitud dependerá de la vida que queráis que tenga el juego (no podemos tener al jugador 10 horas matando bandidos para alargar la vida del juego, si queremos un juego largo necesitamos una historia larga). Aquí es donde debéis escribir y planificar mucho. Tenemos que especificar cuanto tiempo de juego ocupará cada zona. Debe merecer la pena hacer todos los gráficos y material necesario para cada una (somos un grupo pequeño y no podemos tener al grafista 2 meses graficando el interior de una catedral si luego nuetro personaje llega, habla con el cura y se va…) y debe ser siempre coherente (bueno, hay juegos en los que se les va el pisto como en Tomb raider con los dinosaurios, pero claro, era Tomb Raider…)

Bueno, creo que en cuanto a la historia está bien. La semana que viene hablaré de otras cosas que debemos decidir y que podemos (y debemos, sobre todo por cuestión de tiempo, pero también para no cansarnos y para hacer que enlacen bien todas las partes) hacer a la vez, como las mecánicas de juego, de combate, etc. Para tener al final el esbozo de un futuro juego de rol. Todo lo que he contado en este artículo vale para todo juego con historia elaborada, aunque lo haya hecho pensando en juegos de rol también nos serviría para una aventura, y quizá no tanto para un juego de estrategia, al no ser necesarios tantos personajes, pero sí en cuanto a creación de un ambiente, un guión, un némesis y demás.

Como siempre podéis comentar si creéis que olvido algo o si queréis contad vuestras experiencias al respecto, como creadores, jugadores, lectores, etc.

28 July, 2007

Modelos de juegos: novedades y quejas..

Escrito a las 20:04 en la categoría: Juegos, Modelos de juego

Debido a que sigo en la campus party, colaborando como dinamizador y además tratando de aprovechar el tiempo y durmiendo poco, no tengo la cabeza muy en condiciones ni el tiempo suficiente para un nuevo artículo de modelos de juegos. Pero si que traigo una entrada con varias propuestas y reivindicaciones al respecto :)

Bien, como siempre digo: vayamos por partes. Lo primero que quería hacer es ofrecerme como consultor de videojuegos amateur.

¿Cómooor?

Pues que si alguno queréis que trate un tipo de problema, hable de un modelo o desglose las dificultades de llevar a cabo un juego en concreto, me comentáis o me mandáis un correo (juanmi ‘punto’ malak ‘arroba’ gmail ‘punto’ com) y yo lo traigo en cuanto pueda a Modelos de Juegos.

Existen dos motivos principales por los que hago estos artículos. El primero es obligarme a leer y aprender cositas de videojuegos con regularidad, pensarlas y masticarlas un poco. El segundo es el poco apoyo y distribución de ideas, opiniones constructivas (no en plan “mira google”) y tutoriales (no de engines) que veo en el foro y en el mundillo en general. Acabo de asistir a la mesa redonda de videojuegos (aunque esto no sé si lo publicaré ahora o mañana, son las 19:30 del sábado 28) y he visto lo mismo de siempre: gente que te dice que te partas los cuernos para que ellos vean que vales pero que no ofrecen formación, guías, mínimos, frameworks, ni nada parecido. EJSainz ha hecho una pregunta sobre la importancia de la jugabilidad y los expertos la han esquivado con descaro. También ha habido una pregunta sobre sueldos esquivada y bastante poco interés en las inquietudes y propuestas de los asistentes… Y la idea más o menos con la que sales es:

“Oye macho, si eres un maquina, te curras muchísimas horas por tu cuenta, haces un juego que nos impresione, no te pones exigente con el tema de sueldos (porque al fin y al cabo trabajas en lo que te gusta, es como allí en málaga, que el hecho de tener playa cerca lo cuentan como un plus en el trabajo…) y te mueves un montón… cabe la posibilidad de que alguna empresa se fije en ti”

Señores, el que llegue a ese nivel, tal vez no necesite ninguna empresa que lo contrate…

Bueno, al meollo, que me descentro. El segundo objetivo es ayudar y ofrecer material mascado a todo el que pueda interesarle, así que por eso abro esa puerta de las preguntas. Si queréis aprovecharla me sentiré alagado y estaré encantado de ayudar. Sino, seguiré eligiendo los temas yo y explicando lo que me parezca.

La segunda propuesta que tengo es de colaboración, ya lo he comentado varias veces y me he propuesto a mi mismo no hacerlo más, pero vuelvo a decirlo porque creo que es importante: todo el que pueda y quiera aportar su granito de arena en los comentarios será gratamente recibido. Enlaces de interés, experiencias personales, comentarios de estilo o de fondo, etc. Toda colaboración es bien recibida ya que enriquece y ayuda a mejorar. Soy consciente de que hay mucha gente en el foro de que sabe mucho más que yo y que haría esto mucho mejor que yo. Pese a eso, lo sigo haciendo por los motivos que ya he comentado, pero estaría de lujo tener comentarios de aquellos que hayáis tocado los temas que toque.

No me alargo más, tenéis mi opinión y mis propuestas. Como siempre, la decisión de ser un elemento activo o pasivo recae sobre cada uno en particular.

22 July, 2007

Modelo VII: Diagramas de Estado

Escrito a las 21:36 en la categoría: Juegos, Modelos de juego

Definición: Los diagramas de estados son grafos dirigidos cuyos nodos representan posibles estados de un autómata y cuyos arcos representan la posibilidad de pasar de un estado a otro. La posibilidad de usar esa transición suele venir indicada con una condición sobre la entrada o sobre las variables del autómata. Un diagrama de estado debe tener un estado inicial y al menos un estado de salida.

Jugabilidad:
En resumidas cuentas un diagrama de estados es una representación gráfica para un autómata. Un autómata es un programa que pasa a un estado u otro en función de las variables de entrada y del estado anterior. No tiene que hacer nada, solo cambiar de estado cuando debe. Pero en diseño de videojuegos, podemos aprovechar este comportamiento para que cada estado simule una determinada situación, con lo que podemos emular comportamientos o movimientos o reacciones inteligentes.

Por ejemplo, en el tema de movimiento, si tenemos un juego en el que queremos que un enemigo patrulle una determinada zona, podemos usar un diagrama de estados para hacerlo. Creamos tantos nodos como vertices tenga el polígono que define la ruta a seguir por el patrullero, luego creamos al autómata que cambia de un estado al siguiente si y solo si el patrullero llegó al punto indicado en ese nodo y sino permanece en el nodo y manda al patrullero la orden de avanzar en la dirección del punto.

patrulla

Pero, además de para esto, podemos usar los diagramas de estados para simular comportamientos o reacciones de los enemigos. En el mismo patrullero anterior podríamos definir otro diagrama de estados que indicara el estado de alerta. En condiciones normales el enemigo está en modo descanso, patrulla pero lleva haciéndolo meses y está horriblemente aburrido. Si oye algo o ve algo puede pasar a modo alerta, con lo que estará mucho más pendiente y tal vez se mueva más rápido o se quede quieto oteando. Si ve al jugador pasaría a modo ataque, y emprendería fuego a la vez que alerta a la base.

patrullero

Técnicamente éste diagrama de estado no es correcto al no tener estado de salida, pero en nuestro caso el enemigo patrullaría indefinidamente hasta que cambiáramos de fase o de zona o resultara muerto en combate. Podríamos añadir el nodo “Muerto” al que se podría llegar desde todos los estados al recibir un evento de colisión con una bala, pero para no emborronar más el grafo no lo he puesto, tampoco está en los algoritmos de abajo ya que simplemente tendríamos que eliminar el objeto (estructura o lo que sea) patrullero en ese caso.

Esto mismo puede aplicarse a la base. En condiciones normales hay patrullas y ambiente distendido. Si alguien da la voz de alarma se doblan las patrullas y todos pasan a estado de alerta. Si alguien dispara, los soldados más cercanos acuden al lugar del tiroteo…

No sé si os recuerda a algo, pero éstos podrían ser, muy básicamente, los diagramas que rigen el comportamiento de los alemanes en Commandos I. (En el segundo iban a recoger los paquetes de tabaco y eran más suspicaces :P) No hace falta mucho más para emular reacciones o estados de ánimo. En el Vampire Bloolines, que estoy jugando ahora, en la primera misión tienes que conseguir unos explosivos de un traficante. Si llegas a un “acuerdo” con él no tiene porqué haber derramamiento de sangre. Pero en el momento en el que tratas de entrar por la fuerza, robar algo o dices algo sospechoso, todos se ponen en modo ataque y te fríen a tiros, (por suerte eres un vampiro y las balas poco menos que te resbalan) en algunos casos sin ningún tipo de intersección como “EH! tú ¿qué haces robándonos el radiocasete?” Simplemente comienzan a disparar y el jugador comprende rápidamente que esa acción lo ha delatado…

Dificultades técnicas:
Bien, los diagramas son muy útiles, pero ¿Cómo los programo? Al hablar de grafos dirigidos, puede parecer que es una tarea difícil, pero nada más lejos. Para programar un diagrama de estados solo necesitamos una sentencia de condición switch.

Veamos el ejemplo del comportamiento del patrullero:

int estadoPatrullero1(int entrada){
	
	switch(entrada){
		case 0: //0 => sin rastro de enemigo ni pista a la vista
			if(estadoActual() == ALERTA){
				tiempoAlerta--;
				if(tiempoAlerta == 0) cambiaEstadoPatrullero(CALMA);
			}
			if(estadoActual() == ATAQUE){
				cambiaEstadoPatrullero(BUSQUEDA);
				cambiaEstadoBase(ALERTA);
			}
			break;
	
		case 1: //1 => pista localizada
			if(estadoActual() == CALMA)cambiaEstadoPatrullero(ALERTA);
			if(estadoActual() == ALERTA)cambiaEstadoPatrullero(BUSQUEDA);
			break;
	
		case 2: //2 => enemigo a la vista
			if(estadoActual() == CALMA)cambiaEstadoPatrullero(ATAQUE);
			if(estadoActual() == ALERTA)cambiaEstadoPatrullero(ATAQUE);
			break;
	
	}
}
	
int estadoPatrullero2(int estado){
	
	switch(estado){
		case CALMA:
			if(recibePista()){
				cambiaEstadoPatrullero(ALERTA);
				cambiaEstadoBase(ALERTA);
			}
			if(enemigoALaVista()){
				cambiaEstadoPatrullero(ATAQUE);
				cambiaEstadoBase(ALERTA);
			}
			break;
	
		case ALERTA:
			if(recibePista())cambiaEstadoPatrullero(BUSQUEDA);
			else if(enemigoALaVista()){
				cambiaEstadoPatrullero(ATAQUE);
				cambiaEstadoBase(ALERTA);
			}else{
				tiempoAlerta--;
				if(tiempoAlerta == 0)cambiaEstadoPatrullero(CALMA);
			}
			break;
	
		case ATAQUE:
			if(!enemigoALaVista()){
				cambiaEstadoPatrullero(BUSQUEDA);
				if(!recibePista())cambiaEstadoPatrullero(ALERTA);
			}
			break;
	}
}

He puesto dos posibles algoritmos que implementarían el estado del patrullero y sus avisos a base. En el primero recibimos como entrada de la función el resultado de procesar la información que puede ver el patrullero, en la segunda recibimos el estado actual y el algoritmo llama a las funciones que chequean lo que ve el patrullero. Son ejemplos bastante simples, pero espero que ayuden a hacerse una idea de por donde van los tiros. En el estado de Calma el patrullero ejecutaría el diagrama de patrulla, en el de alerta podría otear y tener un bonus en sus sentidos (ampliar el rango de visión como ocurría en comandos) o simplemente andar más rápido. En el estado de ataque el enemigo dispararía al jugador (que se encuentra a la vista forzosamente) y lo buscaría si intenta escapar. Si el soldado lleva un tiempo X en estado de Alerta y no ha vuelto a ver ninguna pista ni enemigo, vuelve a estado de Calma…

Esta misma utilidad se puede utilizar para juegos de estrategia en la que la computadora, en función de las estadísticas o el modo de juego de sus contrincantes se ponga en estado atacante o defensivo. También son muy utilizados en aventuras gráficas, donde según el estado de la aventura o las acciones que hayamos desempeñado, un mismo personaje nos hablará de unas cosas o de otras.

En definitiva, los diagramas de estado son una herramienta muy potente y muy utilizada en videojuegos. Para tener claro a la hora de implementar lo más cómodo es tener el diagrama dibujado y luego solo tenemos que hacer el switch e ir implementando las funciones que rigen el comportamiento en cada estado.

15 July, 2007

Modelo VI: Pathfinding y aplicaciones

Escrito a las 23:02 en la categoría: Juegos, Modelos de juego

Hoy voy ha hablar un poco del algoritmo A*, utilizado para pathfinding y de posibles aplicaciones de éste y otros algoritmos que resuelvan el mismo problema en los videojuegos.

Definición: los algoritmos de pathfinding o búsqueda de caminos son aquellos que encuentran un camino válido desde un punto A a otro B en un terreno con obstáculos.

Estos obstáculos pueden ser bien infranqueables o simplemente aumentar el coste del camino. Los algoritmos de pathfinding son en realidad algoritmos de búsqueda de caminos en grafos, pero veamos un pequeño boceto de principio a fin:

Lo primero que haremos para poder aplicar el algoritmo es dividir el terreno o escenario en cuadrantes (nodos del grafo) y clasificar cada uno de ellos como obstáculo o terreno libre. Como comentaba antes esta división no tiene por qué ser binaria, podemos asignar a cada cuadrante un entero que indique su coste en ser atravesado (por encima de un máximo arbitrario el cuadro se considerará infranqueable). A la hora de estimar el coste del camino tendremos en cuenta estos enteros y podremos elegir el camino más ventajoso o rápido.

Una vez tenemos los nodos, el algoritmo A* es un algoritmo voraz que va creando un árbol cuyos nodos son los posibles nodos del camino y va escogiendo siempre el que estima mejor. ¿Cómo hacemos ésto? Pues para cada nivel introducimos un nodo nuevo por cada casilla o cuadro alcanzable del terreno, en el primer nivel estos nodos serán todos los adyacentes al cuadro en el que se encuentre el personaje que desea moverse.

Una vez introducidos, evaluamos, con un heurístico optimista, la distancia del camino desde cada uno de estos nodos al nodo meta, lo que nos da un valor de su bondad. Un heurístico de estimación optimista quiere decir que todos los caminos posibles desde ese nodo tendrán un costo igual o mayor al calculado en la función heurística. Además para que podamos llamar a nuestro algoritmo A* esta función debe ser monótona, lo que quiere decir que el coste desde el nodo actual no puede ser mayor que el coste en el nodo actual no puede ser mayor que el coste desde un sucesor del nodo actual más lo que nos cueste alcanzar al sucesor. En nuestro ejemplo se suele utilizar la distancia del punto al destino sin obstáculos. De este modo cumplimos ambas restricciones, somos optimistas (el camino sin obstáculos siempre será más corto que con obstáculos) y monótonos, ya que en el mejor de los casos (si no sorteamos ningún obstáculo) El coste desde un sucesor a la meta más el coste en llegar al sucesor será igual al coste estimado.

Cuando hayamos calculado la bondad de cada nodo podremos escoger el mejor y desechar todos los demás gracias a lo que nuestra heurística cumple las condiciones comentadas.

Desde el nuevo nodo realizaremos la misma operación hasta alcanzar el nodo destino.

El camino encontrado es óptimo y ya solo tendremos que mover el personaje de un nodo al siguiente de la lista hasta alcanzar el destino.

Para aquellos que no os haya quedado muy claro o queráis ampliar o conocer otros algoritmos de pathfinding al final pondré algunos enlaces.

Aplicaciones:

En el mundo de los videojuegos existen muchas aplicaciones para este tipo de algoritmos. Son necesarios siempre que tengamos un escenario o nivel con objetos sólidos o infranqueables en los que queramos que el computador mueva un objeto de un punto a otro del escenario. Esto ocurre como todos sabemos en los juegos de estrategia y de rol, donde le decimos a las tropas donde deben moverse y ellas se las apañan para alcanzar ese punto a través del terreno. Pero también cuando el ordenador necesita mover un enemigo de un punto a otro del escenario necesitará de un pathfinding.

El problema del algoritmo que he comentado es que no es dinámico, y por tanto si queremos que, por ejemplo, un enemigo persiga a un jugador tendríamos que recalcular el camino a seguir por el pnj cada poco tiempo, lo que puede resultar demasiado costoso.

Pero para estos casos podemos usar técnicas mixtas. Por ejemplo en un arcade los enemigos (verde) podrían utilizar el pathfinding para ir a la habitación en la que está el jugador (azul), o a determinados puntos de control dentro de esa habitación (amarillo) donde su posición sea ventajosa. Una vez con el jugador “a tiro” simplemente deberían orientarse en la dirección del vector que apunta desde ellos al jugador.

pathfinding

Para ampliar:

A* para principiantes: una explicación muy sencilla, con varios gráficos, que nos dejará el algoritmo A* bien clarito.
A* en la wikipedia - A la derecha tenéis enlaces a algoritmos relacionados así como el pseudocódigo del algoritmo y un pequeño análisis de su complejidad.
The Game AI Page: Pathfinding - enlaces a algoritmos y papers sobre búsqueda de caminos.

9 July, 2007

Modelo V: Detección de colisiones

Escrito a las 0:15 en la categoría: Juegos, Modelos de juego

Antes que nada agradecer a aquellos que votaron en la encuesta del foro y más aun a los que comentaron su opinión. Gracias por el apoyo y vuestros consejos. Dado que la encuesta ha resultado en una aplastante victoria de los algoritmos, voy a centrarme más en ellos. Pero shephiroth me dio una idea que me gustó que es la de hablar de algoritmos pero mostrar aplicaciones prácticas y ejemplos. Procuraré traer un algoritmo o grupo de algoritmos nuevo cada semana, pero también habrá semanas que dedicaré a un modelo de juego o a ejemplos de juegos que aplican algoritmos ya vistos. Como siempre los comentarios, críticas y aportaciones son bien recibidas.

Hoy voy a hablar un poco de detección de colisiones y al final traigo una pequeña sorpresa, para los que sean capaces de leerlo completo :P

Definición: Tomaremos como Algoritmos de Detección de Colisiones (a partir de ahora ADC) aquellos que se ocupan de que, en la geometría de un juego, no haya intersecciones entre objetos. Además estos algoritmos pueden indicar cómo debe reaccionar determinado objeto en caso de intersecar a (chocar con) otro.

Dificultades técnicas: Los AGC son, si no los acotamos, algoritmos muy costosos, ya que tenemos que calcular la intersección de cada objeto con todos los demás y para cada caso tendremos que comprobar cada pixel o cada vértice de cada objeto… Esto los hace en principio muy costosos computacionalmente, y por eso son uno de los temas más tratados en programación de juegos. Para acotar el problema e incluso reducir su orden de complejidad tenemos que saber bien qué resultados queremos obtener y qué es lo que realmente necesitamos. Por ejemplo:

  • Si los enemigos y objetos del juego siguen un camino predefinido o son estáticos no necesitarán de estos cálculos y podremos aplicar el ADC sólo al jugador principal.
  • Si la forma de los objetos de nuestro juego es cercana a un cuadrado o un círculo (un cubo y una esfera en 3D) no necesitaremos algoritmos complejos y este será un problema casi resuelto.
  • Tenemos que saber cuánta exactitud queremos conseguir y cuanto sacrificio computacional representa.

Como dijo Jack el Destripador: Vayamos por partes…

Muchas librerías y motores traen funciones más que de sobra para hacer el trabajo sucio por ti. Si estás utilizando o pretendes utilizar cualquier motor o librería, lo que debes hacer es leer qué funciones te provee y cómo puedes utilizarlas para cumplir tu objetivo. Si eres un campeón y estás escribiendo tu juego desde cero o simplemente quieres aprender cómo va esto de la detección de colisiones… Sigamos ;)

Lo primero que debemos hacer, una vez evaluado nuestro problema, y si necesitamos velocidad y tenemos muchos objetos que comprobar, es dividir el escenario en una cuadrícula. Si tenemos un escenario 2D esto será fácil, si tenemos 3D, pero básicamente los movimientos son a lo largo y ancho de un escenario, podremos dividir igual que antes, el plano XY. Si no, tendremos que dividir en cubos. ¿Para qué hacemos esto? Para acotar el número de objetos con los que haremos cálculos. De todos los objetos que necesiten ser revisados por el ADC, eliminaremos aquellos que se encuentren en cuadros separados de la cuadrícula, con lo que ahorraremos mucho cálculo inútil. En el dibujo de ejemplo, solo calcularemos la intersección del jugador (azul) con los objetos rojo oscuro, que son los que se encuentran dentro de sus cuadrículas (verde).

Dibujo 1
Dibujo1: División del escenario.

Una vez reducido el número de objetos que necesitan comprobación pasaremos al test de intersección propiamente dicho. Aquí también hay muchas técnicas, voy ha hacer un pequeño repaso de peor a mejor:

  • Si estamos en 2D podemos comprobar pixel a pixel si dos sprites se superponen, esta es la técnica que afina al máximo, pero muy costosa.
  • Tanto en 2 como en 3 dimensiones podemos aplicar la técnica de cajas o esferas envolventes o bounding boxes/spheres. Esta técnica consiste en definir un cuadrado o círculo que acota completamente cada objeto. Hacer cálculos con éstas cajas es muy sencillo ya que son formas sencillas:

    Dibujo 2
    Dibujo 2: Bounding boxes/spheres

    • - Para comprobar colisiones con el rectángulo del jugador, para cada vértice de un rectángulo objeto comprobamos:
      SI (xPunto > xJugador) Y (xPunto < xjugador + anchoJugador) Y (yPunto > yJugador) Y (yPunto < YJugador+largoJugador) ENTONCES El punto se encuentra dentro del rectángulo -> COLISIÓN DETECTADA.
    • - Para comprobar colisiones con círculos:
      SI (suma de los radios) > (distancia centroJugador, centroObjeto) ENTONCES COLISIÓN DETECTADA.
  • Si los objetos del juego están constituidos por vértices y aristas podemos aplicar funciones de intersección entre aristas, puntos y planos. Esta es una solución más costosa pero más certera que la anterior. Podríamos obstar por soluciones intermedias, como tener un modelo en muy baja poligonización para la detección de colisiones y otro para la representación gráfica. O tener al jugador dividido en partes y aplicar bounding boxes a cada parte para luego comprobar a nivel de superficie sólo las partes que dieron positivo en el primer test.
  • Podemos usar árboles BSP (partición binaria del espacio) para dividir recursivamente las BB y obtener más precisión

.
.
.

Hay decenas de técnicas, por ahora creo que está bien como introducción, más abajo dejo unos cuantos links para los que quieran profundizar. ¡¡Y ahora viene la sorpresa!!

Esta semana me puse un ratillo y completé el menú y el sistema de fases de un juego inspirado en el Asteroids que comencé hace tiempo. La verdad es que quería añadir algunos detalles más, sobre todo gráficamente para explotar un poco el pequeño sistema de partículas que implementé, pero hacía tiempo que no lo cogía y le había perdido ganas, así que por ahora estoy contento con poder mostrar un juego cerrado. Es totalmente procedural, como todos mis jueguecillos hasta ahora (nada de imágenes, solo código).

La detección de colisiones es a nivel de aristas, Java provee de funciones para el cálculo de intersecciones entre aristas y rectángulos y decidí utilizar las aristas ya que los polígonos de los meteoros y la nave están almacenados como listas de vértices. No divido la pantalla ni en cuadros ni nada de eso ya que el juego no requiere demasiado y yo no quería meterme en más fregados (a mi no me consume ni un 10% de CPU, comentadme que tal os va).

Espero que os divertáis un poco, si os picáis dejadme comentada vuestra puntuación máxima ;)

El juego: (more…)