Immortal Redneck [CremaGames]

Nuevo devlog, mostrando a fondo nuestro primer enemigo: http://cremagames.com/blog/2015/11/11/the-unstoppable-warrior-devlog-9/

El guerrero imparable – Devlog 9

El Guerrero es uno de nuestros primeros enemigos y también uno de los más fuertes: si te golpea con su mazo gigante vas a notar el dolor.

Aquí tenéis el concept 2D del Guerrero. Parece una criatura pequeña y gordita, pero realmente mide más de dos metros y medio. El Redneck mide sobre 1,8m así que es bastante grande en comparación con el jugador. En los vídeos que os pongo más alante puede parecer que es pequeño en comparación con el escenario, pero tened en cuenta que es un escenario vacío de prueba.

El Guerrero es un adversario a melee, grande y lento. Incluso siendo la primera vez que lo veas creemos que te puedes imaginar cómo se mueve y cómo golpea. Como siempre nuestro equipo de arte estuvo a la altura intentando plasmar todo eso en el personaje (o al menos eso pienso yo xD).

Nuestro equipo de arte es tan bueno que los animadores tuvieron que inventarse una animación de andado bastante curiosa para poder adaptar la silueta del personaje a la velocidad a la que queríamos que se moviese. Nuestro CM según vio el personaje andando ya visionó el siguiente Vine y tuvo que hacerlo de inmediato.

[media]https://vine.co/v/e2rVu1KHMmp[/media]

Aunque sea poderoso, es un enemigo bastante simple. Es el tipo de enemigo que puedes matar fácilmente con algo de distancia y paciencia pero que tienes que mantener un ojo en él. Si dejas un par de Guerreros andando libremente acabarán rodeándote y causándote doloros problemas.

¿Cómo se hizo?

La respuesta no es rápida y queremos entrar bastante en detalle siendo el primer enemigo que presentamos al completo, así que agarraos. Una vez que teníamos el modelo 3D integrado en la escena de Testing en Unity teníamos que implementarle dos estados: intentando atacar al enemigo y buscándole por el terreno.

Para conseguir esto y como solución general para todas las IA estamos usando Behaviour Trees. Como el Guerrero ha sido nuestro primer enemigo hemos querido hacer todo desde cero. Es un proceso lento, pero ha rentado mucho porque muchos de los nodos que hemos creado se pueden reutilizar en el resto de enemigos y a la larga nos ahorra tiempo.

El primer paso era hacerlo mover. La secuencia es simple: el enemigo tiene un nodo para inicializar el Warrior (este nodo se usa en todos nuestros enemigos ahora mismo) y otro nodo para moverse hacía el personaje. Esta es la pinta que tiene el árbol en este punto:

La animación en este punto estaba a medias, así que parece un poco pobre, pero la intención de que te siga cuando te vea estaba conseguida.

El Guerrero puede atacar mientras se mueve, pero también mientras está parado, así que creamos dos estados de animación con capas para cada estado. Todo muy simple.

También queríamos que los personajes tuviesen un sistema de patrulla en caso de que no estén en contacto visual con el jugador, así que lo añadimos al árbol.

Si os fijáis en la lógica del árbol, tenemos un selector que elige entre la rama con la prioridad más alta y el resto. Si el enemigo no consigue verte, simplemente hará una patrulla por el escenario.

Por ahora tenemos el movimiento conseguido, pero también tiene que atacarte. Cómo enemigo melee, el Guerrero tiene que llegar hasta el personaje para poder atacar. Cuando empieza a atacar la animación y el timing tienen que ser bastante precisos. Aquí tuvimos unos cuantos problemas porque queríamos que comenzase la animación de ataque antes de llegar hasta el personaje para que tuviese un poco de previsión.

También con esto conseguimos que parezca algo más natural, aunque hacía nuestro árbol de comportamiento más complejo. Al final hemos añadido un nodo personalizado con este comportamiento.

Funcionó perfectamente, ahora el enemigo parece mucho más inteligente y real (incluso teniendo en cuenta la animación no final).

Por último, los retoques finales. Tuvimos que cambiar el comportamiento del ataque para que también siga buscando al jugador a la vez que ataca. Sin este cambio era realmente sencillo bordear al enemigo mientras seguía ocecado intentando atacarte en la posición en la que estabas antes.

Para solucionarlo, añadimos un último selector para que el enemigo pudiese girar con la condición de que busque al jugador en frente.

Este es el Behaviour Tree final:

Y aquí tenéis al Guerrero actuando como una máquina imparable de matar rednecks:

Y eso es todo, parece más fácil contado que programado, pero el resultado final hablan por si solos. Nuestra idea es que el Guerrero (y en realidad casi todos los enemigos) no sean enemigos díficiles de derrotar por si mismos, aunque haga bastante daño, si no que serán un problema cuando tengas una sala llena de una horda de diversos enemigos.

Las calaveras que veis en este vídeo son muy temporales, ya os hablaremos de ellas en el futuro

De bonus os dejo el modelo que si no Adri se mosquea.

Nuevo devlog, hablando sobre generación de dungeons: http://cremagames.com/blog/2015/11/19/randomly-generated-levels-devlog-10/

Niveles generados proceduralmente - Devlog 10

Lo primero una aclaración: hablamos de niveles, no de salas. Como en The Binding of Isaac y otros innumerables juegos, nuestras salas no se crean proceduralmente, son diseñadas una a una por nuestro equipo pero la colocación de estas salas en la mazmorra es totalmente aleatoria.

Dicho esto, toca hablar sobre algoritmos.

BSP no nos encajaba

Para el primer intento de hacer nuestra mazmorra intentamos usar Binary Space Partitioning, o BSP. De primeras nos pareció una buena técnica para implementar y que podría encajar con nuestras habitaciones (dado que la planta siempre es cuadrada) pero había un problema: conectar las habitaciones. Inicialmente este método nos requería diseñar pasillos entre cada habitación y es algo que no queríamos implementar, así que teníamos que buscar una forma más óptima de dividir el espacio.

Nos quitamos los pasillos de en medio rápido, pero apareció otro problema: a más tamaños de habitación que métiamos, más espacios sin usar aparecían. Esto era simplemente un problema de geometría: si tienes un tamaño determinado para tres habitaciones al insertar una de ellas te limita la posibilidad de colocar las otras dos.

Tras todas las pruebas, BSP era un dolor y los layout que generabamos con él no nos convencían al 100% así que tiramos todo lo hecho y probamos algo nuevo.

Un nuevo y mejorado algoritmo

Nos tocaba probar otro algoritmo, obviamente.

Dada una habitación inicial con un número 'x' de puertas, este algoritmo conectaba esas puertas a otras puertas al azar de las nuevas habitaciones. Dentro de cada nueva iteración de habitaciones, cogeríamos esas puertas y repetimos el proceso hasta que la planta de la mazmorra quede llena. Esto generaba algo de espacio vació pero no era un problema para nosotros.

Era un proceso bastante sencillo y nos gustaba porque era capaz de crear grandes mapas sin ningún pasillo. Por desgracia, como siempre, había un problema: los mapas quedaban con unos caminos muy prefijados. Partiendo por ejemplo de una habitación inicial con cuatro puertas se generaban cuatro caminos claros y nunca se conectaban entre ellos (norte, sur, este y oeste) por lo que tendrías que estar constantemente volviendo sobre tus pasos para llegar a la habitación inicial de nuevo y probar otro camino.

Aquí es cuando se nos ocurrío conectar las puertas automáticamente de habitaciones que estuviesen cerca unas de otras (aunque sean de distintos caminos) pero no funcionó muy bien, raramente las puertas encajaban y si lo hacía siempre había alguna diferencia de unidades entre ellas. En lugar de esto, cambiamos la forma en la que las habitaciones se colocaban de manera que se testeen todas las posibles posiciones y probando cual es la que genera más conexiones.

De esta forma, el algoritmo siempre tiene un listado de puertas a conectar y testeará unas cuantas habitaciones para cada una de ellas. Como las habitaciones tienen multiples puertas, el algoritmo evaluará todas las posibilidades para ver cual es la que más conexiones genera con lo que ya haya anteriormente en la mazmorra. Cuando encuentra la mejor habitación posible con la mejor posición/rotación posible la coloca.

Cada vez que una nueva habitación se coloca, sus puertas son incluidas en la lista del algoritmo como puertas a conectar así que las habitaciones nuevas van comprobando también con estas. De esta forma conseguimos que las diferentes alas de la mazmorra queden conectadas y no haya caminos muertos como antes.

Ahora que hemos explicado todo el tocho, disfrutad de algunos ejemplos de mazmorras generadas proceduralmente. también hemos sacado algunas en isométrico porque queda realmente bonico y nos recuerda a La Abadía del Crimen <3

Un gif de la generación de la mazmorra. En este punto es cuando el algoritmo no conectaba las habitaciones correctamente así que no es la solución final que hemos implementado.

Y aquí tenemos el algoritmo final funcionando. Las habitaciones como véis se conectan correctamente y hay varios caminos por los que navegar por la mazmorra.

Algunas pruebas más

¡Vista isométrica!

Y por último algunos ejemplos del algoritmo con las habitaciones finales con iluminación y demás. Aquí veréis que se repite bastante más porque por ahora solo tenemos cuatro habitaciones "finales".

Nuevo devlog, otra vez con retraso de cojones. Mañana os pongo el que salió ayer y a ver si voy cogiendo el ritmo xD
http://cremagames.com/blog/2015/11/26/meet-the-archer-devlog-11/

El Arquero - Devlog 11

Nuestro arquero es una criatura antropomórfica con un casco extraño con forma de Anubis que esconde su cara y nos hace preguntarnos que habrá detrás. O a lo mejor el casco realmente es su cabeza, realmente no lo sabemos. Hemos preguntado a nuestro concept artist sobre ello y nos ha puesto esta cara :/

En cualquier caso, es un enemigo a distancia, con predicción de movimiento, ágil y cobarde.

Al igual que el Guerrero, el Arquero es más alto que el Redneck. Nuestro querido paleto mide sobre los 1,8m y el Arquero mide más de 2 metros. Como el arquero siempre ataca a distancia parece bastante más pequeño de lo que realmente es.

Cómo se hizo

El Arquero patrullará la habitación buscándote hasta que te vea o le golpees. Cuando una de esas dos cosas pasen, entrará en "modo ataque" y te disparará flechas intentando anticiparse a tus movimientos. Si pierde el contacto visual intentará moverse hasta tu última posición para volver a buscarte y seguir disparandote.

Para hacer que el arquero patrulle implementamos un nodo de Wander (patrulla).

También hicimos un nodo para detectar cuando está siendo golpeado e insertamos un selector entre las dos posibilidades.

Cuando entra en modo ataque, empieza a perseguirte y a atacarte sin parar gracias al repetidor. También hemos añadido otro nodo para que esté constantemente comprobando el jugador de tal forma que si te deja de ver camine hacia su última posición por el camino más corto. En este punto parece que estén jugando al escondite porque todavía no estaba el disparo implementado.

Eso fue lo siguiente que hicimos. Programamos nuestro nodo de ataque y animamos al arquero.

Por último los retoques. Nos dimos cuenta que el Arquero a veces asomaba un poquito por una esquina y ya empezaba a dispararte a pesar de que la pared estaba casi totalmente entre medias. Esto pasaba porque estabamos usando un raycast para detectar la visión del jugador así que lo solucionamos usando un SphereCast. De esta forma tiene que verte completamente para empezar a disparar.

Una vez solucionamos esto, implementamos también la detección de movimiento. Un último vistazo a la IA final del arquero y sus animaciones.

Esperamos que os guste. ¿Sugerencias? ¿Críticas?

#205 #206 #207 Efectivamente si te paras cuando dispare la flecha no te va a dar nunca, esto es así intencional.

Tenéis que pensar que la idea de Immortal Redneck no es que combatas contra un arquero ni contra dos. En el juego los enemigos vienen representados por hordas, el combate 1vs1 no es relevante porque siempre va a haber multitud de enemigos de diferentes tipos en la pantalla.

La idea no es que el arquero suponga un reto, la idea es que cuatro arqueros + dos guerreros + dos demonios voladores supongan un reto.

Si ponemos que la predicción sea menos simple, o que la flecha salga más rápido o que disparen con menos cadencia como nos han comentado también el juego resultaría imposible desde el momento en el que haya más de un arquero en pantalla.

Espero que cuando os enseñemos cosas más avanzadas del juego en si quede más claro