Grasancrem 2: The Game

1024

Vamos a empezar con la inspiración, pero todos sabemos que una imágen dice más que mil palabras, entonces un video debería hablar por sí solo:

Con tan solo el guión de este cortometraje y un deadtime bastante ajustado, teníamos que hacer un videojuego simple y entretenido.

Convocados por Mattu Rock (BuenoDale!Films, productor) trabajé junto a Mauricio Navajas (3OGS, administrador), Sebastian Lujan (Cumulus3D, artista gráfico), Ariel Contreras(se enoja si no pongo el guionsito)-Esquivel y Melisa Stasiask (OstrichSound, Música y Sonido) y Juan Pablo Zalazar (GameDesignDocuments), y mi trabajo (Emmanuel (con 2 «m») Cesar Rubio (Héroes Estudios, Programador (see)))

La convocatoria tenía el objetivo de crear en este poco tiempo un videojuego para promocionar el Cortometraje del afamado Grasancrem, en el estreno de su segundo capítulo.

11076814_652423004902490_115245833292654039_oTécnicamente fue sencillo, debido a que eramos un equipo bastante experimentado en cada área y  dejaron en nuestras manos el desarrollo completo. Con esto me refiero que por un lado trabajamos despegados del progreso del corto, por otra parte el juego se terminó con tiempo justo, estando testeado y confirmado para el estreno en el Cabildo de Córdoba el 26 de Marzo.

Lamentablemente no pude asistir al estreno en el Cabildo, porque me encontraba en Buenos Aires participando del MICA (Mercado De Industrias Culturales Argentinas) como representante de Videojuegos Centro. Pero fue inevitable enterarme del tremendo impacto que tuvo cuando el servidor del juego me advirtió de estar por superar los límites de descargas. En menos de 6 horas hubo cerca de 2000 jugadores.

El desarrollo del juego fue simple: Dividimos las tareas con tiempos de entrega. Si bien Ariel y Melisa entraron un poco más tarde, pudimos ajustarnos tranquilamente.

Este devlog lo enfocaré en esto: las tareas DIVIDIDAS, el trabajo en un equipo de corazón, es decir, cada uno a su ritmo pero teniendo en cuenta las pautas y progreso de los demás. Lo curioso de trabajar con videojuegos, es lograr la sinergia entre las partes. Un trabajo de muchos núcleos al mismo tiempo.

Organización

lineamiento
Lineamientos generales, ideas, referencias, etc..

Sabiendo que ninguno podría reunirse muy seguido, y que como en mi caso soy de una ciudad distante, estuvo claro que la primera reunión y acordar encuentros por skype era primordial. Si fuéramos todos del mismo estudio o trabajáramos más cerca, sería más fácil controlar el progreso, pero no era el caso, así que herramientas como Google Drive y documentos bastante seguido nos ayudaron a solventar estas distancias.

Estos documentos no se quedaban en tan solo «es lo que yo establezco», eran documentos editables para todos y donde cualquiera podía agregar su granito de arena. Todos podíamos opinar, agregar, sacar y acomodar, siempre y cuando respetemos al anterior, agregando notas como quién escribe qué.

De esto, Diseñador y Programador nos ponemos de acuerdo para tomar solo lo más importante y avanzar.

Gráficos y Programación

Dibujo sin título
Mi versión de la visión sin prestar mucha atención en el arte (sion).

Un ejemplo claro de trabajo de corazón, es el programador y el artista. Mientras yo programaba no necesitaba las artes (como se ve claramente en la imagen 1). Pero de por sí, ya estaba marcando áreas que el artista debería respetar (más que nada proporciones, es decir por ejemplo, el tamaño de la cabeza) pero que con un mensaje por facebook alcanzaba y no necesitábamos una reunión nueva para estos detalles.

REferencia
Imagen solo de concepto, de aquí se discutió el cómo lograr que el juego se vea así.

Por otro lado, mi trabajo de programador, no es el de diseñador, el primer paso, despegado del resto, fue poner de acuerdo la mecánica básica del juego. Con esto definido, yo no necesito esperar más datos ni del diseñador ni del artista, poniendo manos a la obra para lograr los objetivos más fijos y claros (disparos, movimientos, puntaje y armado de los personajes).

De la misma forma el artista ya estaba trabajando en un concepto de cómo debería verse la estética del juego, como se puede ver en las dos imágenes, la comunicación fue bastante buena ya que ambos veíamos un mismo juego (nada más que el mio no tenía placa de video xD)

Música y Sonido

Ostrich Orchestra
Ostrich Orchestra

Este es un apartado realmente particular. Para empezar hay que entender que en la música y en los sonidos también existen los bocetos. El juego comenzó con bocetos, con ideas, con conceptos de lo que queríamos escuchar mientras se jugaba.

A partir de allí, Ariel tomó su barita mágica y comenzó con las primeras líneas de lo que sería la música. A la par, Melisa tiraba distintas posibilidades para los numerosos sonidos que se producen durante el juego, pero todos con la aclaración que son bocetos.

Es un trabajo igual que todas las otras ramas que tomó su tiempo y una de las que llegó a terminarse con el tiempo límite.

Como consejo a los desarrolladores, nunca se olviden de hacer jugar a algún músico o sonidista, para que encuentre y te ajuste desde el volumen hasta los tiempos de cuando y donde se debe escuchar algo, quizá el error más común que pasa es tomar todo y ponerlo uno sobre el otro (porque normalmente lo acomoda el programador) y que por hacer un alfajor de audio nos perdemos de la torta.

 Testing

IMG-20150314-WA0000
glitches? donde?

La parte de testeos fue constante. Cada nuevo ajuste se subía, la suerte de que construct permite literalmente hacerlo funcionar apenas se sube ayudaba bastante. Descubriendo así limites y problemas en cada plataforma que lo probábamos. Así salieron errores muy graciosos como personajes violando a grasancrem pero no perdiendo, glitches gráficos catastróficos inexplicables, problemas de sincronía, etc… Pero nada realmente que nos detuviera, gracias a los CONSTANTES TESTEOS. Siempre habrá un error, siempre, jamás será perfecto, pero al menos en un 80% de los dispositivos que lo jugaran andaría bien, y así fue.

El testeo estuvo a cargo de nosotros mismos, siendo tantos, aprovechamos, en algunos casos se mostró a otras personas (versiones más pulidas) para ver reacciones o destacar la dificultad.

 Encontronazos y Diferencias personales

fullscream
Siempre teníamos un documento donde anotar los detalles que cada uno encontraba o quería aportar.

Si fuéramos todos clones sería perfecto, y más si fueran todos clones míos (?), pero las diferencias existen, la importancia es aprender que a veces esas visiones diferentes son las que dan el toque final o hacen que algo se vea mejor de lo que uno cree que está.

Como dije antes, siempre habrá correcciones. Siempre habrá algo para agregar. Pero el tiempo sigue siendo el mismo, o menos, raramente tenemos más.

Aprender a escuchar no es decir «sí a todo», es entender que hay algo que esa otra persona está mirando y nosotros no. Valorar cuan importante es cada detalle que las otras personas ven, tampoco es decisión nuestra, sino del equipo. Nosotros (cualquier área no estoy hablando del programador) podemos decidir únicamente cuando el tiempo se acaba, o cuando eso conlleva REALMENTE a un problema mayor, que esas otras personas no ven.

El resultado

¿Para qué contarlo si podes jugarlo?

480
CLICK PARA JUGAR

Adelante, Héroes! Comenten sus puntajes, sus dudas, sus críticas!


Vistas: 3172

Apolo Vs The Sun Part1

10259945_304214656369997_2835325278273842766_nIntroducción

Voy a reconstruir un videojuego que hice el año pasado, por completo, en este caso es el turno del viejo  «La desesperación de Apolo». Este juego no me gusta como está, en casi ningún aspecto, pero tengo la sensación que el gameplay, la simple mecánica, se puede explotar.

Por ello, junté un equipo de desarrollo pequeño para reconstruirlo y empezarlo de nuevo. El grupo encarado por «Goat Mengot Home» (el jugador que encontró todas las roturas del juego) va a ser las voces, Martin Oddino, será el músico y compositor, Ema Zen el artísta gráfico y seguimos abiertos a sumar otras personas dependiendo como avance el proyecto, pero el tiempo limite que me autoimpongo es inicios de marzo, quede como quede, publicarlo y seguir al siguiente proyecto…

Backstory

pulmonear3_leyendas_y_simetriaHace unos años atrás, en la comunidad de la página oficial de Duval (ahora conocida por el gigantesco grupo de Facebook), organizaban un pequeño concurso de creación de videojuegos, siempre quise participar pero no tenía ni la experiencia ni el tiempo, pero justamente por esas razones decidí participar en la última que tuvieron.

En este último concurso la temática para trabajar nuestros juegos debía ser «Leyendas y Simetría». Me gustaron los temas y necesitaba un reto, algo que me ponga a prueba, algo que me inspire a estudiar nuevamente programación. Por aquel entonces estaba en el proceso de pasarme del lenguaje de Gemix (un excelente pseudo codigo enfocado en la programación de videojuegos, basado en el antiguo y amado DIV Game Studio) a Construct2 (un engine de creación de juegos 2d en html5, con una larga historia y una comunidad inmensa).

La razón de este pasaje de lenguajes es que veía a Gemix cada vez más distante de mis objetivos y a Construct2 más fácil y creciente. Así que este concurso de Pulmonear sería mi primera puesta a prueba con el engine.

Con el objetivo de crear un juego, sencillo basado en «Leyendas y Simetría», quería poner a prueba el nuevo engine, pero justamente, un juego sencillo no era suficiente, por lo que me autoapliqué una nueva condición y era «Publicado en Facebook con Highscores».

Ya estaba mentalizado. Ahora bien, el juego. No quería hacer algo tan raro, ya que realmente no era mi objetivo ser muy original sino poder aplicar tooooodas las propiedades que pudiera darme el construct2. Toqueteando tres o cuatro «Behaviours» (es una forma de decir scripts en construct), logré que un sprite diera vueltas y vueltas y vueltas al rededor de un punto, atados por una distancia y persiguiendo al mismo tiempo mi mouse… bastante impresionante considerando que apenas tenía lineas de código y no me esforcé en nada… Pero de allí en más faltaba mucho para un videojuego.

Apollo_disney_4La simetría era obvia en este caso, los círculos, girar y girar, tratar de mantener el equilibrio de algo que debe girar al rededor de otra cosa o perder, como el ying y el yang o… el SOL! 😀 bueno ya vamos por buen camino, ¿leyendas del sol? justamente unos pocos días antes, había visto (por decimocuarta vez) la película de disney Hércules, el cual recordé que tenía una serie de dibujos animados hacía mucho tiempo, del cual recordé un capitulo 😀 el capítulo en el que salía Apolo y su poderosa carroza tirando el sol al rededor del mundo… el cual por giros de la historia del capítulo hercules trata de hacer lo mismo pero se quemaba con el sol… bueno…

No tenía tiempo ni gráficos para hacer todo en hércules con tanta historia que explicar, por lo que decidí reducirlo: Apolo escapa del sol, el sol trata de alcanzar a Apolo, si Apolo no gira al rededor de la tierra el Sol se lo come… bueno, ya tenía el «Argumento» mi «Leyenda y Simetría»…

Desarrollo

Clipboard02 En este caso no pasé tanto tiempo por el papel y lápiz, ya que estaba experimentando con construct2. Esto te sirva de advertencia lector, que si no haces una buena planificación en papel y lápiz, tan solo estas experimentando y los experimentos pueden terminar como terminó este juego: Lleno de huecos.

Los límites de la versión gratuita de Construct2 eran más que suficientes para hacer el juego completo en aquel entonces. Para aprovechar lo mejor posible ese límite de lineas de código (o Events, como se llama en construct2), hice mucho uso de los behaviours, estos concatenados le dan a construct un poder interesante al momento de prototipar juegos.

3º Mucho testing: Este juego, al estar haciéndolo al «ring raje» (una forma de decir a tocar y ver que pasa y salir corriendo por no saber qué pasa), requirió de una absurda cantidad de testeo, constante. Lo más difícil en este juego simple, fue coordinar correctamente los clicks con el movimiento constante de «la Carroza».

4º Gráficas, los gráficos quise hacerlos lo más minimalista posible, pero entre que no sabía y no quería gastarme en gráficos, terminé haciendo una suerte de monedas que escapan de pelotas :P.

El éxito!
El éxito!

5º Publicado en Facebook, aquí vino el terror, resulta que en aquel entonces, facebook era bastaaaante restrictivo con los juegos que podías publicar, hoy incluso tiene algunas restricciones algo duras (por ejemplo debe estar publicado en una web con SSL, HTMLS) lo cual es costoso y no muy práctico para quien solo está probando un engine.

Hoy en día por suerte se «ablandaron» un poco y permiten que uses todas las funciones pasando por una prueba.

Para empezar, publiqué el juego como una aplicación (ya que si decía que era un Juego, te caían con todas las restricciones, pero por alguna razón las aplicaciones no lo tenían). Hoy podes hacerlo directamente como juego.

También en aquel entonces te obligaban a crear una página en fácebook, lo cual hoy ya no hace falta. Podes simplemente usar tu propia web o no tener web (si se trata de una aplicación de android por ejemplo).
El tema es que renegué mucho, fue bastante difícil hasta que encontré los «botones adecuados», también me enteré de limites en el uso de Facebook con Construct2 por ejemplo para las aplicaciones de android, que por suerte hoy en día también están solucionados 😛

Tips And Tricks:

Facebook:

Hace menos de un año se veía mucho más amenazante...
Hace menos de un año se veía mucho más amenazante…

La parte que más les interesa a quienes llegaron hasta aquí es los pasos a seguir para publicar, pues les digo que es más fácil de lo que parece, en primera instancia deben estar en la developers zone de facebook. De allí van a «My Apps y Create new App» Aquí encontrarán una serie de pasos a seguir que son extremadamente sencillos.
1 Cómo les dije antes, no hace falta seguir toooodos los pasos, una vez creada la «app» de face, vas a las configuraciones y le entregas los datos que piden, el más curioso es el de copiar el App ID y App Secret, que tus juegos deben tener en sus configuraciones del codigo de face (en construct es en el plugin facebook, que tenes para rellenar esos datos).
2 Luego el Setting, donde colocas ¿dónde se juega? (recuerda que «app domain» es el dominio principal, no la dirección al juego), ya con eso alcanza.
3 Si querés usar por ejemplo los Highscores de facebook o la lista de amigos de face, vas a tener que ir a «App Details» y completar todo TODO HASTA LOS ICONOS E IMÁGENES, el vídeo es el único que no hace falta. Luego en «App Center Permisions» elegir los permisos que vas a usar por ejemplo user_friends o user_game_activities.
4 Finalmente, vas a «Status & Review», lo activas y lo mandas a Items in review (aquí sigues los pasos, completas todas las preguntas, vas a necesitar más screenshots y tratar de ser lo más claro posible porque son bastante idiotas difíciles de convencer. Pero en un día recibís la respuesta y vas ajustando según te indican 🙂

La clave de los behaviours de construct:

es aprender a combinarlos, aprender que un «bullet» no necesariamente es una bala de disparo, sino que puede ser por ejemplo, un simple empujón del ultimo eslabón de cadena, que sumado a un «Pin», puede generar un tironéo interesante parecido a una cadena tirando de un caballo.

El tiempo refleja vida

Así como la combinación es la clave de construct2, en la programación de videojuegos que quieran dar una sensación de vida, no importa donde lo hagas, la clave es y será siempre «Timers», tiempos, un cuidadoso acomodo de DONDE, CUANDO y POR CUANTO TIEMPO. Programar el aparecer o suceder, frecuencias, secuencias, consecuencias y movimientos cíclicos, sinuosos o simplemente moverse un poco. Un ejemplo: en un juego por turnos programar un timer que haga hacer un suspiro al personaje cada 5 segundos, pare recordarle al jugador que la pantalla no está congelada y que su personaje está vivo.

50 Shaders of genius

be

A esto no hay que olvidarse de los Effects, conocidos como «Shaders» en lenguajes 3D, que existen en photoshop también como «Modos de fusión» en las capas. Los Effects o shaders, es una ecuación matemática compleja usando colores y pixeles, que provoca distorsiones en el resultado los pixeles, de una imagen completa o de lo que vemos en tiempo real, así pues por ejemplo un circulo celeste + Effect «Brillo» + fondo negro con poco porcentaje de azul muy bajo, genera un curioso efecto de «noche y día», sin hacer dos imágenes y le da vida.

El tema es simplemente «probar», porque lamentablemente este tipo de efectos especiales requieren cierta compatibilidad, en muchos casos también depende donde se van a ver, por ejemplo muchos de los effects de construct no van a poderse ver en exploradores des actualizados o androids viejos.

Continuará…

Debido a que tengo todo un mes para desarrollar la nueva versión, dejaré hasta aquí lo que fue la vieja versión, en el próximo capitulo entraremos a repasar el codigo y mejorarlo con la experiencia que tengo actualmente y la orientación que le daremos al juego.

Así que nos vemos próximamente, Adelante, héroes!


Vistas: 288