chess-1742720_640

¡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!

Leave a Reply

Your email address will not be published. Required fields are marked *