Highsight and Us. Us and Highsight.

Gamers del mundo!

El pasado miércoles a las 2:00 am (8:00 pm) tuvimos la oportunidad de ver cómo Sticks & Stones era jugado por alguien totalmente ajeno a nosotros. Le habíamos hecho llegar la última build a un chico en EE. UU. con su propio canal de Twitch llamado Highsight y pudimos ver cómo jugaba. En vivo. ¡A todo el mundo!

¿Qué tal fue? 

Pues….

En las palabras del chico: Not bad guys. Not bad at all. I  really hope to hear more from you. 

Pudimos ver cómo exploraba y comía champiñones, pudimos ver al público alabando a las Gunslingers (las “Cowboy Robot Thingies”), pudimos ver cómo crafteaba, pudimos ver cómo experimentaba mientras crafteaba. Habló de lo interesante del estilo gráfico y de lo prometedor de las holoballs  y de cómo era posible adivinar las intenciones de las holoballs a partir del personaje que eran.

Nos hizo recomendaciones sobre la UI, cosas que hacíamos bien (“it’s the easiest crafting system I’ve used“),  cosas para mejorar y cómo mejorarlas (“it all feels too disconnected, you should take Minecraft as  an  example of how to do it perfectly“) y cosas que hacíamos mal (“why shouldn’t this item replace the one’s that’s already in place?“). Al final, nos permitió ver cómo juega alguien sin tener a uno de nosotros inspeccionando cada cosa que hace por encima del hombro, para darnos la tenue satisfacción de confirmar (de nuevo 😉 ) que la idea en la que hemos invertido tanto funciona.

Ya estaremos anunciando por aquí cuando haya otra transmisión así: el equipo entero quedó con la misma sensación luego de que terminara, somnolientos y exhaustos, a las 4:00 am del miércoles: queremos más.

Nos vemos!

Nueva Build Disponible, JUGAD!

Ya era hora. Aunque el año empezó hace 25 días, hemos estado trabajando día y noche y fines de semana y festivos y no festivos y días de cumpleaños y festivos no nacionales y festivos galácticos para poder llegar a esto.

¡De acuerdo! ¿Dónde la descargo?

¡Qué entusiasmo!

Aquí desde Dropbox. Pero si lo prefieres por algún motivo, en indiedb también está disponible.

No, no, es verdad. Me apresuré. Pero de acuerdo, tienes mi atención ¿Qué hay de nuevo?

¿Qué hay de nuevo? !¿Qué hay de nuevo?! “¿Qué hay de nuevo?”, pregunta.

Por qué no mejor te lo descargas y dejas que la majestuosidad te eleve hasta Proxima Centauri.

Buen intento, ahora dime: ¿qué hay de nuevo con respecto a la última vez que jugué?

Perdón, perdón. Hay:

  • Nuevos enemigos: dile adiós a las arañas y dile hola a las Holo-balls. Llevamos tiempo hablando de ellas, pero ahora vas a poder sentir lo que es ser golpeadas por su furia.
  • Mejoras visuales: mira cómo salen chispas cuando golpees a una Holo-ball. Mira cómo una de ellas (no diremos cuál) acumula Energía Oscura para pegarte un pepazo fulminante. Mira cómo la nieve queda estampadas con tus pasos ligeros mientras te mueves en el escenario o cómo tus huellas se entrecruzan con el rastro sucedáneo de holo-balls con miras a destruirte (¡!). Mira el humo, ¡EL HUMO!
  • Escenarios nuevos: complace tu mirada con la pradera nevada, el bosque, el pantano. Tienes que saber que hay cierta aleatoriedad así que es posible que no lo veas a la primera, ni a la segunda. Tampoco es para que las cuentes. Juega, disfruta, eso es todo.

De acuerdo. Suena bien. ¿Tengo que pagar por esto?

¡JA! Esa es la mejor parte. No (aunque posiblemente querrás pagar luego). Es una build. No es un juego completo. Hay mucho por hacer y mucho por pulir, pero te da una idea de lo que viene.

Si quieres ayudarnos, y nos fascina que quieras ayudarnos, sería muy conveniente que regaras la voz. Twitter, Tumblr, Facebook, Tinder, Tuenti, Google+ (no, mentira, nadie usa eso), LinkedIn, MySpace (¿todavía existe MySpace?), Pinterest, StumbleUpon, Reddit, donde quieras. Un comentario, un enlace a la descarga, lo que quieras. Todo ayuda ;).

Más vale que no me decepcionen…

No lo haremos.

De acuerdo. ¿Dónde la descargo?

Directamente desde Dropbox.

O de nuevo, si prefieres, también puedes descargarla desde indiedb.

Muchas gracias chicos.

No, no, gracias a ti artificio narrativo.

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: