Pay-to-Win: Nobody Pays and nobody Wins.

Primero aclaremos el término: Pay-to-Win (Pagar-para-Ganar) se refiere a la práctica de diseño que resulta en un juego en el que para poder progresar TIENES que pagar, entonces llega un momento en el que el juego te presenta algún tipo de bloqueo que para poder pasarlo y continuar progresando debes pagar (dinero de verdad, por si hay dudas).

Yo he visto muchos debates al respecto, pero la mayoría se centran en el aspecto "ético" de diseñar algo que se siente explotador y deshonesto con el jugador, como si los estuviesen robando y no dejándoles otra opción que pagar y pensando que al hacer esto la gente simplemente paga, en contra de su voluntad, por un juego que detestan, como zombies.

Foto tomada en el momento en el que un grupo de jugadores pagan como zombies por un juego que detestan

Esto no podría estar más lejos de la realidad, ya que la verdad es que en el momento que a un jugador se le presenta este tipo de bloqueo simplemente abandonan tu juego, hay demasiadas opciones y todas están un click o un tap away, y con Free-to-Play (F2P) estamos educando al jugador (para bien o para mal) a probar muchas opciones y quedarse con la que lo engancha desde el principio, lo cual es un cambio de paradigma de los juegos Pay-to-Play, como los juegos de consola, ya que una vez que el mercadeo y los reviews hacen su efecto, compras tu juego y si no te engancha desde el principio igual sigues jugando, ya lo pagaste, es como el cine vs la TV, en el cine la película tiene que ser realmente mala para salirte, mientras que en la TV no lo dudas para cambiar de canal si no te engancha lo que estás viendo. Nuestros niveles de tolerancia son mucho más elevados mientras más dinero hayamos pagado adelante y nos volvemos totalmente intolerantes cuando no pagamos nada adelante, y por eso el "onboarding" o First Time User Experience (FTUE) es tan crítico para el éxito de un F2P.

Gráfica totalmente inventada de la relación entre pago upfront y la tolerancia de un jugador para mantenerse en el juego.

Entonces mientras muchos piensan que Pay-to-Win es una práctica poco ética, pero que genera mucho dinero para los creadores del juego la verdad es que, además de una práctica "tosca" de diseño, es simplemente una pésima práctica de negocio.

Y tengo pruebas, les presento "Exhibit A": nuestra experiencia con Hans Hans, como ya comenté en una entrada anterior nosotros tuvimos que lanzar el juego en la fecha acordada y para poder lanzarlo tuvimos que eliminar la economía "soft currency" para reducir complejidad y dejar solo el "hard currency", quedando con un juego totalmente Pay-to-Win. Sospechábamos que esto iba a afectar nuestra monetización, pero hoy en día lo puedo decir con conocimiento de causa, señores del jurado: Pay-to-Win es una pésima práctica de negocio y que estamos seguros que es una de las principales causas de la baja retención que tiene el juego en este momento (y por eso estamos en este momento implementando la economía soft-currency ;))

La razón obedece a que un juego Free-to-Play realmente "vende tiempo", es decir, el jugador espera poder jugar indefinidamente sin TENER que pagar y cuando llega a cierto punto en el que siente que progresa muy lento tiene la OPCIÓN de pagar para progresar más rápido.

Entonces, apartando los temas éticos, artísticos, emocionales y pasionales, Pay-To-Win, visto desde un punto de vista totalmente pragmático y de negocio simplemente no funciona.

Un ejemplo de un juego F2P que funciona a la perfección es Clash of Clans, y esto en gran parte es porque han diseñado su economía soft currency de una forma impecable, teniendo por ejemplo casos en los que van duplicando el costo necesario para hacer un nuevo upgrade, resultando en una progresión exponencial en la que al llegar a cierto nivel debes reunir montos muy elevados y esperar días para que se haga el upgrade, pero no te dicen: hasta acá llegaste, ahora paga!

Tabla de economía de las "minas de oro" en Clash of Clans. fuente: http://clashofclans.wikia.com/wiki/Gold_Mine

En conclusión: Diseña tus juegos Free-To-Play de manera que siempre tus jugadores puedan quedarse jugando indefinidamente sin tener que pagar, pero diseñando tu economía de manera tal que en un punto del juego el progreso comience a ser mucho más lento y en ese momento el jugador tenga la OPCIÓN de pagar para progresar más rápido, ya que poner barreras y exigir al jugador tener que pagar para progresar, simplemente no funciona, ni desde el punto de vista de experiencia, ni desde el punto de vista de monetización y de negocio.

Y cuál es el problema?

No sé si pasa en todas las industrias, pero después de un tiempo haciendo videojuegos uno empieza a pensar que todo gira en torno a su industria, todo es mecánicas de juego, economía de juego, core loops, platformers, GDCs, GDDs, TDDs, MMOs, RPGs, MOBAs, etc! Lo malo de todo esto es que se deja de ver más allá y de conectarse con otras influencias externas a nuestra industria y en todo este proceso perdemos perspectiva.

Sobre todo perspectiva de negocio, pensamos que la unica manera de lograr un hit es creando el siguiente Angry Birds, hasta que sale un Clash of Clans y entonces ahora todos a correr a crear el siguiente Clash of Clans, y así sigue el proceso, like a dog chasing cars, sin entender realmente qué es lo que hizo a esos juegos exitosos en el contexto de mercado y el momento en el que fueron publicados.

Afortunadamente hace unos dos años comencé a participar en procesos de formación y mentorías en el area de emprendimiento, el primero fue Emprende País, un proceso operado por Endeavor . Más recientemente tuve la suerte de tener un proyecto seleccionado para ser acelerado por Wayra. Estas dos experiencias me han puesto en contacto con personas brillantes de otras industrias, con experiencias interesantísimas y perspectivas muy diversas, lo cual me ha permitido sacar la cabeza un rato de mi pequeño mundo del desarrollo de videojuegos.

Y definitivamente una de las cosas que más me ha puesto a pensar es la bendita pregunta que le hacen a uno en estos procesos (y también muy común en los círculos de inversionistas): "cuál es el problema?"

Sí, cuál es el problema que soluciona tu producto o servicio?, a lo cual respondía con muchísima seguridad, "ahhh nooo, pues ningún problema, esto es entretenimiento! entonces quizas el 'problema' es el ocio o el aburrimiento, pero acá no hay ningún problema, esas son preguntas para software administrativo y otros negocios aburridos, estos son VIDEOJUEGOS! acá no se puede pensar en términos del 'problema a solucionar'"

Correcto no? .. Incorrecto! o al menos eso creo después de haber meditado y ayunado por un largo periodo, entrar en estado zen, ver la luz y volver... bueno quizas exagero con lo del ayuno y la meditación, pero sí lo he pensado bastante! y mi conclusión es que sí podemos diseñar juegos que resuelven 'problemas', sólo que los problemas no son obvios como reducir el tiempo de procesamiento de la contabilidad o eliminar el intermediario en la cadena de valor, y tampoco me refiero a serious games ni gamification, me refiero a productos de entretenimiento que pueden ser enfocados bajo el paradigma de 'Cuál es el problema?'.

Y entonces, cuál es el problema?

Pienso que en videojuegos los problemas están asociados a circunstancias específicas que se crean al rededor de las dinámicas del negocio. Ok, bla bla bla... Mejor les pongo algunos ejemplos para ilustrar lo que quiero decir:

- La adquisición de usuarios se ha vuelto super costosa y competida. Este es un problema concreto y en un nuestro juego Hans Hans Batalla por Asgard, del que he hablado bastante en posts anteriores, utilizamos un método de adquisición de usuarios bien diferente a los métodos establecidos en la industria: adquirimos usuarios a través de cuadernos, llevando el costos de adquisición de usuarios prácticamente a cero.  Al enfocarnos en atacar el problema del costo de adquisición de usuarios se nos presentó una alternativa cost-effective e hicimos nuestro negocio más viable.

- Otro enfoque al mismo problema de costo de adquisición de usuarios es cómo puedo hacer mi juego más viral (aumentar K-factor) y diluir mis costos de adquisición. Distintos juegos han encontrado soluciones para este problema, Zynga lo hizo hace unos años obligando a las personas a compartir con sus amigos para avanzar en el juego y le funcionó por un tiempo, hasta que el problema se transformó en "cómo hacer el juego viral sin que la gente lo odie por utilizar técnicas 'Spammy'" y entonces salieron juegos como Clash of Clans donde la virálidad es mucho más orgánica por toda la dinámica que establecieron de clanes y donaciones.

- Otro problema podría ser cómo entretener a los usuarios en plataformas móbiles si los períodos de atención son muy cortos? esto suena obvio hoy en día ya que es casi una premisa de diseño universal para juegos móviles aplicar el "Stabucks test" (sesiones de juego que duren el tiempo que alguién estaría en la fila de Starbucks, o Juan Valez en nuestro caso), pero es un problema que se pensó y se resolvió en un momento y ahora todos adoptamos este approach casi inconscientemente.

Entonces al diseñar un juego creo que hay que pensar no solo en el componente de entretenimiento, sino en los problemas reales del negocio: adquisición de usuarios, retención, etc. entiendiendo cuáles son los retos principales que está teniendo la industria (que cambian constantemente) y enfocando el modelo de negocio de tu juego en resolver alguno de estos problemas y que esa resolución del problema esté integrado "by design" en las mecánicas de tu juego, con eso no solo tendrás mejores probabilidades de que a tu juego le vaya bien sino que tendrás una respuesta para cuando te pregunten: "cuál es el problema que resuelve tu producto?", y podremos dormir tranquilos :)

Funnel Analysis: la clave para mejorar retención y monetización.

Hasta ahora he hablado de métricas que nos ayudan a saber cómo le va al juego y compararlo con otros juegos, pero no de herramientas específicas para mejorarlo.

Entonces cómo podemos subir retención y mejorar ARPU? pues como todo problema la solución comienza por entenderlo y eso quiere decir tener data muy detallada para poder determinar exactamente dónde y cuándo estamos perdiendo nuestros usuarios, y eso es justamente lo que se logra con un "análisis de embudo" o como lo llaman en Ingles: Funnel Analysis.

Funnel Analysis

Conceptualmente entonces el funnel luce algo así:

Donde por un lado entran todos los usuarios que llegan a tu juego y en cada una de las etapas del juego vas perdiendo usuarios. Lo que normalmente ocurre es que aquellos que avanzan más en el embudo y que se mantienen jugando son los que pagan por tu juego (recuerden que estamos hablando de juegos free-to-play).

Pero realmente se ve algo así:

Aunque se puede ver "más bonito" y amigable si usas una herramienta como Mixpanel:

Pero en escencia el análisis es el mismo: cuantos usuarios llegan a un punto dado de tu juego y cuantos pasan al siguiente, calculando el % de usuarios que se mantienen de un paso al otro.


Qué herramienta usar para hacer funnel analysis?

En nuestro caso hemos decidido no usar ninguna herramienta sino capturar directamente la data en una base de datos distinta a la del juego y hacer data mining de esa base de datos a punta de queries, dependiendo de lo que nos haga falta medir.

Hemos decidido hacerlo así para tener todo el control de la data, cosa que nos ha ayudado muchísimo en este proceso inicial de aprendizaje porque no estamos limitados a lo que ofrece una herramienta y nunca nos queda la duda de cómo estará la herramienta obteniendo y calculando la información que nos provee, ya que nos podemos meter "under the hood".

El plan es más adelante automatizar estos queries y tener nuestra propia "herramienta" de analytics.


Funnel Analysis para Hans Hans

Ningún estudio por más grande que sea tiene recursos ilimitados, y si tu estudio es pequeño como el nuestro pues los recursos son mucho más limitados, así que la clave es enfocarse donde hace falta y tal como comenté en un post anterior es muy importante priorizar. Copio de nuevo esta lámina que pienso que resume muy bien el enfoque:

Lámina tomada de http://www.slideshare.net/agarimella/social-gaming-metrics

Lo que hicimos en nuestro caso fue primero realizar mediciones generales para decidir dónde enfocarnos, y nos dimos cuenta que estamos perdiendo más de la mitad de los usuarios entre que llegan a www.normajuegos.com hasta que finalmente llegan al Home del juego, entonces estamos perdiendo más la mitad de los jugadores antes de jugar!

Perdemos más de la mitad de los usuarios entre este punto...

... y este.

Y acá es donde la premisa de "Prioritization" se aplica al máximo: no tiene sentido medir cuál es el personaje que más eligen los jugadores, cuanto tiempo pasan jugando, cuál es el arma que más eligen, cuantos enemigos derrotan en una partida, etc. cuando más de la mitad se nos está yendo antes de siquiera ver un pixel del juego como tal.

En base a este descubrimiento decidimos entonces "meterle la lupa" a este proceso inicial, midiendo cada click desde que el usuario llega a la página hasta que entre al juego, sacando %s de cuantos usuarios permanecían de un paso al siguiente y encontramos que nuestras áreas donde más usuarios estamos perdiendo son las siguientes:

- Alrededor de 30% está haciendo click en el botón de "Cerrar" del formulario de registro (no se registran aun cuando hicieron click en registrarse y llegaron al formulario).
- Del remanente (los que sí se registran) casi un 50% se van antes de instalar Unity.
- Y de los que quedan un aprox de 25% se van durante el proceso de loading.

Lo bueno de esto es que entonces te permite analizar cada problema por separado, buscando soluciones para situaciones específicas, aplicando el famoso "divide y vencerás".
Así estamos analizando y atacando cada uno de estos 3 grandes momentos de fricción:

Registro: 

Estamos capturando cada vez que un usuario hace click en el boton de cerrar el formulario de registro y  cada vez que ejecuta esta acción es porque: hizo click en "Creala ahora", vio el formulario y algo lo llevo a que decidiera no registrarse y cerrar el formulario.

Estamos atacando este problema específico de dos maneras:
1. Haciendo un registro paso a paso, más amigable y "asistido", dando mejores mensajes de validación.

2. Se nos ocurrió también que cuando el jugador haga click en cerrar el formulario le vamos a mostrar una ventana que le de la opción de registrarse con facebook.

Instalación Unity player:

Con la instalación de Unity estamos implementando instrucciones lo más amigables posibles. También estamos esperando con muchas ansias la integración de Unity y facebook  , para mover el juego a facebook, esto debería reducir dramáticamente esta fricción.
Pero la solución absoluta será cuando pasemos el juego a tabletas, ya que el juego será una app nativa y no requerirá la instalación de ningún plugin. Pero para esto falta mucho aun, primero queremos tener un juego que retenga y monetice bien en la web, donde podemos hacer updates hasta varias veces al día si queremos, y luego moverlo a plataformas móviles, donde los updates deben ser muchísimo más esporádicos.

Loading: 

Este es uno de los puntos de fricción que podrían ser fáciles de soluciones y básicamente lo que estamos haciendo es tener un loading mejor distribuido, ya que en este momento se está cargando todo el juego en ese loading inicial.


Todas estas medidas deberían contribuir a reducir fricción (nunca eliminar, ya que hay que estar claros que cualquier paso adicional que lo pones al jugador crea fricción, entonces lo ideal es tener la menor cantidad de pasos posibles y hacerlos sencillos para el jugador). En cuánto pensamos que reduciremos fricción? ya lo mediremos!

Resumiendo, algunas consideraciones y recomendaciones al hacer funnel analysis:

• Para poder elevar tus números de retención y ARPU debes hacer un detallado Funnel Analysis midiendo cuantos usuarios se mantienen de un paso al siguiente de tu juego.
• Realiza primero un análisis macro y a partir de ahí decide donde "meter la lupa". 
• Una vez que encuentres donde está el problema general mide paso por paso, click por click, para entender lo que está pasando. "Divide y vencerás".
• Enfocar tus (limitados) recursos donde puedes hacer una diferencia significativa (i.e. donde estes perdiendo más jugadores).
• Comienza con establecer qué vas a medir e implementa estas llamadas en tu juego. Guarda esta data en una BD distinta a la del juego, para no poner en riesgo la estabilidad de tu build en producción.
• Una opción totalmente viable es usar tu propia base de datos, aunque hay herramientas muy buenas como Mixpanel.
• Toma decisiones de mejora de tu juego en base a lo que arroje el Funnel Analysis. Mide de nuevo una vez que hayas implementado los cambios, and repeat ;)

Como siempre, espero que esta info sea de ayuda.

Kike.

Lanzamiento Hans Hans - Aprendizajes (Parte 2: show me the moneeeey)

En el post anterior me enfoqué en dar un poco de contexto del proyecto y hablar sobre la importancia de medir retención, así como compartir los nros de retención D1 que tenemos actualmente para el juego.
En este post me voy a enfocar en uno de los aspectos más importante a nivel de negocio: La monetización y más específicamente me enfocaré en dos métricas vitales para entender la monetización de un juego: ARPU y ARPPU.

ARPU

ARPU significa Average Revenue Per User o Ingreso Promedio Por Usuario y básicamente se mide tomando todos los ingresos generados por el juego en un período dado y dividirlo entre el nro de usuarios que jugaron es ese mismo periodo (usuarios activos), que puede ser un dia, un mes, un año, etc. Entonces para ser más precisio se usan términos como ARP DAU (Average Revenue Per Daily Active Users) o ARP MAU (Average Revenue Per Monthly Active Users) que son básicamente decir que estás tomando el ARPU en base diaria o en base mensual respectivamente. Claro hasta acá? para que no quede ninguna duda:

ARPU es el ingreso promedio por usuario activo (generalmente cuando no se especifica el periodo de tiempo se asume que es en un mes pero también se usa anual).
ARP DAU es el ingreso promedio por usuarios activos diarios.
ARP MAU es el ingreso promedio por usuarios activos mensuales.

Para efectos de este post usaré ARPU en base mensual, equivalente a ARP MAU.

ARPPU

Qué es ARPPU (con dos "P") entonces? (en ingles lo pronuncian como AR-Pi-Piu) es el ingreso promedio por usuario que paga, por ejemplo si tengo 1000 usuarios activos en un mes y solo 2 de ellos pagan, uno de ellos ha pagado $5 y el otro usuario ha pagado $7 el ARPPU es $6 = ($5+$7)/2 ,  mientras que el ARPU sería de $0.012 ($12/1000).. sencillo también, right?

ARPU y ARPPU en Hans Hans ... Show Me The Moneeey!

Entendiendo entonces estos dos conceptos básicos, ARPU y ARPPU, cuales han sido los valores que hemos obtenido para Hans Hans para estos dos indicadores?

En el caso de Hans Hans nuestro ARPU mensual (o ARP MAU) ha sido de $0.026 USD en nuestro primer mes de operación vendiendo bienes virtuales a través del juego.

Nuestro ARPPU, al momento de escribir este blog está en 8,128 pesos colombianos, unos $4.5 USD.

Esto nos lleva entonces a nuestra pregunta obligada, son estos valores buenos o malos?

Comparaciones... the right way.

Es importante comparar tus números con referencias que hagan sentido para tu juego, en nuestro caso lo ideal sería conseguir números de juegos web based, free-to-play, en Latam y dirigidos al demográfico de 8 a 14 años, pero realmente no he logrado conseguir números de juegos que reunan todas esas características (si consiguen algunos serán muy bienvenidos! :))

Entonces me he dedicado a conseguir números de juegos que sean lo más "parecidos" posibles.

En esta presentación de Kongregate proveen algunos ARPUs y ARPPUs que me parecen muy interesantes:
http://twvideo01.ubm-us.net/o1/vault/gdc2012/slides/Summit_Social%20&%20Online%20Games/Greer_Emily_Core%20Games%20Real.pdf

Y la razón por la que me parece una muy buena referencia para nosotros es porque Kongregate es una plataforma de juegos web (y definitivamente plataforma es uno de los aspectos a tomar en cuenta cuando hagas análisis comparativo para tu juego, no es lo mismo el ARPU en un juego web que en juego mobile, incluso pueden haber diferencias significativas de iOS a Android).

Otras dimensiones importantes a tomar en cuenta son la ubicación geográfica, el demográfico, el genero del juego (builder, tower defense, adventure...), entre otras, pero básicamente el mensaje es que todas estas dimensiones tienen un impacto en la monetización y mientras más parecidas sean las referencias a tu juego, mejor información te van a aportar.

Aja, pero entonces, good, bad (or ugly)?

Pues ni bueno ni malo (aunque quizas un poco ugly no? XD), sino consistente con los números que se esperan de un juego lanzado en Latam, ya que es ya casi una regla que un juego en Latam tiene un ARPU entre 5 y 10 veces menor (again, ugly) al de un juego en Norte America, esto se lo he escuchado a distintas personas que trabajan en compañías grandes de USA que distribuyen juegos en muchas regiones, incluyendo NA y Latam, por lo que han comparado números en ambas regiones para muchos juegos.

Entonces, comparando los ARPUs provistos en la presentación de Kongregate con el de Hans Hans ($0.026):

Kingdom Rush = $0.05 -> aprox 2 veces mayor
Bloons = $0.09 -> aprox 4 veces mayor
GemCraft = $0.16 -> 6 veces mayor
Defender's Quest = $0.11 -> 4 veces mayor

Podemos ver que los juegos tomados tiene un ARPU entre 2 a 6 veces mayor al de Hans Hans. No está tan mal, considerando lo antes mencionado sobre el ugly ARPU en Latam.

Ahora, comparando los ARPPUs

Kingdom Rush = $3 -> menor que el de Hans Hans
Bloons = $4.35 -> casi igual al de Hans Hans
GemCraft = $5 -> casi igual al de Hans Hans
Defender's Quest = $5 -> casi igual al de Hans Hans

Debo confesar que esto no me lo esperaba cuando comencé a estudiar nuestros números: nuestro ARPPU es de hecho muy bueno! mientras que nuestro ARPU está entre 2 a 6 veces menor que estos juegos usados para comparar, nuestro ARPPU más o menos igual!

Cómo debo interpretar esto? pienso que es un problema de "fricción" a la hora de pagar, ya que tenemos un problema de no muchos usuarios pagando (bajo ARPU), de hecho nuestra "conversión" -usuarios que pagan/total usuarios- está alrededor del 0.37%, cuando debería estar al menos entre el 1% o 2%, pero el que se decide y logra pagar, paga "bastante" (alto ARPPU). Mi apuesta sobre por qué pasa esto: métodos de pago.

Métodos de pago, la gran barrera.

Algo que afecta significativamente en nuestra región son los métodos de pago, ya que partamos del punto que la bancarización en nuestra región es más baja que en USA, lo cual significa menos personas con tarjetas de crédito, también tenemos mayor resistencia a usar las tarjetas en línea, aparte de tener un poder adquisitivo más bajo, al sumar todo esto resulta lógico que el ARPU en nuestra región sea más bajo que en Norte America.

En este momento sólo tenemos dos métodos de pago en el juego:

1- Tarjetas de prepago vendidas a través de (algunos pocos) automercados Éxito
2- Pagos en línea a traves de librerianorma.com

Ninguno de los dos son muy efectivos: el primero está limitado a sólo unos pocos Exitos, de hecho muchos niños nos han escrito que van al Exito y no consiguen las tarjetas, gran costo de oportunidad!

mensaje de un niño en nuestro fan page (por favor traten de obviar la ortografía)

El segundo ha demostrado ser bastante inefectivo con nuestro demográfico (además pienso que hay problemas serios de usabilidad una vez entran en la tienda virtual), ya que de 15,000 clicks que hemos recibido en esta opción solo 5 (si CINCO) han comprado usando esta opción, no quiero ni sacar el %, simplemente concluyamos que es casi como si no tuviésemos ese medio de pago, ya que el impacto de tenerlo ha sido casi cero, pero sin duda otro gran costo de oportunidad.

En este momento estamos trabajando duro en lograr métodos de pagos que sean más sencillos para nuestros usuarios, como pagos con efectivo, SMS, depósitos, etc. y pronto tendremos varios de estos implementados en el juego. Afortunadamente no hemos hecho un lanzamiento global, y apenas este mes vamos a lanzar en nuestro segundo país: Ecuador, con lo cual seguiremos mejorando el juego tanto desde el punto de vista de retención, como incorporando métodos de pagos que hagan sentido para nuestra región (más sobre esto y el impacto sobre nuestra monetización cuando los hayamos implementado).

Bonus question ;) : Cuál es tu experiencia con la monetización de juegos? en base a lo mencionado en este post podrías calcular tu ARPU y ARPPU? cuáles crees que son los factores que influencian la monetización que estás logrando actualmente con tu juego?

Compartamos esta información y comencemos a entender mejor los números en nuestra región y busquemos soluciones a los problemas que tenemos para monetizar nuestros juegos, les puedo jurar que llegaremos a conclusiones similares y las soluciones que consigamos nos serán muy útiles a todos.. yo por mi lado seguiré compartiendo todo lo que pueda, esperando que la suma de todas nuestras experiencias sirvan para seguir empujando esta gran industria hacia adelante en nuestra región.

La parte 3 pienso dedicarsela a "Funnel Analysis"... hasta la próxima ;)

Lanzamiento Hans Hans Batalla por Asgard - Aprendizajes (Parte 1)

Tal como comenté en mi Hola Mundo, la idea de este blog es compartir experiencias, buenas y malas, de lo que hago en mi día a día para desarrollar videojuegos desde Latino America y vivir de ello, esperando que ojalá otras personas que estén haciendo lo mismo, o quieran hacerlo en algún momento, puedan beneficiarse de conocer nuestros aciertos y desaciertos.

Hace dos meses lanzamos Hans Hans Batalla por Asgard en el mercado colombiano, así luce el juego:

Capturas de panatalla de Hans Hans - Batalla por Asgard.

Esta semana alguien me preguntó en el grupo de facebook de IGDA Colombia cómo nos había ido con el lanzamiento y la respuesta me pareció que iba a ser tan larga que preferí escribir este blog post. Espero que no sea demasiado largo, pero es que hay mucho que contar porque el aprendizaje ha sido intensivo, y sobre todo porque mi idea no es montar una "nota de prensa" mostrando la mejor cara posible del juego, sino realmente mostrar una radiografía del proceso, señalando errores y aprendizajes, para que ojalá alguien pasando por el mismo proceso pueda obtener algo útil, aclarando que estoy lejos de considerarme un experto en free-to-play y que lo que que comparto acá es el aprendizaje de unos pocos meses de experiencia en este tipo de producto.

Primero un poco de contexto sobre el proyecto

Hans Hans Batalla por Asgard es un juego web, Player vs Player (PvP), basado en equipos y Free to Play (F2P), cuya monetización (como casi todos los juegos F2P) está basada en la venta de bienes virtuales. En este momento tenemos un solo modo de juego: captura de la bandera (que en nuestro juego es una runa), pero pensamos expandir con modos de juego adicionales en el futuro.

Algo muy particular de este juego es que el mecanismo de adquisición de usuarios ha sido promoviendo el juego y la marca a través de los cuadernos Norma, ya que nuestro aliado (que hasta podríamos llamar publisher, ya que financió el desarrollo y ha provisto el mecanismo principal de mercadeo) es la compañía colombiana Carvajal, dueños de dichos cuadernos.

Cuadernos Norma de Hans Hans en el automercado Éxito.

El juego ha sido lanzado solamente en Colombia (restringido por IP en este momento para que no se pueda acceder desde otro país) y poco a poco lo iremos lanzando en otros países de Latam (y quizas más adelante en otras regiones). Así que si vives en Colombia puedes jugar Hans Hans Batalla por Asgard acá.

También existe un fan page en facebook y un blog. (en otra entrada escribiré sobre la experiencia que hemos tenido en community management y de adquisición de usuarios, ya que es todo un tema).

Vanity Metrics

Ian Brillembourg, un buen amigo que trabaja actualmente en U4iA con Dusty Welch (co-fundador de la franquicia Call of Duty) en un proyecto muy interesante llamado Offensive Combat que busca traer la experiencia de los hard core games a plataformas sociales, es un verdadero experto en temas de monetización de juegos free-to-play y me ha ayudado muchísimo a entender todo este tema. Ian llama a todas esas cifras que uno muestra hacia afuera (MAU, DAU, Installs, Registered users..) las "vanity metrics" o "métricas de vanidad" y la verdad que lo son, porque no sirven de mucho a la hora de querer hacer un análisis útil para optimizar la monetización del juego.

Estas son nuestras "Vanity Metrics":

- Al momento de publicar este post tenemos 50,244 jugadores registrados. Estos son todos jugadores en Colombia, ya que es el único país donde hemos lanzado.
- Nuestros Usuarios Diarios Activos o Daily Active Users (DAU)  están alrededor de 1,000 DAU.
- Nuestros usuarios activos mensuales (MAU) están alrededor de 20,000 MAU.

No son números demasiado grandes, pero para ser solamente Colombia y con menos de dos meses de historia no están mal, así que vanity metrics: check.

Pero esos números no dicen mucho sobre cómo le va a al juego realmente (ojo: no quiere decir que no haya que medirlas también, ya que sin duda aportan información necesaria)

Entonces cuáles son las medidas que realmente importan? algunas extremadamente importantes son: Retención, ARPU y ARPPU.

Retención

En esta entrada me voy a concentrar sólo en Retención, y elijo esta primero no por azar, sino porque a su vez retención afecta todo lo demás, ya que un usuario retenido es un usuario más propenso a pagar eventualmente por tu juego y un usuario que paga por tu juego es un usuario más propenso a volver a pagar por tu juego, entonces en mi caso particular la Retención se ha convertido en nuestro "score" de cómo vamos con el juego, y la medimos diariamente, compulsivamente, obsesivamente! Para mí se ha convertido en un "meta-juego de analíticas".

La retención generalmente se mide tomando un día como referencia (llamemoslo día 0 o D0), obteniendo los usuarios que se registraron (o que instalaron en el caso de juegos móbiles) ese día específico y viendo cuantos de esos jugadores regresan al día siguiente (retención D1), cuantos regresan en una semana (retención D7) y cuantos regresan a los 30 días (retención D30).

Nosotros en este primer mes de mediciones (porque el mes anterior  fue enfocado en resolver bugs e implementar features básicos que sabíamos que debíamos implementar, como el chat in game, un mapa in game y tabla de posiciones , entre otras) nos hemos enfocado en retención D1, ya que si estamos perdiendo muchos usuarios en el día 1 (al día siguiente de haberse registrado), debemos comenzar por atacar ese problema antes de pensar cómo retener a los usuarios por 7 o 30 días.

Lámina tomada de http://www.slideshare.net/agarimella/social-gaming-metrics

Nuestra retención D1 en este momento ronda el 10%, o dicho de otra forma: si 1,000 usuarios se registran hoy, sólo 100 de esos 1,000 vuelven mañana.

Eso es bueno o malo? Pues lo bueno de estas mediciones es que te ayudan a poder compararte con otros juegos y hablar un lenguaje común con otros desarrolladores y definitivamente 10% no es un número bueno según las referencias que hemos podido ver, ya que un juego exitoso generalmente la retención D1 está por encima del 30%! así que tenemos mucho por mejorar.

Pero de eso se trata llevar un juego como servicio, se trata de medir, analizar, corregir, actualizar y repetir, de manera que puedas ver el impacto que tiene una actualización específica en cada uno de tus KPIs (Key Performance Indicators), y no podemos esperar lograr tener el juego perfecto desde el día uno de lanzarlo, esto es un maratón, no una carrera de velocidad.

Por donde empezar?

Dicho todo esto, dónde pensamos nosotros al día de hoy que están los puntos flojos del juego que nos están causando la baja retención que estamos observando? Estas son nuestras hipótesis iniciales:

Pay To Win (ya lo sé... yikes):

- En este momento la monetización de nuestro juego es totalmente "Pay to Win", y sí,  lo digo con cierta verguenza porque sé que es una pésima práctica de diseño y de monetización, pero a la vez también confieso que fue una medida un poco "desesperada" ya que debido al mecanismo de adquisición de usuarios teníamos una fecha rigida de lanzamiento, en otras palabras, las clases en las escuelas comienzan cuando comienzan y no hay manera de retrasar esa fecha, por lo que los cuadernos estaban allá afuera y tuvimos que sacar el juego con solo 4 meses de desarrollo, un tiempo de desarrollo que raya en lo absurdo para un juego de estas características, con los retos que tiene a nivel de manejo de recursos, multiplayer, integración con métodos de pago, balancing, UI, etc., lo cual nos llevó a tener que simplemente eliminar la economía de "soft currency" (las monedas que obtienes jugando) y dejar sólo el "hard currency" (las monedas, o Gemas en nuestro caso, que obtienes pagando), ya que una de las cosas más complejas en un juego free-to-play es lograr una economía bien balanceada y eso toma tiempo y mucha iteración, y tiempo era justamente lo que no teníamos, así que tuvimos que optar por simplemente eliminar el soft currency para poder enfocarnos en sacar un producto que funcionara a tiempo y poder iterar a partir de esa primera versión.

Esto seguramente nos está afectado fuertemente la retención y es de las cosas que más nos han pedido los jugadores, nos dicen comentarios como: "deberían dar gemas cuando uno gana una partida" o "deberían dar gemas cuando derrotas a un enemigo" etc., lo cual además refleja que ya el mercado está acostumbrado a esta mecánica y es esperada en los juego free-to-play.

En este momento estamos trabajando en la economía basada en "soft currency" y pensamos que en uno o dos meses lanzaremos una actualización con dicho feature. Estaré comentando por aca cómo esa actualización afecta retención y si realmente tiene un impacto significativamente positivo como esperamos.

Balancing:

El juego en este momento no está suficientemente bien balanceado. Si has jugado TF2 sabes que en un juego de equipos basado en clases, donde cada uno tiene ventajas y desventajas, el balance es vital para evitar tener clases "Overpowered". En este momento nosotros tenemos ese problema y estamos dedicando tiempo y energía a observar el comportamiento de los jugadores y sus preferencias en cuanto a los personajes del juego para determinar las variables que debemos mover en cada uno de ellos. Para dar un ejemplo concreto de nuestro juego, sabemos que el poder y resistencia de Thor no es suficiente como para compensar su lentitud de movimiento, por esto estamos por lanzar una actualización en la que Thor tendrá muchos más Puntos de Vida, haciéndolo más difícil de derrotar. Como esta tenemos varias situaciones que estamos explorando y que pensamos que harán el juego más balanceado y "rewarding".

Thor es uno de los personajes del juego que requiere balancing.

Mínimo Producto Viable:

Por la razón ya mencionada antes sobre la necesitdad de publicar el juego coincidiendo con la temporada escolar, tuvimos que salir con un producto que le faltaban muchos aspectos por pulir y en ocasiones bugs que rompían la experiencia de juego, lo cual sin duda afecta directamente la retención ya que un jugador frustrado por algún comportamiento erratico del juego es un jugador que dificilmente retorna.

Para solucionar bugs y añadir features importantes lo más rápido posible estamos haciendo al menos uno o dos updates a la semana, lo cual es una ventaja que tenemos gracias a haber sacado un juego en plataforma web, hacer updates tan frecuentemente en mobile sería casi imposible. Tener el juego online nos ha permitido iteraciones rápidas, e incluso probar features, ver si nos funcionan y si no, poder revertirlos en cuestión de minutos.

El plan es seguir hacia adelante, aprendiendo e iterando para hacer cada vez mejor este juego hasta lograr un punto en el que sea realmente exitoso! (y en el peor de los casos aprender un montón en el camino para nuestro siguiente juego). Estamos apenas al principio del camino, así que dejo esta puerta abierta para compartir el proceso con todos los que lo encuentre interesante.

En la siguiente entrada pienso escribir sobre nuestro Funnel análisis, monetización, métodos de pago y como todo esto afecta el ARPU y ARPPU, pero siéntete libre de proponer otros temas o hacer cualquier pregunta relacionada con el lanzamiento de este juego.

Hola Mundo, y no Hello World.

Hola Mundo, y no Hello World... ya que la primera decisión "importante" que he tomado para comenzar este blog ha sido hacerlo en Español.

Y digo "importante" no por la trascendencia que pueda o no tener este blog, sino porque estoy consciente que al hacerlo en Español dejo por fuera potenciales lectores y colegas de la industria que no entenderán ni Ñ (no pun intended - ah por cierto, eso si lo pienso hacer bastante: usar algunos anglicismos que resulten convenientes en el momento, excuse my spanglish!).

Pero al final este blog no está dirigido a ellos, va dirigido a los que están en algún país de America Latina soñando con algún día hacer videojuegos o para los que ya los estás haciendo y quieren escuchar de otro loco que se metió en esto y además está en un contexto similar, con retos y situaciones parecidas, y si bien es muy recomendado que todos los que formamos parte de esta industria sepamos ingles, he querido hacer un blog que sea de latinos para latinos, que hable en nuestro idioma y sea más accesible, amigable y cercano para los que habitamos esta región de tantos retos pero de tanto potencial.

En este blog busco compartir mi experiencia y todo lo que aprendo cada día al vivir de hacer videojuegos, tanto en areas de negocio, como de producción, game design, monetización y cualquier cosa que me parezca interesante compartir con otros colegas y entusiastas del desarrollo de videojuegos.

Bueno, suficiente para un "Hola Mundo", nos vemos por estos lados... en Español!