Implementando el diseño

Una de las partes críticas a la hora de hacer un prototipo, es implementar todo aquello que hemos estado pensando, definiendo y escribiendo en nuestro GDD (abreviatura de Game Design Document o en castellano: Documento de Diseño del Juego).

Pero, ¿por dónde empezar?, ¿qué hay que programar primero?, pues con este post la idea es contestar a estas preguntas.

Lo más importante de un prototipo no es que se vea bien, ¡¡es que sea DIVERTIDO!! :D, al fin y al cabo es un juego lo que estamos haciendo y para ello tenemos que buscar cuál es el MVP de nuestro juego, “MVP” son las siglas de “Mínimo Valor de Producto” (no Most Valuable Player xD), que en este caso se define como “aquellas mecánicas o cosas que el juego necesita obligatoriamente para poder tener una idea de cómo será éste una vez esté terminado”. Por poner un par de ejemplos, el MVP de Minecraft sería programar el movimiento por el mundo y que puedas quitar y poner cubos, o el MVP del Mario Kart sería que pudieras conducir por los circuitos y que se pudieran usar objetos. Todo lo demás, equilibrar el juego, añadir opciones, modelar el escenario, hacer el diseño del nivel, es prácticamente secundario a la hora de prototipar, ya que lo que nos interesa es que funcione y que sea divertido.

La idea es que cuanto menor sea el MVP, mayor provecho podremos sacar de nuestro juego, ya que todo el trabajo que hacemos una vez hemos cumplido el MVP será sólo para mejorarlo, por que lo principal estará terminado. De manera que como os podéis imaginar, hay juegos cuyo MVP es muy inferior (dado que se tarda muy poco en programar y la idea es muy simple), los juegos mencionados antes son un ejemplo de esto, pero estoy seguro de que juegos más complejos, como el Sid Meier’s Civilizations V o Europa Universalis tardaron meses en cumplir su MVP.

En el caso de Vault Bandits y tras unos cuatro meses de trabajo a ratos (y con medio personal trabajando en Unity), se puede decir que hemos cumplido con el MVP. Ya que te puedes mover con los personajes principales, disparar, hacer acciones, infiltrarte para cumplir las misiones, y aunque no tengamos IA (que es MUY importante), siempre podemos manejar a los malos para hacernos una idea de cómo quedará el juego.

Para implementar todo esto, el orden  fue más o menos el siguiente, partiendo por lo más importante a lo que menos:

  1. El movimiento: Dado que teníamos un movimiento basado en D&D, y que tenemos un mapa cuadriculado, necesitábamos que el sistema funcionara lo más pronto posible, por un lado porque necesitamos saber cómo localizar a los distintos actores dentro del mapa, y segundo porque teníamos que estar seguros de cómo sería el sistema, para poder modelar adecuadamente los edificios que pueblan el mapa.
  2. Acción de atacar: Lo segundo que nuestro juego necesitaba era que los personajes pudieran disparar, un sistema de equipado de armas y de daño aleatorio según el arma equipada y, por supuesto, lo debían poder usar tanto los protagonistas, como el resto de NPCs del juego.
  3. Habilidades: Ésta es quizás la que más tiempo nos ha llevado de todas las tareas, y es que cada personaje tiene habilidades muy distintas, que usan combinaciones de casi todos los scripts que hemos hecho, pero lo bueno es que una vez están programadas, ya hemos construido la base para que el resto de cosas sea mucho más fácil de implementar. Aun así, dado que hay habilidades que afectan a la IA, aún nos queda un largo proceso, pero por suerte tenemos unos buenos cimientos sobre los que no tardaremos mucho en construir el resto del juego.

Y bueno, estos fueron los aspectos fundamentales. Obviamente, no estoy incluyendo todo el tema de correción de bugs, que a lo largo del desarrollo crecen y se multiplican como conejos, y como no vayas parando de vez en cuando para corregirlos, te puedes encontrar tras unos meses con un prototipo más inestable que un flan en un terremoto.

Espero que os sirva y que si tenéis una idea, no empecéis a programar vuestro juego por el tejado (¡¡aunque el tejado mole mucho!!, porque necesita paredes y un suelo para que no se caiga jajaja).

¡Un saludo y nos vemos en el próximo post! 😀

Diario de desarrollo #3

Ya casi parece que es costumbre hacer este pequeño resumen con los progresos del proyecto, ¡y esta semana no podía ser menos!

1.- ¡Empezamos con los grandes progresos del prototipo! Ahora gracias a la implementación de unos algoritmos de búsqueda, nuestros protagonistas ya tienen pathfinding, esto significa que ya no atraviesan paredes y buscan un camino a través de puertas y obstáculos, lo cual nos da un movimiento muy realista. Otra nueva característica es que pueden “ver”, por lo que saben qué enemigos y civiles hay a su alrededor, y además miden distancias y saben si están lo suficientemente cerca como para poder disparar y acertar con el arma equipada.

Por supuesto, ¡también tenemos un nuevo sistema de turnos! que es absolutamente imprescindible para el género que estamos haciendo. El código ha sufrido un rework más para que todos los que estamos trabajando en él podamos entender lo que se hace con más facilidad y para que trabajar en él siga siendo igual de fácil.

Para los días que vienen, la idea es trabajar y rematar el pathfinding y en cuanto esté, el sistema de puntos de habilidad, ya tendríamos un prototipo jugable (aunque no muy bonito) pero que nos permitiría probar las mecánicas y pasar a una fase de testeo más intensiva.

Pathfinding
El movimiento desde arriba. Como se aprecia, junto a las paredes no debería haber un hueco sin poder caminar.

2.- El arte no es morirte de frío, sino que comprende los modelos de personajes y props (un prop es un objeto que decora el escenario).

Por fin tenemos un modelo terminado (aunque sin texturizar), y un prop que nos ha servido para ver cómo se importan Objetos a Unity, se hacen unwraps sencillos, aplicar bumps y otras técnicas para que quede más realista. Aquí tenéis el resultado inicial:

Caja
Hola, soy una caja 😀

Además, esta caja ya contiene una animación, con lo que también podemos probar a animar props y ver cómo activar estas animaciones según vayan ocurriendo acciones.

En cuanto al modelo del NPC, lo utilizaremos para hacer pruebas de shaders y ver qué estilo aplicamos al final al juego, si un estilo cel-shading de cómic o un estilo 3D crudo y realista, ya se verá.

3.- Por último, ahora que ya sabemos cómo va a funcionar nuestro sistema de movimiento por el escenario, tenemos una idea muy clara de cómo hacer los edificios. Para ello vamos a usar un sistema modular con paredes de varias unidades (una unidad es un cuadrado de 1 metro en Unity), que incluirán puertas o ventanas. A continuación usaremos estos módulos como piezas de un puzzle para montar los edificios. Este sistema lo usaremos tanto para los edificios principales como para los de los alrededores, y como es modular, los podremos usar a lo largo de todo el juego ahorrándonos trabajo a la hora de crear edificios nuevos.

Y hasta aquí la entrada de hoy. Ya sabéis que cualquier comentario nos lo podéis hacer llegar por Twitter a @ProjectDinamita, por Facebook a Dynamite Project o por esta misma página 🙂

¡Un saludo y hasta la próxima!

Arte, modelado y otros menesteres

Originalmente esta semana tocaba hablar del aspecto visual de Vault Bandits: qué utilizamos para trabajar en estas cosas y poner algún ejemplo, pero creo que también es bastante interesante comentar los problemas que nos van surgiendo, y este fin de semana hemos tenido ya los primeros encontronazos con Git.

Pero hablemos primero de arte. Los videojuegos tienen un componente visual muy fuerte, por algo la palabra “video” está incluida en el término, por ello uno de los aspectos más importantes es el arte del juego, que está comprendido por escenarios, modelos de los personajes, estilo de animación o paleta de colores de escenarios y personajes, entre muchas otras cosas.

Herramientas de modelado: Pese a que Vault Bandits tiene una vista isométrica, los edificios y personajes serán en 3D, y para crearlo usamos 3DS MAX (la versión 2014 para ser exactos, que la 2015 aún tiene un par de bugs importantes…). Con este programa podemos realizar varias tareas:

  1. Modelado de los escenarios para prototiparlos haciendo cajas: Con ésto podemos implementar nuestros niveles de una manera rápida y sencilla, e ir probando si el mapa en sí es divertido y está equilibrado.
  2. Modelado de escenario y edificios finales: Aunque en Unity 5 se puede modelar usando prefabs y assets importados, creemos que es mucho más sencillo usar 3DS MAX para crear los edificios. Aunque tengamos un desarrollo modular, lo que significa que el escenario está compuesto de varias piezas tileables que vamos uniendo como queramos para crear escenarios más grandes, lo que nos da mucha más libertad a la hora de editar los pivotes, o a la hora de retocar las mallas, cosa que en Unity es imposible.
  3. Modelado y animación de personajes: No sólo podemos crear cómo se van a ver nuestros personajes (ya sean NPCs o protagonistas), sino que también podemos animarlos con “bastante facilidad”, ya que con la herramienta de bípedo de 3DS MAX, es más sencillo de lo que parece hacer que nuestros protas caminen, corran y disparen, eso sí, para los caballos y otros cuadrúpedos es otra historia, pero nada que la tenacidad no pueda resolver.
Primeros pasos en modelado
Este es el modelo inicial en low poly de un NPC mujer civil

De todas formas, esta es una pequeña parte de todo el proceso, ya que si no texturizásemos los modelos que hacemos, el escenario se quedaría con un color blanco muy muy soso. Para arreglar esto, usamos el archiconocido Photoshop, con el que pintamos los unwraps de los diferentes modelos que vamos haciendo. Estos unwraps los hacemos desde 3DS MAX, de manera que luego en Photoshop pintamos sobre una cuadrícula que se corresponde con los lados de nuestra figura a pintar. El caso es que además, por el modo en el que se importan las cosas a Unity, todos los objetos que hacemos han de tener su propia textura en un archivo aparte.

Ahora vamos al caso del Git. Como ya comenté en un post anterior, para sincronizar los archivos del proyecto en Unity y que todos pudiéramos trabajar con la misma versión estamos usando Git, usando Sourcetree como interfaz para ello. En estas semanas, mientras Miguel implemetaba características en el prototipo, Andrés luego, en su propio archivo de Unity por separado, cogía el código ya hecho y lo refinaba para obtener una versión más modular y que pudiese evolucionar mucho mejor, además de añadir compatibilidad con otras características. La cosa es que se implementaban características más rápido de lo que se refinaban en el modelo final, y tras una semana de sprint y con un prototipo con funcionas básicas plenamente funcionales, decidimos aunar versiones.

Para ésto en Git existe la opción merge, que permite llevar tus cambios al código que está hecho sin borrar lo que ya está, pero claro… con ésto Unity explotó (ja-ja-ja) de lo que aprendimos varios e importantes detalles:

Primero, a Unity no le gustan los cambios que se hacen con merge en una escena, esto dará un conflicto y tocará borrar a mano los cambios introducidos, no asegurando que aun así la escena se pueda cargar.

Los cambios en los scripts fueron mas fáciles de implementar, ya que al hacer un merge, Git separa el código de cada uno con varios headers, pero aun así, dado que el código de Andrés no estaba con todas las funciones que Miguel había implementado, el prototipo era menos estable que un flan en una montaña rusa.

Dado que el prototipo final está basado en lo que Andrés ha hecho (el pobre se ha pasado todo el fin de semana implementando las funciones del código de Miguel en el suyo) y para que pudiéramos revisar los cambios hechos, tuvimos que crear branches para cada código. Al final, cuando el código de Andrés ya tenga las funciones básicas, haremos un merge y trabajaremos sobre lo suyo como base (para así ahorrar tiempo y que no nos pase lo mismo otra vez), aunque todavía nos queda ver qué hacemos con el branch que hemos creado…

Repositorio de VaultBandits
Así ha quedado tras nuestras peripecias con Github xD

Y bueno, ahora mismo la idea es que Andrés termine la limpieza y optimización así como la total implementación de todo lo que Miguel había desarrollado en su proyecto. Mientras tanto tenemos a Antonio e Inés modelando, a Miguel haciendo pruebas de importación de modelos y animaciones y a Santi redactando nuevas características. Eventualmente, cuando el código de Andrés esté terminado podremos volver a implementar nuevas características, pero hasta la semana que viene no parece que podamos progresar con eso.

¡¡Y esto es todo amigos!!

Espero que os haya gustado y que ahora os hagáis una idea de lor problemas que os podéis encontrar al usar Git. Con el tiempo ya iremos compartiendo más imágenes sobre el desarrollo y modelado, pero de momento vamos tan rápido como podemos.

Recordad que nos podéis encontrar por Twitter en @ProjectDinamita, por Facebook en Dynamite Project o podéis dejar comentarios en esta misma página 🙂

¡Un saludo!

P.D.: Al final hemos tenido final feliz con el Sourcetree y ya está todo arreglado y  listo para darlo todo en el sprint de esta semana

🙂

:)
Happy Sourcetree 🙂