Conceptos más allá del desarrollo

Cuando empiezas en el mundo del desarrollo de videojuegos es muy probable que sólo conozcas conceptos como programación, diseño, jugabilidad y términos así. Pero realmente si quieres avanzar un poco más y dedicarte de manera profesional a lanzar juegos al mercado, y vivir de ello (o intentarlo), tendrás que conocer y estudiar muchos otros conceptos muy importantes.

Muchos de estos nuevos términos tienen como objetivo medir tu juego, es decir, sirven más para valorar la viabilidad, rentabilidad, etc. del juego que has desarrollado que no para desarrollarlos en sí mismo. Aunque para poder tener unas buenas estadísticas es importantísimo que en el momento del diseño del juego tengas en cuenta todos estos conceptos y tomes decisiones que puedan mejorar las estadísticas de estos conceptos.

Aquí enumeraré y haré una breve descripción de los más usados, pero no entraré en detalle a explicarlos. Hay bastantes blogs y páginas por internet que se encargan de definir algunos de ellos con mucho detalle y con unos ejemplos muy buenos para profundizar. Sólo intento tener una lista clara de los conceptos para que sirva de punto de partida para los que se inician y puedan después investigar más si realmente están interesados.

• F2P (Free to Play): Indica el tipo de juego que no tiene ningún coste para el usuario descargarlo o jugar. En este área hay de varios tipos y aunque pueda parecer que no vaya a ser rentable para el programador, es el modelo que más se está usando en el mercado de videojuegos para móviles.
• DAU (Daily Active User): Es la medida de usuarios únicos que han accedido a tu juego en un día en concreto. Es decir, se mide diariamente.
• MAU (Monthly Active User): Es la medida de usuarios únicos que han accedido a tu juegos en un mes en concreto. Es decir, se mide mensualmente.
• Stickiness (Engagement): Es la medida de fidelidad o de usuarios que permanecen en tu juego y siguen jugando durante un tiempo, sin abandonarlo. Es decir, se puede decir que sirve para saber si tu juego "engancha" (engagement). Se calcula diviendo el DAU por el MAU.
• ARPU (Average Revenue Per User): Es la media de ingresos por usuario activo cada mes. Es decir, del MAU que tienes la media de ingreso por cada uno de ellos.
• ARPPU (Average Revenue Per Paying User):Es la media de ingresos por usuario activo, y que ha hecho alguna compra, cada mes. A diferencia del anterior no se coge todo tu MAU, sino que de ahí sólo se cogen los que realmente han pagado algo ese mes en tu juego.
• Churn: Indica el porcentaje de usuario que dejan tu juego cada mes. Se mide de forma mensual y sirve para calcular otros conceptos.
• LTV (Life Time Value): Es la media de dinero que un usuario consume en tu juego durante toda su vida de juego, es decir, lo que cada jugador (en media) te hará ingresar al hacerse jugador de tu juego. Es un media y se usa el ARPU para poder medirlo.
• Whale user: Hace referencia a los usuarios que más gastan en tu juego. Son aquellos usuarios jugones que además hacen muchas compras de tu juego.
• K-Factor: Es el factor de crecimiento viral. Es decir, la capacidad que tiene tu juego de conseguir atraer usuarios sin invertir nada en que vengan y se queden como jugadores.

Los siguientes conceptos están más centrados en el área de publicidad dentro de los juegos, pero también hacen referencia a ciertos métodos de adquirir usuarios (costes, "comprar usuarios", etc.)

• CPM (Cost Per Mil): Hace referencia al coste que tiene para un anunciante el impriman 1000 veces tu banner. Es decir, que tu banner salga 1000 veces en algún juego. Este concepto también se usa al contrario, es decir, el ingreso "teórico" que recibes por cada mil banners que imprimes en tu juego.
• eCPM (Effective Cost Per Mil): Actualmente pocas veces ingresas dinero por mostrar banners en realidad, sino que ingresas en realidad por los clicks que hacen los usuarios o si llegan a instalar la app que hay detrás. Por eso surgió este concepto, para medir de forma homogénea lo que ingresas por los supuestos 1000 banners que has impreso, aunque en realidad esos ingresos es porque de esos 1000 banners, has conseguido que 200 usuarios hayan pulsado en él. Es un concepto que sirve para comparar plataformas de publicidad.
• Fill rate: Es el porcentaje de "rellenado" de un espacio de banner. Es decir, cuando tu reservas un espacio de tu juego para poner banners y se los pides a tu red de publicidad, puede ser que esa red no te dé ningún banner cuando se lo pides. Por eso es importante saber si estás perdiendo "dinero" con un espacio de publicidad que se queda vacío.
• CPI (Cost Per Impression): El coste, para un anunciante, de que su banner salga publicado alguna vez en algún juego.
• CPC (Cost Per Click): El coste que tiene para un anunciante el que un usuario pulse su banner.
• CPA (Cost Per Adquistion): Es lo que un anunciante paga por poner publicidad y que esa publicidad consiga que un usuario nuevo se instale su juego. Es decir, si un usuario ve un banner en una app, lo pulsa y le lleva al store, si se instala ese juego, el anunciante pagará. Coste por adquirir un nuevo usuario.
• eCPA (Effective Cost Per Adquisition): Es el coste real de adquisición de usuario. Este dato se ve modificado por tu k-factor y otros factores que permiten incrementar el número de usuarios adquiridos en función de otro usuario adquirido.

Lo que escribo aquí es simplemente para hacer una pequeña introducción, me sirve para que yo mismo asiente los conceptos. Si creéis que hay alguno erróneo, falta alguno importante o simplement queréis comentar cualquier cosa al respecto, ya sabéis que esto es un foro abierto.

UPDATE: Gracias a los comentarios incluyo este añadido:

• Retention KPI (Key Performance Indicators): Son indicadores de retención de los usuarios, medidos a diferentes fechas o después de X días desde que pasó a ser jugador (después de 1 día, después, de de 7 días, después de 28 días)

Por otro lado en este link de Gamedonia podéis ver más información sobre estos conceptos.

Nueva etapa, nuevos juegos

Este post se podría haber publicado perfectamente hace unos meses, cuando estrenamos nuevas oficinas y así, una nueva etapa para Divertap. Una etapa que empieza con un cambio de ubicación que nos ha ayudado a focalizar nuestros objetivos.

Aún así, lo realmente importante de esta nueva etapa no es especialmente el espacio de trabajo, sino que hemos centrado de nuevo nuestro esfuerzo en lanzar juegos propios y así, reanimar el sentido de Divertap. Creamos Divertap con la voluntad de desarrollar juegos para móviles, pero durante los dos primeros años de vida de Divertap, diferentes proyectos nos permitían afianzar nuestra relación con nuestros clientes, pero no cumplir nuestros objetivos de productos propios.

Actualmente tenemos en el mercado 5 juegos total o parcialmente nuestros, pero el dato significativo es la inercia que hemos cogido y sobretodo, un enfoque más claro sobre nuestro objetivo: queremos crear juegos o iteraciones de desarrollo corto que nos permitan de verdad acceder al mercado de las AppStore. Actualmente, tenemos en desarrollo 3 juegos más que esperamos vean la luz este 2014, además de nuevas versiones de los ya lanzados, así que comparándolo con los dos años anteriores estamos a años luz en objetivos cumplidos.

Para poder coger esa inercia hemos cambiado y asumido algunas cosas:

• No nos embarcamos en más colaboraciones de las que podemos realmente asumir. Es difícil decir "no", pero la calidad debe prevalecer a la cantidad.
• Asumir que no podemos solos. Esto se traduce en varias líneas pero principalmente en dos:
  1. Incorporar personas al equipo que se dediquen exclusivamente a desarrollar los juegos de Divertap.
  2. Buscar financiación para abordar todos planes que tenemos en mente y que a base de proyectos para clientes no se financiarán nunca. 
• Focalizamos sobre dos líneas de tipo de juego por ahora: juegos de tablero y casual. Esos dos tipos nos permiten realmente conseguir ciclos cortos de desarrollo y así poder tener productos de calidad en el mercado.

Estos cambios, juntos con otros pequeños esfuerzos que estamos haciendo para llevar a Divertap a donde queríamos estar hace dos años, es lo que esperamos que cristalice y nos permita realmente ser un estudio de desarrollo de juegos de referencia.

PS: Si te interesa puedes ver todos nuestros juegos aquí

Use ASO to Rank Higher in the App Store

Discoverability. The bane of all developers without deep pockets to market their games. Naturally, this includes us in Divertap.

 How do you plan to gain exposure in the App Store? If you think using ASO is the way to go, you’d be right!
Read more...

cocos2d-iphone with javascript: El entorno

Después de un tiempo usando esta tecnología, y como no podía ser menos, ya estamos en disposición de colgar en el blog las primeras experiencias e impresiones.

Hoy me gustaría hablar del ENTORNO de PROGRAMACIÓN, EJECUCIÓN y DEPURACIÓN.

1. ENTORNO de PROGRAMACIÓN
   Todos los que nos dedicamos a ésto, estamos acostumbrados a IDE's de tipo Eclipse, Visual Estudio, etc, herramientas que en general nos facilitan las cosas. Temas tan habituales como errores de sintaxis, errores de compilación, etc, se hacen fáciles de detectar y corregir. Incluso programando en ObjectiveC con Xcode la experiencia es semi-agradecida. Pues bien, olvidaros de todo eso. Usar Xcode con JavaScript es la muerte, así que hay que buscarse la vida con herramientas alternativas. Particularmente he decidido usar la misma herramienta que el autor de cocos2d-iphone: SublimeText. Este pequeño editor nos ofrece algunas facilidades programando en JavaScript que seguro agradecerás, como el autocompletado, codesnippets, etc.


2. ENTORNO de EJECUCIÓN
   Una vez encontrado el editor, hay que ejecutar el código que desarrollamos. Aquí es donde viene el segundo problema. JavaScript es un lenguaje interpretado, así que los errores de sintaxis no se detectan cuando se programa, si no cuando se ejecuta. El ciclo de pruebas es por tanto: programa, ejecuta, error, revisa el código. Pero claro, ¿cómo reviso el código en busca de errores de sintaxis? ¡VISUALMENTE! Consejo: no tires muchas líneas de código antes de probar las cosas, te volverás loco.


3. ENTORNO de EJECUCIÓN
   Otro de los típicos problemas son los errores de la lógica que estás desarrollando, para lo que usualmente debugamos. Esta tarea todavía está muy atrasada en cocos2d-iphone, y aunque actualmente están implementando un debugger, todavía no está listo. Volvemos pues, tiempo atrás, donde el JavaScript más arcaico lo depurábamos con los típicos 'alert'

En definitiva, y respecto al tema del post, mi opinión es #FAIL, porque una cosa es acostumbrarse y otra que de un inicio te faciliten tu trabajo.

M.

Cross-platform development to the next level: cocos2d-iphone with JavaScript

Después de alguna que otra prueba con Unity y con CoronaSDK para desarrollar juegos en modo "cross-platform", esto es, desarrolla una vez y despliega en iOS y Android, hemos decidido darle una oportunidad a una nueva tecnología que promete y mucho: cocos2d-iphone with JavaScript.

La teoría es la siguiente: utiliza javascript para desarrollar tu juego, y luego una máquina virtual de javascript interpreta tu código (SpiderMonkey) y acaba invocando el código nativo (cocos2d-iphone).

Esta interpretación y ejecución de código nativo se produce gracias a unos "proxies" o "glue code" que están incorporados en cocos2d-iphone a partir de su versión 2.1. Este código se autogenera gracias a un proyecto del creador del cocos2d, Ricardo Quesada, y que está disponible en github: JSBindings

Bonito y sencillo, ¿no? Bueno, pues no es oro todo lo que reluce. Para que puedas programar en JavaScript 100%, necesitas que todo el código nativo que vayas a utilizar tenga su correspondiente "glue code" o "proxies". Y claro, quién pueda desarrollar un juego sin crear sus propias clases para comportamientos particulares que tire la primera piedra.

La buena noticia: es posible generar tu propio "glue code" o "proxies" para tus objetos javascript.

La mala noticia: el proceso es para "machos" y la documentación es escasa.

M.

Take it easy!

Una de las cosas más aburridas a la hora de construir aplicaciones y juegos para iOS, es pasar del material original en formato photoshop (PSD) a imágenes que se puedan utilizar en las pantallas o texturas.

Ahora que Apple nos ha fastidiado con una nueva resolución (iPhone5), se hace todavía más palpable lo engorroso de esta tarea. Muchas veces nos vemos obligados a recortar nosotros mismos el material para generarlo de forma optimizada a lo que haremos a la hora de programar.

Es en este punto donde todo programador debe intentar pensar en la automatización de este tipo de cosas. Y por ello quiero compartir un pequeño truco (si se puede llamar así). El proceso a automatizar es la generación de la imagen de resolución normal a partir de la HD (ó @2x). Y es que con una pequeña shell y con ImageMagick instalado podemos reducir a la mitad el tiempo de la tediosa tarea de cortar las imágenes del PSD a PNG.

Simplemente genera la imagen @2x y deja que la shell haga el resto. Copia la shell en directorio donde estén las imágenes y ejecuta. Aquí tenéis el código:

#!/bin/sh
echo "Resizing retina..."
CURRENT_DIR=`pwd`
FILES=$CURRENT_DIR/*@2x.png
cd $CURRENT_DIR

for image in $FILES
do
        image_noretina="${image%@2x.png}.png"
        echo "Processing $image to $image_noretina"
        convert "$image" -resize 50% "$image_noretina"
done
exit 0

M.

Adaptando tus juegos a la resolución del iPhone5

Ya tenemos aquí el nuevo y esperadísimo iPhone5, y aunque sus nuevas especificaciones no han sido ninguna sorpresa, para los desarrolladores de juegos y aplicaciones ya hay un motivo más de preocupación.

Se trata de la nueva pantalla, cuya resolución y aspect-ratio cambia respecto los antiguos iphone. En concreto, la pantalla pasa a ser de 1136x640píxeles (landscape) o lo que es lo mismo de 568x320puntos. Y claro, para aquellos a los que nos pilla en pleno desarrollo de juegos o aplicaciones, es una put... tener que estar contínuamente modificando este tipo de cosas.

Afortunadamente Apple nos lo intenta poner fácil, y nos asegura que nuestra app o juego se verá magníficamente bien en el nuevo iPhone5 si no tocamos nada, salvo por unas barras laterales de color negro. Pero claro, eso no queda muy bien, y toca investigar cómo migrar nuestros juegos a la nueva resolución. Es en este punto donde quería hacer algún comentario.

A priori es tan fácil como indicar en la IDE, Xcode4.5, un splash-screen (Launch Image, o el famoso Default.png) con una resolución de 1136x640. A partir de ese momento, nuestro terminal nos dará un tamaño de pantalla adaptado a la nueva resolución. Si no indicamos ese splash, todo seguirá como antes.

Pero claro, normalmente utilizamos herramientas y frameworks que nos ayudan al desarrollo y éstas tardan un poco en adaptarse. Por lo tanto, y aunque Apple lo ponga fácil, siempre toca adaptar nuestro código a las nuevas especificaciones. Algunas de las cosas típicas que deberemos modificar:

1. Cocos2d: reposicionar elementos en función del tamaño de la pantalla.
2. LevelHelper: desactivar la conversión de aspect-ratio y adaptar nuestras escenas

¡Ojo! La API de cambio de orientación del terminal ha sido rediseñada. Aquí tenéis algunas pautas: http://www.cocos2d-x.org/news/73

M.

Uso de publicidad en apps

Desde hace ya casi 3 años que iParchis y iOca están publicadas en el App Store con suerte dispar. iParchis ha tenido una cantidad bastante alta de descargas, principalmente la gratuita con publicidad. iOca ha tenido bastantes menos descargas.

Cada app tiene una versión gratuita que presenta publicidad y ciertas funcionalidades no activadas. Pero la que realmente tiene actividad en la publicidad es iParchis, porque iOca apenas generar impresiones en publicidad (seguramente se hacen menos partidas que en el parchis). Hoy os presentamos aquí los datos de publicidad que genera el juego iParchis.

Cuando integramos los ads en los juegos el primer objetivo era maximizar los ingresos y por eso queríamos maximizar el número de impresiones. Para conseguirlo no integramos directamente ninguna plataforma de publicidad, sino que integramos AdWhirl que se presenta como un mediador de plataformas de publicidad, de tal manera que te permite configurar qué plataformas presentarán ads en tus apps en tiempo de ejecución (mediante una interfaz web).

Es decir, integras la SDK de AdWhirl y las SDKs de las plataformas de ads posibles que vayas a usar y después desde la web configuras qué plataformas usarás realmente y con qué prioridad.

En el caso de iParchis configuramos las plataformas iAd y AdMob, con esta distribución: 100% de iAd y en caso de fallo (impresión no resuelta) que sea AdMob quien responda. Por suerte AdWhirl permite definir casos de error, de tal manera que si una plataforma no te ofrece un ad, se lo pide a otra. Con esta distribución estos son los números de iParchis durante los últimos 3 meses

1. 2.500.693 impresiones totales (unas 830.000 por mes)
2. de las cuales 1.755.690 son de Admob y 745.003 son de iAd (curioso dato)

Plataforma	Fill Rate	CTR	eCPM
AdMob	98,5%	0,41%	0,08$
iAd	37,75%	0,22%	0,52$

Se ve claramente que iAd puede ser más rentable en términos de CPM pero que con el nivel tan bajo de fill rate se hace difícil conseguir ingresos. iAd es una plataforma que funciona muy bien en USA y nuestro juego se utiliza principalmente en España, por eso el fill rate es tan bajo.

Con estos datos se pueden sacar algunas conclusiones y sobretodo tomar alguna decisión, como por ejemplo buscar otras vías de ingresos (otros modelos de negocio) o incluso buscar otros formatos de ingresos por publicidad.

El proyecto Rita La Lagartija

Estamos ya en la recta final del desarrollo del cuento ilustrado interactivo para niños en iPad: Rita La Lagartija, estamos con unas ganas locas de poder lanzarlo y ver cómo acoge la gente un proyecto que lleva casi un año desarrollándose. Creemos que es un cuento muy bonito y cuidado, tenemos confianza en que realmente guste a los niños (y sus padres ;).

Es un buen momento para explicar cómo nació este proyecto y conocer su historia. Rita La Lagartija es un cuento escrito e ilustrado completamente por Irene Blasco, ilustradora valenciana autora y creadora de esta joya. Este cuento ha ganado el Premio al Mejor Libro Ilustrado en Valencià en el 2006 y realmente destaca por su bonitas ilustraciones.

Hace un año encontramos por Internet un anuncio que Irene publicó, donde buscaba desarrolladores iOS para colaborar pasando su cuento en papel a la plataforma iPad. Nos pusimos en seguida en contacto con ella y después de hacer una pequeña prueba de capacidad técnica iniciamos la colaboración. El primer gran reto era la distancia, ella vive en Valencia y nosotros en Barcelona, pero con una buena elección de herramientas de trabajo colaborativo (Dropbox y Teambox) se hizo mucho más sencillo.

Además de las herramientas ha sido importantísimo todo el material que ha ido preparando Irene, muy completo. Tenemos experiencia en desarrollar a distancia y se hace mucho más farragoso cuando el material (documentos, imágenes, explicaciones, etc.) es muy reducido o casi nulo. Pero el material que Irene ha ido preparando se componía de documentos autoexplicativos, Gifs animados de las animaciones, imágenes con nombres que daban pistas de su disposición en pantalla, etc. Realmente así es un placer poder trabajar a distancia en un cuento con tanta riqueza visual y una interacción muy completa, se hizo mucho más sencillo.

Una vez superado el reto de engrasar el proceso de desarrollo, se nos han planteado muchos otros: rematar detalles, versión lite, marketing, traducciones, web, redes sociales, testing, etc. Es un mundo en el que todos estábamos más bien verdes, pero poco a poco hemos ido avanzando en esos temas y en ese aspecto Irene también ha sido clave. Pero todo el proyecto y el proceso ha sido y está siendo muy gratificante, no sólo por la buena colaboración que existe, sino también por el producto en sí que nos ilusiona y nos encanta poder enseñarlo a los niños.

Estamos deseando que se publique y estamos muy contentos de haber encontrado a Irene y de que nos haya permitido participar de este proyecto. Después de su publicación habrán muchos más retos, el usuario nos irá guiando.

Ahorrando memoria: Texturas en formato PVR

Uno de los principales problemas en la construcción de aplicaciones y juegos para dispositivos móviles, es la escasez de recursos de que disponen. Entre esos recursos, unos más importantes que otros, se encuentra la memoria. Para hacernos una idea del reto que ésto supone, aquí tenéis algunos datos: un iPad dispone de 256Mb, un iPad2 dispone de 512Mb y un iPad3 dispone de 1Gb.

Excepto el nuevo iPad, estamos hablando de niveles de memoria de portátiles de hace más de 10 años pero con unos requerimientos gráficos y de jugabilidad actuales. Además de esos requerimientos, hay que tener en cuenta que en la memoria total del dispositivo también hay que cargar el sistema operativo y demás, con lo que el espacio total todavía es menor. Y para bien o para mal, un buen producto entra, antetodo, "por la vista", lo cual se traduce en un excelente aspecto gráfico, es decir, una buena gestión de las texturas.

Una textura no es más que una imagen aplicada a un polígono o polígonos, pero ¿cuánto ocupa esa imagen memoria? La respuesta es la siguiente:

ESPACIO EN BYTES = ANCHURAxALTURAxNºBYTESPORPIXEL

Hagamos el siguiente ejercicio con el primer iPad: 256Mb disponibles, menos lo que ocupa el sistema operativo, etc etc, se queda en unos 180Mb reales para aplicaciones. Teniendo en cuenta que el dispositivo ejecuta aplicaciones en background que ocupan memoria, nos damos cuenta de que realmente disponemos de una cantidad de memoria todavía menor. Ahora cargamos una animación a pantalla completa (1024x768). Pensemos en una animación basada en una sucesión de imágenes (pongamos 8) en formato PNG. Como dicen los americanos, "this is the math":

ESPACIO(Mb) = 1024x768x4x8 = 24Mb

24Mb para una simple animación: ¡EXCESIVO! Hemos supuesto 4bytes por pixel porque hemos cargado PNG's en formato RGBA con 1byte por canal(4canales, 4bytes). ¿Cual es entonces la solución? Hay diferentes técnicas a aplicar aquí, pero me quiero centrar en el formato de las imágenes. Los chips gráficos de la mayoría de los dispositivos móviles incluyen la tecnología PowerVR, que permite cargar texturas con un consumo de memoria hasta 16veces menor, ¡16 veces!. Pero claro, siempre hay alguna restricción y alguna que otra pega: la calidad. Convertir imágenes en formato png a pvr tiene un coste, pero en la mayoría de casos es asumible.

Muchas de las herramientas que se utilizan en la construcción de juegos permiten generar nuestras texturas en formato pvr, como TexturePacker. Después de trastear con algunas, yo os recomiendo lo siguiente:

1. Generar las texturas con Xcode (a través de 'texturetool'). Definitivamente la calidad de las imágenes es mejor que TexturePacker
2. Si queréis haceros una idea de la calidad que vais a perder, instalaros las tools de PowerVR Tech.

M.