Postmortem: Dots of War

18 min readOct 18, 2020

Dots of War es un juego rápido de estrategia en línea para dispositivos móviles, está basado en el juego Timbiriche (dots and boxes) y el objetivo es conquistar la mayoría del mapa conectando cuatro líneas para ganar puntos. Una vez que capturas una parte del mapa, la energía de tu jugador sube y con ella puedes hacer habilidades especiales que te permitirán afectar el turno de tu contrincante.

Dots of War fué el primer juego que se hizo en conjunto bajo el estudio LunarCrown, un estudio de videojuegos independiente basado en Hermosillo Sonora, México formado por otros estudios locales en una propuesta para profesionalizar nuestro trabajo y llegar a un público más amplio.

Dots of War Trailer

¿Cómo elegimos el tema?

Como la mayoría de las decisiones que se tomaron en el proyecto, nos basamos en votaciones. Al inicio del proyecto nos pedimos mostrar 1 o 2 propuestas que nos gustaría desarrollar como primer juego, después las explicamos ante el equipo y al final votariamos por la que nos parecía más sencilla de implementar, interesante para trabajar y que nos gustaría para trabajar en ella.

De todas estas propuestas ganó recrear el juego de Timbiriche y darle un giro al ganar habilidades para afectar al rival.

Primeros bocetos de diseño del juego

Después de eso se hizo un “mood board” (un tablero para inspirarnos) sobre el tipo de decisiones artísticas que se tomarían, un “cómo nos gustaría que se viera” por así decirlo, donde se colocaban varias fotografías para inspirarnos,pueden ver el mood board aquí, la saga de Professor Layton y Advance Wars fueron una gran inspiración para el look and feel que le dimos a Dots of War.

¿Cuánto pensamos que duraría el proyecto?

Inicialmente pensamos que el proyecto duraría alrededor de 3 meses, sin embargo, una vez que tuvimos el arte del juego decidimos extender el tiempo de desarrollo “un poco más” para entregar un producto de mejor calidad, eso se convertiría en un proceso de alrededor de 9 meses.

¿Cómo trabajamos en el proyecto, tiempos, tareas, talento?

Inicialmente el proyecto comenzó con 8 integrantes, 3 programadores, 2 artistas 3D, 1 artista 2D (que también tenía la labor de director de arte), una persona encargada de la experiencia de usuario y calidad y una persona en tareas de Game Design y arte 2D.

Pero al igual que otras decisiones, muchas veces el equipo hacía una propuesta de cambio y se tomaba en cuenta lo que se acordara por la mayoría, dentro de cada sub-equipo la decisión final quedaba dentro de ellos, tomando en cuenta las opiniones que se daban, no queríamos influir mucho en decisiones que no estuviéramos muy seguro de la opinión que estábamos dando.

Al inicio, estos puestos no existían pero dejamos saber que tipo de rol nos sentíamos más cómodos para trabajar durante el proyecto tomando en cuenta las habilidades de cada persona y el área en la que nos gustaría colaborar.

Desde un principio, decidimos que este sería un proyecto que tendríamos que completar en nuestro tiempo libre, cuando no atendieramos a nuestras responsabilidades principales con nuestro trabajo y familia.

Por ello, cada semana durante una pequeña llamada de 15–30 minutos, daríamos nuestros avances durente el proyecto y terminaríamos aclarando cuantas horas ibamos a poder dedicarle al proyecto esa semana, por lo regular, serían de 6 a 10 horas por semana.

Respetamos mucho el tiempo de cada integrante y no queríamos que sintieran que se les estaba exigiendo mucho tiempo y dejamos que cada integrante se hiciera responsable por sus tiempos.

Para dividirnos las tareas, utilizamos trello, donde cada integrante podía seleccionar la tarea en la que quisiera trabajar basándose en los talentos de cada quien y lo que se necesitara hacer en ese momento.

¿Cómo calculamos cuánto cuesta hacer un juego?

Al inicio del proyecto, les pedimos a todos los involucrados calcular cuánto cobrarían por una hora de su trabajo, ese monto se multiplicaría por las horas trabajadas en una semana y a su vez por 4 semanas de cada mes que durara el proyecto para así tener el costo mensual de desarrollo.

Dado que Dots of War fue un proyecto de hobby, ese dinero no vendría de ningún inversionista y sería “absorbido” por nosotros, al final de cuentas nosotros queríamos saber cuánto nos costaría hacer un juego de estas características entre el equipo y el ejercicio nos sirvió para darnos cuentas de los costos reales de producción.

$27,650 pesos Mexicanos era el costo promedio por mes para mantener al equipo, esto sin contar ningún otro gasto de operación, licencias o equipo de computo, esos 27 mil pesos virtuales serían exclusivamente para pagar salarios.

Si el proyecto durar 3 meses el cálculo sería: 3 x $27,650 = $82,950 . Esa sería la cifra que el juego debería de recuperar para salir en numeros negros si hubieramos invertido en en salarios con dinero real.

Cada mes que nos excediéramos con el lanzamiento del juego, se deberían agregar $27,650 para pagar los salarios de ese mes.

Propiamente, en un proyecto verdadero, se debería de tener una estrategia de monetización para intentar ganar 5 veces el costo de desarrollo, dando un total de: $414,750 lo que mantendría a LunarCrown con suficiente dinero para pagar los salarios, licencias y el desarrollo del siguiente juego.

Como veremos a lo largo de este artículo, nos daremos cuenta acerca de cómo no logramos llegar a esas metas.

Crear un MVP

Una vez que tuvimos definida la idea del juego que queríamos hacer y las tareas que se tenían que completar para lanzar el juego decidimos hacer un Minimum viable product (MVP) o Proof of concept (POC) que simplemente es implementar las mecánicas básicas del juego para probarlo internamente y ver si en realidad era divertido.

Hacer el MVP nos llevó menos de una semana, básicamente se hizo un juego de conectar los puntos con las siguientes características.

El jugador puede conectar dos puntos con una línea
El jugador puede conectar formar un cuadrado conectando cuatro puntos con lineas
El juego identifica que es un “cuadrado” y le da un puntaje al jugador que lo cerró.
El juego identifica cuando es el turno de cada uno de los dos jugadores.
El juego termina cuando no hay más movimientos posibles por hacer y determina quién de los dos jugadores es el ganador.
El jugador puede elegir si juega otra vez.

Todo eso fue hecho con arte de placeholders muy rudimentaria, una interfaz de usuario que no sería la final pero que nos serviría para saber que estaba pasando “detrás de cámaras” de nuestro juego.

Una vez que tuvimos las mecánicas básicas del juego, supimos que podíamos terminar un juego así y lo siguiente sería pulir el juego para volverlo más divertido y agregar el arte.

Primeros indicios de Scope creep y cómo lidiar con ellos

Scope creep es un término utilizado en proyectos cuando el alcance del proyecto se empieza a extender hasta convertirse de un proyecto chico a un proyecto cada vez más grande.

Es muy fácil dejarse llevar por la emoción de querer agregar más funcionalidades a un proyecto de este tipo, pero también es parte de la responsabilidad y profesionalismo de los integrantes saber reconocer cuándo se debe de ajustar el proyecto a lo acordado para respetar el tiempo de todo el equipo.

En LunarCrown nos preocupamos mucho por el tiempo del equipo, así que respetamos enormemente el tiempo que le invierten al proyecto y nos gusta saber que lo aprovechamos al máximo.

Una vez que tuvimos el MVP y se consiguió tener un juego de Timbiriche que funcionaba y era de dos jugadores, hacerlo destacar era parte de la siguiente tarea.

Esto puede lograrse gracias al arte sorprendente, efectos visuales interesantes o mecánicas únicas que lo distinguirían de los demás.

Pero en cada uno de esos aspectos, es fácil dejarse llevar y querer agregar “solo una cosa más”.

Por ejemplo, en Dots of War puedes elegir 3 clases de heroes distintas para jugar, cada clase tiene por lo menos 1 aspecto 2D para representarla (con la opción de comprar aspectos adicionales) y 3 modelos 3D para representar cuando han capturado un cuadro en el mapa.

Era muy tentador para el equipo decir “hay que agregar otra clase”, pero eso conlleva:

Crear más assets 2D
Balancear la interfáz de usuario de selección de personajes (o codificar una solución para el menú de selección que acomode solo cada nuevo personaje, lo cuál también llevaría tiempo no presupuestado)
Crear 3 modelos 3D extra.
Hacer un test completo del juego con las combinaciones de ese jugador.

En momentos como ese podemos preguntarnos como equipo: ¿En realidad es necesario agregar un nuevo personaje?, ¿Le dará más valor a nuestro juego?, ¿Vale la pena la recompensa que recibiremos a cambio del esfuerzo que se tiene que hacer?, ¿Hay otros objetivos pendientes que podríamos estar realizando en vez de esto?.

El manejo de un videojuego está lleno de decisiones que no son divertidas, pero que tienen que tomarse para que al final el proyecto se complete.

Al inicio del proyecto, cada clase también tenía una “habilidad especial”, esta habilidad se podía utilizar cuando el jugador ganaba 3 puntos de energía y esos puntos de energía se conseguían por capturar cuadros adyacentes, la cantidad variaba dependiendo de la clase.

Aparte de su habilidad especial, todas las clases tienen una habilidad en común llamada “bloquear” que cuando se usa, el rival no puede continuar con su turno después de capturar un cuadro.

Los Humanos podían gastar sus 3 energías en robar una casilla al adversario.
Los Hombres piedra podían bloquear sus casillas para ser inrobables.
Los Magos podían bloquear una linea para ser solo ellos los que pudieran utilizarla.

Tener una habilidad especial para cada jugador era algo muy llamativo para el equipo y para el juego, pero esa funcionalidad tenía que programarse individualmente por cada clase y probarse varias veces contra diferentes combinaciones de jugadores para balancearlas.

Las habilidades especiales se volvieron un problema muy grande, el juego tenía que seguir avanzando, el equipo de programación debía de terminar de implementar esa funcionalidad y probarla para ver si la mecánica estaba balanceada y si el juego se volvía más o menos divertido con ello.

Algo que pasa cuando se desarrollan videojuegos es que nos enfocamos tanto en el proyecto que aveces ya no podemos confiar si lo que estamos probando una y otra vez sigue siendo divertido, por lo que se debe de estar probando constantemente con personas externas al equipo para escuchar su retroalimentación y opiniones frescas.

Explicar la mecánica de las habilidades de las clases era tan complicado para los jugadores externos que la mejor decisión que tuvimos fue cortar ese aspecto del juego.

Teníamos adelantado buena parte del juego y aún no sabíamos si esta otra gran pieza del diseño del juego iba a encajar con la mecánica principal o si iba a tener algún efecto perjudicial cuando los jugadores se dieran cuenta de que cierta clase tenía ventaja contra las demás.

Se tuvo una votación interna para hablar de esa mecánica, y se llegó a un acuerdo para removerla del juego y solo dejar la habilidad general de bloqueo para todas las clases, en este punto todas las clases son iguales.

Hacer un juego en línea

Algunos pensarían que la parte más difícil del proyecto fué el modo en línea, pero gracias al uso de Plugins como Photon esta parte fué relativamente sencilla.

En el alcance original del proyecto queríamos hacer un juego que fuera multijugador en línea, ningún miembro del equipo había hecho un proyecto como este antes y nos resultaba realmente retador.

Muy pronto en el diseño del juego (y varias veces fué recomendado por conocidos ajenos al desarrollo del juego) se contempló la opción de crear nuestro propia lógica cliente-servidor para tener un control más completo del juego y así de pronto también se decidió que no se utilizaría esos métodos ya que no teníamos el tiempo estimado para ello y realmente no le agregaría nada al alcance inicial del proyecto.

Construímos la interacción en línea para ser escalable por si en futuras versiones decidiéramos crear nuestra propia API para ello, pero de momento, nadie se iba a comprometer a dejar el desarrollo del juego para crear esas piezas, así que votamos por que no se hicieran.

Photon es una herramienta que maneja la lógica de recibir y transmitir información de los clientes a los servidores.

Tiene un plan gratuito que te permite 20 conexiones concurrentes, si hay más de 20 jugadores a la vez jugando el juego comienza a negar el servicio a los que van llegando pero uno como administrador de la cuenta puedes decidir en que momento hacer el upgrade de tu cuenta y permitir más conexiones concurrentes.

Concluímos que, para un MVP y como versión inicial, la versión gratuita de Photon nos serviría bastante bien, y que si llegábamos a tener el “problema” de que más de 20 jugadores estuvieran jugando a la vez, valdría la pena hacer el upgrade, pero de momento supervisaríamos la cantidad de jugadores concurrentes e iríamos evaluando la situación conforme los datos que tuviéramos.

La manera en la que implementamos la lógica para el juego en línea es bastante sencilla.

Primero terminamos todo el juego para que se pudiera jugar con una sola persona.
Después vimos la lógica para que el juego se jugara con 2 personas usando el mismo dispositivo y así ver cómo se comportaban los turnos.
Una vez que pulimos esa parte, creamos el modo en linea, donde se crea una sala y se espera a que se conecte otro jugador, una vez dentro de la sala el juego comienza y determina quien es el jugador 1 y quien es el jugador 2.
Las acciones de cada jugador se transmiten a la red, y el juego está diseñado para recibir las acciones y mostrar la misma interacción independientemente de los dispositivos.

El diablo está en los detalles

Así que, ¿qué es lo que pasa cuando ya tienes un juego, el arte está en su lugar y ya tienes la mecánica de juego en línea implementada?

Tienes que terminar el juego.

Ese último 10% para terminar un proyecto de este tipo donde tienes que corregir los bugs, terminar de hacer las pruebas completas de regresión, crear las imágenes para las tiendas donde se publicará el juego, preparar el texto optimizado con ASO (App Store Optimization) para que tenga buen ranking en cada tienda, arreglartelas como puedas para traducir tus imágenes y texto a otros idiomas, preparar un trailer, y una lista de tareas que no son técnicas pero se tienen que hacer.

Es difícil terminar un juego y cuando le has invertido tanto tiempo a un proyecto te puedes enfocar mucho en un aspecto y empezar a descuidar otros, por ello es importante que los miembros del equipo tengan una meta clara de lo que se quiere lograr.

El desarrollo de Dots of War inició en Julio de 2019 y para Octubre ya teníamos un MVP y de ahí en adelante sería cuestión de pulirlo.

Comenzamos el proyecto siendo 3 programadores, pero para antes de los primeros tres meses el equipo de programación se redujo a 1 ya que un programador tuvo que cambiar de domicilio por un mejor trabajo, y otro fué recortado de su trabajo y nosotros entendimos que hacer juegos como hobby no iba a ser la prioridad de ellos durante los siguientes meses.

En LunarCrown siempre pensamos primero en las personas antes del trabajo, y al final de cuentas, era un tiempo en conjunto que estabamos brindando para el proyecto, así que no hubo malos entendidos, siguieron siendo parte del equipo y daban su retroalimentación pero no tenían asignadas tareas cada semana.

¿Saben que pasó también a finales de 2019 y a principios de 2020?

La pandemia de COVID-19 afectó a todas las industrias y los trabajos de todos incluídos donde trabajaban otros 2 miembros del equipo, donde tuvieron que reducir al personal y un miembro de LunarCrown también fué despedido y el que quedó absorbió varios puestos.

Así que una vez más ciertas tareas iban a quedar en espera mientras todo se fuera acomodando y tuvieran más tiempo libre para dedicarle al proyecto.

Yo creo que en este punto, más de una persona hubiera puesto a este proyecto en espera y re-pensar el alcance, o quizás lanzar un juego más sencillo, o alguna otra solución.

En nuestro caso, el equipo de arte había terminado con sus tareas, y había hecho tan buen trabajo que nos parecía un desperdicio no terminar Dots of War.

Así que decidimos avanzar un poco más lento pero sin dejar de seguir adelante. Después de todo, el juego ya estaba casi listo, solo faltaba ese último 10%.

El peor error que tuvimos

Aspecto de Samurai opcional para la clase de Humanos

Somos un equipo que nos gusta compartir avances, bugs y demás detalles durante el proceso de desarrollo de un juego, Dots of War no fué la excepción, no teníamos una campaña de Marketing pre-establecida a parte de la difusión que nosotros mismos le dabamos al proyecto con conocidos, familiares y en redes sociales.

Además de participar en post donde se compartían avances o en #screenshotsaturday.

Dado el gran avance que teníamos, cometimos el que considero fué el error más grande durante todo el proceso de desarrollo del proyecto.

Comprometernos a una fecha de salida del juego.

A finales de Marzo calculamos lo que se tenía que terminar de hacer (incluír las compras de aspectos en la aplicación y hacer todo el proceso de aceptación para itunes) y evaluamos la fecha en la que tendríamos todo listo, así que lo implementamos y comenzamos el proceso para subirlo a iTunes.

En esta parte iba a comentar una larga lista de cosas que me disgustaron del proceso que tiene apple para subir sus aplicaciones pero prefiero resumirlo con:

No tengo nada bueno que decir sobre el desarrollo de aplicaciones para apple o su plataforma.

Para las personas interesadas en publicar su juego con Unity en iOs, aquí están algunos consejos que aprendimos a la mala.

Ten a la mano una Mac con la versión de Unity en la que estás desarrollando, hay opciones como Unity Cloud build pero si existe la ligera posibilidad de que tengas que alterar algún archivo de configuración para iOs, consigue una mac con algun conocido o miembro de tu equipo.
Los estados de tu aplicación toman tiempo, nadie sabe cuánto pueden tomar y no tienes control sobre cuanto pueda tardar.
Ten en cuenta que iOs es muy selectivo con los plugins que puedes usar en tu proyecto, en algunas ocasiones ciertos plugins pueden alterar algunos permisos de tu aplicación que te dará un dolor de cabeza una vez que te comiencen a rechazar tu aplicación y rastrear el codigo de error que te envía apple.

¿Por qué digo que dar una fecha de lanzamiento fué el peor error que cometimos?

Porque en realidad no teníamos la necesidad de dar una fecha clara de lanzamiento, hubieramos podido lanzar de igual manera en alguna otra fecha y no hubiera habido problema o enojos, dar una fecha de lanzamiento pone un peso extra en el equipo de trabajo y en este caso que era un proyecto de Hobby, nadie nos lo estaba pidiendo salvo nosotros.

Burnout

Durante este proyecto tuve que tomar dos descansos por el burnout (o síndrome de agotamiento/fatiga) que sentía, uno en Diciembre para tener la oportunidad de pasar más tiempo con mi familia, y otro en Mayo, cuando la pandemia estaba en el alza y el estrés que tenía por trabajar se manifestó como una erupción en la piel de mis manos que hasta ahora no se ha ido completamente (lavar constantemente mis manos y ponerle alcohol para prevenir el COVID tampoco ayuda)

Justo antes del lanzamiento hicimos el alcance a los medios enviando correos personalizados a unos 200 sitios web para que cubrieran el lanzamiento, corregimos los últimos bugs, y pudimos lanzar el juego.

Cuando te das cuenta que el ultimo 10% es en realidad el ultimo 30%

Una vez que lanzamos el juego y tuvimos las impresiones externas, nos dimos cuenta de algunos bugs menores, y uno mayor (no se podían comprar los aspectos), teníamos un grupo de usuarios alfa que nos ayudaron mucho durante el desarrollo, pero nunca probamos directamente esa parte con ellos, solo de manera interna.

En ese momento, ya que vimos que el esfuerzo por contactar a la prensa no dió los resultados que esperábamos (terminamos siendo cubiertos por algunos portales, pero en general muchos sitios web te piden dinero para cubrir tu juego, dinero que no teníamos presupuestado así que tuvimos que dejar pasar esa oportunidad) y al tener a todo el equipo realmente cansado, decidimos tomarnos unos días para descansar, y volver al proyecto con ojos más frescos.

Al final los errores fueron corregidos y el proyecto estaba completo en su primera versión, habíamos hecho un juego en conjunto con un equipo 100% remoto y terminamos Dots of War.

¿Que hacer en caso de incendio?

Teníamos planeado toda una estrategia de mercadotecnia antes del lanzamiento que incluía:

Asistir a eventos locales
Asistir a eventos nacionales de desarrollo de videojuegos
Hacer presentaciones públicas donde los asistentes pudieran probar el juego, darnos sus comentarios, ganar premios.
Ir a las televisoras y medios de comunicación.

Pero cualquier actividad presencial se descartó totalmente a partir de Marzo de 2020 aquí en México cuando oficialmente se iniciaron los planes de cuarentena.

Al ser un equipo que ya trabajamos de manera remota, no nos afectó a la hora de trabajar pero si nos vimos bastante afectados en otras áreas, tanto en nuestro trabajo formal como en nuestras relaciones interpersonales, fueron meses de mucho estrés personal así que no se le pidió a nadie que hiciera más trabajo de lo que se sintiera cómodo y relajamos bastante la noción de las fechas de entrega.

Aún así trabajar tu turno completo desde casa, encargarte de tu familia y trabajar en un proyecto como este, aunque sea de hobby, toma un precio sobre uno y varios miembros del equipo experimentamos el burnout en mayor o menor medida.

Lo mejor que se puede hacer en esos casos es tomar un paso atrás, respirar profundo y evaluar cuales son las prioridades que se tiene, tomarse un tiempo para descansar y cuando estemos en un mejor estado mental, continuar.

Nos sentimos muy agradecidos de formar parte de un equipo que entiende y es responsable por los miembros que lo conforman, que sabe exigir resultados pero que también se preocupa realmente por la persona que los está entregando, después de todo, comenzamos como un grupo de amigos con una meta en común, y nuestra relación es más importante que cualquier proyecto.

¿Qué aprendimos?, ¿Cómo podemos terminar esto en una nota felíz?

El desarrollo de Dots of War no es una historia de éxito comercial o mediático, pero sí una historia de éxito para el desarrollo de videojuegos en equipos remotos.

Cualquier juego que se termine es un éxito.

Hay muchas áreas de oportunidad en Dots of War, pero también estamos muy contentos con lo que logramos, se hizo un precedente para este tipo de desarrollos, sin fondos, sin inyecciones de dinero de terceros, sin préstamos o ayuda de gobierno, todas formas válidas de empezar a hacer juegos, pero no las únicas.

Siempre va a existir la manera de avanzar con un proyecto, y ni siquiera una pandemia o el fin del mundo lo puede detener.

¿Qué pudo haber salido mucho peor?

Se tomaron buenas y malas decisiones durante el desarrollo de Dots of War, algunas basadas en tiempo y otras en dinero.

Mucho antes de comenzar este proyecto, hablamos entre los miembros del equipo sobre crear un juego para PC y consolas con un modelo de desarrollo muy parecido al que teníamos (pero incluyendo una oficina prestada por un grupo de inversionistas), a la mitad del desarrollo de Dots of War nos dimos cuenta que si nos hubiéramos comprometido en realizar aquel juego con ese alcance mucho más grande, nos hubiera colocado en una situación mucho más difícil y para nada rescatable como lo fué este proyecto.

Estamos muy contentos con los resultados que tuvimos y con las decisiones que tomamos, pero también estamos muy contentos con las otras decisiones que no tomamos.

¿Qué es lo que sigue?

Como nota final, queremos agradecer a todos los involucrados durante el desarrollo de Dots of War, a todos los beta y alpha testers, a la comunidad de Unity user group HMO que nos apoyó desde el inicio, a las personas que se fueron enterando del proyecto y nos dieron sus palabras de ánimo y a todos los jugadores de Dots of War.

Muchas gracias, hicimos lo mejor que pudimos en el momento que pudimos.

Ahora mientras nos recuperamos del Burnout, nos queda claro que siempre habrá más juegos por hacer, un siguiente proyecto que hacer y cuando desarrollas como un pasatiempo y para aprender, no le tienes que rendir cuentas a nadie.

Está bien aprender de nuestras experiencias y no pensar que fueron un fracaso, está bien dar un paso atrás o quedarse un tiempo donde mismo para recuperar el aliento, cada quién avanza a su paso y nos alegra mucho saber que lo seguimos intentando.

Para LunarCrown seguramente hay más proyectos que dada la situación actual, no sabemos que forma puedan tener en un futuro inmediato, pero tenemos seguro que contaremos los unos a los otros para seguirnos apoyando.