Adios 2016 – ¡Hola 2017!

Cierro la última entrada del 2016 con un par de palabras de agradecimiento para todas aquellas personas que nos apoyaron mientras nos adentramos en este proyecto.

Que jugaron la pequeña demo que hicimos, que respondieron encuestas y nos dejaron sus comentarios; que fueron a las presentaciones internas, que preguntaron sobre cuánto, cuánto faltaba para que el juego saliera, que se atrevieron a dejar su comentario en el blog o que van tweet tras re-tweet por ahí, que se acercaron en algún momento a ver por encima de nuestros hombros a ver qué había en el monitor, que nos daban sugerencias sobre cómo resolver el targeting, o el movimiento parabólico, o la supervivencia; que se ofrecieron a colaborar con x temas que tenemos aún por resolver y que no tenemos idea cómo, que preguntaron cómo estaba yendo todo y que, sin ellos saberlo, servía de respiro entre tantos cómo, cómo, AGH CÓMO vamos a implementar eso; a todos los que nos dijeron, cuando estábamos por entrar a una reunión de seguimiento, “ya ya, seguro que todo saldrá bien”…

Gracias.

Y especialmente a Carlos, Gabriel, Dani, Marc, Manel, Cárdaba, Rubén y Albert.  Respect. 

“Porque la fortaleza de la manada es el lobo, y la fortaleza del lobo es la manada.” – Kipling.

Hacia un espectacular 2017.

V.

¡Aciertos, aciertos, aciertos!

Siguiendo con los posts de reflexiones, quiero aprovechar la última entrada (larga) del 2016 para señalar las cosas que hicimos bien, (dándonos unas palmaditas en la espalda a nosotros mismos, claro está) y que quede también como registro. Si debemos aprender a apreciar los fallos, también debemos darle valor las veces que la hemos acertado.

Aquí vamos…

Acierto Número 1: Hitos 

That’s how you devour a whale, Doug, one bite at a time… – Frank Underwood

Desde el día, no sé, -40, cuando estábamos en fase incipiente y no teníamos idea de qué queríamos hacer (y ni siquiera sabíamos si podríamos hacerlo), hemos tenido esta mentalidad Orientada a Objetivos. Aún cuando Sticks & Stones ni siquiera se llamaba Sticks & Stones, sino JalapeñoTV, hablábamos de trabajar en capas, de hacer iteraciones. Primero  una cosa, luego la siguiente, luego la siguiente. Poco a poco. Un paso a la vez…

Mientras íbamos avanzando podíamos cómo nuestro concepto original, ya de por sí abierto, iba mutando por cada pieza de feedback (externo e interno) que recibíamos mientras calibrábamos la definición que teníamos de lo que era entretenido, vistoso, excesivo…  Agile, y la orientación a objetivos nos permitía planificar esos cambios a la vez que nos obligaba a mantener los pies en la tierra cuando la creatividad se disparaba hacia la luna. Ha habido entregas, tiempos definidos y requerimientos; ha habido tareas, subtareas e iteraciones. Ha habido demos y ha habido feedback.

Estoy convencido de que si no hubiésemos adoptado esta manera estructurada de trabajar (que tal vez, en realidad es que la tenemos ya inyectada en la sangre)  no habríamos llegado a lo que tenemos ahora.

agiledev

 

Acierto Número 2: Estructura de Clases adecuada

Ya Adri habló de la abstracción que conllevó diseñar la mochila, y explicó los primeros rudimentos de cómo funciona el crafting. Aunque prefiero que él sea quien profundice en los detalles técnicos y los problemas y beneficios que hemos encontrado en el camino, algo que nos ha resultado evidente ha sido el beneficio de diseñar toda las estructuras de clases como representaciones de la realidad, donde la abstracción no llega más lejos que cómo uno, sin usar demasiado la imaginación, haría las cosas…

Uno de los ejemplos más inmediatos viene del diseño del crafting: en Sticks & Stones, hay interfaces

ICraftingIngredient
ICraftingTool

y una clase para encargarse en sí del crafting,

CraftingEngine

que incluye, entre otros, métodos para controlar que una combinación es válida, o para ejecutar las combinaciones de ingredientes con herramientas, o para verificar si una combinación está disponible (dependiendo de la pantalla a la que ha llegado el jugador). Aunque existe el debate de que demasiada abstracción puede ser nociva, un beneficio inmediato que percibimos ha sido el de poder trabajar, de cierta forma, instintivamente;  no tener que pensar demasiado para decidir dónde ubicar una clase (o una variable o un método), y de qué debe heredar;  poder, sin conocer todo lo que hay en el código, utilizar IntelliSense no sólo para apoyarnos con la sintaxis, sino también con los conceptos propios del juego.  No sólo es por tiempo que se ahorra, sino también por una sensación de fluidez y avance muy agradable y muy provechosa en el momento.

Acierto Número 3: ¡Comunicación, comunicación, comunicación!

En Sticks & Stones tenemos tres canales electrónicos para comunicarnos:  WhatsApp, Hangouts, correo. Tenemos reuniones de seguimiento. Tenemos tareas de discusión. Estamos la mayoría del tiempo sentados uno al lado del otro, al alcance de un “hey tú!” el ocasional “…OTRA VEZ, PERO QUÉ DEMONIOS ESTÁS HACIENDO!?”. Debemos lidiar entre nosotros, cada uno con su propia mochila: esos son 3 conjuntos de anhelos, 3 conjuntos de intereses, 3 visiones del juego final, 3 personalidades, y más importante, 3 universos de inquietudes por entrar en un mundo que sólo conocíamos superficialmente.

Afortunadamente, porque en esencia estamos yendo a ciegas, nos hemos visto obligados a depurar la comunicación mientras ocurre; y eso a ambos lados del mensaje. No sólo los que hablamos hemos tenido que aprender a decir las cosas adecuadamente, cuidando no sólo el lenguaje sino también de usar la inflexión correcta, la que apoye el significado, la que lo haga más efectivo; también mientras escuchamos hemos tenido que aprender a hacerlo desapegadamente, a reconocer las motivaciones detrás, las inquietudes, la personalidad, con empatía y hasta agradecimiento. Todavía no es perfecto (y quién dice si siquiera tiene que serlo), pero gracias a S&S hemos logrado establecernos como Compañeros en Armas, con diferencias siempre pero capaces de tranquilamente confiar entre nosotros, a la vez que hemos aprendido a comunicarnos mejor.

Acierto Número 4: ¿Se suponía que no debía ser divertido?

flow

Mihály Csíkszentmihályi (pronunciado, más o menos, como chik-sent-mi-já-li) definió en su libro  Fluir: La psicología de las experiencias óptimas, el estado de Flujo (que es lo que informática llaman estar en la Zona), un estado mental donde la persona está totalmente sumergida en la actividad que realiza, con una sensación de enfoque activo y de disfrute: es lo que pasa cuando practicas el violín y se hacen las 10 de la noche y tu vecino está ya tumbando las paredes a martillazos y tú ni te habías dado cuenta de que no has cenado aún y has gastado, qué, ¡6 horas!.

Es un pelín más complicado que esto, pero, para conseguir ese estado de flujo, Csíkszentmihályi sugiere que deben cumplirse tres condiciones:

  1. Uno debe saber qué hacer y cómo medir el progreso: una tarea debe estar estructurada con objetivos y resultados, tener formas de saber cuán cerca se está de completarla.
  2. La tarea debe tener feedback inmediato, así la persona puede ajustar sus acciones para mantener el estado de flujo.
  3. Debe haber equilibrio entre la dificultad de la tarea y las habilidades propias de la persona y cómo las percibe, y debe poseer la confianza para completarlas.

Este estado es el que se dice está detrás de ese golpe perfecto cuando se juega golf, el gol espectacular en el fútbol; el desempeño óptimo para un atleta, pero también el genio creativo en la ciencia (como Einstein que le describe a su hijo el secreto de la felicidad, y habla de ese mismo estado donde utiliza sus habilidades al máximo, dos días después de haber postulado la Relatividad General) y el arte. El estado de Flujo aparece incluso, y esa puede ser otra de las razones de por qué lo hacemos, mientras jugamos videojuegos.

Aunque Csíkszentmihályi publica su libro en 1990, el Flujo es un estado que ha sido reconocido a lo largo de la historia y en diferentes culturas, y que ha ganado valor últimamente, no sólo como una herramienta de valor para la satisfacción del individuo sino también como un estado aprovechable por las organizaciones para el aumento de la productividad, la innovación, la creatividad y el desarrollo de sus empleados.

Nosotros ni lo sabíamos, pero si había una señal que nos indicara que estábamos ahí, Fluyendo, en la Zona, era que nuestros días siempre transcurrieron en un abrir y cerrar de ojos (excepto esos de cierre de hito, esos eran eternos…). Algunos estaban llenos de ruido y discusiones y fricción, otros de silencio sepulcral apenas interrumpido por una toz o un crujir de nudillos. Siempre, sin embargo, quedaba la sensación de oh, cuán rápido pasa el tiempo, mañana más, mañana más…  Mientras íbamos avanzando más nos dábamos cuenta de que hacer un videojuego era un proceso de duro aprendizaje. Sin embargo, de alguna manera, siempre estuvimos en sintonía para hacer que cada día fuese una experiencia gratificante. Si había que sufrirlo, nunca se sintió así. Cada día podíamos decir, sí, ¡bien!, estuvimos en la Zona

Indiedb – we’re live!

Hola mundo!

Hoy queríamos anunciar nuestra aparición en indiedb. Un portal para el apoyo de desarrolladores indies en el mundo.

Iremos subiendo artículos, imágenes y cualquier cosa más, mientras seguimos avanzando con el desarrollo. Así que asegúrate de seguirnos también por ahí.

Ah. Y hemos aprovechado para hacer disponible una versión Pre-alpha jugable muy muy simple, en caso de que quisieras sentir cómo va avanzando el juego, por lo que ya puedes darnos sugerencias de qué crees debería haber, qué no, qué deberíamos arreglar y por supuesto, cuándo aparece uno de esos bug que son imperdonables...

Déjanos saber qué opinas sobre esta salida al mundo real en los comentarios abajo. ¿Es temprano? ¿Fue tarde…? Cómo podríamos mejorar…

¡Errores, errores, errores!

Si la semana pasada hablé sobre qué había aprendido este primer año, quiero aprovechar este post para señalar en dónde, con toda franqueza, creo que nos equivocamos. Como es de suponer, la mayoría son evidentes ahora, en retrospectiva (“hindsight is 20/20…”), pero no tanto ahí, cuando estábamos cometiéndolos, y creo que ese es el valor de un ejercicio así. Utilizarlo como:

  1. Memoria: registrar qué hemos hecho mal.
  2. Comunicación: compartir para que cualquier persona en un contexto parecido pueda reflexionar.
  3. Aprendizaje: ayudarnos a reconocer esos momentos en el futuro cuando cometeremos otro error. (porque sí, habrán más errores, pero la gracia es que por lo menos sean nuevos errores…)

Error Número 1: No tener una Guía de Diseño hasta muy tarde

Sticks & Stones nace de la pasión, pero la pasión a veces puede darte alas y llevarte arriba para, sin que te des cuenta, quitártelas y hacer que te estrelles en un cataclismo de fuego. Nos pasó que por dejarnos llevar por la inspiración, por dejar que nuestras habilidades determinaran cómo debía verse tal ítem, o tal escenario, obteníamos un resultado que era muy vistoso e interesante pero que chocaba con todo lo que habíamos hecho antes.

Somos tres artistas, y varias veces resultamos inconsistentes, no sólo entre nosotros, sino con nosotros mismos.  Un día hacíamos un componente con estilo futurista, para el día siguiente hacer otro con estilo steam-punk, para el otro hacerlo en estilo cartoon. El problema no es tanto que sea inconsistente todo (que lo es), sino que el mindset del momento permite que justifiques por qué diseñar de una manera u otra: no resultamos inconsistentes de gratis, sino, al contrario, ¡muy deliberadamente! Cada decisión era, en ese pequeño contexto del día a día, coherente, pero no en el contexto global del proyecto, y tuvimos que pagar por ello. Muchas veces.

Error Número 2: Discusiones, discusiones…

Heredada de la consultoría, tenemos la tradición de los hitos y del Agile y de sprints y del vocabulario (backlog, test, daily, en desarrollo, etc…), sin embargo, a pesar de que tenemos hitos con un alcance bien definido, nunca fuimos demasiado rígidos con el cierre de algunas tareas de diseño (diseño visual, de jugabilidad, de implementación…) que requerían que fuéramos efectivos y bien concretos, y que sin embargo, nos permitíamos alargar (en ocasiones hasta por días) mientras pasábamos por temas que no tenían inmediatamente mucho que ver, o que podían sinceramente esperar, o que lentamente se convertían en otros temas. A veces sí, con resultados muy buenos, pero también muchas otras con, “no lo vemos claro, lo dejamos para más adelante.”, que era el peor resultado de haber invertido 8 horas hablando: ni un sí, ni un no, sino “bueno, invirtamos más tiempo luego”.

De ahí que decidimos establecer dentro de cada hito un número finito de horas para discutir ciertos temas y poder llegar en algún momento a interrumpir las discusiones con, “oh, se nos acabó el tiempo: tenemos que decidir.” Durante los primeros meses nos fue muy fácil caer en conversaciones filosóficas; alargarlas justificando que era necesario resolverlas antes de poner una línea más de código. Ahora, seguimos cayendo en esas discusiones, pero lo hacemos por tiempo predefinido (y próximamente cronometrado…), con mucho énfasis en la efectividad. ¿Qué vamos a resolver ahora? ¿Cuánto tiempo vamos a invertir? ¿Cuál es el resultado que debemos obtener? Go!

Error Número 3: Testing ahora no, después

Creo recordar que fueron 3 hitos (eso es mes y medio) de desarrollo antes de que viéramos la primera necesidad de hacer pruebas sistemáticamente. Enfocados en avanzar en las mecánicas, olvidábamos probar las mecánicas integradas con todo lo previo, y luego olvidábamos probar el juego en sí, cómo se sentía, cuán entretenido era y qué pasaba en él cuando las condiciones absurdas se cumplían (“¿qué pasa si dejas presionado las teclas, más el clic del ratón, mientras estás en una pared en la que hay un collider pero que no debe haber impacto?”).

Cuando se acercó la fecha de entregar el prototipo interno para que gente en BaseTIS lo probara, tuvimos que quemarnos las pestañas para resolver problemas y bugs que habíamos descuidado por 4 meses… Si el crunching es habitual en el mundo del desarrollo de videojuegos, pues, esa fue nuestra primera degustación… ¡Horrible!

Error Número 4: No haber salido antes al mundo

Nadie nos conoce. De casualidad nos conocen en BaseTIS y no de manera memorable y transversal. Llevamos 8 meses de desarrollo y pasaron 4 antes de que decidiéramos tener un blog. Apenas ahora es que estamos decidiendo invertir más tiempo en exponernos, y aunque sabemos que falta mucho por hacer, ya se siente tarde, sobre todo porque es la recomendación que hemos leído y escuchado una y otra vez desde que empezamos.

Hay que invertir hasta el 50% del presupuesto en marketing. Hay que salir tan rápido como se pueda. Hay que invertir HASTA EL 50% en marketing. El mundo es muy grande, y hay mucha gente ahí luchando por la atención del resto…

Sí, sí. Lo habíamos oído pero es ahora cuando apenas lo estamos empezando a escuchar. ¡Pero sin lamentos ni arrepentimiento! Nadie dijo que esto iba a ser fácil…

Hemos cometido muchos otros, pero creo que es suficiente por hoy. ¡Hay mucho que hacer!

Wizard of Legend – un indie para seguirle la pista

Hoy quería hablarles sobre un roguelike que está por ahí dando vueltas con fecha de release Enero 2017 y que creo que es lo suficientemente interesante para hablar un segundo de él.

Se llama Wizard of Legend. Está hecho por un equipo de dos personas llamado Contingent99, ubicados en Los Ángeles.

Como todos sabemos, una cosa es el trailer y otra el producto final; espero esta vez la diferencia no sea tan grande.

Parecerá publicidad gratuita, pero la verdad es que la comunidad indie está repleta de buena voluntad y empeño. Debemos todos apoyarnos entre nosotros.

¿Un videojuego?… ¡Pero si es muy fácil!

Llegó Diciembre. La mejor época del año, la Navidad, oportunidad para reunirse en familia, compartir, reflexionar sobre, ah, los buenos tiempos, el año que pasó, al año que vendrá, las oportunidades, las promesas, los propósitos cumplidos, no cumplidos y los por cumplir. Es fácil ponerse nostálgico y evocador durante estos días, así que aprovecho para compartir un par de lecciones que he aprendido desde que todo esto de Sticks & Stones empezó, y que me hubiese gustado que alguien me dijera, no como advertencia, sino para saber mejor en qué me estaba metiendo…

No volverás a jugar un videojuego de la misma forma

Sí. Tu relación con los videojuegos cambia irremediablemente. Hasta antes de que tuvieras la opción de hacer un videojuego, podías utilizarlos de una manera, digamos, distante. Fácil. Entrar y salir. Tú en tu sillón, el juego en la TV . Bueno, malo, entretenido, aburrido. Antes podías utilizar unas pocas palabras para resumir tu experiencia. Podías alabar a ciertos personajes, ciertos momentos (como cuando, por fin, POR FIN, lograbas pasar el nivel de las motos en Battletoads) o detestarlos absolutamente (como cuando recuerdas que ibas por la quincuagésima vez y no lo habías pasado).

Cuando haces un videojuego, empiezas a hacerte sensible a un conjunto de variables que posiblemente ni te imaginabas existían. Luego de que pasas de preocuparte de lo visual (que no es que dejas de preocuparte, sino que pasa como cuando conduces un coche de dirección manual: el primer día lo sufres, pero después de dos años, es parte de la mecánica de tu cerebro), empiezas a ver detalles. Siempre. Siempre…

Como te has topado con problemas, empiezas a buscar cómo hacen otros juegos para resolverlos. Adquieres visión crítica: empiezas a ver cómo aquí utilizan artimañas, trucos y estrategias para resolver problemas con los que ahora sabes con certeza los desarrolladores se toparon. ¿Cómo mantienen los fps a niveles racionales cuando hay tantos personajes en la escena? AH, bajan la cantidad de polígonos.  ¿Cómo hacen la pantalla de loading sin que se corte la experiencia? ¡Ajá! Para cambiar de nivel, el jugador se encuentra con una puerta y la atraviesa (Resident Evil… Donde con las puertas esas de hecho se acentúa la experiencia…). ¿Cómo este juego te explica los controles? ¿Cómo te hacen saber que esto es bueno y aquello malo? ¿Cómo hacen que vayas en cierta dirección para que aprendas que ahí está el Boss? Cada vez que juegues estarás atento a las cosas que lo hacen efectivo y las cosas que lo debilitan. Ya no más “el juego es entretenido”, sino “el juego es bueno porque hace esto, esto, esto, esto y aquello, y tiene una falla acá, y esto encaja perfecto, y aquello es brillante, y esto, esto se nota que a los desarrolladores se les acabó el dinero o el tiempo…”

Descubrirás si de verdad es una pasión

Siempre lo imaginaste. Ah. Hacerlo tú. Suena tan bien… Tal vez tan rápido como el mismo día en el que empiezas el proyecto te das cuenta, ahora sí, de primera mano, de que tu trabajo no es estar sentado frente a una pantalla dándole a botones, pasándola bien en un mundo de fantasía, como aún cree la gente (a pesar de que la industria tiene ya más de 30 años…). “Ay qué bien te la pasas, ¿no?”, dicen. Sí, me la paso bien, pero tan bien como podrías tú pasártela en tu trabajo. Es cierto que no estoy en las minas sacando carbón, y hay mucha apreciación por tener la oportunidad de hacerlo, pero no deja de ser un trabajo.

Como en cualquier trabajo, día tras día vas a toparte con retos. Sin embargo, estos retos, estas dificultades del día,  te las vas a llevar a casa, y ah, no te habrás dado cuenta pero ahora estarán contigo mientras comas. Estarán presente mientras vayas en el metro, y en tus cenas de navidad; cuando estés en el cine, cuando estés viendo Juego de Tronos, cuando cargues a tu hija y la pongas en tus hombros. Estarán cuando estés de vacaciones, contemplando la naturaleza en un parque perdido en Nicaragua y digas, “oye, esta especie de árbol permite que crezcan lianas y son así de altos y si alguien quisiera podría colgarse y balancearse y saltar hacia aquel otro árbol, y de ahí al otro, y existe el peligro y más si hay algo que pueda hacer que se corte la liana, tal vez la fricción del uso repetido, tal vez otra persona, y tal vez debería lanzarle algo a esa persona para evitar que corte la liana mientras me balanceo en ella, y tal vez no una vez sino varias veces, ah, pero esto se parece mucho a Pitfall pero podría ser, será que puedo hacer…”. Estarán cuando te sientes en tu sillón, luego de un día duro, extenuado, dispuesto a descargar con unas horas con The Last Of Us, y cuando te sorprendas que acabas de pensar “oye, esa es una forma muy muy inteligente de reutilizar la textura de las ventanas”.

Vas a pensar en videojuegos, vas a soñar en videojuegos, no podrás salir de la oficina sin deshacerte de lo que hiciste ese día. Eventualmente te verás obligado a responder: ¿cuánto de verdad te gusta pertenecer a este mundo (o acaso, que este mundo pertenezca a ti)?

Si quieres que valga la pena, deberás soltar el ego

En todo proyecto hay al menos dos personas. Siempre. Incluso si eres el único: están el tú de hoy y el tú de ayer, y lo normal es que el tú de ayer tome decisiones con menos información que el tú de hoy y que el tú de hoy está obligado (a veces a regañadientes) a aceptar. Por eso es que existe el Control de Versiones, y las aseguradoras y, bueno… Me estoy yendo por la tangente…

En Sticks & Stones somos tres. Cada uno con sus propias fortalezas y debilidades, cada un con su personalidad. En algunas ocasiones estas fortalezas se compensan (por ejemplo, la falta de conocimientos de uno de nosotros sobre XNA se compensa con su habilidad organizativa y de pensamiento abstracto). En otras ocasiones, se chocan y hacen fricción (“Vamos a implementar el sistema de Crafting con clases heredadas”, “¿Para qué si debidamente encapsuladas es suficiente?”, “¿Por qué no te callas?”, “¿Por qué no te callas tú?”, “¡Muere hereje!”, etc, etc). Y en otras, pues,  se amplifican las debilidades (“¿Tienes idea de cómo resolver la iluminación dinámica?” “¡Ja! ¿La ilumina-qué?”).

Si no quieres que todo sea una discusión, y que la dinámica de la Decisión por Comité se apodere del proyecto (ya que deberán discutir y opinar sobre las cosas que no saben), deberás aprender a renunciar a tu visión ideal y original y perfecta e imposible de alcanzar, y aprender sobre resolución de conflictos y comunicación efectiva. A ser refinado con el lenguaje, a aceptar la crítica (sea constructiva o destructiva) y a cultivar relaciones interpersonales. Entender que es válido que nos equivoquemos y que, si no somos expertos (que no lo somos), es muy positivo que nos equivoquemos.

Más aún, deberás aprender que cada miembro del equipo tiene una visión propia, y que, de hecho, es en la conjunción de esas visiones donde ocurre lo especialmente interesante y mágico de un proyecto así. Será responsabilidad de cada uno de los miembros reconocer las fallas y sus propias inseguridades, aprender a ver las diferencias entre ellos como oportunidades y no como obstáculos; aprender a canalizarlas para el beneficio del juego, y dejar de lado “El juego de tus sueños” e intercambiarlo por “El juego que puedes hacer”. De seguro en una empresa de juegos AAA la visión es mucho más corporativa, donde una persona que sabe manda y otros que saben menos obedecen, pero en Indie, todos mandan y todos obedecen, y todos no saben, y eso es muy bueno. 

Crees que estás preparado: nunca estás preparado.

¿Crees que sabes de animación? Ya tendrás que hacer el movimiento de un personaje en una dirección que nunca habías hecho. ¿Crees saber de programación? Ya tendrás que buscar una manera de ir persistiendo en alguna estructura de datos el progreso de todo el juego para implementar una especie de repetición instantánea. ¿Crees que sabes de música? Ya deberás implementar un sistema que introduzca ritmo y sonidos dependiendo de lo que hace el jugador.

Hacer un videojuego requerirá siempre adentrarse en territorio inexplorado. Deberás aprender sobre marketing o sobre qué hace un publisher. Sobre la temática en la que se desarrolla tu juego: cómo sobrevivir en un bosque, qué fauna es endógena, cuál vegetación se permite naturalmente, cuál no y cuál el jugador podría aceptar. Deberás aprender sobre redes, sobre historia, sobre ciencia ficción, sobre jugadores, sobre interfaz, sobre jugabilidad, sobre interacción (“¿Háptico, qué demonios es háptico?”), sobre cosas imposibles de prever.

En algún momento, mientras más tiempo inviertas en él, más dejará de ser tu juego; de hecho se invertirá la relación:  mientras más tiempo inviertas en él, más se adueña de ti. El juego te exigirá que animes mejor, programes mejor, diseñes mejor. Irá cobrando vida, y mientras más lo haga, más necesitará de ti, hasta que eventualmente llegue el momento (y deberás aprender a reconocer ese momento) donde deberás renunciar, aceptar lo que has hecho. Cerrar los ojos y esperar lo mejor…

Final Thoughts

El mundo de los videojuegos está cambiando muy rápidamente. Cada año el territorio de lo que es posible (AAA, indie, y triple-indie…) se agranda. Cada año hay nuevas librerías, motores y frameworks, más rápidos, más poderosos, y más fáciles de utilizar. La tecnología es cada vez más democrática, y los consumidores más ávidos por nuevas experiencias.

Como desarrolladores, es nuestra responsabilidad utilizar el espacio de exploración e innovación que ofrecen las disciplinas artísticas para buscar la satisfacción de ese apetito, pero a la vez debemos también aprovecharlo para nuestro crecimiento y desarrollo profesional, recordando que la gracia de todo esto no está tanto en lo que se ha hecho antes, sino en lo mucho mucho que hay por aprender, lo mucho que hay por descubrir.

¡Feliz navidad!

V.

Música en el género Roguelike

Siguiendo el tema de la Música, hoy quiero aprovechar para extender el post anterior con un par de ejemplos para exponer cómo los Roguelike utilizan la música. Como suele suceder, la música es un apoyo al estado actual del juego, que refuerzan la narrativa que llega primordialmente a través de lo visual (más, tal vez, que la misma jugabilidad…).

Más aún, toda esta fiebre de videos Let’s Play, donde los comentarios del jugador son más relevantes que el audio, revelan lo delicado que es este tema: si no pones música, el juego se siente vacío e incompleto; si la pones, pues debes hacerlo sin que sea demasiado relevante, que no estorbe y, más importante aún, no fatigue…

Spelunki

Nota cómo empieza la música con la presentación (minuto , el estilo 8-bits, cómo refuerza el sentido de aventura, con toques tribales a lo Indiana Jones, y cómo, cuando empiezas ya explícitamente a jugar, pasa a un segundo plano. En el minuto 2:50, de nuevo vuelve a ser relevante: sube el volumen, ayuda con la transición que está ocurriendo en pantalla y aporta un efecto de misterio e intriga, como entrando dentro de una pirámide azteca.

The Binding of Isaac

Aquí, la música utiliza menos texturas 8-bits pero igual con bastante importancia (a partir del minuto 3:27, se nota el cambio con mucha claridad). La tonalidad es Menor la mayoría del tiempo, alternando entre guitarras eléctricas, violines, techno y sintetizadores con mucho dramatismo y reforzando con,  a mi parecer, mucha efectividad la tensión cuando se combate contra un boss o contra múltiples minions. 

Rogue Legacy

Aquí también hay mucha presencia del 8-bit, con tonalidades menores, toques de fantasía y cierta tenebrosidad. Sin embargo, hay variaciones para estados especiales del juego: por ejemplo, cuando es momento de elegir el personaje (4:36), la música adopta un carácter renacentista, con la melodía llevada por un laúd por unos segundos, luego por un piano, con instrumentos de cuerda llevando el ritmo de fondo. En el minuto 6:35, cuando el jugador se acerca a un “Carnaval”,  puede escucharse la interrupción abrupta de la música que llevaba el juego, para cambiar en una absolutamente 8-bit/retro, alegre y rápida, para reforzar el sentido frenético y la prisa… Otro detalle interesante es cómo la cantidad de efectos de sonidos, reflejo de lo que ocurre visualmente en el juego, puede opacar casi totalmente la música de fondo sin que tenga ninguna consecuencia para el jugador (11:11).

Creo que lo interesante de estos ejemplos está en ver cómo la música, siempre con ese sentido accesorio, rellena los espacios necesarios para que la experiencia sea inmersiva.

(Por cierto: a ver si adivinas qué canción es la que hemos utilizado en la imagen principal de este post!)

La Música – Primera aproximación

Hoy vamos a hablar de uno de los temas más interesantes y complejos de resolver al desarrollar un videojuego: la música.

Si te pidieran que tararearas una de las canciones de Star Wars, ¿podrías hacerlo? ¿Qué tal una de Indiana Jones? ¿Harry Potter? ¿Súperman (de las de Cristopher Reeves)? ¿James Bond? ¿Misión Imposible…? Ahora, ¿qué tal si te pidiesen tararear la canción de Tomb Raider? ¿Mass Effect, Halo? ¿Qué tal Sonic? ¿Qué tal Chronno Trigger? ¿Zelda? Seguramente te habrá resultado más fácil recordar los temas de las películas que los de los videojuegos, no sólo porque tendrán más tiempo desde que fueron introducidas a la cultura, sino porque también fueron utilizados con un propósito mucho más deliberado e íntimamente relacionado con la narrativa y con el impacto emocional de una secuencia de escenas desplegadas en la pantalla.

En los videojuegos, la metodología es fundamentalmente diferente. Existe una variable enorme con la que ningún otro medio debe ni ha debido lidiar antes: el jugador; aleatoriedad, opciones para que la persona haga. Si la música permite permite provocar cambios en las emociones y estado anímico de las personas, ¿cómo puede un videojuego incorporarla efectivamente cuando hay un sinnúmero de secuencias lineales que seguir? Tal vez esa condición es la que ha hecho que, a pesar de como dice Jack Wall (el compositor de los primeros Mass Effect) “la música es el personaje invisible. Es la emoción detrás de las acciones del jugador.”, la música sea considerada no fundamental, accesoria, y en algunos casos hasta decorativa en un videojuego. ¿Cómo la haces parte de la historia si no tienes certeza de cómo se va desplegar esa historia?

Por supuesto, mientras más control tengas sobre la linearidad, más efectivamente podrás usar la música, como una película. Red Dead Redemption, por ejemplo, cuyo soundtrack es aún alabado por la crítica y jugadores por igual, tiene una historia bastante lineal en la que la música puede planificarse casi como si fuera un evento cinemático. Cuando el jugador llegue a el punto P, ejecutar tema T. Journey (cuya creadora Kellee Santiago ha dicho que los videojuegos serán, como medio expresivo, más poderosos en el siglo XXI que la radio, el cine y la televisión juntos) en cambio, utiliza la música (así como su ausencia) no sólo de manera muy efectiva para la narración, sino como aspecto fundamental de la experiencia: es el mejor ejemplo de lo que se denomina Música Adaptativa. Ella responde a las acciones del jugador,  al ambiente, a la existencia de otros jugadores on-line y a los “mensajes” con los que el jugador se comunica; sin embargo, al igual que Red Dead Redemption sigue siendo una historia lineal donde puedes, con sus innumerables sutilezas, guiar al jugador hacia un estado emocional.  La pregunta que se me ocurre es, ¿cómo puedes utilizar la música de forma creativa y a la vez efectiva, en un juego como Sticks & Stones, donde la generación aleatoria y el re-juego son esenciales, donde no hay forma de saber cómo avanzará el juego? Es fácil poner una canción encima, con suficiente variedad y longitud para que no se fatigue el jugador, pero ¿podríamos hacer algo más interesante que eso?

¿Qué alternativas tenemos?

Música pre-renderizada.

En la música pre-renderizada, secciones musicales, grabadas a partir de instrumentos musicales reales o virtualizados a través de DAWs (Digital Audio Workstations) son invocadas desde el motor del juego directamente, a través de una interfaz especialmente diseñada para la reproducción de música. En XNA, si quisieramos que sonara cierta canción cuando el jugador crafteara algo interesante, o si quisiéramos que sonara siempre de fondo, haríamos algo como:

protected Song song;
song = Content.Load<Song>("crafting_success");
MediaPlayer.Play(song); 

Simple, ¿no? Sí, pero demasiado simple. Es una manera de incorporar música en XNA, pero no necesariamente la mejor. Por ejemplo, MediaPlayer.Play() permite sólo una instancia a la vez, de modo que cualquier técnica de música adaptativa, (como horizontal re-sequencingvertical re-orchestration, ya hablaremos más adelante de ellas…)  se hace imposible de implementar. Es decir, siempre podremos cambiar una canción por otra (un momento de tensión pasando a uno de relajación) pero no podremos hacerlo sin cambios abruptos ni interrupciones que saquen al jugador de su estado inmersivo. De hecho, una de las consideraciones que surge de aquí es que hace falta pensar en el audio en general en más que sólo su reproducción o como una lista de assets. Hay que pensar en cómo el todo el audio (efectos de sonidos + música) funcionan juntos dentro del juego, no como items discretos, sino continuos, que son ejecutados y modificados de acuerdo a ciertas condiciones.

Por ejemplo: si en Sticks & Stones, Ferguson pudiera conducir un automóvil y acelerara y redujera la velocidad, habría falta de mucho más que sólo un MediaPlayer.Play(engine): habría necesidad de una interfaz que modificara el sonido para cuando aumentaran y descendieran las revoluciones del motor:

Estas interfaces, o middleware, son asociados generalmente con la implementación de efectos de sonidos y de ambiente, pero en realidad están preparadas para resolver por completo las necesidades de audio de un videojuego. Existen tres especialmente populares:

  • XACT (de Microsoft, gratis para uso comercial, relativamente simple de usar pero compatible sólo con plataforms  Windows y Xbox).
  • FMOD (de Firelight Technologies, gratis para uso no comercial).
  • Wwise (de Audikinetic, gratis para uso no comercial).

Para el caso de la música, se podría alternar entre el estado natural del personaje (como cuando Mario explora en Super Mario Bros) y un estado excepcional (cuando agarra una Estrella) sin tener que interrumpir una canción y sustituirla por otra. En cambio, podría aprovecharse uno de los tiempos débiles o un silencio en la canción para hacerle fade-out a una y fade-in a la otra transparentemente.(no es que así se haga en Super Mario Bros., ahí todo se interrumpe, pero por ejemplo…)

Música a partir de Datos Musicales.

MIDI (Musical Instrument Digital Interface) es un protocolo de comunicación a través del cual se pueden enlazar instrumentos musicales electrónicos entre sí y con ordenadores y otros dispositivos, transmitiendo información sobre tono, velocidad, volumen, dinámicas y vibratto de un sonido.  La manera más simple de entender MIDI es como una pianola: la música que es reproducida está limitada por la cantidad de información que puede codificarse en un rollo de papel, y la habilidad del piano para reproducirla.

Un ejemplo inevitable del uso de MIDI en videojuegos es el de iMUSE de LucasArts: utilizado por primera vez en Monkey Island 2: LeChuck’s Revenge, el sistema permitía manipular el contenido de la música directamente dado el estado actual del videojuego. Podía introducir melodías, modificar el tempo, cambiar la instrumentación, transponer claves. Sin embargo, para la última versión del 2013, iMUSE manipulaba la manera en la que música pre-renderizada era utilizada por el motor del videojuego: MIDI, con todas sus ventajas, aún posee inconvenientes considerables: requiere de grandes espacios de memoria para una librería de efectos si se quiere que la música sea suficientemente sofisticada y expresiva, y no puede compararse con la flexibilidad de un entorno completo de mezclado para la obtención y  de resultados de calidad.

¿Y Sticks & Stones entonces?

¡No sabemos! O no lo hemos decidido aún… El contexto habla de un programa de televisión superpuesto sobre entornos naturales. Existe la opción de un sonido ambiental natural, con aves y animales en la distancia rugiendo y cantando cada cierto tiempo, mezclados con el crujir de las hojas de árboles en el viento o bajo los pies de los personajes, o con la aparición imprevisible de elementos de alta tecnología como hologramas, Holo-balls, el cercado eléctrico… También podría diseñarse en los términos estruendosos y sobresaturados de un programa de concursos de televisión, apareciendo para recordarle al jugador del contexto, con un presentador, el Tema del concurso, las señales auditivas diegéticas para los personajes… O más interesante (o peligrosamente), podríamos explorar el concepto de Música Generativa, aprovechando la creación aleatoria del entorno (Perlin Noise + Poisson Disk) para también generar la música que acompaña al jugador. Se ha hecho antes, pero de nuevo, el problema, como con todo lo procedural, recae en la misma pregunta de siempre: de acuerdo, esto es música, pero ¿es acaso música interesante?

Ya iremos avanzando…

Mientras tanto, les dejo con esta versión del que debe ser el tema más intrusivo en la historia de los videojuegos, y que sin embargo, tal vez por nostalgia, todos apreciamos:

 

Screenshots – II

No hace apenas ni un mes que adjuntamos algunas capturas del aspecto que tenía el juego en ese momento. Como ya avanzamos, ese aspecto era totalmente temporal, ya sea por que aún faltan incorporar muchos de los elementos que queremos o bien por que algunos son temporales.

screenshot_2

Desde entonces, hemos estado trabajando muy duro para impregnar a las pantallas de un aspecto más orgánico y natural.

Creemos que estamos un paso más cerca del resultado final que buscamos. En otro artículo ya os explicaremos en qué consiste este nuevo sistema de generación procedural, pero para abrir boca os dejo algunas capturas del resultado conseguido hasta el día de hoy.

– Bosque –
screenshot_forest

– Pantano – screenshot_swamp

¿Qué opinas del cambio? ¡Deja tus comentarios! 😀

Sistema de Crafting

En este artículo hablaré sobre el sistema de crafting que hemos diseñado para Sticks & Stones, pero antes de entrar al detalle, analizaré a alto nivel un par de videojuegos con modelos de crafting distintos.

 

minecraft-icon Minecraft

El rey del crafting, su nombre ya lleva escrita la mecánica que forma el pilar central del juego.

Su sistema consiste en combinar objetos en una cuadrícula de NxN, dónde la posición en la que se colocan los objetos dentro de la cuadrícula es importante. Además tiene cientos de combinaciones distintas.

minecraft-crafting

Para descubrir una receta –un ítem u objeto– debes imaginarte de que materiales está compuesto y que forma tiene.

El jugador puede llegar al resultado aplicando la lógica, así que podemos decir que todas las combinaciones que nos permite el juego son lógicas, pero no todas las combinaciones lógicas que se le ocurran al jugador tienen un resultado. Es decir, el jugador podría llegar a sentir frustración si cree haber encontrado una combinación razonable y no consigue nada, pero por otro lado, descubrir una nueva receta puede ser muy gratificante.

En definitiva, nos encontramos ante una original y difícil mecánica de crafting, con un catálogo de recetas muy amplio (más de 100) y con un alto grado de satisfacción y frustración.

 

how-to-survive-icon  How To Survive

En How To Survive el crafting no tiene tanto peso como en Minecraft. Ofrece un sistema de elaboración de recetas diferente, por lo que es un buen ejemplo para contrastar.

Nos encontramos ante una mecánica basada en combinaciones binarias, es decir, combinar objetos de dos en dos.

Durante el proceso de crafting, es posible crear recetas sin utilidad directa en el juego, pero que combinando con otros objetos puede llegar a obtenerse una receta útil.

howtosurvive-crafting-chainsaw

Una detalle particular de su sistema, es que una misma receta puede elaborarse con diferentes combinaciones. Por ejemplo, la cuchilla de hueso puede obtenerse de un hueso + cualquier cosa que sea cortante.

howtosurvive-crafting-bone-blade

Cuando se quiere combinar un objeto, el juego te marca en el inventario aquellos que son compatibles, por lo que reduce la frustración del jugador al crear combinaciones que no funcionan.

howtosurvive-craft-arrow

Además, conforme se avanza en el juego se van desbloqueando algunas recetas que quedan guardadas en un diario de supervivencia para poder consultarlas.

How To Survive tiene una mecánica de crafting sencilla, con tendencia a simular combinaciones reales de materiales y herramientas para elaborar las objetos. Dispone de un catálogo de recetas inferior a 100 elementos y tiene un equilibrado grado de satisfacción y frustración.

 

Comparativa: Minecraft vs How To Survive

Como resumen al análisis de ambos sistemas de crafting, añado una tabla comparativa de algunas de sus características:

minecraft-vs-howtosurvive

Esta comparativa no quiere indicar que un juego tiene mejor sistema que otro, simplemente pone sobre la mesa información para ver que existen diferentes modelos de crafting que pueden funcionar.

Lo importante es saber encajar el modelo adecuado con el tipo de juego.

 

Modelo de Sticks & Stones

Lo primero que hicimos fue analizar el sistema de crafting de otros juegos, como por ejemplo los explicados en el artículo. Y luego analizamos las características del nuestro, para ver qué modelos encajaban mejor.

Sticks & Stones, como buen Rogue-Like que es, necesita potenciar la dificultad así como alargar la curva de aprendizaje. El objetivo es que el jugador deba repetirlo varias veces y en cada partida aprenda algo nuevo.

Pero también es un juego de acción, lo que implica que el sistema de crafting debe ser ágil.

El enfoque

Para cubrir el aspecto de la dificultad, creemos que las recetas deben ser descubiertas por el jugador a medida que prueba combinaciones. Como no tendrá disponible el catálogo de todo lo que se puede hacer, hemos pensado en la posibilidad de que existan recetas básicas aprendidas desde el inicio. Esto ayudará a que el primer contacto con el videojuego sea más asequible.

Para hacer ágil el crafting, las recetas que se descubran quedarán guardadas. De esta forma, es el jugador el que va creando su propio catálogo.

Pero… ¡Basta ya de cháchara! ¡Vamos a ver algo!

sticksandstones-crafting

En nuestro modelo de crafting distinguimos entre dos elementos: ingredientes y herramientas. Lo mas importante es entender la diferencia:

  • Ingredientes: son los elementos que al combinarse producen el nuevo objeto. Desaparecerán del inventario del concursante tras la elaboración.
  • Herramienta: es el elemento necesario para poder elaborar la receta, pero no se consume tras la elaboración, y por tanto, permanecerá en el inventario del concursante.

Una receta puede elaborarse a partir de la combinación de 1, 2 o 3 ingredientes y 1 herramienta.

En algunos casos, con una misma combinación de ingredientes y herramienta pueden obtenerse hasta tres recetas distintas. Lo que distingue una de otra, es el proceso de elaboración. Por ejemplo, para hacer flechas de madera se requiere lo mismo que para hacer una lanza de madera: una rama dura y una herramienta cortante.

Queremos recetas intuitivas, para que el jugador pueda deducirlas, pero tenemos un espacio limitado, un máximo de cuatro elementos entre ingredientes y herramienta. Esta decisión la tomamos pensado en que fuera ágil, así que en ocasiones tenemos que diseñar recetas simplificadas.

 

Conclusiones

Diseñar un buen modelo de crafting es difícil. Si además hay que encajarlo con las características del videojuego, aún lo complica más… Y si aún así se quiere innovar, la tarea se vuelve titánica.

Para finalizar, comparto algunas de las preguntas más críticas que nos han ido acompañando a lo largo del proyecto:

  • ¿Es compatible unir acción y crafting?
  • ¿Es arriesgado innovar en un nuevo sistema de crafting?

Estaré encantado de recibir tus comentarios y discutir sobre el tema.