Los famosos estados «waiting for review» y «ready for sale»

¿Cuánto tiempo ha transcurrido sin saber dar señales de vida? Hemos estado en el limbo de las validaciones de apple. Es comprensible que una marca como apple reciba miles de aplicaciones diarias para su análisis y precisamente, ese este análisis minucioso el que hace que su tienda funcione tan bien y tan elitista. Pero esto tiene un precio para los desarrolladores: una larga espera.

Como nuestro estudio es pequeño, nuestras inversiones también lo son, pero el haber estado tantos días parados y a la espera nos ha puesto un poco de los nervios. Así que os contamos un poco nuestra película con nuestra primera aplicación en iOS por si a alguien le sirva que no vuelva a cometer nuestros errores.

23 de Marzo de 2014 – Día 1

Tras terminar de portar todo nuestro juego y acabar con todas las adaptaciones necesarias nos disponemos a mandarlo. Para ello usamos el XCode.

En primera instancia no hay ningún problema, la aplicación se valida y se sube sin ninguna complicación y nuestro juego recibe el estado de «Waiting for Review».

wait

Creíamos que ya podríamos brindar, y de hecho lo hicimos, pero no sabíamos que el dolor de cabeza acababa de empezar… XD

31 de Marzo de 2014 – Día 8

No tenemos noticia alguna, pero como estamos al tanto de las novedades que incorpora apple imaginamos que habrán tenido una subida masiva de apps debido al apple watch. Así que con algo de impaciencia se nos ocurre buscar en internet el tiempo medio de espera en este estado.

Esto es como cuando te duele algo y buscas en internet a qué enfermedad corresponde tu síntoma, que siempre es cáncer o algo mortal. Pues en este caso no era diferente, la gente sólo escribe cuando está de los nervios y el tiempo de espera medio se dispara.

Así que encontramos una página, por casualidad, que toma datos de desarrolladores para estimar promedios. Que por cierto la recomiendo:

http://appreviewtimes.com/

time

Claro, como pone 8 días y es nuestro octavo… pues la histeria se nos come, pero tranquilos que no es ni buena ni mala señal, simplemente aún no han tocado tu aplicación, ni saben que existe. Así que no hay porqué preocuparse.

2 de Abril de 2015 – Día 10

¡Por fin! Ya tenemos noticias de apple y esta vez toda una lista:

«Prepare for upload», «waiting for review», «in review», «pending developer release».

statesreviewios

Quiero decir que cuando puso el estado In Review me saltó una notificación en el iPad. Era de madrugada y no pude dejar de consultarlo a cada instante. Es como cuando un profesor te corrige un examen contigo delante. No sabes qué hace, ni qué le pasa por la mente, ni si es bueno o es malo.

Fue una horita de incertidumbre, en la que al poco recibí el otro estado: «Pending Developer Release«.

Recibí este estado porque nosotros señalamos que queríamos decidir cuando publicarlo, esto es así porque pretendíamos sacarlo el 27 de Marzo, de hecho esa era su fecha de publicación. Como ya no tenía ningún sentido esperar porque la fecha quedaba en el pasado activamos la opción de publicarlo inmediatamente.

3 de Abril de 2015 – Día 11

Pues con toda la satisfacción del mundo ya observamos la esfera en verde ¡Qué ganas!

Obviamente notifiqué al resto del equipo que ya podían descargarlo para comprobar en otros dispositivos que todo funciona correctamente. Ya sé que lo ha comprobado apple y que nosotros lo testeamos, pero nunca viene de mal una tercera comprobación.

readyforsale

Sin embargo la sorpresa nos la llevamos cuando nadie ve la aplicación en el store. No obstante notifican que puede tener un retraso de 24h.

4 de Abril de 2015 – Día 12

Ni rastro de la app. En la ficha hay un enlace que pone «View in the app Store» Pero ese enlace está roto, no lleva a ningún lado.

vew

 

Nos ponemos a buscar problemas similares por internet, otra vez como el caso de los dolores y las enfermedades. Eso cuando encontramos algo, porque a la gente le gusta ignorar los problemas ajenos.

Pero en algún momento de nuestra búsqueda descubrimos que tenemos un mail de apple en el que nos explica algunas cosas que tienen que cumplirse para que nuestra app, que ya está en «Ready for sale» realmente aparezca en la tienda:

  • Hemos de verificar en la sección de Precios y Distribución que su fecha esté en el pasado, el precio y que hallamos marcado alguna región. (Esto ya estaba, todas las regiones sin discriminación, el 27 de marzo y el precio gratis)
  • Hemos de comprobar que en la seción de Acuerdos (Agreements, tax & bank) esté todo correcto (El nuestro no lo está, sólo tenemos aprobada el acuerdo de app gratis)

Indagando más por internet descubrimos a que muchos desarrolladores NO les publican si no completan los otros dos acuerdos, el de app de pago y el de app con compras dentro de la app. La verdad es que no tiene ningún sentido para nosotros porque nuestra aplicación es GRATIS. No obstante donde manda patrón, no manda marinero… Así que hacemos caso y obtenemos al final una pantalla como esta:

agreements

 

Además leemos en estos posts, que una vez modificado debes esperar entre 24 y 48 horas para ver tu app en la tienda.

7 de Abril de 2015 – Día 15

Nuestra app no está. ¿Por qué? Realmente esta pregunta no expresa el tono adecuado, sería algo así:

¿¿¿¿¿¿¿Por quéeeeeee???????

Añádele una pizca de desesperación y un par de lágrimas…

Ahora en serio, no podemos esperar más, tenemos otros juegos y actualizaciones que queremos subir y estamos esperando a tener todo el tema controlado para no cometer dos veces los mismos errores.

Así que recurrimos al camino «cansino» pero efectivo: mandar un mail al soporte de apple para recibir ayuda. Al hacerlo recibo un mail automático en el que pone que me dan las gracias por ponerme en contacto, que seré atendido lo antes posible pero que podrían tardar en contestar debido al gran volumen de mails que reciben.

La verdad es que yo lo entiendo, cada persona tiene dos manos y no pueden duplicarse. Pero a estas alturas de la espera y acostumbrado al Google Play que tarda 2 horas como mucho en publicarse algo… Lo cierto es que me entró la risa. Sí, sí, no me cachondeo de nadie, es esa risa histérica que te entra justo antes de volverte loco y convertirte en un psicópata a sueldo.

Pero diga lo que diga NO me puedo quejar, porque me contestaron en un tiempo récord, ese mismo día. Así que la demencia tendrá que esperar.

Resulta que no señalamos el nivel de madurez al enviar el juego a validar. Realmente podría validarlo la misma web o los mismos testeadores, porque al probarlo yo creo que ven si el juego es violento, pornográfico o lo que sea… Pero lo cierto es que el error fue nuestro, así que nos toca corregirlo.

8 de Abril de 1015 – Hora 0:52 – Lugar: Zulú o donde cristo perdió el gorro… (Día 16)

No podemos modificar la clasificación. No, no hay un botón editar para cambiar estas cosas, se impone crear una NUEVA VERSIÓN para poder modificarlo.

A lo mejor nos confundimos, pero probamos a través de la app, por la página web, en distintos navegadores… Pero no hay forma. Entramos a los diferentes submenús de nuestra versión, pero este campo no deja modificarlo…

Así que a nuestro pesar, creamos la nueva versión 1.0.93, en la que no añadimos absolutamente nada, salvo la clasificación +9 años (Lo siento chicos, pero el muñeco al morir explota en cachitos…)

Pero no iba a ser tan fácil, al darle a «envíar» no nos deja.

Hemos de señalar «el binario». El archivo de juego, el ejecutable, vamos… nuestro juego. Y no nos deja marcar el que ya subimos. Así que compilamos otra vez indicando que es la versión 1.0.93 y no la 1.0.92. Lo volvemos a mandar y ahora sí que podemos darle a «envíar a revisión».

¿Y sabéis lo que pasa cuando enviamos?

Pues sí amigos míos, la noria gira, el bucle se repite… esto es como la película de «Atrapado en el tiempo» o «el día de la marmota». Nuestra aplicación vuelve a estar ahora en: «Waiting for review». El estado que teníamos hace 16 días

wait

 

 

 

Portando a iOs el Survivor Silhouette – Parte 2

Hace unos días comentábamos las primeras impresiones que tuvimos portando uno de nuestros juegos de Android a iOs. Hoy retomamos el tema abordando una segunda parte.

PANTALLAS DE INICIO Y MENÚS

Como ya comentábamos hemos tenido que reestructurar el juego para adaptarlo a la nueva resolución de 1920×1080. No ha sido muy complicado ya que optamos por «alejar la cámara» y mostrar más espacio durante el juego. Sin embargo no podemos hacer lo mismo con el resto de pantallas (menús y selección nivel), porque estaban diseñadas adrede para 960×640 y si «alejamos» mostraremos un mosaico feo.

Se impone por lo tanto reestructurar estas pantallas:

Pantalla a 1920×1080 de CoolPixel Games. Bueno, esto no ha sido muy costoso, ya que es nuestro logo y lo tenemos en dimensiones desproporcionadas. Simplemente hemos tenido que sustituir la antigua por la nueva.

Pantalla de Inicio.  Aunque la pantalla de inicio es muy simple, hemos decidido modificarla un poquito, porque siendo tan grande queda muy pobre con su aspecto original.

Pantalla de Selección de mundo. Utilizamos el mismo fondo anterior y distanciamos un poco más los iconos. No supone un problema porque como vamos a añadir más mundos, cuanto más amplia sea la pantalla más mundos cabrán.

Pantalla de Selección de Nivel. Utilizamos parte del diseño de inicio para añadir los niveles sin perder mucho espacio. Así el trabajo de antes no ha sido en balde, no hay mal que por bien no venga.

BOTÓN ATRÁS

WTF!! (Piiiiiii – sonido de censura)

Nos encantaría enseñar la cara que se nos ha quedado al descubrir que los dispositivos de apple no tienen botón de atrás. Siempre le hemos añadido funciones en todos nuestros juegos, y el saber que ahora no tiene ha sido un duro golpe. ¿Por qué? Porque nos valíamos de él para no tener que implementar el típico botón en la pantalla y despejarla de tantos botones.

Menús y selección de pantalla. No es el fin del mundo, teníamos implementada una flecha de volver a atrás, así que tampoco vamos a echarnos a llorar.

Menú de juego. Aquí ya duele un poco más la cosa, porque usábamos el volver a atrás para desplegar un menú. Sin embargo, ahora que la pantalla es tan grande y se ha despejado la cabecera, vamos a incluirlo siempre desplegado con dos únicos botones:

  • Salir
  • Reiniciar

¡¡CAMBIOS INESPERADOS!!

Y ahora es cuando nos reímos a carcajadas… El juego se veía mal por la resolución… pero también se veía borroso porque estábamos trabajando con las librerías antiguas y no reconocía el iPad Air 2, y lo trataba con la resolución del iPhone 4… Así que reescalaba los gráficos varias veces y creaba un efecto borroso.

¿Todo lo que hemos hecho no sirve de nada?

Bueno yo no iría tan lejos, porque la verdad es que hemos optimizado el código para que respete las proporciones de la pantalla y no vaya a ojo. Preferimos la resolución anterior para que no se vea tanto mapa, pero ya que lo hemos optimizado a esta resolución… usaremos 1920×1080 para todo el juego, pero para los niveles reduciremos un poco, a 1248×832 (un 30% más grande que en la versión de Android).

TESTEO

Bueno llegados a este punto sólo nos queda ir testeando los niveles con la nueva resolución para ver que no hay fallos gráficos ni de jugabilidad. Esta fase la dividiremos en 2:

  • una en la que nos pasaremos el juego en el iPad
  • otra para el móvil.

¿Por qué? Porque así comprobaremos que se ajusta a diferentes resoluciones sin problemas y que los botones virtuales y menús funcionan correctamente.

Y ahora sólo falta esperar la validación de Apple, que antiguamente era mucho tiempo, ahora comprobaremos cuánto nos tienen esperando…

Portando a iOs el Survivor Silhouette – PARTE 1

Pues ha sido una semana muy larga con mucho trabajo y apenas hemos podido dedicar tiempo a lo que nos importa de verdad. Entre configurar el equipo, las actualizaciones a las nuevas versiones, corregir algunos bugs de otros juegos y algunas otras tareas casi no hemos tenido tiempo de ponernos con el dilema en cuestión: portar un juego a iOs.

LA RESOLUCIÓN

El primer problema que nos surgió fue la resolución. Porque en Android hay miles de dispositivos y cada cual tiene una resolución. Así que intentamos usar una resolución bastante utilizada 960×640 y de esa vamos reescalando según el dispositivo.

Sin embargo cuando llegamos a apple nos hemos dado cuenta que trabajan con resoluciones muy altas, puesto que son aparatos un poco más caros que la media lo que los sitúa en una gama muy elevada. Así que el iPad Air 2 que es la herramienta con la que vamos a testear nuestros juegos se planta en una resolución de 2048×1536.

Rápidamente echamos un vistazo a las resoluciones más frecuentes de dispositivos apple:

  • iPad Air 2: 2048×1536
  • iPhone 6: 1920×1080
  • iPhone 6; 1334×750
  • iPhone 5s: 1136×640
resolucionapple2

Resolución dispositivos iOs de Apple

 

El problema está en que cuando reescalamos de nuestra resolución nativa de 960×640 a la del iPad Air 2… no es que se vea pixelado, es que se ve megapixelado. Y aunque somos un defensor del pixel, una cosa es hacer un juego pixelado a propósito y otra diferente es que se vea tan mal sin quererlo…

Así que nos vemos obligados a cambiar la resolución con la que trabajaremos en apple, lo que nos obligará a cambiar bastante programación del juego y lo que puede ser peor… tener que rehacer algunos dibujos.

Por lo que a primera vista, lo que iba a  ser portar fácilmente un juego se complica un paso más allá.

Y dicho esto ¿con qué resolución trabajaremos? Pues excepto las del iPad, el resto son múltiplos por lo que a la hora de reescalar conservan el aspecto bonito y proporcionado. Así que utilizaremos la más alta de estas, que será 1920×1080.

PRIMERAS PRUEBAS

Las primeras pruebas fueron un caos, porque no cambiamos la resolución y el aspecto del juego era bastante pobre.

640 en iOs

960×640 en iOs

 

No sé si aprecia en la imagen, pero los bloques negros se ven con pequeñas transparencias en las esquinas y hemos tenido algún error gráfico. Todo eso sumado a que ahora se ve borroso.

El problema de los bloques son los tiles, porque usamos imágenes grandes de las cuales solo usamos porciones y al reescalar esas porciones empezamos a tener fallos gráficos en resoluciones no esperadas.

Quizá este error ya nos pasaba en alguna versión de Android, pero no éramos conscientes porque no tenemos dispositivos de resoluciones tan altas. No obstante hemos trabajado en solucionar este error y al final lo hemos conseguido.

Como rehacer todas las imágenes es muy costoso optamos por el camino fácil, alejar la «cámara». Ya que nuestros escenarios son bastante grandes, si vemos más escenario podemos mejorar la resolución notablemente sin apenas cambiar gráficos. Además esto ayudará al usuario a completar los niveles.

Simplemente hemos de centrar los paneles informativos de puntos, tiempo, etc. y cambiar la ubicación de los botones de control.

Tras corregir estas cosas y minuciosas pruebas, el aspecto del juego es algo así:

1920x180 nueva Resolución

1920×180 nueva Resolución

Ahora luce mucho mejor.

LA MÚSICA

Cuando sacamos este juego en plan beta para android, nos faltaba algo muy importante, la música. Así que usamos un recurso fácil que fue utilizar músicas de otros juegos nuestros que teníamos desarrollados para dejarle una melodía y no hacer un juego mudo.

Aunque de esta producción se está encargando Fernando Borja Moreno, de momento sólo tenemos una pequeña base a modo de prueba, que le falta mucho por pulir. Ha querido darle un toque industrial/siniestro y algo movidito. No obstante os dejo aquí la pimera prueba de sonido:

Survivor Silhouette: Gemas y Monedas

Ya comentábamos en otras entradas que aquel deseo de superar puntos, por el mero hecho de la superación personal es cosa de nuestra generación, quizá una generación ya en vías de extinción que ha dado paso a una nueva más evolucionada.

Así que los jugadores más jóvenes nos plantearon esa incómoda pregunta ¿Para qué sirve coger puntos? ¿Qué nos dan?

Así que ante tal incógnita hemos tenido que crear cosas especiales que animen a los jugadores a conseguir esos retos completando enteros los niveles.

EQUIVALENCIAS DE LOS NUEVOS OBJETOS

Os adjuntamos una tabla del valor de los 4 tipos de gema nueva y de las monedas. Por si alguno no ve la foto la explicamos:

  • 1 moneda = 1000 puntos y 100 segundos
  • 1 gema Verde = 5 puntos y 5 Puntos de Nivel
  • 1 gema Azul = 10 puntos y 10 Puntos de Nivel
  • 1 gema Roja= 25 puntos y 25 Puntos de Nivel
  • 1 gema Dorada = 100 puntos y 100 puntos de Nivel
survivor coins

¿Qué me dan las gemas y Monedas del Survivor Silhouette?

QUÉ SON LOS PUNTOS DE NIVEL?

Bueno, viendo la tabla anterior quizá os preguntéis qué son estos Puntos. En las versiones anteriores creamos un objeto muy interesante que eran las armaduras.

Cuando antes cogías una armadura, te transformabas en una evolución con el ojo naranja, lanzabas las armas de 2 en 2 y aguantabas dos golpes de la mayoría de enemigos.

Si volvías a conseguir una segunda armadura evolucionabas a lo que sería un nivel 3, lanzando 3 armas y aguantando hasta 3 golpes hasta morir.

Armadura o Gemas

Armadura o Gemas

Bien… pues eso es cosa del pasado. Ahora disponemos de una barra de Nivel que se irá rellenado a medida que consigamos gemas. La barra se llena con un total de 350 puntos dando lugar a una evolución de nivel superior.

 

barr

 

Lo primero que parece es que este cambio es peor, pues antes cogías un único objeto y ya evolucionabas. Pero en cuanto lo probéis veréis que hemos ido a mejor. ¿Por qué?

Porque en una misma pantalla podemos evolucionar un montón de veces. Podemos estar en el nivel máximo, recibir daño y tener la posibilidad de recoger monedas para volver al máximo nivel.

Además cuando bajas de nivel la barra de Nivel se mantiene por dónde la teníamos, siendo posible volver a evolucionar con muchas menos monedas.

Y para nosotros esto es positivo, porque os brindamos una ayuda siempre y cuando superéis la pereza de recoger gemas por el mapa. ¿A que ahora si os apetece perder el tiempo consiguiendo gemas?

POR QUÉ LAS MONEDAS OTORGAN TIEMPO?

Si recordáis la penúltima actualización, pusimos un máximo de 300 segundos por pantalla. Que por cierto el contador iba un poquito loco en algunos dispositivos móviles… Cosa que ya hemos ajustado.

Aún así había gente que apuraba el tiempo hasta el final, perdiendo no sólo el bonus de tiempo sino que algunos morían por su culpa.

Ahora las partidas sólo tienen 100 segundos. ¿Cómo? ¿Lo hemos complicado? Para nada… Porque con cada monedas que recoges obtienes 100 segundos extra, lo que hace un total de 400 segundos para acabar la pantalla. Por lo que  a fin de cuentas se os han concedido 100 segundos extra para poder acabar la pantalla.

BONUS DE TIEMPO

Cuando llegas al final se otorga un bonus de tiempo. Para nosotros el tiempo normal de una pantalla es de 300 segundos, por lo que si acabáis por encima de esa cantidad se os otrogará un porcentaje de puntos mayor del 100%. No os sorprendáis al ver cosas como + 115% de puntos.

Porque realmente seguimos esta fórmula:

tiempoBonus

Y el resultado de esa fórmula se le suma a los puntos que hemos conseguido. Si no lo entendéis muy bien ponemos un ejemplo redondo. Si llegamos a la meta habiendo conseguido 1000 puntos y con un tiempo sobrante de 150 segundos:

150/300*1000+1000 (sobrante/tiempo*puntos+puntos)

Y así en vez de ganar 1000 puntos, ganaríamos 1500 puntos, es decir, un 50% más de puntos.

¿Cómo se diseña un nivel?

Hemos hecho mucho hincapié en la programación de los juegos. Sin embargo una programación excelente no sirve para nada sin un diseño de niveles correcto. Un ejemplo claro de lo que decimos lo tenemos en el Portal  o Portal 2. No significa que su programación sea menos importante, pero si hubieran enfocado mal el diseño de cada uno de sus niveles el juego hubiera sido un completo fracaso. Gracias a Dios, no lo fue, porque es uno de los títulos que siempre nos han encantado.

Nosotros intentamos adaptar los diseños a la experiencia que vemos de los teteos de nuestros usuarios. Pero… ¿y antes de testearlo nadie? Pues realizamos algunos bocetos previos.

Paso 1. El Boceto

Hacer 4 rayas sobre un papel siempre será más rápido que colocar todos los elemento sobre un escenario. Así cualquier idea o corrección es mucho más rápida.

disenyo2

Cuando hemos garabateado una hoja nos hacemos una idea visual del nivel que queríamos crear. Hemos elegido el Nivel 6 del Mundo 2 del Survivor Silhouette para ilustrar este ejemplo.

En ocasiones nos ayudamos de colores para señalizar lo que pensamos que puede ser un camino principal de secundarios.

Paso 2. Portando nuestro boceto a una cuadrícula

Utilizamos hojas cuadriculadas para hacernos una idea de la situación de los objetos en el espacio. Con el boceto en mano es muy rápido comprobar la disposición de los objetos en una cuadrícula.

Podríamos obviar este paso, pero al trasladar nuestro boceto a una cuadrícula comprobamos si las proporciones son las adecuadas y no va restar movilidad al juego.

Sobre esta cuadrícula ya disponemos los objetos más importantes (llaves, monedas, puertas, etc.). Digamos que el «quebradero de cabeza».

Pase 3. Lo añadimos al juego

Naturalmente para realizar este paso debemos tener creado todos los elementos y toda la programación que haga falta ya lista, de tal forma que sólo es depositar los objetos en una interfaz gráfica.

Conforme lo iremos añadiendo a veces observamos algunos problemas que no habíamos previsto, incongruencias o mejoras. Deberemos testear repetidas veces los niveles en busca de fallo y para comprobar que realmente es posible de completar.

Aquí os dejamos un vídeo a velocidad rapidilla de cómo se diseñó el nivel 6 del Mundo 2 de Survivor Silhouette.

 

Survivor Silhouette Nuevo Trailer

Hace apenas unos días publicábamos la primera beta para intercambiar impresiones con algunos usuarios más allá de nuestro entorno. Estamos muy contentos de la colaboración que habéis mostrado y os hemos hecho caso redibujando las líneas de nuestro juego.

¿Qué novedades hemos incorporado?

– Hemos añadido dos enemigos nuevos, las bombas de proximidad y los lanzacohetes que te localizan.

– Hemos mejorado el movimiento de péndulo del hacha de tal forma que vaya con aceleración y deceleración progresiva.

– Hemos añadido una nueva variable tiempo. Si se acaba mueres y si llegas a la meta sin que se acabe te otorga una bonificación muy jugosa extra. Si ahorras más tiempo, más puntos te llevas.

– Al acabar las partidas hacemos un fundido en negro que explica lo anterior y queda más claro los puntos que has conseguido.

– Hemos variado algunas recompensas para que tenga sentido recoger las monedas:

  • Gemas – 5 puntos
  • Munición – 10 puntos
  • Armadura – 100 puntos
  • Monedas – 1000 puntos

– Hemos añadido algunos niveles nuevos y hemos incorporado uno en el que no puedas volver atrás porque un enemigo (una pared gigante de pinchos) te persigue. Así cambiamos un poco la dinámica.

– Hemos añadido botones que puedes chafar con el doble salto. Al hacerlo se activan otros objetos.

– Hemos ampliado un poco las colisiones del doble salto para facilitar romper bloques.

Y bueno, aquí os dejamos un pequeño trailer para la versión inglesa:

 

Survivor Silhouette: Gameplay y avance del Mundo 1

Llevábamos tiempo queriendo crear una mini-aventura al más puro estilo plataformas. Lo que empezó como un simple jueguecillo para probar unas cosas ha empezado a tomar forma y consistencia como un título más.

Es por ello que ya no podemos dejarlo como un tutorial o como un trozo de código olvidado. Así que hemos decidido darlo a conocer ¿Y qué mejor que un pequeño vídeo con su gameplay correspondiente?

Aún así este juego se encuentra en fase de desarrollo, pero hemos subido esta fase Beta a Google Play para que podáis ir conociéndolo, dar vuestra opinión, criticarlo (siendo buenos…. :P), y sobre todo darnos sugerencias para encaminar nuestro desarrollo. Aquí os dejamos un pequeño vídeo: