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.

Divertap en la radio

Esta vez no queremos comentar ningún aspecto técnico de la programación. Sólo decir que estaremos en la radio para hablar de Divertap, RitaLaLagartija y desarrollo de apps.

COMRàdio nos ofrece esta oportunidad de poder hablar de este mundo del desarrollador de apps, con bajo o nulo presupuesto. De la dificultad real de tener éxito en las stores y de cómo está siendo un boom todo el desarrollo de aplicaciones móviles en las empresas.

No os perdáis el jueves 30 de Agosto por la mañana en L'Apartament nuestra participación, ya que estaremos regalando camisetas ¡como ésta!

Después nos podréis comentar cualquier cosa que os haya interesado o que os haya parecido una tontería.

"Bitmap Fonts" aplicadas al lenguaje chino

Una de las cosas que me ha sorprendido y al principio no acababa de entender, es cómo se aplica el concepto de fuentes "bitmap" al idioma chino.

Para aquellos que no estéis familiarizados con este concepto, una fuente "bitmap" es aquella que nos permite, en un entorno gráfico donde todo son texturas (típicamente un juego), "pintar" una cadena de caracteres. La técnica es conceptualmente sencilla: dispongo de un fichero de definición de la fuente (típicamente "mifuente.fnt") y otro fichero que contiene un atlas con los caracteres a utilizar (típicamente "mifuente.png").

Cuando queremos pintar en pantalla, por ejemplo, "HOLA MUNDO", la forma de proceder es la siguiente: se consulta en "mifuente.fnt" dónde está la "H", se va al atlas "mifuente.png", se elije la zona donde está la "H" y se pinta en pantalla; y así sucesivamente con todas las letras. Conclusión: con 2 ficheros podemos pintar los textos que queramos.

¿Pero qué pasa con el chino? Si alguna vez habéis intentado averiguar cómo funciona el lenguaje chino, habréis visto que todo son símbolos, y que el contexto de lo que quieres decir es lo que marca utilizar uno u otro símbolo. Hay más de 20.000 símbolos en el chino tradicional, y el nivel de aprendizaje del mismo depende del número de símbolos que sepas. Pero entonces... ¿qué pasa con las fuentes "bitmap"? Pues que el concepto deja de ser aplicable. ¿Por qué? Pues porque no podemos incluir en un único atlas todos los símbolos chinos. La imagen ocuparía "infinito", y todos sabemos que en los dispositivos móviles la memoria es muy limitada. ¿Pero entonces cómo lo hago? Bueno, aquí viene el punto que me costaba entender, ya que intentaba aplicar siempre el concepto de base. La respuesta es: incluye en el atlas sólo los símbolos que vayas a utilizar.

¡OJO! Es evidente que no podrás escribir nada que no esté incluido en los símbolos que hayas incrustado en tu atlas, pero por lo menos la memoria de tu dispositivo móvil lo agradecerá.

Aquí os dejo un par de enlaces de programas que podéis utilizar para generar vuestras fuentes "bitmap" (personalmente os recomiendo el primero)

1. bmglyph
2. glyphdesigner

M.

Entendiendo el diseño gráfico para juegos 2D Multidispositivo

Uno de los principales quebraderos de cabeza en la creación de un juego 2D "mobile", es la decisión de si lo quieres hacer multi-dispositivo. Para aquellos que no sepáis de qué hablo, me refiero a programar el juego una única vez y que funcione en los diferentes tipos de teléfonos móviles y tablets existentes.

Dos de las cosas a tener en cuenta en esta decisión son:

1. Necesito una tecnología/framework que me permita generar mi código para las diferentes plataformas (iOS, Android, etc)
2. El diseño gráfico y la programación tiene que estar preparado para todas las resoluciones

En este post me quiero centrar en el segundo punto, ya que es una cosa que parece fácil pero que es un todo un mundo. Y digo todo un mundo, porque personalmente nunca he sabido concretar con los diseñadores cómo tienen que hacer sus gráficos para conseguir la ansiada "caja de pandora", sin que tu vida como programador se convierta en un continuo: if (iphone) else if (ipad) else if (nexus) .... Afortunadamente ¡eso se ha acabado!

A día de hoy, son varias cosas las que hay que tener en cuenta para llegar a buen puerto:

1. Como diseñador, diseña las pantallas a máxima resolución y luego genera las imágenes para esa resolución
2. Como programador, programa las pantallas pensando un dispositivo concreto, en la resolución de ese dispositivo, y deja que las herramientas hagan el resto

Tengo que aclarar que cuando hablo de resolución como diseñador, hablo en píxeles, y cuando lo hago como programador, hablo en puntos. En la mayoría de dispositivos un píxel es un punto, pero en los iphone4 e ipadretina no. En estos últimos, por cada punto hay 2 y 4 píxeles respectivamente.

DISEÑO A MÁXIMA RESOLUCIÓN
Puesto que existen diferentes relaciones de aspecto (ancho de pantalla dividido por alto de pantalla) y diferentes tamaños de pantalla (smartphone o tablet) necesitamos un diseño que cubra todo eso. A día de hoy, una resolución de 1536x2384 cubre todos los dispositivos (en modo 'portrait'). Pero no te engañes, no todo el área de ese tamaño es zona "jugable", ya que dependerá del dispositivo. Por ejemplo, en un iphone, tan sólo será jugable un área de 1280x1920. Entonces ¿qué pasa con el resto de espacio de mi photoshop? El resto de espacio es para las zonas muertas que cubrirán los diferentes tamaños de pantalla.
Una vez tengas tu diseño, exporta las imágenes en esa resolución y no curres más de la cuenta... Las herramientas del programador le permitirán generar las típicas resoluciones que existen en la actualidad (actualmente con 3 es suficiente): ipadretina (ipadhd), ipad/iphone4 (hd), iphone (normal).

PROGRAMACIÓN A MÍNIMA RESOLUCIÓN
Como programador, lo primero a hacer es generar las imágenes en esas 3 resoluciones (ipadhd,hd,normal, con herramientas como SpriteHelper). Una vez generadas, lo siguiente es fijar un terminal y resolución. En este post voy a utilizar como referencia un iPhone (320x480, recordad que son puntos) y utilizaré CoronaSDK para explicar los diferentes conceptos. En Corona, la resolución se fija mediante el config.lua width = 320, height = 480, scale = "letterbox" A partir de aquí, todo sucede en 320x480 para cualquier iPhone. Pero, ¿y el resto de dispositivos? Aquí es donde está el kit de la cuestión y la clave para entenderlo todo: el escalado. Efectivamente todo se escala. Es similar a cuando vemos una película en modo "cinemascope 16x9" en la tele pero podemos elegir diferentes escalados. Según lo que elijamos, veréis que hay zonas de la película que desaparecen de la pantalla o que quedan bandas negras alrededor (zonas muertas de las que hablábamos antes). En un juego pasa lo mismo: puedes elegir, principalmente, escalar hacia abajo ("letterbox") o escalar hacia arriba ("zoomEven"). Según lo que elijas, así se verá en el terminal diferente para el que se diseñó. Uno de los principales errores es utilizar la relación de aspecto como factor de escalado, ya que provoca deformaciones y no genera el ansiado "pixel perfect". El factor de escala depende del tipo de escalado que elijamos:

1. Hacia abajo escalan las anchuras, manteniendo toda la imágen en pantalla. En nuestro caso sería 320 entre XXX, donde XXX es el ancho de la resolución del dispositivo en el que queremos desplegar nuestro juego.
   
2. Hacia arriba escalan las alturas, provocando que puedan desaparecer imágenes de nuestra pantalla. En nuestro caso sería 480 entre YYY, donde YYY es el alto de la resolución del dispositivo en el que queremos desplegar nuestro juego.

A modo de ilustración, os pongo una figura de nuestro diseño de iPhone comparado con un NexusOne:

Por último os dejo un enlace a un template de proyecto de corona donde ilustra todo lo explicado:

https://www.dropbox.com/s/mmlfxont1uo5oqj/UniversalBuildSkeleton.zip
y un enlace con más información sobre este tema:
http://www.coronalabs.com/blog/2010/11/20/content-scaling-made-easy/

M.

Desarrollo en iOS con Cocos2D+LevelHelper+SpriteHelper

Ahora que estamos a punto de sacar al mercado nuestro producto Rita la lagartija, merece la pena echar la vista atrás y repasar lo que ha sido el proceso de desarrollo de esta historia interactiva para niños (aká, "cuento infantil").

Y es que cuando uno se embarca en la construcción de un proyecto de estas características, lo primero que le viene a la mente es: "¿Qué voy utilizar que me facilite la vida?". Comienza pues el proceso, bien llamado "googlear", en el que básicamente pasan por delante de tus ojos decenas de webs, blogs, referencias, preguntas, respuestas, etc etc etc. Idealmente, la solución a la pregunta pasa por el siguiente timeline:

1. Anotar referencias de herramientas y frameworks
2. Descargar dichas referencias y frameworks
3. Evaluarlas
4. Decidir con quién te casas...

Puesto que nunca se tiene tiempo infinito, al final has de hacer una apuesta y arriesgarte con algo sin estar completamente seguro (a no ser que ya tengas experiencia en el uso de varias de ellas). Para ello uno se hace básicamente tres preguntas: ¿Para qué mercado lo voy a publicar (AppStore, GooglePlay, etc)? ¿Para qué terminales lo quiero desarrollar (Smartphone, Tablet, etc)? ¿Qué tipo de tecnología necesito?

En nuestro caso las respuestas son: 1. iOS, 2. iPad, 3. OpenGL. El punto 1 y 2 lo dominamos sin problemas, pero el punto 3 es donde estamos más flojos. Basado en estas premisas, nuestra decisión ha sido la de utilizar Cocos2D como framework de desarrollo de nuestro cuento. Sin duda, una gran experiencia teniendo en cuenta nuestras carencias y el resultado.

Cocos2D es un framework de desarrollo basado en OpenGL mediante el cual se pueden implementar la mayoría de juegos y aplicaciones 2D sin ningún tipo de problemas. Incorpora soporte para el motor de físicas Box2D que es perfecto si lo necesitas. La curva de aprendizaje es baja y te permite implementar bastantes de las interactividades que este tipo de proyectos necesitan, además de ser fácilmente extensible, ya sea en funcionalidad o complejidad gráfica (OpenGL).

Pero claro, Cocos2D no deja de ser un framework de desarrollo, pero una vez revisado el material gráfico para el proyecto, te das cuenta que necesitas alguna herramienta para construir las diferentes escenas (en nuestro caso, del cuento interactivo). Con la experiencia de LevelSVG y CocosBuilder, hemos decidido utilizar LevelHelper y SpriteHelper.

Estas dos herramientas te permiten definir visualmente el aspecto que van a tener tus escenas. Es como reconstruir el archivo PSD de Photoshop original pero orientado a Cocos2D. Digo el archivo PSD de Photoshop porque normalmente los diseñadores e ilustradores utilizan esta herramienta para construir y transmitir su material.

Ambas herramientas son de pago, aunque su precio es pequeño en comparación con lo que aportan. El autor da un soporte muy valioso, respondiendo al e-mail casi al momento en caso de duda. LevelHelper te permite definir las escenas y las características de los elementos que forman parte ellas (físicos o no), además de incorporar características comunes en este tipo de juegos/aplicaciones (animaciones y parallaxes). Aunque tiene algunas carencias, como el soporte para UI's, la herramienta evoluciona muy rápidamente en el tiempo. SpriteHelper te permite generar los atlas de imágenes (Sprite Sheets) tan valiosos para un buen rendimiento de tu juego/aplicación (es una herramienta similar a TexturePacker o Zwoptex, menos potente, pero imprescindible para usar LevelHelper).

Para acabar, que nadie se piense que mediante el uso de Cocos2D,LevelHelper y SpriteHelper las cosas se mueven o interactúan sólas. ¡La lógica del juego/aplicación la construyes tú!

M.

Portales donde promocionar tus apps

Esta página pretende ser un lugar de recopilación de portales donde promocionar tu app, principalmente orientada al mercado Español y Latinoamericano. La idea surgió a raíz del feliz encuentro de esta otra página de portales americanos http://maniacdev.com/2012/05/ios-app-review-sites/

Cualquier producto que se desarrolla llega a su fase de lanzamiento y por lo tanto de promoción. Es en ese punto donde desarrolladores indie o pequeñas empresas como la nuestra sufren especialmente. Hemos dedicado muchas horas para recopilar información para promocionar Rita La Lagartija y, además de otras acciones de marketing necesarias, esta lista con el top de portales de review puede resultar interesante para empresas sin muchos recursos.

Esta lista no es cerrada y espero que esté en continua actualización, ya sea porque hemos encontrado más portales a incluir o porque nos comentáis otros no incluidos. No dudes en hacernos llegar cualquier comentario o sugerencia sobre la lista.

Esta es la lista ordenada por Alexa rank

Nombre	SO	Alexa Rank	Free Review	Paid Review	Ads	Contacto
Softonic	General	191	Sí	Sí	Sí	Formulario
IGN	General	432	Sí	No	Sí	Mail
Meristation	General	4.500	¿?	Sí	Sí	Formulario
Applesfera	iOS	7.584	Sí	¿?	Sí	Formulario
Trucoteca	General	9.791	Sí	¿?	Sí	Formulario
VaDeJocs	General	9.991	Sí	Sí	Sí	Formulario
El Androide Libre	Android	12.363	Sí	Sí	Sí	Formulario
Xataka Móvil	General	12.903	Sí	¿?	Sí	Formulario
Mediavida	General	12.922	¿?	¿?	Sí	Mail
AppleWeblog	iOS	13.690	Sí	Sí	Sí	Formulario
TICBeat	General	18.742	¿?	Sí	Sí	Formulario
Actualidad iPhone	iOS	22.452	Sí	Sí	Sí	Formulario
GeeksRoom	General	22.559	Sí	No	Sí	Formulario
tuexperto.com	General	30.039	Sí	No	No	Mail
iPadizate	iOS	32.642	Sí	Sí	Sí	Formulario
ClubiFone	iOS	47.318	No	No	Sí	Formulario
Baquia	General	54.415	Sí	¿?	Sí	Formulario
Alfa Beta Juega	General	92.292	Sí	No	No	Mail
VicioJuegos	General	104.210	Sí	No	Sí	Formulario
Soft&Apps	General	104.235	Sí	No	No	Mail
Manzana Mágica	iOS	133.702	Sí	No	No	Formulario
android.es	Android	140.159	Sí	No	No	Formulario
Aplicaciones Android	Android	149.386	Sí	Sí	Sí	Formulario
actualidadiPad	iOS	158.833	Sí	Sí	Sí	Formulario
Overlapps	General	198.483	Sí	No	Sí	Formulario
The App Date	General	212.508	Sí	No	No	Mail
iPadSfera	iOS	214.538	Sí	Sí	Sí	Formulario
iPhone4Spain	iOS	246,608	Sí	¿?	¿?	Mail
Macapuntes	iOS	259.201	Sí	No	No	Formulario
Peques y Más	General	268.717	Sí	¿?	Sí	Formulario
Maquecitos	iOS	301.437	Sí	No	Sí	Twitter
LinciNews	General	357.145	Sí	¿?	Sí	Formulario
Pocket Invaders	General	462.434	¿?	¿?	¿?	Mail
Ático Digital	General	508.055	Sí	No	Sí	Mail
Androjuegos	Android	732.759	Sí	No	No	Formulario
Appuntes	iOS	2.836.155	Sí	No	No	Formulario

Actualizado el:28/09/2012

No dudes en compartir esta información con el resto de la comunidad de desarrolladores para que puedan promocionarse. Y si ves cualquier error o punto de mejora coméntanoslo.

Nota: Free review no implica que siempre publiquen todas las reviews que se piden. Sólo que tienen servicio de review sin cobrar

"Arrejunta" y vencerás

Aquí estamos de vuelta, por segunda vez. Y es que escribir en el blog es bastante más complicado de lo que nos parecía en principio. No sólo por pensar temas de interés y saber darles forma, sino más bien por el tiempo. Espero que este segundo retorno del blog sea el definitivo.

Durante todos estos meses no hemos parado de hacer cosas, principalmente apps para clientes. Este ritmo de desarrollo ha provocado que dejemos de lado el desarrollo de productos propios, que siempre había sido nuestro interés principal cuando decidimos montar divertap. De hecho sigue siendo nuestro principal objetivo. Aún así, sí que hemos hecho el esfuerzo de pensar cuál debería ser nuestra estrategia de cara al desarrollo de juegos para smartphones: no buscar un hit en iOS sino abarcar más mercado para hacer pequeños productos interesantes.

Este enfoque es el que he llamado "arrejuntar", es decir, conseguir tener mucho más mercado objetivo (iOS y Android principalmente) en torno a los productos que publiquemos. Sabemos que iOS tiene un mercado muy grande, pero también una competencia feroz. Por eso apostamos por conseguir llegar a muchos más usuarios potenciales que crear un producto exclusivo de una sola plataforma. Esto no quiere decir que supongamos que por que haya mucha más usuarios posibles será más sencillo conseguir tener éxito, sino que definiendo bien una línea de productos concretos (por ejemplo apps y juegos educativos para niños), es más viable conseguir una pequeña comunidad de usuarios/clientes de nuestros productos si apostamos por varias plataformas.

Hace tiempo hicimos un primer intento de desarrollar los productos directamente en cada plataforma nativa (Objective-c y Java), resultó un fracaso. No conseguimos avanzar en la parte de Android y nosotros tampoco conseguimos tener el tiempo para aprender a desarrollar en esa plataforma. Pero es que además esa línea de desarrollo, cada plataforma por separado, es excesivamente costosa. No se las grandes compañías si pueden abordar el desarrollo de productos con equipos diferenciados, pero divertap somos dos y teníamos que asumir otra línea de desarrollo más factible.


Por "desgracia" esa apuesta nos lleva irremediablemente al desarrollo cross platform. Y digo por desgracia porque ese mundo es otra galaxia más. Si el desarrollo de apps para iOS fue un mundo nuevo, el del desarrollo cross platform es una galaxia. Lua, C++, C#, Javascript, HTML5 y un largo elenco de lenguajes y tecnologías nos venían a la pantalla con hacer una pequeña investigación. Si el conjunto de lenguajes era grande, el conjunto de productos/frameworks/skds que hay para desarrollo cross es casi infinito (http://www.mobilegameengines.com/).

Hemos estado un poco perdidos mirando y evaluando herramientas de desarrollo de juegos 2D. Muchas de ellas muy interesantes, cada una con sus pros y contras. Concretamente nosotros teníamos en mente estas características básicas que debía tener:

1. Poder extender la sdk básica de forma relativamente sencilla
2. Poder usar APIs nativas donde fuera necesario
3. Poder conectarse a servidores de juegos por turnos
4. Herramientas que faciliten el desarrollo
5. Soporte a diferentes plataformas y resoluciones de pantalla de una manera 
6. Buen soporte de físicas (a poder ser con motores de físicas conocidos como box2d o chipmunk)
7. Completo catálogo de operaciones 2D
8. Una comunidad de desarrolladores activa y con documentación abundante

Lo malo de esas 8 características es que casi todos los productos dicen que lo tienen (cómo no :) Por eso llegar a decidir qué herramienta usar es un proceso costoso: conocer el producto (formarse) y desarrollar una prueba de concepto para probar sus cualidades. En realidad ninguna cumple al 100% con esas expectativas o por lo menos no de forma sencilla y directa.


En nuestro caso no hemos hecho un estudio exhaustivo, por un lado nos hemos "casado" con una herramienta que nos parece muy interesante: LevelHelper, que te permite definir escenas, animaciones, físicas para juegos y cuentos animados en 2D. Además genera código para cocos2d-x y CoronaSDK. Y por otro lado nos hemos dejado aconsejar por Edenic Games para usar Unity3D.


Otra alternativa aún por explorar es una herramienta cross platform que está a punto de ver la luz, de forma pública. Es Strawberry, un producto de desarrollo cross que mezcla C++ y HTML5 que ha sido construido por no2. Lo han usado en todos sus productos y parece realmente interesante, le tendremos que dar una oportunidad.


No tengo como objetivo aquí explicar las diferencias entre cada herramienta ni siquiera explicar sus virtudes o defectos.  Por ahora sólo las menciono, pero seguro que iremos escribiendo sobre todos esos productos, porque los próximos meses nos acompañarán en nuestro camino.