Speak of the Cloud: Prólogo - Diario Dev 2

Este fin de semana tenemos bastante lío por asuntos personales, sin embargo hemos estado trabajando en un importante cambio a implementar la semana que viene antes de nada:

Vamos a aumentar la resolución nativa del juego, ya que tenemos todos los elementos a resoluciones bastante grandes, creemos factible para el cliente de windows, trabajar en una resolución mayor. Por ejemplo pongamos el personaje principal

Fenix realmente tiene una resolución base de 642 x 1483. Hasta ahora estabamos trabajando en un estandar de 720 pixels de alto de cámara, por lo que todos los elementos se redimensionaban a un 28% para meterlos al juego. Ahora vamos a trabajar al 50% de la resolución real de los elementos gráficos creados, lo que nos permite trabajar a 1080 (1920 x 1080 de resolución estandar).

Con este cambio, conseguiremos mejorar aún más la definición gráfica y aprovechar los recursos que tenemos para que se vea aún mejor el juego. El proceso se alargará durante unos días, pero los resultado creemos que seran buenos. Son resoluciones altas, pero tampoco hay demasiados elementos en pantalla por lo que aspiramos a funcionar a 60 frames constantes.

Seguiremos informando ;-)

Speak of the Cloud: Prólogo - Diario Dev 1

Bueno, esta semana tras recapitular y ver por donde empezamos a mejorar el juego, me he puesto a reprogramar el código del juego para adecuarlo y mejorarlo. Los dibujantes ya llevan varias semanas mejorando escenarios, y ya están empezando a preparar algunos nuevos para este prólogo.

Por resumiros un poco: Nos hemos dado cuenta que cada personaje es descrito por los objetos que acompaña su escenario. Simplemente observando los distintos objetos y decoración del escenario el jugador se puede hacer una idea de quién es. Esto nos funcionaba bien con el abuelo y con el Freak, sin embargo ¿Qué pasa con Fenix, el niño que controlas?

Para resolver esta cuestión hemos decidido aclararlo de la mejor forma posible: Fenix vive con su abuelo y tiene su propia habitación. Podrás entrar a ella y ver varios objetos personales suyos. Esto implica cambios en la distribución de objetos, (por ejemplo la mochila estará en su cuarto, no en el salón).

Ahora, hablando de programación, he comenzado a estructurar mejor el código, huyendo de variables globales para gestionar la trama de este capítulo, para así poder liberar memoria y hacer sitio para futuros capítulos, metiendo todas las variables de trama en un objeto persistente que durará mientras estés en este capítulo en concreto.

Sobre el control, hemos decidido seguir el ejemplo de los grandes y vamos a probar con un sistema de boton izquierdo/derecho del ratón para interactuar/observar, reduciendo las opciones de interacción a dos + uso de objetos. Nos gustaba el chiste de hablar con las cosas, pero tras 3 o 4 intentos la broma perdía gracia y era usar líneas repetidas continuamente. Además de esta forma reduciremos los clicks para jugar al juego a la mitad, sin esperas para que aparezcan las nubes de opciones. Estas nubes se mantendrán en ocasiones puntales para resolver puzles o cuando haya varias acciones disponibles, pero todo mucho más personalizado para cada ocasión: Por ejemplo, al usar el ascensor.

Ya iré mostrando cosillas, poco a poco el proyecto irá creciendo.

POSTMORTEM: Speak of the Cloud

Few days ago, Gamejolt organized the AdventureJam. We had only two weeks to develop a graphic adventure. However, this time we had some extra time to work in the plot and the script of the project. We base our game in a text written in times of college, called "The Cloud". Its target was to be a comic's script. A strange argument about a boy and his grandfather against an alien conspiration. The boy wanted to left the city but his grampa does not. Soon we had the title: Speak of the Cloud.

  ...

Hace bien poco se celebró la Adventure Jam organizada por Gamejolt. Dos semanas intensivas para desarrollar una aventura gráfica. Como en cualquier Jam hay una fecha de inicio y una de final. Sin embargo aquí se podía especular sobre temas de guión antes de comenzar. Y más nos valía. Porque cuadrar todas las situaciones se puede volver excesivamente complicado y farragoso.

Decidimos rescatar un texto escrito en tiempos de universidad que se llamaba La Nube, pretendía ser el guion de un cómic. Una extraña trama de conspiración alienígena en la que una pareja muy peculiar es el eje central de la acción. Un abuelo y su nieto sitiados en el ático del primero. El nieto, preocupado por la situación quiere salir de la ciudad. Pero el abuelo no quiere moverse de su piso. Dice que ha depositado demasiado esfuerzo a lo largo de su vida cómo para escapar de allí por un puñado de ovnis. Lo llamaríamos Speak of the Cloud.

Portada para el Banner de la Adventure Jam en Gamejolt

El germen de la historia estaba claro. Pero quedaba el trabajo duro. La importancia de los diálogos y de la acción es muy diferente a la hora de abordar un cómic que a la hora de abordar una aventura gráfica. Procuramos mantener la esencia del guion y buscamos situaciones divertidas de combinatoria de objetos y el ritmo de los escenarios.

Trazamos nuestro diagrama de flujo, donde cuadramos personajes, escenarios y situaciones lo mejor que pudimos. Elaboramos un listado de los diferentes elementos gráficos que necesitaríamos: personajes, escenas y objetos importantes. Además de otro listado para las animaciones necesarias, sonidos y música.

Lo teníamos. Una aventura gráfica con corte de conspiración alienígena y un objetivo muy claro: convencer a tu abuelo de abandonar su casa. Seis escenarios. Unos 18 objetos para resolver distintas situaciones. Y cuatro puzles que enseñaban distintas mecánicas y hacían más ameno el desarrollo de la acción distanciándote de una simple aventura conversacional. Aunque siempre surgen imprevistos.

Al comienzo de la Jam tocaba volcar todas las ideas dormidas, bocetos, bocetos y más bocetos.  Gracias a las vueltas que dimos al guion, surgieron rápido los primeros esbozos y diseños. El proyecto había crecido demasiado. Pero.. ¿Quién no puede en dos semanas?

Parte de los bocetos

Muestra de como se nos va de las manos. Falta mesa para más bocetos tras la cámara.

Escaneos, trazados, coloreado. Dividimos el trabajo a nivel gráfico. Una vez los diseños de personajes estaban solucionados. Sindarta Monleón los dividió en piezas para que fueran animables. Mientras ella hacía el trabajo pesado de articular todas sus piezas Eduardo Pérez  se encargaba de delinear y pintar escenarios.

Fuimos normalizando el ritmo de trabajo. Y enviando lo más rápido posible los esbozos de escenarios  y personajes a Javier Martínez (javifugitivo) para que pudiera trabajar en la programación mientras terminábamos. Mucha comida basura para no perder ni un solo minuto y muchas horas delante de las pantallas dieron lugar al resultado que veis. No nos podemos olvidar de nuestro músico, Felix Herrero, que se volcó sobre todo en la grabación de efectos de sonido y de las voces en ruso, que contribuyeron a darle un toque único a las conversaciones.

Capturas del prototipo realizado para la Adventure Jam

Esto no podría ser un Post Mortem si no comentaramos también lo peor y lo mejor del proyecto:

LO MEJOR: Ha sido un primer contacto con el género de las Aventuras Gráficas como estudio, por lo que hemos podido crear una base sólida para ampliar el juego y sin apenas bugs importantes. Hemos creado sistemas de inventario, conversaciones, movimiento, animaciones coordinadas, etc. Por otro lado ha sid también nuestro primer juego en Alta Resolución y ciertamente nos hemos sorprendido del rendimiento que hemos conseguido a una resolución similar a la de la PS3 (720p).

LO PEOR: Lo de siempre. La falta de tiempo para terminar el juego tal comonos habría gustado. Podríamos deciros que teníamos al menos 3 grandes puzles diseñados a pantalla completa que hubieran podido agilizar y amenizar la trama a parte de dar más variedad al proyecto. Además sólo nos ha dado tiempo a implementar el 35% de la trama para este capítulo "Prólogo". Finalmente, unos pocos bugs aislados han perjudicado la jugabilidad a algunos usuarios, pero es comprensible, al no haber tenido apenas tiempo de testeo.

A MEJORAR: Todos los aspectos prácticamente, desde los gráficos, al interfaz, el guión, la estética, la navegabilidad, la (ausencia de) música, sonidos, etc.


Y AHORA QUÉ: Ahora estamos ya manos a la obra, haciendo balance de los puntos fuertes y los puntos débiles de Speak of the Cloud para trabajar en terminar lo que teníamos planeado, y no solo eso, sino también mejorar lo presente. ¿Qué quiere decir esto? Que estamos trabajando ya en una mejora gráfica sustancial, en nuevas conversaciones, puzles y pequeños arreglos de trama para cerrar y dejar mucho más redondo todo el argumento, además de mejorar la jugabilidad. Es decir, terminar este "prólogo" al 100%.

Esperamos que lo disfrutéis. Podéis entrar a jugar Speak of the Cloud en Gamejolt. O si preferís una versión más trabajada para darnos vuestro feedback para mejorarlo, entrad a través de este link de control de versiones. Además si hemos conseguido contagiaros la ilusión sobre el proyecto despues de jugarlo podéis entrar para puntuarlo aquí.

Diario Dev: Adventure Jam Project

Work in progress

We are working in our new game for the Adventure Jam. We will control Fenix, a boy with a huge problem: A giant cloud have appeared in the sky and there are UFOS over their building! His mission will be to escape with his grandfather. But nothing is simple or easy. Fenix has to think a lot, resolve puzzles and find help to escape of the menace. This screenshot show one of the first stages that you will be able to find in the game.

 .................................

Estamos trabajando a tope en nuestro nuevo juego para la Adventure Jam. En él controlaremos a Fenix, un niño con un gran problema: Una nube gigante ha aparecido en el cielo y hay Ovnis rondando la terraza del edificio. Su misión será escapar con su abuelo. Pero nada es simple o fácil. Fenix tendrá que pensar mucho, resolver puzles y encontrar ayuda para escapar de la amenaza. En la imagen se muestra uno de los primeros escenarios que podrás encontrar en el juego.

Aún nos queda mucho por hacer, pero una vez más os presentaremos al equipo y lo que estamos haciendo en estos momentos.

Edu Pérez: Está trabajando duro pintando los escenarios del juego, organizándolos por capas y separando los objetos y partes que serán interactuables. Cada escenario está creándose a una escala increible. Este escenario por ejemplo mide 8858 x 2598 píxeles, que luego reduciremos para poder usarlo en el juego.

Sindarta M.H: Está varias noches sin dormir, creando los personajes de la historia totalmente despiezados para más tarde animarlos. Cada personaje está siendo creado con mucho mimo sin descuidar el tiempo. Tenemos tiempo limitado, pero queremos que todo quede lo mejor posible.

Félix Herrero: Hemos hecho una gran inversión con la compra de equipos de sonido y de composición para que nuestro músico pueda trabajar a gusto y entre algodones. Félix es el encargado de darle vida al ambiente del juego. A día de hoy está trabajando en efectos sonoros para completar toda la parte gráfica, además de una sorpresa relativa a las conversaciones que les dará un toque increible.

Javi Martínez: El programador del proyecto está enfrascado en la creación de la base de interacción con los objetos y personajes. El personaje ya se mueve y cambia de escala conforme se acerca o se aleja de cámara, pero ahora toca dinamizarlo con animaciones y enseñándole a usar objetos, recogerlos y hablar con personas. Es un trabajo duro, ¡pero valdrá la pena si terminamos a tiempo!

¡Esto es todo por hoy, seguiremos informando!

Hablemos de Shaders (para novatos)

Como muchos bien sabeis, en Mechanic Moon Studio trabajamos principalmente con el programa Game Maker Studio. Durante el último mes hemos estado investigando sobre características a implementar en nuestros próximos proyectos. Una de ellas, a la que hemos querido nunca renunciar, han sido los Shaders.

¿Qué son los Shaders? A todos nos sonará en los reportajes sobre juegos los términos shaders de iluminación, efectos o quizás en los requisitos técnicos: Requerida Tarjeta Gráfica con Pixel Shader 4.0.

Digamos que los Shaders son operaciones que hace la GPU (el procesador de la tarjeta gráfica) con las imágenes y elementos que tiene en pantalla. En plan resumido, cuando se aplica un shader a una imagen sea 2D o 3D, la imagen pasa a aplanarse y a convertirse en cientos de triangulos, guardando sus posiciones, profundidad, colores, etc. Seguidamente se convierten a píxeles y ahí empieza el trabajo del sistema de shaders.

Normalmente los sistemas de shaders hacen diversas pruebas para comprobar qué deben dibujar en pantalla y así ahorrar trabajo a la GPU:

- Todo elemento fuera de pantalla no se tiene en cuenta.

- Elementos demasiado alejados de la "cámara" tampoco se tienen en cuenta.

- Elementos que están tapados completamente por otros elementos, tampoco se dibujan.

- Elementos que están parcialmente tapados o parcialmente fuera de pantalla, se dividen y se tiene en cuenta sólo lo que se ve por la cámara.

Cómo podréis imaginar, al aplicar estas reglas, la carga gráfica y cantidad de información que debe calcular la GPU con su motor de shader se reduce drásticamente, además nada de esto lo gestiona la CPU (el procesador de la placa base). Ahora bien, ¿Qué puede hacer un shader?

Un sistema de shaders realmente hace pocas cosas, pero con esas pocas operaciones se pueden conseguir muchísimos efectos. Simplificando, las operaciones más comunes que se hacen, pixel a pixel son:

- Transformar el pixel (Escalarlo o rotarlo)

- Cambiar su opacidad / color / brillo / contraste

- Cambiarlo de posición

Con sólo estas pocas operaciones ya podemos hacer efectos de filtro encima de la imagen, efectos de ondulación para simular que algo está debajo del agua y mil cosas más, entre ellas, efectos de iluminación. Para muchos de estos efectos, además, el motor de Shader usa otras texturas de apoyo para controlar cómo afecta o refleja la luz cada objeto. Por ejemplo: Mapas de Normals, Specular, Diff, Depth, etc.

SU USO EN GAME MAKER STUDIO

Para nuestros proyectos, vamos a utilizar un Shader preparado para crear una iluminación realista a la imagen. Otros sistemas anteriores de iluminación en Game Maker, usaban sistemas basados en Surfaces. Dichos sistemas consumían demasiado rendimiento del CPU y entonces no eran factibles para el desarrollo de un juego comercial. Al usar un sistema de Shaders, liberamos memoria a la CPU y cargamos esos cálculos a la GPU, normalmente más liberada, ya que los Shaders, digamos que van al final del proceso de cada frame dibujado en pantalla.

Este sistema lo hemos estado editando durante varias semanas y hemos conseguido que funcione en Android. Sin embargo al ser un proyecto en 2D necesitamos algo que nos permita utilizar toda la potencia del sistema, dando profundidad a nuestros sprites. Para ello hemos apoyado una excelente herramienta en Kickstarter: Sprite DLight

Este programa (que ya  hemos probado en versión Alpha como buenos backers que somos) nos permite crear mapas de Normals y Speculars para nuestros sprites pixelados y sin profundidad. No me entretendré mucho en explicaros esta parte, pero gracias a esta inestimable ayuda vamos a poder dar profundidad a nuestros personajes y escenarios de forma dinámica, decidiendo cómo queremos que les afecte la luz, influyendo la distancia a la fuente de luz o su ángulo.

Os recomendamos que sigais este proyecto ya que es muy prometedor y necesitan también vuestro apoyo para entrar en Steam: Sprite DLight en Steam GreenLight.

Dicho programa es compatible también con Unity 3d y otros programas de desarrollo web, por lo que es una forma rápida y semi-automática de generar mapas de normales y speculars para ir trabajando y mejorando vuestros proyectos con el uso de shaders.

 Como conclusión os comento que nuestro proyecto "Fire Tactics" usará Sprite DLight para aplicar los shaders en Game Maker Studio. Por nuestra parte, el descubrimiento y dominio de estos nuevos "juguetes" nos permitirá trabajar la ambientación de nuestros proyectos con más mimo y conseguir resultados (esperamos) más espectaculares.

Juegos para móviles: ¿Es posible triunfar con algo diferente?

Comienza el año, tras las resacas invernales, y no dejo de darle vueltas a la cabeza sobre las posibilidades de éxito lanzando juegos para móviles. Está claro que como estudio, nuestro próximo juego queremos que sea para smartphone, pero leer noticias como la concerniente a Monument Valley, pone los pelos de punta. Pongámonos en antecedentes.

Monument Valley es un videojuego hecho obra de arte creada en Unity, que fue lanzada el año pasado en Iphone y posteriomente en sistemas Android. En el juego llevas a un personaje por escenarios tridimensionales, por los caminos establecidos, no tanto por la lógica y la gravedad, como por los caminos visuales. Al cambiar la perspectiva de la cámara, se producen ilusiones visuales que abren nuevos caminos. Hay que jugarlo para maravillarse.

Digamos que este juego en cuestión es un juego de culto. A la vieja usanza. No tiene micropagos, no requiere conexión a internet permanente y es un concepto de juego original con un único defecto: Excesivamente corto. Es un juego de pago, no es gratuito. Durante muchos meses ha estado en las listas de Android como uno de los juegos más vendidos. Sin embargo.. hoy leo esta noticia:

" Sólo el 5% de los jugadores de Monument Valley en Android compraron el juego. "

Realmente es un panorama desolador. Un juegazo indie como éste, teniendo un éxito increible, pero que debería ser muchísimo más grande en conceptos de beneficios para el desarrollador. Pero si le damos la vuelta a la tortilla y leemos sobre los juegos gratuitos con micropagos:

"Sólo el 5% de los jugadores gastan dinero real en juegos con micropagos". Otra patada en la boca. Es imposible triunfar sino eres un Rovio o un King, teniendo índices tan bajos de compra. Puedes tener muchos jugadores, pero conseguir que realmente consigas vivir desarrollando videojuegos sigue siendo igual de complicado. Conozco gente que odia los juegos con micropagos, pero que nunca ha comprado nada en Google Play. Digamos que es el pez que se muerde la cola. No se pueden hacer desarrollos exclusivos de juegos buenos, sabiendo que nadie los va a comprar.

En Iphone e Ipad sin embargo el panorama es distinto. Sobre un 40% de los jugadores compraron Monument Valley, e incluso han tenido de forma gratuita una expansión con nuevos niveles. Pero la base de usuarios de Iphone respecto a sistemas Android también está bajando (la cuota de mercado del sistema de google está creciendo año tras año).

El tercero en discordia es Windows Phone. Una tienda pequeña, pocos usuarios, pero con poca competencia. He leído artículos sobre juegos vendiendo 1000-2000 unidades mensuales, estando los desarrolladores sumamente contentos.

¿Cúal es el camino a seguir entonces? ¿Se puede hacer algo diferente? ¿Toca adaptarse a los nuevos tiempos y caer en la red de los juegos gratuitos con micropagos? Son preguntas que nos hacemos y que esperamos poder responder con alternativas que sobre todo beneficien al jugador y que nos permitan seguir soñando, creando juegos, aquí en Mechanic Moon.

Fuente: http://www.joystiq.com/2015/01/06/monument-valley-dev-5-of-android-players-paid-to-play/

Fire Tactics LD31: Post Mortem

Faltan pocos días para que salgan los resultados de la Ludum Dare 31. Una de las apuestas en esta edición del concurso, fue la que llevamos a cabo, pensando en ella como un pequeño experimento.

Fire Tactics aparece como una idea sencilla y un handicap enorme a la hora de empezar a programarlo: Son las 18:00 de la tarde y quedan unas 30 horas para entregarlo. El juego no tienen nada creado, únicamente la idea general de la Jam: Todo el juego debe ser una pantalla.

Dándole vueltas a la cabeza se nos ocurrió un juego de bomberos. Queríamos que tuvieras que apagar un fuego, con vista cenital. Además para darle vida al asunto pensamos en tres pilares básicos:

- Juego en equipo
- Expansión del fuego
- Control totalmente táctil.

Entrada LD31 Fire Tactics

El resultado, por tanto podeis verlo en el enlace superior. El juego empieza con una serie de incendios en el mismo escenario que aparecen esporádicamente. El objetivo es sencillo: Apagar el fuego y sobrevivir todo el tiempo posible. No había tiempo para más, sin embargo quedamos muy contentos con el resultado a pesar de los fallos y de los (fallidos) controles.

Gracias a la ayuda de los dibujantes Edu Perez y Sinda MH, pudimos darle un toque de calidad importante con multitud de objetos para decorar el escenario. El uso de un filtro ayudó a crear el ambiente y hubo muchos factores que ayudaron a que el proyecto creciera hasta conseguir una identidad por sí mismo. Aquí os mostramos algunos pasos de la evolución del juego, bastante curiosos:

Cómo podéis comprobar, la evolución gráfica es patente. Desde los iconos de los personajes, cambiados por retratos más caracterizados, hasta el fuego o los efectos de agua y sobre todo el escenario, constatan una evolución bastante afortunada en la parte gráfica.

Ahora os hablaremos de tres conclusiones básicas en todo Post Mortem que se precie:

Lo bueno:

- El haber conseguido un juego original de estrategia en tiempo real bastante distinto a proyectos anteriores en muy poco tiempo. Poco a poco como equipo hemos aprendido a gestionar mejor los tiempos y a saber qué cosas se pueden hacer y qué cosas no. Sobre todo a priorizar elementos tanto de programación como de gráficos. En concursos hay que conseguir una calidad mínima. No hablo de florituras, sino que hay que saber encontrar el equilibrio entre jugabilidad y presentación.

- Gracias a una correcta gestión de tiempos, conseguimos meter varios elementos indispensables para un juego de Jam: Un control de volumen, un tutorial y una versión en Html5. En una jam es muy difícil, pero controlar el rendimiento en todo momento, aprender de errores anteriores y  presentar el juego bien, son objetivos que se cumplieron a la perfección.

Lo malo:

- El haber tenido poco tiempo nos dejó cojos en algunos aspectos que habría valido la pena investigar. La generación de fuegos es bastante prefijada, y aunque se crean aleatoriamente por varios contadores de tiempo, no conseguimos que la dificultad escriptada fuera en aumento. El calibrar la dificultad y conseguir que sea un reto y no un paseo, es una de las cosas más complicadas del diseño de videojuegos. Con unas cuantas horas más por delante. La jugabilidad habría quedado mucho más redonda. Si valoramos este proyecto como prototipo, vale. Pero como juego completo, tiene potencial, pero hay que limarlo y pulirlo para sacarle partido.

A mejorar:

- Siempre se puede mejorar. Tuvimos problemas con el sonido (cómo siempre). La música no molesta, pero tampoco destaca. El sonido de la manguera es bastante cargante, aunque el del fuego quedó bastante bien. En futuras ocasiones hay que trabajar mejor con distintos ordenadores y altavoces para conseguir un mejor equilibrio en los volumenes de los sonidos y mejorar su calidad. Sigue siendo nuestra asignatura pendiente y esperamos para el año que viene, solventar los distintos problemas que hasta ahora hemos tenido.

- La programación. A pesar de ser un resultado bastante complaciente, sí que existen diversos bugs, al recoger la manguera, al andar demasiado o con el control de los bomberos. Al estar rodeados por el incendio, es prácticamente imposible escapar, habiendo poco feedback sobre la bajada de la "vida" de cada bombero. En esta ocasión no arriesgamos mucho inventando códigos imposibles, pero sí que había un fallo importante que fue imposible de solventar en el poco tiempo disponible. Hay que pulir mejor el código para asegurar una experiencia positiva para el jugador.

¿Y ahora qué?

Work in Progress

Ahora, a esperar las votaciones. Sin embargo, desde Mechanic Moon os transmitimos que hemos acabado bastante satisfechos con Fire Tactics. Es un juego bastante sencillo en su tema: Apagar incendios. Por eso mismo vemos que puede ser un juego muy interesante para desarrollar más en profundidad, siempre que no pierda su esencia. Debido a esta convicción, estamos trabajando en un nuevo prototipo cogiendo lo mejor del juego y puliendo los aspectos más flojos del mismo en vistas a un lanzamiento a 2015.

 ¿Qué tendrá esta nueva versión?

En este blog y vía redes sociales, a partir de Enero empezaremos una serie de diarios de desarrollo en los que comentaremos todos los aspectos que mantendremos, mejoraremos y sobre los que estamos trabajando, para que la experiencia sea óptima. Pero puedes esperar muchísimas novedades:

- Escenarios variados y de mayor tamaño.
- Control mejorado y simplificado.
- Nuevas mecánicas y tipos de incendio.
- Niveles de puzle y de supervivencia.
- Funciones online (¡Sin confirmar pero lo intentaremos!)
- Rescate de heridos y de ¡gatitos!
- Rendimiento mejorado y nuevos efectos gráficos.
- Y mucho más...
 

Fire Tactics volverá con fuerza.. en 2015