domingo, 28 de septiembre de 2014

Libros: Unity 2D Game Development

Siempre he sido un gran amante de los juegos 2D, sin importar que tengan sus gráficos pixel art, vectorial o como sea. Forman parte de mi infancia y han ocupado la mayor parte de mi vida como desarrollador y como usuario, dejando en mi memoria (escasa, por otra parte) inolvidables personajes desplazándose únicamente en los ejes x e y. Como consecuencia de todo esto, casi todo el uso que he dado a Unity ha sido para crear mundos 2D, unas veces recurriendo a “trucos” de cámara y quads (polígono cuadrado plano formado por dos triángulos) y otras recurriendo a las nuevas funciones 2D del engine.

Quería profundizar en las funciones 2D de Unity y me hice con Unity 2D Game Development, un libro de la genial editora de Packt Publishing que se dedica bastante al tema de los videojuegos, en el que de forma resumida y entretenida (tiene algo más de 100 páginas) nos ayudan a desarrollar un juego de plataformas 2D en nuestro querido motor, recurriendo a las nuevas funciones que nos harán la vida más fácil para este tipo de desarrollos. Así, entre tiempo de proyectos, buscar un curro con el que ganarme la vida y alguna que otra partidilla de vez en cuando, dejo pendiente también una lectura de principio a fin del libro, para hacer el juego que propone y sacar alguna idea que tenga por ahí dentro del género plataformas y poner en práctica lo aprendido. Todo a largo plazo, porque estoy un poco ocupado, pero bueno. :P

Solo para ir comentando por encima como funciona esto del 2D en mi motor favorito, decir que se recurre a cámaras ortogonales (se proyectan paralelamente hacia el infinito, por lo que captan los objetos al 100% de su tamaño independientemente de la distancia a la que estén situados), un sistema de estados para controlar las animaciones, colliders 2D para controlar las colisiones de objetos planos, y el nuevo objeto sprite, que viene a ser un Quad donde colocar nuestros gráficos bidimensionales… pero se comporta de otra forma. (Más o menos esto es el 2D de Unity).

Para despedir el post toca comentar algunas cosillas sobre esta publicación. En primer lugar, está en inglés, como de costumbre para este tipo de volúmenes; en segundo lugar es de principios de 2014, por lo que ya hay por ahí otros nuevos, concretamente estoy pendiente de uno que está por salir, si no ha salido ya, titulado algo parecido a “Mastering Unity 2D Development” y que se estaba comentando hace unos días por los foros de desarrolladores Indies. Si finalmente sale y puedo conseguirlo (porque tardará en llegar a mi país), lo comentaré aquí, como siempre. :)

miércoles, 24 de septiembre de 2014

Colaboraciones: Guac-a-Note

De nuevo me he puesto a colaborar en un proyecto, creando algunos gráficos con un ajustado límite de tiempo y con objetivos de proyecto universitario. Y es que esta vez, mi primo, el programador de videojuegos Chechu Gracía, tenía que presentar su proyecto final de post-grado antes de pasar a sus estudios en la Universitat Pompeu Fabra.

La idea de juego y su programación, con ayuda de Unity, han sido trabajo de Chechu (como es lógico) y su novia, Natalia, se ha encargado de ayudar con la parte musical, la cual ha sido necesaria porque este es un juego de género musical y educativo en el que unos extraños seres llamados Pianemblims, deben ser “golpeados” a través de la pantalla táctil de nuestro teléfono o tablet, cuando aparecen sobre las teclas de un piano, generando así el sonido de las teclas que, gracias a la secuencia de aparición de los Pianemblims, nos hará interpretar una canción completa al piano sin que nos demos cuenta. Es decir, que es una mezcla del clásico juego Guac-a-mole o golpea al topo, con una aplicación de piano. ¿No es original?

El proyecto ha obtenido una nota muy alta debido , entre otras cosas, a la originalidad de la idea y ahora estamos barajando la posibilidad de crear una versión más completa, con mejores acabados y más larga para exponerla en Google Play… ¡aunque ya se verá! :P

La parte gráfica que ha sido lo mío, ha consistido en un poco de pixel art por aquí, y otro poco de reinterpretar gráficos que estaban usándose como temporales por allá. Eso sí, como siempre, algunos de estos gráficos temporales han quedado sin ser sustituidos a la espera de una posible versión final debido a los ajustados límites de tiempo para la entrega.

Dejo como siempre algunas capturas del proyecto y ya haré un postmortem para contar todo el proceso e iré informando sin hay avances en este trabajo.



martes, 16 de septiembre de 2014

Juegos 3D con gráficos 2D

Hace años la revolución llegaba con los juegos 2D cuyos gráficos estaban hechos en 3D, es decir pre-renderizados, consiguiendo que las animaciones fueran más fluidas y el acabado gráfico tuviera un poco más de realismo. Sin emargo, con el tiempo los polígonos se impusieron y pasamos al 3D, moviéndonos no solo arriba y abajo en la pantalla si no también “en profundidad”. Bien, pues han pasado años desde entonces y muchos desarrolladores han cambiado esta filosofía del 3D en juegos 2D para usar Sprites 2D en entornos 3D y conseguir así juegos con el aspecto más tradicional o retro moviéndose en distintos planos y por escenarios más vistosos.

Actualmente los motores para crear videojuegos como Unity trabajan “siempre” (Se que tiene nuevas funciones 2D, pero no trabaja realmente en 2D) en 3D, por lo que, aunque creemos juegos con un movimiento 2D y gráficos retro, los estaremos desarrollando en un completo entorno tridimensional, con las ventajas que esto nos proporciona. Por ejemplo, podemos elegir entre una cámara ortogonal (es decir que proyecta sus rayos hacia el infinito de forma paralela y muestra los objetos en pantalla al 100% de su tamaño sin importar la distancia hacia donde se encuentren) o una cámara en perspectiva, consiguiendo que sprites planos se desplacen sobre fondos 3D, pudiendo así crear proyectos tan interesantes como lo fue en su día Paper Mario.


Gracias a esta nueva forma de desarrollar juegos 2D, aunque tengamos que tener otra mentalidad, distinta a la del movimiento bidimensional de antes, podremos aprovechar para generar menús de juego más dinámicos de forma sencilla, dividir nuestros personajes en piezas para animarlos por rotación, o dar cierta sensación de profundidad en capas de objetos planos, muy útil para los decorados. (En la imagen podéis ver el juego Teslagrad como un bonito ejemplo de todo esto)



Unity antes de incorporar sus funciones 2D permitía el desarrollo de este tipo de juegos con algunos trucos de programación y diseño que han quedado simplificados. Y es que con unos cuantos Quads (un polígono formado por 2 triángulos), la ya mencionada cámara ortogonal y el desplazamiento de la textura aplicada al Quad para convertirlo en sprite y, gracias a este, animarlo,ya teníamos todo lo necesario para recuperar los viejos tiempos de los juegos retro. Aunque eso sí, todos agradecemos la simplificación que ha supuesto este tipo de desarrollo en las últimas versiones del popular motor.


martes, 9 de septiembre de 2014

Postmortem P.U. Pets (Parte II)

El escenario

Ya he comentado que el tamaño de las pequeñas baldosas que componen el escenario era de 32x32 pixeles y a la vez, se corresponderían con el tamaño de la casilla por la que se pueden desplazar los personajes en el juego o calcular su distancia de ataque. Es por esto que de nuevo tuve que hacer un poco de pixel art, aunque no con el resultado que habría deseado por culpa de la limitación del tiempo. Aunque en principio mi intención era rehacer y retocar tiles para conseguir que se notara bastante menos la repetición y porque no quedé muy contento con el aspecto final de algunos de ellos, al final no pudo ser. Además, el programador tampoco pudo añadir una variedad mayor de los fragmentos que compondrían el escenario, por lo que las transiciones entre tierra y agua, por ejemplo, eran un poco bruscos y “cuadriculados”.

Los combates

El combate era en cierto modo, automático, ya que la parte estratégica estaba en situar nuestras tropas a una distancia determinada sacando provecho de sus rangos de ataque para poder dañar al enemigo sin que en el turno siguiente el enemigo pudiera dañas a nuestras unidades. Así, cuando el juego pasaba a este modo combate, en él se visualizaban los personajes a pantalla completa y los puntos de daño que se hacían entre ellos eran mostrados. Todo era breve, pero duraba lo suficiente para poder apreciarse mejor el aspecto de los P.U. Pets.

Cada unidad tenía un rango de movimiento que le permitía avanzar más o menos en cada turno variando así sus velocidades de avance y, por supuesto, un rango distinto de ataque, con la posibilidad de algunos de dañar a distancia y de otros de tener la necesidad de hacerlo “cuerpo a cuerpo”.



El juego

Normalmente en este tipo de trabajos los derechos de distribución se los queda la Universidad y tampoco llegamos a terminar una versión lo suficientemente estable para publicarlo en Google Play, así que decidimos dejarlo como proyecto acabado pero evitando hacerlo llegar al público general.

Disfruté de largas e interesantes partidas en las salas de espera de hospitales, peluquerías, clínicas dentistas y, por supuesto, durante mis viajes de una ciudad a otra, y siempre me pareció un juego entretenido (claro, que yo amo los Tactic RPG). Además, quedamos relativamente contentos con el aspecto final y su funcionalidad dadas las limitaciones temporales para su desarrollo. Eso sí, evidentemente, de haber invertido mucho más tiempo esfuerzo podría haber quedado mucho más profesional, con mas animaciones, transición entre pantallas, movimientos más suaves, magias, etc.



Fallos

El proyecto final, como es lógico, tiene algunos Bugs, ya que no hubo tiempo de testeos y tampoco de pulir prácticamente nada. Por ejemplo recuerdo que era un problema recibir una llamada en el teléfono mientras estaba jugando porque la música permanecía sonando cuando descolgaba. La inteligencia artificial de la máquina también era limitada y en ocasiones bastante suicida al atacar, y algunas veces se desplazaban las zonas rojas que indicaban los rangos de ataque, por lo que acababas lanzando dicho ataque una casilla más a la derecha de lo que deseabas.

Corregir todo esto no habría sido excesivamente complicado pero decidimos dejarlo. Mi primo tendría que empezar pronto nuevos proyectos en su Postgrado y yo andaba, como siempre, embarcado en muchos otros y variopintos trabajos.

Otros elementos

Menús de juego, interfaz de usuario, pantalla de título… Muchas de estas cosas se quedan con unos gráficos temporales que creó Chechu en el programa de dibujo por defecto de Windows porque yo no tuve tiempo de terminar su versión final, o simplemente decidimos que no era necesario. En ocasiones, dado el aspecto retro del juego, no le quedaban mal algunos botones bastante sencillos y pixelados y la paleta de colores era más o menos uniforme y a mi parecer, adecuada.


Conclusión

Un nuevo juego para el curriculum, tareas nuevas de las que aprender y obtener más experiencia, y un icono más en el teléfono o la tablet que nos permitiría una partida de vez en cuando con recuerdos entrañables de esta aventura del desarrollo.

Aunque pudiendo ser muy críticos hacia nuestro propio trabajo no dejábamos de estar orgullosos de verlo en funcionamiento y sabíamos que en el futuro podría abrirnos alguna que otra puerta para trabajar en la industria. Era solo un paso más, pero un paso al fin y al cabo.

domingo, 7 de septiembre de 2014

Postmortem P.U. Pets (Parte I)

La colaboración 

Chechu García es uno de mis primos, que tiene casi mi misma edad y que desde niño tuvo como yo, el sueño crear sus propios videojuegos. Juntos diseñamos juegos, jugamos juegos e incluso creamos nuestra propia revista casera especializada en juegos.

Con el tiempo yo me centraría en la parte gráfica mientras que el acabó escogiendo la programación y, mientras que yo era un poco más autodidacta (solo un poco), el siguió el camino de estudios enfocados en el tema habiendo acabado recientemente un postgrado en programación de videojuegos y apuntando ahora hacia un master.

Con esta trayectoria es evidente que surgirían colaboraciones en muchas ocasiones y que estaría contando con la aportación de mis gráficos para alguno de sus proyectos igual que yo tendría muchas dudas que plantearle en temas de programación.
Motivos para hacer el juego

Precisamente el motivo de este juego, diseñado por Chechu García, es un proyecto final de carrera, con las limitaciones de tiempo que trae una entrega en una fecha determinada. En este proyecto pude aportar al menos una parte de los gráficos, sin que las prisas nos permitieran a ninguno de los dos lucirnos demasiado, pero posibilitando el añadir al curriculum un nuevo juego terminado, jugable y entretenido.

Programación

He de reconocer el merito del programador de crear un juego para Android desde cero sin saber realmente cómo funcionaba el tema (con Java y el SDK de Android). Era hora de coger uno de esos libros gruesos de programación de juegos en este sistema operativo y empezar a hacer pruebas y más pruebas para sacar adelante un prototipo al que poco a poco añadir los gráficos, sonidos y otros elementos para llegar a una versión más o menos definitiva.

A partir de gráficos temporales que luego sustituiría por algunos que yo crearía fue testeando y añadiendo funcionalidades y elementos, algunos de los cuales como ya he comentado, por falta de tiempo, desgraciadamente se quedarían en una versión temprana.

 

Documentación

En los proyectos que se realizan para las universidades se exige mucha documentación y, por supuesto, muy detallada, hasta el punto que en ocasiones se le da casi tanta importancia como al proyecto en sí. Yo lo viví en su día cuando hice la demo de Piratebots en mi etapa de estudios Superiores de Diseño Gráfico y Chechu tendría ahora que pasar también por esto. Sin embargo, en este caso resultó útil tener el gameplay, la historia y demás características bien explicadas para que yo mismo entendiera el arte que se iba a necesitar para el proyecto y de cuánto tiempo disponía para generarlo.

Las descripciones de los personajes y escenarios fueron quizá las cosas más útiles a las que tuve acceso, teniendo en cuenta que el gameplay ya estaba bien definido por el género de juego escogido: el Tactic RPG, es decir, la mezcla de la estrategia con las batallas de los juegos RPG. Todo por turnos, por supuesto.

Bocetos de personajes

La historia era sencilla. Básicamente consistía en un grupo de “mascotas“ o “peluches” enfrentados en una feroz batalla para conquistar industrias donde producir energía para aumentar su ejército y derrotar al enemigo. Así, habiendo ya un gameplay definido y un prototipo prácticamente funcionando, comencé a diseñar los personajes en base a una descripción que aparecía en la documentación.

Gracias a un cuaderno que siempre llevaba encima y a un lápiz, fui dibujando las ideas cuando me surgían, pero siempre teniendo en cuenta que mis creaciones tendrían que acabar convirtiéndose en pequeñas figuras compuestas de pocos pixeles.


Pixel Art

Una vez tenía los bocetos a lápiz iba escaneando y reduciendo al tamaño que necesitaba. Por supuesto al hacer esto el dibujo se hacía casi irreconocible, así que había que calcar encima pixel a pixel para situar cada parte en un sitio que permitiera hacer reconocible al personaje, elemento del escenario u objeto.

El tamaño de la cuadricula era de solo 32x32 pixeles, por lo que este era el tamaño de los personajes de juego, así como de los tiles que compondrían el entorno de combate.

Por otro lado estaban las escenas de combate que permitirían un tamaño de sprites mucho mayor. En este caso el método elegido para crearlos fue exactamente el mismo que el de los gráficos que entrarían el juego, por la sencilla razón de mantener la uniformidad en el estilo. Si el movimiento se iba a ver en pixel art, las batallas debían ser también en pixel art. Por ello el arte fue dibujado con líneas “duras” de pixeles evitando lo vectorial y los contornos suavizados dejando el aspecto “dentado” tradicional de este tipo de gráficos.


¡Y continuaremos en siguiente entrega!

Eso es todo lo comentado por ahora. Terminaremos en una segunda parte de este Postmortem para que no se haga muy largo.

miércoles, 3 de septiembre de 2014

El Concurso “The Room” de Toodaim presenta a sus ganadores

Desde ayer por la tarde, finalmente tres afortunados participantes van a poder disfrutar de los premios que, gracias al Blog de Toodaim y sus patrocinadores, se ofrecían a los juegos elegidos del concurso The Room, junto con la gloria de haber vencido a todos los demás creadores.

Los juegos elegidos han sido estos:

Empezando por el elegido como mi favorito como gran fan de este género de juegos, desde este Blog, Subject 3 de Toffy Games que ha quedado en tercer lugar, seguido después del divertidísimo UFO Rise de Estudio Cálcifer en segundo lugar, y terminando con… unos minutos para darle emoción…

3er Clasificado

2º Clasificado

El ganador total del concurso se veía venir desde hace tiempo por sus gráficos, su buen acabado casi profesional, buen trabajo en el diseño de mecánicas y niveles (o nivel) y su interesante historia de corte infantil contada a través de imágenes estáticas al principio y al final del juego. No podía ser otro que Dreaming High de Emini Studio. 

1er clasificado

Recomiendo a todo el mundo que pruebe los juegos descargándolos desde este post en el Blog organizador del concurso y si antes de guardarlos en su disco prefieren hacerse una idea del ganador en movimiento, dejo un enlace al video con su gameplay.

https://www.youtube.com/watch?v=LfHlV428ecU

Desde aquí les doy la enhorabuena a los ganadores y las gracias a Toodaim por organizar el concurso y a sus patrocinadores por apoyarlo. Hemos visto grandes trabajos gracias a ellos y nos hemos divertido e inspirado como desarrolladores o aspirantes a serlo.

Como siempre, hay que decir que la idea original de este concurso pertenece al Blog de desarrollo de Toodaim y los derechos de las imágenes a sus respectivos creadores.