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.
Té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
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
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.
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
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
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
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?
Adelante, Héroes! Comenten sus puntajes, sus dudas, sus críticas!
Vistas: 3595