De vuelta a Unity

Buenas tardes o buenos días, según cuándo estéis leyendo estas líneas. Como ya sabéis, este proyecto es el trabajo de Fin de Máster del Máster en diseño y desarrollo de videojuegos PlayStation First, y como todo Máster, tiene unas fechas de entrega. En nuestro caso, el 18 de este mes, tenemos la presentación del prototipo Vault Bandits y entregaremos a los profesores el GDD (Game Design Document) para que nos evalúen el trabajo realizado.

Así que en estos días, estamos trabajando todo lo que podemos en el prototipo, ya que tiene que estar terminado, y jugable para cuando lo entreguemos, para que os hagáis una idea de en qué andamos trabajando aquí os dejo un resumen:

  • En Programación, Andrés esté terminando la IA del juego, es decir, que los personajes manejados por la máquina disparen, se muevan, y actúen por sí solos, respondiendo a las acciones que hace el jugador. Este es uno de los puntos fuertes del juego, ya que sin IA, el jugador no tiene oposición a lo que está haciendo, y sería muy aburrido. Los civiles se comportan de forma más pasiva, y solo reaccionan ante lo que hace el jugador, mientras que los guardias, tienen varios estados de alerta. Por defecto, sólo patrullarán por una ruta establecida, pero si se da la alerta, los guardias atacarán a los personajes con todo lo que tienen.
  • Por otro lado, tenemos a Miguel trabajando a full en el resto de detalles que conforman el prototipo: implementando animaciones de los protagonistas, implementando el HUD (la barra de vida del jugador, el sistema de inventario, de puntos de habilidad, para que el jugador sepa en qué estado está), programando condiciones de victoria/derrota (el Game Over de toda la vida), corrigiendo bugs.. y eso sólo son unas pocas de la miríada de tareas que quedan pendientes: implementar la habilidad de robar, implementar la destrucción de escenario, refinar el movimiento de la cámara y los controles, implementar un sistema de pausa, refinar el sistema de visión (qué ven los personajes)… bueno, un montón de cosas.
  • Por el lado de arte, tenemos a Antonio e Inés trabajando en campos distintos, Antonio está detallando los gráficos del HUD y la interfaz así como para el resto de ventanas que se usan en la partida, y a su vez, está terminando los props que llenan el escenario ( barriles, mesas, estanterías, cajas, alpacas de paja un poco de todo), e Inés, está animando a todos los personajes que usaremos en el juego, de momento tenemos a Clyde listo, pero aún faltan Tala, Francis, los guardias, y los civiles.

Y esto es un poco el resumen de esta semana. En cuanto tengamos el prototipo listo, no dudaremos en compartirlo con todos vosotros, para que nos deis un poco de feedback, aunque tenéis que pensar que esto está en alfa, que ni siquiera es una prueba de alfa, más bien, una prueba de concepto para desarrollar nuestras habilidades, y a la vez demostrar que se puede hacer un juego de estrategia por turnos ambientado en el salvaje Oeste.

Nos despedimos con nervios, dado que mañana saldrán los resultados de los premios PlayStation, ¡a ver si con suerte estamos entre los 25 clasificados! 😀

¡Un saludo y hasta luego!

Anuncios

Diario de desarrollo #4

Hoy os ponemos al día con el estado de desarrollo de “Vault Bandits:  Looters Unleashed” en este cuarto diario:

1.- Primero, en el apartado de Programación, ya hemos terminado de implementar las características más importantes y claves para tener un prototipo funcional. Ahora bien, aún queda mucho por hacer, empezando por la niebla de guerra.

Niebla de guerra
Niebla de guerra del clásico juego de estrategia Age of Empires II

La niebla de guerra es un sistema que permite emular lo que los personajes ven realmente, así el jugador también tiene la incertidumbre de no saber dónde están los enemigos e invita a explorar y conocer el mapa detenidamente antes de hacer algún movimiento que ponga en peligro de muerte a los protagonistas, y es que el conocimiento es tan importante como la fuerza bruta. En los mapas, los personajes sólo verán el terreno que ya hayan explorado, o en caso de tener un mapa, conocerán de antemano cómo es el lugar al que van. Pero programar esto conlleva solucionar varios problemas con shaders, líneas de visión, recordar los sitios en los que ya han estado y otros detalles. En resumen, una tarea ardua que Andrés está llevando diligentemente y que esperamos poder terminar pronto.

2.- Por otro lado, tal y cómo ya hemos comentado anteriormente otras semanas, el resto del equipo estamos volcados en tareas de Arte, que conlleva lo siguiente:

  • Inés está trabajando en el modelado y animación del NPC vigilante, los primeros defensores de la ley con los que te encuentras en el juego. Aparte, ya está terminado el modelo del NPC Civil hombre, sólo que sin texturizar y sin animar… ya que tiene prioridad el NPC vigilante, y una vez este personaje esté terminado, lo implementaremos en nuestro prototipo para que en vez de ver una caja por fin aparezca un modelo hecho y derecho.
  • Antonio está al cargo de texturizar los modelos que Inés va haciendo, aunque el pobre está sin móvil y comunicarnos con él es algo más difícil, pero bueno, el modelo del NPC civil de mujer está quedando fetén ^_^. Además, está trabajando ya en abocetar una primera versión de HUD,  con toda la información que el jugador necesita para saber en qué estado están los protagonistas, y para mostrar la información básica de la partida: el turno, las acciones disponibles, munición de  las armas, estado de los enemigos, puntos de acción restantes, etc.
  • Por último, Miguel está con el modelado de los edificios del escenario y para esta semana tendrá acabado el banco (por la cuenta que le trae) tanto el interior como el exterior, y en cuanto esté terminado se pondrá con el edificio de salida y entrada (una especie de abrevadero + establo ), éste es el edificio que marca cuál es el punto en el que los protagonistas dejan los caballos y empiezan la misión, y a su vez marca el lugar por el que tienen que escapar con el botín y terminar la misión.
  • Para finalizar, ¡¡a Santiago hay que felicitarle por su nuevo trabajo!!, aunque eso significa que de momento el pobre no puede dedicarle apenas tiempo a nuestro prototipo, pero no pasa nada, ya se pondrá al día una vez terminen las clases del máster.

Y con esto y un bizcocho ¡acabamos por hoy! No sin antes recordar que esta semana todos los integrantes del Máster GamesUPM vamos a participar en la primera Game Jam organizada en conjunto con Sony, y aunque no vayamos los cinco como un equipo seguro que es una experiencia genial. Si queréis saber más sobre el tema, ¡aquí tenéis más información al respecto! http://t.co/P7a039C0ek, aunque he de decir que las plazas están agotadas, aunque se admite gente para las plazas de reserva. La semana que viene subiremos los juegos que hemos hecho en esas 48 horas, a ver que tal se da :D.

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 🙂