Librería multiplataforma para videojuegos en dispositivos ...

Librería multiplataforma paravideojuegos en dispositivos

móvilesTrabajo �nal propuesto para la carrera

Ingeniería de Sistemas

UNCPBA

Facultad de Ciencias Exactas

Alumno: Costa, Cristian Roberto

Dirección: Mg. Aciti, Claudio

Codirección: Ing. Bricker, Federico

Agradecimientos

A mis padres

Por haberme apoyado en todo momento, por los ejemplos de perseveranciay constancia que me han infundado siempre, sus consejos, sus valores, lamotivación constante que me ha permitido ser una persona de bien, peromás que nada, por su amor.

A mis familiares

Hermanas, tías, tíos y a todos aquellos que participaron directa o indirecta-mente en la elaboración de este trabajo �nal.

A mis amigos

Que siempre me han prestado un gran apoyo moral y humano, necesarios enlos momentos difíciles de este trabajo y esta carrera.

A mis tutores

Mg. Claudio Aciti e Ing. Federico Bricker, por la dedicación y apoyo que hanbrindado a este trabajo, por el respeto a mis sugerencias e ideas y por ladirección que han facilitado a las mismas.

i

Librería multiplataforma para videojuegos en dispositivos móviles

ii

Resumen

El presente trabajo �nal describe la utilización de mecánicas de juegos,una de las estrategias utilizadas para aumentar el nivel de audiencia y partici-pación de distintos usuarios en el ámbito de los videojuegos para dispositivosmóviles. Además, establece cómo hacer uso de los servicios para manipulardichas mecánicas. Éstos son proporcionados por las distintas API's de lascompañías que ofrecen las diferentes plataformas móviles y la capacidad deincluir las mecánicas de juego a cada proyecto.

Se planteó la construcción de librerías individuales que permitan utilizarlos servicios para manipular las mecánicas de juegos que ofrecen las compa-ñías Amazon, Google y Apple. A partir de ellas, se desarrolló una libreríaextra que las uni�que y que, a partir de la plataforma objetivo, determinedesde su lógica qué servicios debe utilizar un videojuego dado. El objetivoque satisface está relacionado a la disminución de tiempos de integración deestos servicios para los distintos proyectos.

Estas librerías se implementaron utilizando el framework multiplatafor-ma OpenFL, haciendo uso de la capacidad de generar extensiones que inclu-yan funcionalidad no provista por el mismo. Como OpenFL se apoya en elcompilador del lenguaje de programación Haxe, dichas librerías, solo podránser utilizadas en proyectos Haxe.

Las pruebas de los servicios de Amazon y Google se realizaron sobre unteléfono inteligente con Android como plataforma móvil, y sobre una instan-cia virtualizada de un dispositivo móvil iPhone utilizando una computadorapropietaria de Apple, denominada MacBook Pro.

iii


iv

Índice general

1. Introducción 1

1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.6. Organización del trabajo . . . . . . . . . . . . . . . . . . . . . 9

2. Estado del arte 11

2.1. Videojuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Videojuegos para dispositivos móviles . . . . . . . . . . . . . . 15

2.2.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.2. Diseño de aplicaciones lúdicas . . . . . . . . . . . . . . 24

2.3. Mecánicas provistas por las compañías móviles . . . . . . . . . 29

2.3.1. Amazon: Game Circle . . . . . . . . . . . . . . . . . . 31

2.3.2. Apple: Game Center . . . . . . . . . . . . . . . . . . . 37

2.3.3. Google: Google Play Games . . . . . . . . . . . . . . . 44

v


2.4. Herramientas para desarrollo de videojuegos móviles . . . . . . 51

2.4.1. Haxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3. Descripción del problema 57

4. Solución propuesta 61

4.1. Módulos puente . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.1.1. Amazon Game Circle . . . . . . . . . . . . . . . . . . . 64

4.1.2. Google Play Games . . . . . . . . . . . . . . . . . . . . 67

4.1.3. Apple Game Center . . . . . . . . . . . . . . . . . . . . 71

4.2. API Homogénea . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5. Pruebas de campo 83

5.1. Análisis de escenarios . . . . . . . . . . . . . . . . . . . . . . . 85

6. Conclusiones 97

7. Trabajos futuros 99

vi

Índice de �guras

1.1. Videojuego con características sociales de Google. . . . . . . . 6

1.2. Videojuego con características sociales de Apple. . . . . . . . . 6

1.3. Copias del mismo videojuego con distintas API's. . . . . . . . 7

1.4. Videojuego con características sociales de Google y Apple. . . 8

2.1. Videojuegos de las décadas del 50 y 60. . . . . . . . . . . . . . 12

2.2. Videojuegos árcade. Principio de la década del 70. . . . . . . . 12

2.3. Primeras consolas domésticas de videojuegos. Década del 70. . 13

2.4. Primeras consolas portátiles de videojuegos. Principio de ladécada del 80: Game & Watch; Final de la década del 80:Game Boy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5. Consolas domésticas de videojuegos. Década del 90. . . . . . . 14

2.6. Consolas portátiles de videojuegos. Década del 2000. . . . . . 14

2.7. Hagenuk MT-2000. . . . . . . . . . . . . . . . . . . . . . . . . 15

2.8. Nokia 6110 con juego Snake. . . . . . . . . . . . . . . . . . . . 16

2.9. Nokia 7110 con juego Snake II. . . . . . . . . . . . . . . . . . 16

2.10. Juego Alien Fish Exchange. Primer juego multijugador a par-tir de WAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

vii


2.11. Videojuegos del año 2003. Todos a color. Primera aparición dejuego en 3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.12. Videojuegos de los años 2004, 2005 y 2006 respectivamente. . . 19

2.13. Juego Tap Tap Revenge en dispositivo iPhone. . . . . . . . . . 20

2.14. Dispositivo HTC Dream, el primero con el sistema operativomóvil Android. . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.15. Juego Angry Birds. . . . . . . . . . . . . . . . . . . . . . . . . 21

2.16. Juego Ninja Fruit. . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.17. Juego Plague Inc. . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.18. El �ujo es alcanzado cuando un jugador se encuentra entre losestados de ansiedad y aburrimiento. . . . . . . . . . . . . . . . 24

2.19. Tipos de jugadores según Richard Bartle. . . . . . . . . . . . . 26

2.20. Metadatos de un logro de Amazon. . . . . . . . . . . . . . . . 32

2.21. Listado de logros registrados. . . . . . . . . . . . . . . . . . . 33

2.22. Metadatos de una tabla de puntajes. . . . . . . . . . . . . . . 34

2.23. Listado de tablas de puntajes registradas. . . . . . . . . . . . . 35

2.24. Metadatos de un logro de Apple. . . . . . . . . . . . . . . . . 38

2.25. Metadatos de un idioma de un logro de Apple. . . . . . . . . . 39

2.26. Listado de todos los logros creados. . . . . . . . . . . . . . . . 39

2.27. Metadatos de una tabla de clasi�cación de Apple. . . . . . . . 40

2.28. Metadatos de un idioma de una tabla de clasi�cación de Apple. 41

2.29. Listado de todas las tablas de clasi�cación creadas. . . . . . . 42

2.30. Metadatos de un logro de Google. . . . . . . . . . . . . . . . . 45

2.31. Listado de logros registrados. . . . . . . . . . . . . . . . . . . 46

2.32. Metadatos de una tabla de puntajes de Google. . . . . . . . . 47

viii

ÍNDICE DE FIGURAS

2.33. Listado de tablas de puntajes registradas. . . . . . . . . . . . . 49

2.34. Recursos dados de alta en la consola de desarrollador. . . . . . 49

4.1. Diagrama de la solución en alto nivel. . . . . . . . . . . . . . . 61

4.2. API Homogénea. . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.3. Suscripción orientada al servicio. . . . . . . . . . . . . . . . . 68

4.4. Diagrama de secuencia de servicio sin retorno. . . . . . . . . . 82

4.5. Diagrama de secuencia de servicio con retorno. . . . . . . . . . 82

5.1. Productos de Sempai Games. . . . . . . . . . . . . . . . . . . 83

5.2. Inicializaciones del videojuego Puralax. . . . . . . . . . . . . . 85

5.3. Tablas de clasi�cación del videojuego Puralax. . . . . . . . . . 86

5.4. Logros del videojuego Puralax. . . . . . . . . . . . . . . . . . . 86

ix


x

Índice de cuadros

3.1. Interfaz de la solución . . . . . . . . . . . . . . . . . . . . . . 59

3.2. Utilidades iniciales de la empresa. . . . . . . . . . . . . . . . . 60

5.1. Tarea de integración - Sin Multigames. . . . . . . . . . . . . . 89

5.2. Tarea de desarrollo - Sin Multigames. . . . . . . . . . . . . . . 89

5.3. Tarea de testing - Sin Multigames. . . . . . . . . . . . . . . . 89

5.4. Tiempo total - Sin Multigames. . . . . . . . . . . . . . . . . . 90

5.5. Cantidad total de código fuente - Sin Multigames. . . . . . . . 90

5.6. Tarea de integración - Con Multigames. . . . . . . . . . . . . . 91

5.7. Tiempo total - Con Multigames. . . . . . . . . . . . . . . . . . 92

5.8. Cantidad total de código fuente - Con Multigames. . . . . . . 92

5.9. Diferencia en la cantidad de días entre ambos escenarios. . . . 92

5.10. Porcentaje de reducción de código fuente entre ambos escenarios. 93

5.11. Integración sobre Puralax - Sin Multigames. . . . . . . . . . . 93

5.12. Integración sobre Puralax - Con Multigames. . . . . . . . . . . 94

5.13. Tiempo total Puralax - Sin Multigames. . . . . . . . . . . . . 94

5.14. Tiempo total Puralax - Con Multigames. . . . . . . . . . . . . 94

xi


xii

Capítulo 1

Introducción

1.1. Antecedentes

En el último año se ha observado un rápido crecimiento del mercado delos teléfonos inteligentes, con niveles de ventas del orden de los 1200 millo-nes de unidades en 2014, que representan un incremento del 28.4% respectoal año anterior [Gartner, 2015]. Por un lado, en términos de hardware ta-les dispositivos muestran incrementos en las capacidades de procesamiento,almacenamiento y conectividad. Por otro lado, en el aspecto del software,estos dispositivos poseen una plataforma móvil (o también sistema operativomóvil) facilitada por distintos proveedores.

Actualmente los proveedores que dominan el mercado de las plataformasmóviles son Google y Apple, con sus sistemas Android e iOS respectivamente,mientras que en un segundo plano se sitúan los proveedores Windows y Black-Berry con sus plataformas Windows Phone y BlackBerry OS [Nielsen, 2015b].En este ámbito, cada proveedor decide el lenguaje de programación en el cualestá concebida su plataforma móvil. Estos proveedores incluyen en cada unade sus plataformas, una aplicación principal denominada tienda (o tambiengestor de aplicaciones) que contiene una gran cantidad de aplicaciones dispo-nibles para ser instaladas en los dispositivos [Jansen and Bloemendal, 2013].Las aplicaciones pueden seguir distintas estrategias de monetización y pro-ducir ganancias tanto para el dueño de la misma como para el proveedor dela plataforma móvil.

Hay distintos actores que se pueden corresponder al rol de dueño de una

1


determinada aplicación. Esto se debe a que no hay restricciones sobre quiénpuede ser el creador de la misma. A partir de esto, las distintas entidadespueden ser:

El fabricante del dispositivo móvil.

La compañía proveedora de la plataforma móvil.

Un desarrollador independiente.

Una empresa dedicada al desarrollo móvil.

Para cualquiera de los casos, el desarrollador sube su proyecto a la con-sola del desarrollador del proveedor. Este último valida la aplicación a serinsertada a partir de las políticas que impone, pudiendo aprobarla o recha-zarla. En caso de que la aplicación no viole dichas políticas, será publicadaen la tienda correspondiente.

Intuitivamente, se puede pensar que el desarrollador tenga como deseoabarcar la mayor cantidad de tiendas con la misma aplicación. Esto lo reali-zará con el objetivo de tener una mayor cantidad de usuarios �nales y, por lotanto, una mayor ganancia. Pero dado que cada proveedor utiliza una tecno-logía y lenguaje de programación diferentes, el desarrollador se ve obligadoa crear la misma aplicación en los diferentes lenguajes. Por ende, el deseo deabarcar cada tienda, a priori, implicaría tener el mismo proyecto replicado.Éste tendrá la misma lógica pero el lenguaje de programación en el que estédesarrollado establecerá la diferencia. A partir de ello, se incrementa el tiem-po de aprendizaje del desarrollador con cada lenguaje y el posterior tiempode desarrollo [Joorabchi et al., 2013].

Ningún tipo de aplicación está exento de esta problemática. Aún así,es normal encontrar la misma aplicación en las diversas tiendas de los dis-tintos proveedores. Un claro ejemplo de esta situación, son los videojuegos.Actualmente, este tipo de aplicación cuenta con aproximadamente 115 mi-llones de usuarios �nales. Tal magnitud representa el 76% de los usuariosque poseen al menos una aplicación de este estilo instalada en su dispositivomóvil [Nielsen, 2015a].

Nótese el detalle de que dicho porcentaje es engañoso. Este número in-dica que los videojuegos poseen una gran audiencia, pero no permite sabercuales son los videojuegos que poseen los diferentes usuarios en sus disposi-tivos. Más puntualmente, este número no indica cuales son los videojuegos

2

1. Introducción

que más usuarios atrae. Es necesario saber esto porque, el requisito más im-portante que debe presentar cualquier videojuego está relacionado al nivelde compromiso (en ingles engagement) o �enganche� que este genere con elpúblico.

Como en cualquier actividad ludi�cada como son los videojuegos, el ni-vel inicial de audiencia está determinado por el núcleo o trama del juego.Pero, a partir de ese núcleo, el potencial incremento en el nivel de audien-cia está determinado por las Mecánicas de juegos que este posea. Tales ele-mentos son complementados al videojuego pudiendo ser: logros, barras deprogreso, niveles, tablas de clasi�cación, sistemas de puntajes, entre otros[Adams and Dormans, 2012].

En el ámbito de los videojuegos para dispositivos móviles, los provee-dores opcionalmente permiten la generación de algunas mecánicas de juegos[Techtarget, 2014]. Las mecánicas que estos últimos ofrecen son el uso delogros y tablas de clasi�cación. Cada proveedor se encarga de nutrir cadatabla de clasi�cación con los distintos participantes del mismo videojuego.Así mismo tales proveedores facilitan la difusión de los avances de cada ju-gador para los logros que vaya desbloqueando, con el �n de informar al restode jugadores. De esta forma, se establece un estado de competitividad entrejugadores, provocando la participación de cada uno con el juego en su afánde superar a los restantes [Tapdaq, 2015].

En caso de que el desarrollador decida crearlas, lo hará desde la con-sola del desarrollador del proveedor correspondiente. Estas, eventualmente,pueden ser complementadas con las mecánicas propias que el desarrolladorgenere (niveles, sistemas de puntajes, etc).

Dado que, desde la consola de desarrollador las mecánicas son generadas,es necesario poder hacer uso de ellas desde la lógica del videojuego. Para ello,cada compañía proveedora ofrece una API con servicios necesarios. A partirde esto, primero es obligatorio integrar cada API al videojuego, para que, enun segundo paso sus servicios puedan ser utilizados.

En caso que el desarrollador simultáneamente opte por:

Lanzar el mismo videojuego en las distintas tiendas.

Utilizar en tal aplicación las mecánicas de juego provistas por los dis-tintos proveedores.

3


Se encontrará con desventajas impuestas por las API's que las manipu-len:

Por un lado, el proceso de integración de cada API es distinto para conel mismo proyecto.

Por otro lado, padecerá la falta de estandarización de estas API's pu-diendo suceder las siguientes situaciones:

• Ciertos servicios que otorgue la API de una compañía, pueden noestar en la API de otra.

• Si las API's ofrecen el mismo servicio, pueden variar en nombrepara invocar tal servicio.

• Los parámetros de entrada que requiere cada servicio (cantidad ytipo de cada uno), como así también el valor de retorno de cadauno pueden no ser necesariamente iguales.

Por último, cada API se encuentra implementada en el mismo lenguajede programación que la plataforma móvil del proveedor. Por ende, lalógica del videojuego también debe ser desarrollada en tal lenguaje.

Estas situaciones provocan que el deseo de abarcar la mayor cantidad detiendas lo convierta en una tarea costosa por el hecho de replicar el videojuegopara cada plataforma. Esta actividad impone tiempos de:

Aprendizaje de cada nuevo lenguaje.

Desarrollo en cada lenguaje.

• Para la lógica del videojuego.

• Para la integración y uso de los llamados de la API del proveedorasociada a la plataforma.

1.2. Motivación

En el contexto de una empresa en la que se desarrollan videojuegos paradispositivos móviles, sus objetivos constan en:

4

1. Introducción

Comercializar sus productos en las distintas tiendas.

Incrementar el nivel de �enganche� de sus aplicaciones para, transitiva-mente, aumentar la cantidad de usuarios.

Para lograr el primer objetivo, tal empresa opta por desarrollar sus apli-caciones en un lenguaje multiplataforma. De esta manera, evitan tener repli-cada cada aplicación tantas veces como cantidades de tiendas deseen abarcar.Por ende, la tarea de los desarrolladores para generar un nuevo videojuegoconsta en generar el código fuente y posteriormente generar la salida deacuerdo a la plataforma deseada. Así mismo, al tratarse de un único códigofuente, el tiempo invertido para el aprendizaje, desarrollo y mantenimientoes mucho menor.

Para alcanzar el segundo objetivo, el grupo de desarrollo utiliza mecá-nicas de juegos, pudiendo separarlas en dos conjuntos: mecánicas propias ymecánicas ajenas.

Las mecánicas propias son modeladas bajo decisión de los desarrollado-res en la etapa de diseño de la aplicación para luego ser materializadasen la misma. Al ser mecánicas �locales� al videojuego, la manipula-ción de las mismas no involucra el uso de API's foráneas al ambiente ylenguaje de desarrollo.

Las mecánicas ajenas son aquellas que facilitan los proveedores a travésde la consola de desarrollador. En este caso, para su manipulación esnecesario complementar al código fuente la API de servicios del pro-veedor.

El hecho de agregar los servicios que manipulan las mecánicas ajenasgenera con�ictos con el lenguaje multiplataforma:

Por un lado, se presenta una incompatibilidad entre los lenguajes deprogramación usados por cada API con el lenguaje utilizado por laempresa. Esto provoca que los servicios no puedan ser usados de maneradirecta desde el código fuente.

Por otro lado, los servicios de cada API son dependientes de la plata-forma en la que son ejecutados.

5


Este último con�icto se presenta en el siguiente escenario:

Por un lado se encuentra el código fuente del videojuego. A continua-ción, se agregan los servicios de la API de Google, Google Play Games, paramanipular las mecánicas generadas desde la consola de desarrollador de Goo-gle (Figura 1.1). Como la plataforma móvil de Google es Android, se generala salida para tal plataforma. Al �nalizar, se obtiene el videojuego con lasmecánicas de juegos de Google para ser utilizados en Android.

Figura 1.1: Videojuego con características sociales de Google.

La situación empeora si al mismo videojuego, se le agregan los serviciosque manipulan las mecánicas de juego que tienen efecto en otra plataforma.En la Figura 1.2 se puede apreciar el problema. En este caso, se reemplazanlos servicios de la API de Google por los de Apple, Game Center. Pero, comola plataforma móvil de Apple es iOS, ahora se debe generar la salida para talplataforma. Al �nalizar, se obtiene el videojuego con las mecánicas de juegosde Apple pero para ser utilizados en iOS.

Figura 1.2: Videojuego con características sociales de Apple.

Como se puede ver, este escenario obliga al desarrollador de la aplicaciónuna situación de permutación entre API's para tener su aplicación �nal en lasdistintas tiendas. Si bien, el código fuente de la aplicación continúa siendo elmismo, este escenario anula la capacidad multiplataforma del lenguaje paracrear la aplicación.

6

1. Introducción

A partir de esta situación se pueden apreciar dos posibles soluciones que,aún así, se encuentran lejos de la solución óptima:

Solución 1: La primer solución, la más trivial, consistiría en manteneruna copia del mismo videojuego por cada API (Figuras 1.3a y 1.3b).A partir de cada una se genera la aplicación a la plataforma que secorresponde la API en cuestión.

(a) Videojuego con servicios de Google.

(b) Videojuego con servicios de Apple.

Figura 1.3: Copias del mismo videojuego con distintas API's.

Si bien el código fuente de cada copia estará desarrollado en el mis-mo lenguaje de programación, las correcciones y/o agregados no serealizarán sobre un único lugar. Por otro lado, se desaprovecha la prin-cipal caracteristica del lenguaje multiplataforma, no pudiendo generarla misma aplicación para distintas plataformas a partir de un únicocódigo fuente.

Solución 2: Una segunda aproximación sería la que se muestra en laFigura 1.4. Lo que se puede apreciar es la inclusión de los serviciosde ambas API's en el código fuente. En ese caso, se podría generar laaplicación para ser usada en ambas plataformas (Android e iOS) sinperjudicar al lenguaje multiplataforma. Obviamente que si la salida es

7


para la plataforma Android, solo se utilizarán los servicios de GooglePlay Games. La situación es análoga si se la genera para iOS.

Figura 1.4: Videojuego con características sociales de Google y Apple.

Eventualmente hay un único código fuente, por ende el mantenimientose realiza sobre un único lugar. El problema es que se va a obteneruna aplicación que incluye funcionalidad que podría no ser utilizadadependiendo de la plataforma a la cual esté orientada. Idealmente, sepretende que la aplicación posea lo necesario que requiera para fun-cionar correctamente y no concentrar en su lógica código adicional einnecesario.

Eventualmente, si el número de API's incrementase, cualquiera de lassituaciones (escenario y soluciones) se agravarían más. Como conclusión, elhecho de agregar y utilizar las mecánicas de juegos de todos los proveedoresposibles es totalmente aceptable, pero, a partir de estos acercamientos sepuede ver que lo hace una tarea engorrosa y costosa.

Lo que la empresa pretende es, algún complemento que permita uti-lizar los servicios que manipulan las mecánicas de juego ofrecidas por losproveedores en el lenguaje utilizado para desarrollar sus aplicaciones. Estodebe realizarse de manera transparente a cada uno de sus proyectos y sincondicionamientos por parte de la plataforma objetivo. Así, reducir los tiem-pos de integración al proyecto y aprendizaje, mediante el desligue de estasactividades.

8

1. Introducción

1.3. Objetivos

Se propone como objetivo la creación de una API que permita utilizar,de forma homogénea, los servicios para videojuegos de los distintos proveedo-res. Como objetivos parciales se generarán los módulos especí�cos para cadaproveedor.

1.4. Alcances

En términos de alcance se pueden divisar dos aspectos totalmente inde-pendientes entre sí:

El primero, tiene que ver con el lenguaje al que está dedicada la solu-ción. El módulo propuesto sólo podrá ser utilizado en el lenguaje deprogramación Haxe. Este, es el que utiliza la empresa para desarrollarsus proyectos.

En segundo lugar, en el plano de las API's que ofrece cada compañía,se establecerá un límite. Estas son las de Google, Amazon e iOS, noalcanzado a las de BlackBerry y WindowsPhone.

1.5. Limitaciones

Hay situaciones en las que la falta de estandarización o las decisiones decada proveedor provocan que los servicios que estén presentes en alguna APIno se encuentren en otra. Tal cuestión podría afectar a la solución propuestapara la empresa, ya que esta es la entidad interesada en hacer uso de lamisma.

1.6. Organización del trabajo

El presente trabajo se organiza de la siguiente manera. En este primercapítulo se introduce la problemática abordada. A continuación, en el segun-do capítulo, se realiza una reseña del estado del arte. En el tercer capítulo

9


se describe de manera formal el problema especí�co atacado. En el capítulocuarto se describe una solución a dicho problema y se narran las estrategiasy métodos utilizados para la producción de la misma. Posteriormente a lasolución, en el quinto capítulo se muestran casos de pruebas de la misma.Luego en el sexto se exponen las conclusiones obtenidas de este proceso. Acontinuación, en el séptimo capítulo son enumerados una serie de trabajosfuturos que se proponen como continuación de este estudio. Finalmente enel octavo capítulo se listan las referencias bibliográ�cas utilizadas.

10

Capítulo 2

Estado del arte

2.1. Videojuegos

2.1.1. Historia

El origen de los videojuegos se produce en la década de 1950, pocos añosdespués de la aparición de las primeras computadoras. En dicho momentode la historia se produjeron los primeros intentos por desarrollar aplicacioneslúdicas. Así, en los años 1951 y 1952 se crearon el Nim [Hipertextual, 2011]y el OXO [PongStory, 2011b] respectivamente. Se tuvo que esperar hastael año 1958 para conocer el tercer videojuego denominado Tennis for Two[PongStory, 2011c], y el cuarto llamado Spacewar! [ComputerHistory, 2012]en el año 1961. Todos estos, no llegaron a comercializarse ni muchos menos apopularizarse ya que fueron desarrollados con equipamiento que solo se podíaencontrar en universidades o institutos de investigación [Lowood, 2009].

En la década del 70, con el descenso en los costos de fabricación, apa-recen las primeras maquinas y videojuegos dirigidos al público. Aparecenlos primeros títulos como Computer Space [Cedmagic, 2012] (1971) o elPong [PongStory, 2011a] (1972) en las maquinas recreativas (llamadas co-múnmente árcades) que funcionaban con monedas. Estas, estaban ubicadasen bares, cafeterías o en salones de recreación (contenían muchos más ár-cades). Gracias a las consolas domésticas llegarían de la mano los videojue-gos para los hogares. La primera de estas consolas fue el Magnavox Odyssey[Retromaquinitas, 2013] (1972) y cinco años más tarde (1977) la Atari 2600 o

11


(a) OXO. (b) Tennis for Two. (c) SpaceWar!.

Figura 2.1: Videojuegos de las décadas del 50 y 60.

Atari VCS (Video Computer System) [Perry and Wallich, 1983]. Ambas con-solas utilizaban cartuchos intercambiables para cada uno de sus videojuegos.En el sector de las maquinas recreativas se va ganando mayor popularidad[Wikipedia, 2013] y por ende masividad de tales maquinas con la llegadade títulos como: Space Invaders (1978), Galaxian (1979), Asteroids (1979) yPac-Man (1980).

Figura 2.2: Videojuegos árcade. Principio de la década del 70.

En la década del 80 la industria de los videojuegos comenzaba a mostrarcierta competencia [Gallagher and Park, 2002]. A la empresa norteamerica-na Atari se le sumaron dos compañías Japonesas: Nintendo (con su consolaNES) y SEGA (con la Master System). La empresa Nintendo agrega una nue-va plataforma al mundo de los videojuegos con la llegada de las consolas por-tátiles, tal dispositivo se denominó Nintendo Game & Watch [Pixfans, 2010].Adicionalmente, para ese momento de la historia surge una generación decomputadoras personales como fueron el Spectrum, el Commodore 64 y elAmstrad CPC con capacidades grá�cas su�cientes para comenzar a soportarvideojuegos. La industria de los videojuegos comienza a crecer a partir de

12

2. Estado del arte

(a) Magnavox Odyssey. (b) Atari VCS.

Figura 2.3: Primeras consolas domésticas de videojuegos. Década del 70.

los distintos dispositivos que los soportaban: árcades, consolas domésticas,consolas portátiles y computadoras personales. Para �nales de esta década(1989) Nintendo presenta al mundo la segunda consola portátil en su haber,siendo la mas popular de la época: la consola Game Boy.

(a) Nintendo Game & Watch. (b) Nintendo Game Boy.

Figura 2.4: Primeras consolas portátiles de videojuegos. Principio de ladécada del 80: Game & Watch; Final de la década del 80: Game Boy.

Los años 90 traen la tecnología de 16-bit (como Nintendo SNES y SEGAMega Drive), lo que signi�ca importantes mejoras grá�cas. Entra en escena elgigante Japonés Sony con su primera PlayStation (1994), mientras Nintendoy Sega actualizan sus consolas (Nintendo 64 y SEGA Saturn). En cuantoa las computadoras, se ve un progreso en aspectos grá�cos y de procesa-miento. El avance tecnológico de las consolas domésticas y las computadoras

13


personales colocaron en crisis a las maquinas árcade. Las nuevas maquinasdomésticas (PlayStation, Nintendo 64 y SEGA Saturn) superaban tecnoló-gicamente a las árcade. Aparecen juegos cada vez más avanzados, como losshooters en 3D agrandando aun más los distintos géneros que podían adoptarlos videojuegos.

(a) Sony PlayStation. (b) SEGA Saturn. (c) Nintendo64.

Figura 2.5: Consolas domésticas de videojuegos. Década del 90.

Para la década del 2000 Sony lanzó la anticipada PlayStation 2 (año2000). En el año 2001 entra Microsoft en el sector de las consolas domésticascon su Xbox y Nintendo lanza la consola doméstica GameCube. En 2003 lacompañía Finlandesa en telecomunicaciones Nokia realiza su primer incursiónen el dominio de las consolas portátiles lanzando su Nokia N-Gage. Siguiendoen el campo de las consolas portátiles, en el año 2004 Nintendo lanza laNintendo DS y poco tiempo después, Sony hace lo propio presentando laSony PSP (PlayStation Portable). Para el año 2005 Microsoft lanza la consoladoméstica Xbox 360 y Sony presenta pocos meses después su PlayStation 3.En los PC y en las últimas consolas domésticas (Xbox 360 y PlayStation 3),gracias a la expansión de Internet, cobran protagonismo los juegos en líneay multijugador.

(a) Sony PSP. (b) Nokia N-Gage. (c) Nintendo DS.

Figura 2.6: Consolas portátiles de videojuegos. Década del 2000.

14

2. Estado del arte

Por último, a �nales de la década del 2000 y principios de la décadade 2010 emergen como plataformas de videojuegos los dispositivos táctilesportátiles, como los teléfonos inteligentes y las tabletas, llegando a un pú-blico muy amplio. En la actualidad, encontramos consolas domésticas comoPlayStation 4 y Xbox One.

2.2. Videojuegos para dispositivos móviles

2.2.1. Historia

El primer videojuego para dispositivos móviles tuvo su aparición en elaño 1994 de la mano del teléfono celular Hagenuk MT-2000 [Phonearena, 2014].Este dispositivo, contenía una variante del popular juego Tetris. Tal disposi-tivo solo contaba con este videojuego preinstalado en el sistema y no ofrecíala posibilidad de descargar otro.

Figura 2.7: Hagenuk MT-2000.

En el año 1997 la compañía Nokia lanza al mercado el teléfono celu-lar Nokia 6110. Este dispositivo contaba con tres videojuegos preinstalados:Memory, Logic y Snake. Este último logró ser el más popular entre los usua-rios, dando como consecuencia que modelos posteriores de nokia (5110, 8810)también tuviesen preinstalado tal juego. El juego [Pocketgamer, 2008h] con-sistía en alimentar a una serpiente evitando chocar con las cuatro paredes ycon el mismo cuerpo del animal. Tales restricciones iban siendo más difícilesde cumplir, ya que por cada alimento que consumía el animal, este aumen-taba su longitud. Además, fue el primer móvil que permitía el modo de dosjugadores para tal videojuego a partir de la conectividad infrarroja.

15


Figura 2.8: Nokia 6110 con juego Snake.

En 1999 nuevamente la compañía Nokia presenta el móvil Nokia 7110. Eldispositivo poseía instalado la secuela del juego Snake (Snake II) [Pocketgamer, 2008h].Este videojuego ofrecía nuevas variantes respecto a su antecesor como: nive-les, obstáculos y permitía al animal atravesar paredes y aparecer por la paredenfrentada. Una particularidad de este dispositivo fue que el mismo contabacon un navegador WAP (Wireless Application Protocol). Básicamente, losdispositivos que contaban con esta tecnología tenían acceso a Internet. Conello, se abría la posibilidad de descargar nuevos videojuegos y jugar juegosmultijugador.

Figura 2.9: Nokia 7110 con juego Snake II.

Una vez arribado WAP (o su equivalente Japones: i - Mode) no tardaronen aparecer los primeros videojuegos multijugadores. Uno de los primeros,lanzado en el año 2000 fue el Alien Fish Exchange [Pocketgamer, 2008a]

16

2. Estado del arte

creado por la compañía NTL Interactive. Este videojuego fue una versióninterconectada del popular Tamagotchi. El jugador iniciaba teniendo en supoder una pareja de peces para cuidar a través de la alimentación, tambiénpodía jugar con ellos en la pecera virtual. El objetivo de tales acciones con-sistía en mantenerlos contentos y mediante la reproducción obtener nuevasespecies. Luego, a través de Internet (usando WAP) se podía comprar o ven-der las especies. Por ejemplo, vender peces a un restaurante para conseguirdinero.

Figura 2.10: Juego Alien Fish Exchange. Primer juego multijugador a partirde WAP.

Para el año 2001 la situación de los videojuegos en términos de inno-vación tecnológica no cambió. Siguieron lanzándose aplicaciones que hacíanhincapié en el aspecto multijugador, para esto, las herramientas disponibleseran los ya conocidos WAP o i - Mode. Algunos videojuegos reemplazabanel uso de WAP o i - Mode por los SMS, pero la idea continuaba siendo lamisma. Del lado de la telefonía móvil, seguían existiendo (hasta Diciembre deese año) dispositivos monocromáticos, con una limitada memoria interna ypobre capacidad de procesamiento. Algunos de los títulos más sobresalientesde ese año fueron: Lifestylers y Wireless Pets [Pocketgamer, 2008b]. Ambos,con la misma idea central como Alien Fish Exchange. En conclusión, video-

17


juegos estilo Tamagotchi con una variación particular adaptada al objetivo�nal de cada uno.

En 2002 se producen dos avances principales. El primero en la Confe-rencia JavaOne de San Francisco, se muestra en un dispositivo Motorola unprototipo de videojuego corriendo en la plataforma Java 2 Micro Edition(J2ME) [Sergio Gálvez Rojas, 2003]. Esto permitió mostrar que la platafor-ma permitía una jugabilidad más �uida en tal dispositivo. En ese mismoaño se realizan teléfonos móviles con la plataforma Java de fondo. El segun-do avance tecnológico fue la aparición de los primeros móviles con pantallaa color. Con el videojuego Space Invaders se comienza a marcar el �n delos videojuegos monocromáticos. A su vez, JAMDAT Bowling, un video-juego de bolos casual, se trató de uno de los primeros videojuegos a color[Pocketgamer, 2008c].

En el año 2003 comienzan a predominar los videojuegos a color. Uno deellos, Nom, consiste en el control de un personaje que debe saltar diversascriaturas cada vez mas extrañas, una particularidad de este videojuego, esque cada vez que se completaba un nivel el siguiente obligaba al jugadora girar su dispositivo para mantener al personaje �corriendo en horizontal�.Otro videojuego de la fecha, Bejeweled Multiplayer, se trató del típico juegode tablero en el que había que juntar tres o mas elementos del mismo tipoen linea (horizontal o vertical). Lo prometedor de este videojuego se encon-traba en la parte de multijugador. Esto, era soportado por WAP, pero teniaasociado un costo elevado por el envío de datos agravado aún más por lainestabilidad del servicio. El videojuego Ridge Racer 3D proveniente de suequivalente en la plataforma árcade de 1993, mostró un estilo grá�co de tresdimensiones corriendo en un dispositivo móvil. Obviamente la calidad de lajugabilidad no resultó ser la mejor [Pocketgamer, 2008d].

Para el año 2004 a nivel consolas de videojuegos, la categoría de videojue-gos de carreras era una de las más grandes. Tal tendencia se trasladó a los dis-positivos móviles, donde los videojuegos más populares eventualmente fueron:The Fast and the Furious, Asphalt Urban GT y Driv3r [Pocketgamer, 2008e].Los años posteriores, 2005 con Midnight Pool, Downtown Texas Hold 'Em,Downtown Texas Hold 'Em [Pocketgamer, 2008f] y 2006 Tower Bloxx, TheFast and the Furious: Tokyo Drift [Pocketgamer, 2008g] no trajeron cambiossigni�cativos en el universo de los videojuegos para teléfonos móviles. Lo quese podía apreciar con relación a años anteriores era una mayor creatividadpor parte de los desarrolladores a la hora de realizar un nuevo videojuego.Cuestión que hasta antes del año 2003 los videojuegos eran éxitos originarios

18

2. Estado del arte

(a) Nom. (b) Bejeweled. (c) Ridge Racer.

Figura 2.11: Videojuegos del año 2003. Todos a color. Primera aparición dejuego en 3D.

de otras plataformas (generalmente árcades).

(a) Asphalt Urban GT. (b) Midnight Pool. (c) Tower Bloxx.

Figura 2.12: Videojuegos de los años 2004, 2005 y 2006 respectivamente.

En el año 2007 se produce un nuevo avance tecnológico cuando AppleInc. presenta el primer teléfono inteligente concebido por tal compañía: eliPhone [Apple, 2007]. Este, ejecutaba el sistema operativo iOS, que continuósiendo utilizado para versiones posteriores del dispositivo. Lo signi�cativo delos teléfonos inteligentes fue la brecha tecnológica entre estos y los teléfonosmóviles. Un claro ejemplo fue la conectividad, la conexión a Internet en un

19


teléfono inteligente podía ser mediante EDGE o Wi-Fi. La primera genera-ción de iPhone no contenía una aplicación principal para descargar nuevasaplicaciones.

No fue hasta el año 2008 que se introdujo la tienda de Apple, denominadaApp Store, permitiendo así instalar nuevas aplicaciones a los terminales iPho-ne en cualquiera de sus modelos. Uno de los videojuegos mas descargados detal tienda para la plataforma iOS fue el Tap Tap Revenge [Techcrunch, 2008].Se trató de un videojuego musical donde el jugador utilizaba sus dedos pa-ra tocar pelotas de colores cuando estas llegaban al fondo de la pantalla(las pelotas simulaban ser las notas musicales). El objetivo era tocar dichoselementos en el momento adecuado para sumar la mayor cantidad de puntos.

Figura 2.13: Juego Tap Tap Revenge en dispositivo iPhone.

Tal cual sucedió con Apple Inc., en el año 2007 es presentado el sistemaoperativo móvil Android. Tal plataforma inicialmente perteneció a AndroidInc., empresa que Google respaldó económicamente y más tarde (2005) com-pró. A diferencia de Apple, que poseía (y posee) su plataforma móvil iOSen dispositivos móviles de su propiedad (iPhone, iPod), Android puede serinstalado en diversos dispositivos móviles (Alcatel, Samsung, Motorola, etc.).Es por esto, que el primer dispositivo con Android fue el HTC Dream (co-mercializado también como T-Mobile G1) presentado en el año 2008. Latienda Android Market fue lanzada ese mismo año [AndroidCentral, 2008]permitiendo descargar contenido multimedia y aplicaciones a través de unaconexión a Internet mediante la tecnología 3G o Wi-Fi. Actualmente la tien-da se denomina Google Play Store. La plataforma móvil Android es de códigoabierto, contando con una comunidad muy amplia que utiliza el código fuen-te de la plataforma [SourceAndroid, 2008] para crear sus propias versionespersonalizadas.

20

2. Estado del arte

Figura 2.14: Dispositivo HTC Dream, el primero con el sistema operativomóvil Android.

Para el año 2009 se lanza uno de los videojuegos más exitosos y descar-gados del año: Angry Birds. Tal aplicación estaba disponible en las tiendasde las dos plataformas móviles iOS y Android. El objetivo del videojuegoes ayudar a los pájaros a recuperar los huevos que le fueron robados porsus enemigos: los cerdos. Para ello, el jugador debe catapultar los pájaroshacia las distintas estructuras que construyen sus enemigos los cerdos en losdistintos niveles.

Figura 2.15: Juego Angry Birds.

21


En el año 2010 se lanza otro videojuego denominado Ninja Fruit. Concifras en el número de descargas del orden de millones. La mecánica delvideojuego es sencilla, se lanzan frutas de manera aleatoria desde la parteinferior de la pantalla y el jugador con sus dedos simulando ser cuchillos lasdebe cortar, el objetivo básicamente consistía en cortar la mayor cantidadde frutas antes de que el jugador pierda sus tres intentos. Tales intentos, seperdían si la fruta desaparecía sin ser cortada o si el jugador cortaba unabomba que también aparecía mezclada con la fruta.

Figura 2.16: Juego Ninja Fruit.

Para ese mismo año, Apple Inc. anuncia el lanzamiento del servicio Ga-me Center. Este servicio consiste en una red social de jugadores que permitea los usuarios a invitar a sus amigos a jugar determinado videojuego, organi-zar partidas multijugador, obtener logros por cumplir objetivos y compararsus puntajes más altos en tablas de clasi�cación. Todas estas característicassociales o algunas (las que desee el desarrollador) podrían ser agregadas a unvideojuego para posteriormente ser insertado en el App Store.

En el año 2011, Amazon, compañía de comercio electrónico y proveedorade servicios en la nube (IaaS - Infrastructure as a Service) anuncia su entradaal mercado de dispositivos móviles introduciendo la primer tablet concebidapor tal empresa: Kindle Fire. Tal dispositivo opera con una versión perso-nalizada de la plataforma móvil Android (código fuente obtenido a partirAndroid Open Source Project y modi�cado por Amazon) denominado FireOS. Este dispositivo trajo integrada la aplicación Amazon AppStore para ladistribución digital de nuevas aplicaciones, libros, videojuegos, etc.

En el 2012 se lanza para las plataformas iOS y Android el videojuegoPlague Inc. Tal aplicación alcanzó los dos millones de descargas únicamente

22

2. Estado del arte

en la plataforma iOS en ese año [Wired, 2012]. Se basa en un simulador estra-tégico donde el jugador controla una plaga que inicia infectando al pacientecero. El objetivo es ir mutando el patógeno para que sea lo su�cientementemortal para eliminar a toda la población mundial antes de que los sobrevi-vientes encuentren una cura.

Figura 2.17: Juego Plague Inc.

En ese mismo año, Amazon anuncia la aparición del servicio de juegosGame Circle [AnikiJournal, 2012]. Tal servicio permite al desarrollador de vi-deojuegos crear logros, tablas de clasi�caciones y almacenamiento en la nubepara guardar el progreso de las partidas de cada usuario. Tales complementosfueron probados en la versión beta de videojuegos como Temple Run, DoodleJump o Triple Down.

Para el año 2013 Google anuncia el lanzamiento del servicio de juegosde Google Play [9To5Google, 2013], estableciéndose una competencia con elmismo servicio ofrecido por Apple y Amazon. Los servicios que ofrece GooglePlay son la capacidad de establecer partidas multijugador, almacenamientoen la nube, tablas de clasi�caciones tanto sociales como publicas y logros.En el 2014 Google lanza una guia denominada �The Secrets to App Successon Google Play� [Google, 2013a] donde explica la razón de la utilización delservicio de juegos de Google Play: Los usuarios responderán mejor a un vi-deojuego cuando ellos tengan para competir o para compararse con jugadoresreales. El servicio de juegos de Google Play permite a los jugadores desa�ar yser desa�ados, medirse con los demás y recibir recompensas. A partir de es-tas funciones del servicio, los usuarios son más propensos a realizar comprasdesde el videojuego y a participar más activamente en el mismo.

23


2.2.2. Diseño de aplicaciones lúdicas

2.2.2.1. Flujo

El núcleo del éxito de los videojuegos es un concepto llamado �ujo (taltérmino se deriva de la investigación de Mihaly Csikszentmihalyi, profesorde psicología) [Zichermann and Cunningham, 2011]. La noción de �ujo (oestar �en la zona�) indica el estado de un jugador entre la ansiedad y elaburrimiento, encontrando su propio nivel de motivación en esa experiencia(Figura 2.18). Los diseñadores de videojuegos tienen como objetivo que eljugador alcance tal estado (que el jugador sea �uno con el juego�). Paraello deben crear una interacción cuidadosa entre el sistema y el jugador,probando tales interacciones para encontrar el punto entre la ansiedad yel aburrimiento. El fenómeno psicológico denominado Refuerzo (en inglésReinforcement), es una herramienta para el proceso de colocar al jugador �enla zona�.

Figura 2.18: El �ujo es alcanzado cuando un jugador se encuentra entre losestados de ansiedad y aburrimiento.

24

2. Estado del arte

2.2.2.2. Refuerzo

Refuerzo estudia cómo convertir una recompensa esperada en una accióndel individuo variando la cantidad y momento de entrega de tal recompensa.Impulsada por los investigadores Pavlov y BF Skinner [Catania and Laties, 1999],la comprensión del fenómeno psicológico es clave para la estructuración ade-cuada de los sistemas de recompensas. Si a una rata de laboratorio se le dauna bolita de alimento desde un dispensador cada una hora, durante los 59minutos entre la recepción de cada bolita el animal no estará pendiente deldispensador. Solo en el minuto 60 tendrá toda su atención en el alimento otor-gado por el dispensador. Tal situación se denomina refuerzo de intervalo �jo.Este tipo de refuerzo tiende a producir bajos niveles de compromiso. El otroenfoque, denominado relación de refuerzo variable es el extremo opuesto alanterior. En este modelo, la rata no sabe que tan grande será la recompensa oen que momento le será otorgado. Esto provoca que el animal esté pendienteen todo momento del dispensador hasta que obtenga la recompensa.

La utilización dentro de una experiencia de juego debe realizarse conprudencia ya que es una fuerza poderosa para la conducción de comporta-miento de los jugadores. En la práctica, la clave está en no abusar de suscualidades.

2.2.2.3. Tipos de jugadores

Cuanto más se sepa acerca de quien esta jugando tal videojuego, tantojugadores actuales como potenciales, más fácil es para el diseñador, crear unvideojuego que impulse su comportamiento en la dirección deseada. Una for-ma de entender a los jugadores es a partir del trabajo realizado por RichardBartle [Bartle, 1996] en la comprensión de los tipos de jugadores. Bartleidenti�có cuatro tipos de jugadores donde de�ne sus motivaciones y sus ca-racterísticas de juego:

Exploradores (Explorers): Les gusta ir por el mundo descubriendo aque-llas cosas que le son desconocidas con el �n de llevarlas a su comunidady decir �Yo descubrí esta cosa!�. En un sentido, la experiencia y laautosuperación son sus objetivos.

Triunfadores (Achievers): Consideran la recolección de puntos, el au-mento de niveles y el cumplimiento de objetivos como su principalmeta.

25


Figura 2.19: Tipos de jugadores según Richard Bartle.

Sociables (Socialisers): Están interesados en la gente y en lo que tienenpara decir. El videojuego entra en un segundo plano para ellos. Lasrelaciones entre jugadores son importantes: empatía, simpatía, bromas,entretenimiento, escuchas. Su motivación se basa en crear una red decontactos o amigos.

Asesinos (Killers): Constituyen la población más pequeña de todos lostipos de jugadores. Son similares a los triunfadores en su deseo de ganar;sin embargo para los asesinos, ganar no es su�ciente. Tienen que ganary alguien debe perder. Por otra parte, a través de sus victimas buscanexpresar admiración/respeto.

Bartle establece una relación entre la acción e interacción ya sea con elentorno (o mundo en términos de videojuego) o con la gente (otros jugadores)tal como se puede ver en la Figura 2.19. Los jugadores sociales y los asesinosse relacionan con las personas, mientras que en el otro extremo los explora-dores y triunfadores pre�eren la relación con el sistema de juego. Atendiendoal eje vertical encontramos que los asesinos y triunfadores pre�eren actuarsobre otros jugadores o una misión del juego respectivamente. Los jugadoressociales y los exploradores pre�eren la interacción con varios jugadores a lavez o diferentes elementos del juego respectivamente.

26

2. Estado del arte

2.2.2.4. Framework MDA

Al crear una experiencia lúdi�cada, se aprovechan muchos aspectos dediseño del juego, mientras se centra en los elementos centrales que produciránel mayor impacto para los jugadores. Uno de los frameworks más frecuente-mente aprovechados para el diseño de videojuegos es el MDA:

Mecánicas (Mechanics): Son los componentes base del juego: sus reglas,cada acción básica que puede realizar un jugador en el juego, los algo-ritmos y las estructuras de datos utilizadas en el motor de juego, etc.Es decir, todo aquello sobre lo que el diseñador pueda in�uir.

Dinámicas (Dynamics): Son los comportamientos en tiempo de ejecu-ción de las mecánicas. Actúan ya sea ante las acciones del jugador ointeractúando con otras mecánicas. En otras palabras, son las situacio-nes que genera (o se generan ante) el jugador del videojuego con lasmecánicas dadas por el diseñador.

Estéticas (Aesthetics): Son las respuestas emocionales que se pretendenevocar en el jugador: alegría, frustración, etc. La estética del juego pue-de ser visto como el resultado compuesto de la mecánica y la dinámicaa medida que interactúan y generan emociones.

Las mecánicas de un sistema lúdi�cado son creados a partir de una seriede herramientas que, cuando se utilizan correctamente, asegura obtener unarespuesta signi�cativa (estética) de los jugadores. Las herramientas funda-mentales son:

Puntajes: Los puntos son importantes, independientemente de si suacumulación es compartida entre los jugadores, o incluso entre el di-señador y el jugador. Cuando se tiene en cuenta por primera vez unsistema de puntos, se podría pensar en puntos canjeables en un video-juego, o puntos de boni�cación otorgados a los jugadores por completarcon éxito las tareas especiales dentro de un videojuego. Los puntajesson un requisito absoluto para todos los sistemas lúdicos. Como dise-ñador es esencial que se tenga un seguimiento sobre los movimientosdel jugador, esto permite tener conocimiento sobre como los jugadoresinteractúan con la aplicación y/o realizar los ajustes apropiados.

Niveles: En la mayoría de los juegos, los niveles indican progreso. Estossirven como un marcador para que los jugadores conozcan cuál es su

27


posición en una experiencia de juego a través del tiempo. En el diseñode videojuegos, el nivel de di�cultad no es lineal. En otras palabras, notoma 100 puntos alcanzar el nivel 1, 200 puntos para alcanzar al nivel2, 300 para el nivel 3, etc. En lugar de eso, la di�cultad incrementa enuna forma curvilínea. Los mejores consejos de diseño para los nivelesson hacerlos lógicos (fácil para que el jugador entienda), extensibles(de modo que puede agregar niveles según sea necesario), y �exibles.Por último, los niveles deben ser comprobables y re�nables. El correctobalance de los niveles es tan compleja como la construcción del juego enprimer lugar, y deben ser probados y vueltos a probar incluso cuandolos jugadores están en el juego.

Tablas de Clasi�cación: El propósito de una tabla de clasi�cación eshacer comparaciones simples. De forma predeterminada, cuando se veuna lista ordenada con una puntuación al lado de cada nombre, seentiende que estamos ante un sistema de clasi�cación. Hay dos tiposde tablas de clasi�cación utilizadas hoy en día.

• Tabla no desalentadora: En la era de Facebook las tablas de cla-si�cación son en su mayoría las herramientas para la creación deincentivos sociales, en lugar de desaliento. Esto, lo logran sim-plemente tomando el jugador y colocándolo en el medio de laclasi�cación. No importando donde cae realmente en el orden deranking, el jugador se verá a si mismo en la mitad de la tabla.

• Tabla in�nita: En los videojuegos árcade de antes, no había mu-chas maneras para poder contener todos los puntajes de todos losjugadores en una misma tabla. En algún momento, el puntaje deun jugador sería superado y este desplazado hasta salir de la tabla.Hoy en día, para una misma tabla de clasi�cación hay más de unavista. Pudiendo ser local (donde se encuentra ubicado un jugadorcomparado con otros en un área cercana), social (ver el rankingde un jugador contra los de sus amigos) y global (donde se ubicaun jugador contrastando contra los puntajes de todos los usuariosde ese videojuego).

Medallas: Para los diseñadores de juegos, las insignias son una excelentemanera de marcan la realización de las metas y el progreso constantede juego dentro del sistema. En algunos diseños, las medallas puedenreemplazar a los niveles como marcadores de progreso.

Desafíos/Misiones: Ofrece a los jugadores cierto sentido para saber quehacer en una experiencia lúdi�cada. Hay casos en que algunas personas

28

2. Estado del arte

entran a un juego sin tener noción de sus objetivos o partes fundamen-tales. Incluso si los retos no son el tema central del videojuego, estosdeberían estar en el mismo ya que pueden agregarle sentido al jugador.Algunos usuarios jugaran reto tras reto tratando de vencer al videojue-go y otros jugaran solo para mantener el interés en tales desafíos.

Incorporación: Es el acto de insertar un principiante en el sistema. Enel diseño de videojuegos lo que determina una incorporación exitosa ono es el primer minuto de juego. Esto se debe a que, en ese minuto, eljugador debe tomar la mayoría de las decisiones para logar una parti-cipación inicial. El objetivo es maximizar el valor y los efectos de eseprimer minuto.

Bucles de Compromiso: Un diseñador no solo debe pensar la forma decomo el jugador se involucrará con el videojuego. También debe ver laforma de como recuperar su motivación en el caso de que el usuariodeje el videojuego.

2.3. Mecánicas provistas por las compañías mó-

viles

El lanzamiento de los servicios de juego de cada compañía (Apple conGame Center, Amazon y su Game Circle, mientras que Google con GooglePlay Games) permiten a los desarrolladores de videojuegos móviles el agre-gado de ciertas mecánicas pertenecientes al framework MDA como son loslogros y las tablas de clasi�cación. Tales aspectos permiten ser complemen-tados con distintas variantes de mecánicas que posean los videojuegos. Lascompañías son las encargadas de nutrir a las tablas de clasi�caciones con losjugadores que participen en el mismo videojuego.

Para poder hacer uso de estas características ofrecidas por las distintascompañías, estas últimas ofrecen servicios que las manipulen a través deAPI's (Interfaz de Programación de Aplicaciones). Cada API contiene losllamados a los servicios encargados de manipular los distintos atributos quecontendrán las tablas de clasi�cación y los logros. Se puede decir que, desdela logica de la aplicacion, las mecánicas del juego se manipulan, mientras quedesde la consola de desarrollador, estas se administran. Así mismo, todoslos cambios realizados desde cada sitio web (altas, bajas o modi�caciones

29


de los atributos de las distintas mecánicas) se re�ejan directamente sobre elvideojuego.

Para las mecánicas de juego, todas las compañías convergen en el mismoconcepto: uso de identi�cador. Cada compañía permite al desarrollador agre-gar, eliminar o modi�car una nueva mecánica de juego (tabla de clasi�cacióno logro). Cada una de estas, tiene asociado un identi�cador. El propósito delidenti�cador es el de ser utilizado por los métodos de la API que lo requieran.Estos métodos se encontrarán ubicados dentro del videojuego. Los identi�ca-dores para las mecánicas pueden ser establecidas bajo deseo del desarrolladoro ser generadas por la compañía donde se esté registrando la aplicación.

Los servicios de las distintas API's trabajan de manera asíncrona. Estosigni�ca, que la aplicación puede hacer uso de un servicio en un momentodado (en ingles Request), y la respuesta (en ingles Response) a tal eventono será instantánea. Este enfoque básicamente no bloquea la ejecución dela aplicación. Para noti�car a la aplicación que la respuesta ha llegado, lascompañías utilizan la estrategia de retrollamadas (callbacks). Con las retro-llamadas en lugar de esperar el resultado de una función, se indica a talfunción qué debe hacer cuando termine.

Por último en el aspecto tecnológico, tanto Amazon como Google ofrecenel servicio de almacenamiento en nube como parte del servicio de mecánicasde juego. Apple, lo ofrece de manera separada. Si bien este complemento, noes una mecánica de juego, permite a los jugadores mantener sincronizadossus puntajes, logros y demás datos de interés en los diversos dispositivos queestos tengan en su poder.

A continuación se presenta el estado actual de cada compañía en losámbitos de:

El proceso para registrar las distintas mecánicas de juego.

Que aspectos de cada mecánica se pueden manipular a partir de losservicios que provee cada API.

30

2. Estado del arte

2.3.1. Amazon: Game Circle

2.3.1.1. Inclusión de mecánicas de juego

Para registrar o gestionar distintas aplicaciones creadas por un desarro-llador en particular, se debe ingresar al sitio donde se encuentre la consola dedesarrollador de Amazon1. Para ello, el desarrollador previamente debe estarregistrado. En caso de no estarlo, el proceso para registrar un nuevo usuariono posee cargo alguno.

Logros

Amazon permite de�nir un máximo de 100 logros por videojuego. Laadición de logros es opcional. Cada logro creado puede alcanzar uno de lossiguientes estados:

Borrador (Draft): Como el nombre bien lo indica, este estado permiterealizar pruebas sobre los logros para validar el correcto funcionamien-to. Los logros en modo borrador pueden eliminarse. Se deben establecerque cuentas de desarrolladores podrán manipular tales logros. Esto serealiza en la parte de Cuentas de Test a lo largo de la creación de unacon�guración. Una vez �nalizadas las pruebas necesarias, se puedenpublicar los logros.

Publicado (Published): Este estado indica que los logros son visibles acualquier usuario que tenga el videojuego instalado en su dispositivomóvil. A partir de aquí, el usuario puede empezar a obtenerlos. Loslogros, una vez publicados, no pueden ser eliminados.

De acuerdo a la Figura 2.20, cada logro requiere los siguientes metadatos:

Achievement ID : Identi�cador para el logro. Este es utilizado por elvideojuego para llamar al servicio GameCircle. A partir de este servicio,se puede solicitar información sobre cierto logro o premiar al jugadorcon la obtención de un logro. El identi�cador puede contener caracteresalfanuméricos (AZ, az, 0-9) y guiones bajos (_). Este identi�cador nose muestra a los jugadores.

1https://developer.amazon.com/home.html

31


Figura 2.20: Metadatos de un logro de Amazon.

Title: Este valor se muestra a los jugadores. No se puede cambiar unavez publicado el logro.

Hide until earned : Indica si los jugadores pueden ver este logro antesde que lo hayan ganado.

Achievement XP : Estos son los puntos de experiencia (XP) otorgadosa un jugador cuando gana el logro. GameCircle recompensa a los ju-gadores con puntos de experiencia (para su per�l GameCircle) cuandoganan los logros para aumentar su nivel como jugador. El valor puedeser de 0 a 100. Los puntos de experiencia total no pueden exceder de1500 (para todos los logros publicados en un videojuego). Una vez queun logro ha sido publicado, no se puede cambiar la cantidad de puntosde experiencia de recompensa.

Locked icon: Imagen de muestra para los jugadores que no hayan ob-tenido el logro. Esta imagen no se visualiza si el atributo Hide untilearned está establecido en Yes.

32

2. Estado del arte

Locked description: Descripción de muestra para los jugadores que aúnno han obtenido el logro. La descripción no se muestra si el atributoHide until earned está establecido en Yes.

Unlocked icon: Imagen de muestra para los jugadores que han ganadoel logro.

Unlocked description: Descripción de muestra para los jugadores quehan ganado el logro.

Una vez completados los campos obligatorios se guardan los cambios. Serepite el proceso hasta establecer todos los logros deseados. Una vez �naliza-do, los logros se resumen en una vista tal como muestra la Figura 2.21:

Figura 2.21: Listado de logros registrados.

Tablas de clasi�cación

Amazon permite de�nir un máximo de 50 tablas de clasi�cación porvideojuego. La adición de tablas de clasi�cación es opcional. Semejante a loslogros, cada tabla de clasi�cación puede estar en estado de Borrador (Draft)o Publicado (Published), con su correspondiente propósito.

De acuerdo a la Figura 2.22, cada tabla de clasi�cación requiere lossiguientes metadatos:

Leaderboard ID : Identi�cador para la tabla de clasi�cación. Este es uti-lizado por el videojuego para llamar al servicio GameCircle. A partir

33


Figura 2.22: Metadatos de una tabla de puntajes.

de este servicio, se puede solicitar información sobre cierta tabla de cla-si�cación o agregar el puntaje/tiempo (según corresponda) alcanzadopor el jugador en la tabla correspondiente según el ID. El identi�cadorpuede contener caracteres alfanuméricos (AZ, az, 0-9) y guiones bajos(_). Este identi�cador no se muestra a los jugadores.

Title & Description: Ambos valores se muestran a los jugadores. No sepueden cambiar una vez publicada la tabla de clasi�cación.

Leaderboard icon: Imagen de muestra para representar la tabla de cla-si�cación.

Score units : Unidad de medida para la puntuación. Amazon solo operacon valores enteros.

Score threshold : Puntuación máxima permitida. Los jugadores que lo-gren una clasi�cación mayor, no aparecerán en la tabla.

34

2. Estado del arte

Sort order : Orden en el cual los puntajes deben ser mostrados. Demanera ascendente (el puntaje más bajo es el líder de la clasi�cación)o descendente (el puntaje más alto es el líder de la clasi�cación).

Tal como sucede con los logros, para las tablas de clasi�cación se sigueel mismo procedimiento. Una vez completados los campos obligatorios seguardan los cambios. Se repite el proceso hasta establecer todas las tablasde puntajes. Una vez �nalizado, se resumen en una vista tal como muestrala Figura 2.23:

Figura 2.23: Listado de tablas de puntajes registradas.

2.3.1.2. API de Game Circle

Se descarga desde el sitio web de Amazon de manera libre y gratuita. Talpaquete contiene diferentes librerías que dan soporte a los distintos serviciosprovistos por Amazon. Algunos de estos son, por ejemplo, el servicio demapas, redes de publicidades, compras desde la aplicación, redes sociales dejugadores, etc.

Logros

En cuanto a los logros, el API ofrece los siguientes servicios [Amazon, 2013]:

Poder visualizar todos los logros a partir de la UI de Amazon.

35


Desbloquear cierto logro en particular a partir del identi�cador delmismo.

Establecer el porcentaje de cumplimiento de un logro en particular(usando su identi�cador).

Consultar el estado de un logro determinado (Bloqueado o Desbloquea-do). Para este servicio es necesario utilizar retrollamadas (Callbacks).

Consultar el porcentaje de completitud que posee un logro determina-do. Al igual que el item anterior, para utilizar este servicio es necesariohacer uso de retrollamadas.

Por otro lado, el API no ofrece los siguientes servicios:

Incrementar el porcentaje de cumplimiento de un logro dado.

A través de la consola de desarrollador de Amazon los logros puedenmantenerse ocultos al jugador o no. Llamativamente, no se permitecambiar su estado desde el código fuente del videojuego.


Las tablas de clasi�cación [Amazon, 2013] almacenan valores del tipoInteger (es decir, de 32 bits). El API, ofrece un servicio que permite almacenarvalores Integer a una tabla en particular utilizando su identi�cador. Además,provee métodos para poder visualizar una tabla de puntaje determinada otodas las tablas de puntajes del videojuego. Para obtener el puntaje de unjugador a lo largo del videojuego se hara uso de retrollamadas.

Almacenamiento

Otro aspecto que Amazon cubre es el asociado a la persistencia de datosy la resolución de con�ictos. El servicio encargado de administrar la sincro-nización se denomina Whispersync [Amazon, 2013]. Maneja los casos en losque el usuario se encuentre jugando en linea o sin conexión y permite sin-cronizar datos a través de múltiples plataformas. Un ejemplo de esto es queel jugador puede comenzar su juego en una tablet FireOS y luego continuarjugando en una tablet de Android o un iPad de Apple. Estas transiciones no

36

2. Estado del arte

son problema ya que continuará jugando con sus datos de juego en cada unode los dispositivos.

Whispersync almacena sus datos en un mapa de datos (Hashtable) quepuede contener: cadenas de caracteres, números, listas de cadenas de caracte-res y otros mapas de datos. Cuando los valores sincronizados cambian, estostienen que combinarse (merge) y cualquier con�icto debe resolverse. ComoWhispersync combina datos ya sean obtenidos en línea o sin conexión, comoasí también los datos a través de múltiples dispositivos, el desarrollador debepensar los diferentes escenarios que los usuarios pueden encontrar y comomanejar los con�ictos que puedan surgir.

Whispersync provee dos estrategias para combinar datos. La combina-ción automática y la combinación manual. Preferentemente se opta por utili-zar la combinación manual ya que el desarrollador es el encargado de resolvercon�ictos y por ende el responsable de la combinación de datos.

2.3.2. Apple: Game Center


Para registrar o gestionar distintas aplicaciones creadas por un desarro-llador en particular, se debe ingresar al sitio iTunnes Connect2. Es aquí dondese encuentra la consola de desarrollador de Apple. En caso de no contar concuenta de desarrollador, el proceso para registrar un nuevo usuario posee uncargo de 100 USD, y renovaciones anuales por el mismo valor. Una vez dentrose pueden visualizar muy resumidamente la lista de aplicaciones que tiene ensu poder un usuario dado.

Logros

Para cada logro a registrar se deben completar dos formularios. Uno secorresponde con las propiedades del mismo y el otro formulario consiste enel establecimiento del idioma de los distintos textos que se mostrarán a losjugadores.


2https://itunesconnect.apple.com/

37


Figura 2.24: Metadatos de un logro de Apple.

Achievement Reference Name: Nombre corto para el logro interno aiTunes Connect. Tiene como objetivo permitir las busquedas de logrosdentro de la consola de desarrollador. No es un nombre o identi�cadorque se muestre a los jugadores.

Achievement ID : Se trata de un identi�cador alfanumerico que el desa-rrollador elije para cada logro. Este identi�cadr esta limitado a 100caracteres. Una vez publicado el videojuego, este valor no puede cam-biar.

Point Value: Son los puntos de experiencia que el logro entrega. Cadalogro posee un máximo de 100 puntos y de 1000 puntos entre todos loslogros.

Hidden: El logro se mantiene oculto hasta que el jugador comience aprogresar para cumplirlo.

Achievable More Than Once: Una indicación de si el jugador puedeganar el logro varias veces.

Es necesario que el desarrollador provea al menos una con�guración deidioma. La estrategia consiste en reutilizarla y establecerla en más de unaregión a la que este orientada la aplicación.

De acuerdo a la Figura 2.25, cada idioma de cada logro requiere lossiguientes metadatos:

Language: Es el idioma en el que se mostrará la tabla.

38

2. Estado del arte

Figura 2.25: Metadatos de un idioma de un logro de Apple.

Title: Se establece el titulo del logro en el idioma correspondiente queserá mostrada a los jugadores.

Pre-earned Description: Descripción de muestra para los jugadores queaún no han obtenido el logro.

Earned Description: Descripción de muestra para los jugadores que hanganado el logro.

Image: Imagen de muestra para representar el logro.

Una vez completados los campos obligatorios se guardan los cambios.Se repite el proceso hasta establecer todos los logros. Una vez �nalizado, seresumen en una vista tal como muestra la Figura 2.26:

Figura 2.26: Listado de todos los logros creados.

39



Para cada tabla de clasi�cación generada se deben completar dos formu-larios. Uno se corresponde con las propiedades de la tabla y el otro formularioconsiste en el establecimiento del idioma de los distintos textos que se mos-trarán a los jugadores.

Figura 2.27: Metadatos de una tabla de clasi�cación de Apple.


Leaderboard Reference Name: Nombre corto para la tabla de clasi�ca-ción interno a iTunes Connect. Tiene como objetivo permitir las bús-quedas de tablas de clasi�cación dentro de la consola de desarrollador.No es un nombre o identi�cador que se muestre a los jugadores.

Leaderboard ID : Se trata de un identi�cador alfanumérico que el desa-rrollador elije para cada tabla. Este identi�cador está limitado a 100caracteres. Una vez publicado el videojuego, este valor no puede cam-biar.

Score Format Type: Se establece el tipo de formato en que se desea quela puntuación sea almacenada, por ejemplo, formato entero, tiempo odivisa.

Score Submission Type: Se elije que puntuación mostrar en la tabla declasi�cación, el mejor puntaje o el más reciente.

40

2. Estado del arte

Sort Order : Las tablas de clasi�cación pueden tener uno de los dos tiposde ordenamientos posibles: De menos a más (los menores puntajes semuestran primero) y De más a menos (los mayores puntajes se muestranprimero).

Score Range: Son valores opcionales que de�nen los límites inferior ysuperior en los que un puntaje es válido para la tabla de clasi�cación.Esto, ayuda a ignorar envíos de puntajes que son claramente fraudu-lentos a tal tabla. Si un jugador reporta un puntaje fuera de los límites,este es ignorado.

Es necesario que el desarrollador provea al menos una con�guración deidioma. La estrategia consiste en reutilizarla y establecerla en más de unaregión a la que esté pensada la aplicación.

Figura 2.28: Metadatos de un idioma de una tabla de clasi�cación de Apple.

De acuerdo a la Figura 2.28, cada idioma de cada tabla de clasi�caciónrequiere los siguientes metadatos:

Language: Es el idioma en el que se mostrará la tabla.

Name: Se establece el nombre de la tabla en el idioma correspondienteque será mostrada a los jugadores.

Score Format : Se establece el tipo de formato en que se desea que lapuntuación sea mostrada, por ejemplo, formato entero, tiempo o divisa.El formato de visualización se debe corresponder con el establecido enel campo Score Format Type de la tabla de clasi�cación.

41


Score Format Su�x Singular/Plural : Es un su�jo que se agrega al �nalde cada puntaje, es un valor opcional muy usado para clari�car el tipode puntaje almacenado (punto/puntos, moneda/monedas, golpe/gol-pes).

Image: Imagen de muestra para representar la tabla de clasi�cación.

Una vez completados los campos obligatorios se guardan los cambios. Serepite el proceso hasta establecer todas las tablas de clasi�cación. Una vez�nalizado, se resumen en una vista tal como muestra la Figura 2.29:

Figura 2.29: Listado de todas las tablas de clasi�cación creadas.

2.3.2.2. API de Game Center

Una de las cuestiones a tener en cuenta es que, en el dominio de Apple,las aplicaciones que se pretendan crear para sus diversas plataformas debenser desarrolladas en computadoras cuyo sistema operativo pertenezca a algu-na distribución OS X (antes llamado Mac OS X). Esta plataforma es propiade Apple y solo permite su funcionamiento en productos producidos por Ap-ple, como es el caso de la computadora Macintosh (actualmente denominadaMac).

Para el desarrollo de software en las plataformas de Apple (OS X e iOS)se encuentra el entorno de desarrollo XCode que posee un conjunto de uti-lidades para facilitar el desarrollo. Además de ser un entorno de desarrollo,XCode, cumple el rol de administrador de las distintas utilidades, permi-tiendo descargar nuevas, actualizarlas o eliminarlas. Una de esas utilidadeses el Framework GameKit que permite utilizar los servicios dedicados paramanipular tablas de clasi�cación y logros.

42

2. Estado del arte

Logros

En cuanto a los logros, el servicio de juegos Game Center ofrece lossiguientes servicios [Apple, 2010a]:

Poder visualizar todos los logros a partir de la UI de Apple.

Establecer el porcentaje de cumplimiento de un logro en particular(usando su identi�cador).


Consultar el porcentaje de completitud que posee un logro determina-do. Al igual que el item anterior, para utilizar este servicio es necesariohacer uso de retrollamadas.

Por otro lado, el API no ofrece los siguientes servicios:

Incrementar el porcentaje de cumplimiento de un logro dado.

A través de la consola de desarrollador de Apple los logros puedenmantenerse ocultos al jugador. Tal estado no puede cambiarse desde elcódigo fuente del videojuego.



Las tablas de clasi�cación [Apple, 2010a] almacenan valores del tipo In-teger (es decir, de 32 bits). El API, ofrece servicios que permiten almacenarvalores Integer a una tabla en particular utilizando su identi�cador. Proveeun servicio para poder visualizar una tabla de clasi�cación determinada, perono un servicio que permita visualizar todas las tablas de clasi�cación de laaplicación. Para obtener el puntaje de un jugador a lo largo del videojuegose hara uso de retrollamadas.

43


Almacenamiento

El servicio de juegos Game Center no provee soporte para almacenamien-to en la nube [Apple, 2010b], ni mucho menos sincronización de un mismovideojuego entre distintos dispositivos. Aún así Apple, a través del Frame-work GameKit provee servicios para que el desarrollador implemente sus pro-pios métodos de persistencia. Este guardado de datos se realiza utilizando elservicio iCloud bajo propia responsabilidad del desarrollador. Del mismo mo-do, in�ere lógica adicional al videojuego para controlar que elementos debenguardarse.

2.3.3. Google: Google Play Games


Para registrar o gestionar distintas aplicaciones creadas por un desarro-llador en particular, se debe ingresar al sitio donde se encuentre la consola dedesarrollador de Google3. Para ello, el desarrollador previamente debe estarregistrado. Una vez dentro se pueden visualizar muy resumidamente la listade aplicaciones que tiene en su poder un usuario dado. En caso de no contarcon cuenta de desarrollador, el proceso para registrar un nuevo usuario poseeun cargo por única vez de 25 USD.

Logros


Nombre: Este valor se muestra a los jugadores. No puede superar los100 caracteres. Es obligatorio para el caso de que se deseen realizarpruebas.

Descripción: Es una explicación breve sobre el logro. Usualmente indi-ca a los jugadores que tareas deben realizar para conseguir tal logro.No puede superar los 500 caracteres. Distinto al campo Nombre, estecampo es opcional completar para el caso de que se quieran realizarpruebas.

3https://play.google.com/apps/publish/

44

2. Estado del arte

Figura 2.30: Metadatos de un logro de Google.

Icono: Se trata de una simple imagen de muestra para los jugadores.

Logros incrementales : Los logros en Google pueden ser designados comologros de tipo estándar o incremental.

• Un logro estándar básicamente es un logro binario, a estos tiposde logros únicamente se los puede desbloquear de manera directa.

• Un logro incremental establece un progreso gradual del jugadorpara con el videojuego. A medida que el jugador progresa, eldesarrollador puede reportar la cantidad de progreso al serviciode juegos de Google Play. Este servicio, mantiene un seguimientode la información de progreso, da aviso al videojuego cuando eljugador lo ha desbloqueado y le indica al jugador el progreso quelleva sobre los logros. Cuando se crea un logro incremental, se de-be de�nir el numero total de pasos requeridos para desbloquearlo(este numero debe estar entre 2 y 10,000).

45


Estado inicial : Desde la consola de desarrollador, un logro puede teneruno de los siguientes dos estados.

• Un logro oculto indica que los detalles sobre él están ocultos parael jugador. El servicio de juego de Google Play provee una des-cripción e icono genérico para los logros que se mantienen ocultos.

• Un logro visible signi�ca que el jugador tiene conocimiento sobreel logro, pero no lo ha desbloqueado aún.

Puntos : Cada logro posee un puntaje asociado. Este puntaje debe serun múltiplo de 5 y un juego nunca puede tener un total de más de1,000 puntos para todos sus logros. Ademas, un logro individual nopuede tener mas de 200 puntos. Los jugadores pueden aumentar sunivel en su Per�l de Juego cuando estos desbloquean logros. Por cadapunto asociado al logro, el jugador adquiere 100 puntos de experiencia.El servicio de juegos de Google Play mantiene un seguimiento de laexperiencia adquirida para cada jugador y envía una noti�cación a laaplicación cuando un jugador alcanza un nuevo nivel.

Orden en la lista: Es el orden en el cual el logro aparece cuando unjugador visualiza los logros asociados al juego. Este orden puede sercualquiera que el desarrollador desee.

Una cuestión importante es la ausencia de un campo para establecer elidenti�cador del logro. Esto se debe a que, Google es el encargado de asignarlea cada logro un identi�cador de manera arbitraria. Tales identi�cadores cons-tan de cadenas de aproximadamente 20 caracteres. A medida que se dan dealta nuevos logros esto son listados a modo de resumen con las característicasmás importantes (Figura 2.31).

Figura 2.31: Listado de logros registrados.

46

2. Estado del arte

Figura 2.32: Metadatos de una tabla de puntajes de Google.

Marcadores


Nombre: Nombre corto para la tabla de clasi�cación que se muestra alos jugadores. No puede superar los 100 caracteres. Es obligatorio parael caso de que se deseen realizar pruebas.

Formato de Puntuación: Todos los puntajes son enviados y almacena-dos internamente como tipos de datos entero (32 bits). El servicio dejuegos de Google Play permite presentar tales valores a los usuarios endiferentes formatos.

• Numérico: Las tablas presentan los puntajes como números. Es-tos pueden ser mostrados como valores de tipo de dato entero ocomo �otantes con un número �jo de lugares decimales. Para esteúltimo, se envía la puntuación con un valor de tipo de dato entero

47


y el punto decimal es insertado en el lugar especi�cado. Una pun-tuación de 314159, será mostrado como 3.14159, 3141.59 o 314159,dependiendo el lugar establecido para insertar el punto.

• Tiempo: Las tablas presentan los puntajes en un formato Hora -Minutos - Segundos - Milésimas. Para esto, se deben enviar valoresen milisegundos. Entonces el valor 66032 será interpretado como1:06.03.

• Divisa: Las tablas presentan los puntajes en un formato de mone-da.

Icono: Se trata de una simple imagen de muestra para los jugadores.

Orden: Las tablas de clasi�cación pueden tener uno de los dos tiposde ordenamientos posibles: Más es mejor y Menos es mejor. El primeroes el más utilizado, ordena los puntajes en un orden decreciente. Elsegundo, los ordena en orden creciente.

Limites : Son valores opcionales que de�nen los limites inferior y supe-rior en los que un puntaje es valido para esa tabla de puntaje. Esto,ayuda a ignorar envíos de puntajes que son claramente fraudulentos atal tabla.

Habilitar protección contra manipulaciones : Se trata de una caracteris-tica de protección agregada a la tabla de clasi�cación. Comprueba lospuntajes presuntamente alterados y los oculta automáticamente.

Orden en la lista: Es el orden en el cual la tabla de clasi�cación aparececuando un jugador visualiza todas las tablas asociadas al juego. Esteorden puede ser cualquiera que el desarrollador desee.

Análogo a los logros, aquí también Google asigna a cada tabla de puntajeun identi�cador aleatorio. Y de la misma manera, a medida que se dan dealta nuevas tablas de puntajes, estas son listadas a modo de resumen con suspropiedades más relevantes (Figura 2.33).

Por último, una vez dadas de altas todas las tablas y logros, se procede aobtener todos los identi�cadores juntos para poder utilizar los servicios desdeel código fuente de la aplicación. Ya sea en la vista de logros o tablas depuntajes, se presiona sobre �Obtener recursos�. A continuación se presentaráuna ventana y se selecciona el formato deseado tal como se muestra en laFigura 2.34.

48

2. Estado del arte

Figura 2.33: Listado de tablas de puntajes registradas.

Figura 2.34: Recursos dados de alta en la consola de desarrollador.

Testing

Si el videojuego se encuentra en un estado de borrador se deben esta-blecer la/las cuenta/s de usuarios a los que se les pretenda dar acceso pararealizar pruebas sobre la aplicación. De otra forma, los usuarios que pruebenla aplicación se encontrarán con errores de acceso inválido. Incluso el desarro-llador de la aplicación debe agregarse como usuario de pruebas. El registrode nuevos usuarios se realiza dando de alta la dirección de correo electrónicode Google de tal usuario.

49


2.3.3.2. API de Google Play Games

No se descarga de manera directa desde un sitio web. Para poder ha-cer uso de sus servicios, es necesario descargarla desde la aplicación AndroidSDK Manager. Esta herramienta es un gestor de paquetes para el desarrollode aplicaciones de la plataforma móvil Android. Posee paquetes de softwa-re separados a partir de los distintos niveles de API del sistema operativo.Además, en la sección de �extras� se pueden encontrar complementos, entreellos, la librería Google Play Services.

Esta librería es de propósito general. Diferente al caso de Amazon dondetodas las bibliotecas son de propósito especi�co, es decir, hay una libreríapara usar exclusivamente con los mapas, otra librería solo para el aspectode redes sociales de jugadores, y así para cada servicio que ofrece Amazon.En cambio Google a partir de la librería Google Play Services otorga desdeun mismo lugar, funciones para los distintos servicios que ofrece. En Googletodo está concentrado en un único lugar, mientras que en Amazon no.

Logros

El API de Google ofrece los siguientes servicios [Google, 2013b]:

Poder visualizar todos los logros a partir de la UI de Amazon.


Establecer la cantidad de pasos de avance de un logro en particular(usando su identi�cador).

Incrementar la cantidad de pasos de avance de un logro dado (Primeradiferencia respecto a Amazon).

A través de la consola de desarrollador de Google los logros puedenmantenerse ocultos al jugador. Contrario a Amazon, se puede cambiarel estado de los logros desde el código del videojuego (de Oculto aRevelado).


50

2. Estado del arte

Consultar el numero de pasos que posee un logro determinado. Al igualque el item anterior, para utilizar este servicio es necesario hacer usode retrollamadas.


Las tablas de clasi�cación [Google, 2013c] almacenan valores del tipoInteger (32 bits). El API, permite almacenar valores Integer. Así mismo,provee métodos para poder visualizar una tabla de puntaje determinada otodas las tablas de clasi�cación del videojuego. Para consultar el puntaje deun jugador a lo largo del videojuego se hace uso de retrollamadas (callbacks).

Almacenamiento

Google también ofrece un servicio para la persistencia de datos y la re-solución automática de con�ictos denominado Saved Games [Google, 2013d].Permite almacenar de manera sencilla el progreso de los jugadores a travésdel videojuego en servidores propiedad de Google. Tal servicio hace posiblerealizar la sincronización de datos de un mismo videojuego que se encuentreinstalado en más de un dispositivo móvil de un mismo usuario. Administralos casos en los que el usuario se encuentre jugando en linea o sin conexióny permite sincronizar datos a través de múltiples dispositivos.

El servicio Saved Games ofrece una experiencia de usuario visual ademásde las características de persistencia. Es posible asociar imágenes representa-tivas con sus correspondientes datos a salvar. Posteriormente estas imágenesson mostradas al jugador al momento de elegir la partida guardada a reanu-dar. Además de una imagen representativa, es posible agregar una descripcióna la partida guardada.

2.4. Herramientas para desarrollo de videojue-

gos móviles

La variedad de dispositivos existentes (consolas, computadoras, teléfonosinteligentes, tabletas, etc.) tiene como consecuencia que los desarrolladores devideojuegos hagan uso de herramientas o frameworks que faciliten el desa-

51


rrollo multiplataforma. La razón es clara: obtener un mayor retorno de lainversión realizada y no depender de una única tecnología.

2.4.1. Haxe

Haxe es un lenguaje de programación de código abierto [Dasnois, 2011].Mientras ciertos lenguajes están estrictamente ligados a una plataforma (porejemplo Java a su máquina virtual), Haxe es un lenguaje multiplataforma[Ponticelli and McColl-Sylvester, 2008]. Esto signi�ca que puede utilizarsecon el propósito de generar código para plataformas [Haxe, 2005a] como Ja-vaScript, SWF (Flash), NekoVM (Neko Virtual Machine), PHP, C++, C#y Java. Como se ve, el soporte multiplataforma de Haxe es muy amplio ypermite mejorar el retorno de una inversión.

La ideología que persigue Haxe se basa en permitir que el desarrolladorelija la mejor plataforma destino para un programa. Este enfoque aumenta la�exibilidad a la hora de desarrollar, porque cada plataforma está típicamenteasociada a un lenguaje de programación en concreto.

Las tres bases sobre los que esta �losofía se fundamenta son:

Lenguaje de programación estandarizado.

Biblioteca estándar de funciones que actúa de manera idéntica en todaslas plataformas [Haxe, 2005b].

Bibliotecas especí�cas de plataforma, posibilitando el uso y acceso alas mismas desde el código Haxe [Haxe, 2005d].

Por otro lado, las principales características que ofrece el lenguaje Haxeson las siguientes:

Lenguaje Orientado a Objetos: Haxe permite estructurar el código enclases, convirtiéndolo en un lenguaje orientado a objetos. Esto facilitael diseño, desarrollo y mantenimiento de proyectos software. Haxe dasoporte, mediante distintos elementos, a las características típicas de laOrientación a Objetos (herencia, encapsulación y polimor�smo).

Inferencia de Tipos: Permite que el compilador de Haxe deduzca el tipode una variable a partir del valor que le fue asignado previamente.

52

2. Estado del arte

Manejo de Excepciones: Mediante los típicos bloques try-catch.

Compilación Condicional: A través de macros de compilación condicio-nal. Este esquema facilita la integración de código especí�co para unadeterminada plataforma y es esencial en lenguajes multiplataforma co-mo Haxe.

1 #if js

2 // Codigo JavaScript

3 #else

4 // Codigo No JavaScript

5 #end

Iteradores: Soporte nativo para el recorrido directo de contenedores,posibilitandola implementación de iteradores personalizados.

Funciones Locales: Las funciones de Haxe pueden ser declarados en lasexpresiones.

1 var buffer = "";

2 function append(s:String) {

3 buffer += s;

4 }

5 append("foo");

6 append("bar");

7 trace(buffer); // foobar

Tal listado no representa una lista exhaustiva sobre todas las caracterís-ticas que ofrece Haxe [Haxe, 2005c].

Por último y no menos importante, Haxe provee soporte multiplatafor-ma tanto en el lado del cliente como en el lado del servidor. Desde el puntode vista del servidor de aplicaciones, Haxe proporciona la siguiente funcio-nalidad:

Es posible compilar a NodeJS y a otras tecnologías relacionadas conJavaScript.

Es posible compilar a código PHP 5.

Por una parte, desde el punto de vista del cliente de una aplicación, Haxepermite:

53


Compilar a JavaScript generando un único archivo .js. Es posible ajus-tar el tamaño �nal del script resultante.

Es posible general a Flash generando un archivo .swf. Es posible inte-grar bibliotecas externas SWF.

Es posible compilar a código C++, el cual se puede compilar a su veza binarios nativos de plataformas móviles, como iOS o Android. Dehecho, OpenFL es un caso representativo de este enfoque.

2.4.1.1. OpenFL

OpenFL [Fernández et al., 2014] es un framework de código abierto ymultiplataforma que, haciendo uso del lenguaje de programación Haxe per-mite la generación de distintas aplicaciones o videojuegos ejecutables, a partirdel mismo código fuente. Como Haxe permite generar código para diver-sas plataformas, las aplicaciones generadas con OpenFL podrán correr sobreplataformas como: ordenadores personales con Windows o GNU/Linux has-ta navegadores web con soporte de HTML5 o Flash pasando por teléfonosinteligentes y tablets con Android o iOS.

OpenFL posee una serie de características que lo convierten en una elec-ción muy interesante para el desarrollo de videojuegos.

Desde el punto de vista grá�co:

Ofrece soporte para bitmaps.

Permite tratar con grá�cos vectoriales.

Soporta manipulación a nivel de píxel.

Soporta batch triangle & batch tile rendering.

Permite un acceso directo a la API OpenGL para tener más controlsobre el proceso de rendering.

Soporte para rendering a pantalla completa.

Desde el punto de vista multimedia:

Soporta la reproducción de audio.

54

2. Estado del arte

Posibilita la generación dinámica de audio.

Desde el punto de vista del networking:

Soporta peticiones HTTP.

Permite el uso de sockets de bajo nivel.

Proporciona soporte para cachés de datos.

Desde el punto de vista de la manipulación de texto:

Soporta el rendering de texto a nivel de dispositivo.

Soporta el rendering de fuentes empotradas.

Posibilita la personalización del rendering de fuentes.

Ofrece rendering HTML básico.

Desde el punto de vista de la gestión de eventos:

Facilita el tratamiento de eventos de teclado y ratón.

Soporta entrada multitouch.

Permite el uso de joysticks.

Por otra parte, resulta importante destacar que OpenFL permite haceruso de extensiones nativas a determinados lenguajes de programación. Es-tas extensiones permiten realizar algo propio de la plataforma que no esteimplementado en OpenFL o en Haxe. Tales extensiones son materializadasmediante librerías, que posteriormente pueden ser incluidas en proyectos Ha-xe como cualquier otra. OpenFL brinda la posibilidad de generar libreríaspersonalizadas que pueden contener servicios íntegramente nuevos, hacer usosolamente de otras funcionalidades provistas por terceros o combinación deestos dos últimos. Por ejemplo, OpenFL posibilita la programación multihi-lo para plataformas que proporcionen, de manera nativa, dicho modelo deprogramación. De este modo, es posible mejorar la e�ciencia, si así es nece-sario, atendiendo al dispositivo �nal sobre el cual se desplegará el videojuegodesarrollado.

55


Por último, OpenFL es un framework que posibilita la integración conotros frameworks para el desarrollo de videojuegos (por ejemplo Flixel, Ha-xePunk).

Como se ha introducido anteriormente, OpenFL soporta una gran varie-dad de plataformas software:

Windows.

Mac.

GNU/Linux.

iOS.

Android.

BlackBerry.

webOS.

Flash.

HTML5.

La consecuencia inmediata de esta característica es que el mercado po-tencial para desplegar un juego desarrollado con OpenFL se multiplica. Porejemplo, un desarrollo de un videojuego con OpenFL se podría ejecutar enun teléfono móvil con Android 3.0, un iPhone con iOS 5.0 y, por ejemplo, unnavegador web con soporte para HTML5. No obstante, a veces todo no es tandirecto y sencillo. En los desarrollos multiplataforma a veces hay que conside-rar cuestiones especí�cas de las plataformas �nales sobre las que se ejecutaráel videojuego (o aplicación) desarrollado. Esto se debe a dos factores:

Controlar que los aspectos de implementación estén soportados por lasplataformas �nales.

Incrementar la e�ciencia en una determinada plataforma. Tal acción,implicaría implementar código especí�co en la misma.

56

Capítulo 3

Descripción del problema

En la actualidad existen diversos entornos de trabajos (frameworks) al-tamente completos para el desarrollo multiplataforma de videojuegos paradispositivos móviles. Estos entornos, di�eren en aspectos como:

Desarrollo de videojuegos en dos o tres dimensiones.

Limitaciones en términos de pagos de eventuales licencias o comple-mentos.

Rendimiento de la aplicación generada en diversas plataformas.

Independientemente de la elección que se realice, el propósito del desa-rrollador es claro: evitar tener múltiples instancias del mismo videojuego deacuerdo a la plataforma al que esté orientado. Como ventaja a este deseo, esel hecho de evitar aprender los distintos lenguajes de programación o diversosentornos de trabajo para el desarrollo en cada plataforma. Esto se traduceen ahorro de tiempo y esfuerzo. Además, para sacar mayor provecho a losdos aspectos antes mencionados, las modi�caciones que deban aplicarse a lalógica del videojuego impactan sobre un único código fuente y no sobre cadauno.

En el contexto de una empresa de desarrollo de videojuegos para dispo-sitivos móviles, se hace uso de un lenguaje de programación multiplataformapara la creación de tales proyectos. El aspecto más importante en esta activi-dad es que, para las aplicaciones lúdicas que tal entidad genera, se hace uso de

57


mecánicas de juegos con un enfoque combinado. Esto es porque, los desarro-lladores generan ciertas mecánicas propias al videojuego y las complementancon las mecánicas que facilitan los distintas proveedores.

Para la manipulación de las mecánicas de juegos generadas de maneraarbitraria por la empresa, no es necesario hacer uso de servicios ajenos allenguaje multiplataforma. En cambio, para hacer uso de las mecánicas pro-vistas por los proveedores es necesario utilizar los distintos servicios de lasAPI's que estos ofrecen. La tarea de agregar los servicios que manipulan lasmecánicas a cada videojuego conlleva un proceso lento. Tal actividad estáligado al aprendizaje de cada API y la eventual integración al código fuentede la aplicación.

Para comprender esta problemática, el accionar de un desarrollador dela empresa se corresponde al siguiente curso de eventos: �Un desarrolladorperteneciente a la empresa genera la lógica del videojuego sin considerar elagregado de mecánicas de juegos de ningún proveedor. Éste, desde la conso-la/terminal procede a generar el código ejecutable a partir de la plataformaobjetivo para la que este pensada la aplicación. Al momento de pretenderincluir mecánicas de juegos de un proveedor determinado, aprecia que laplataforma a la que pertenece la API de servicios condiciona el proceso decompilación. Esto provoca que la salida esté dirigida a la plataforma de laAPI para que las mecánicas funcionen y puedan ser utilizadas correctamente.Para solventar esto, concluye que, una primera solución implica tener múlti-ples instancias del mismo proyecto donde cada una utiliza una API distinta,mientras que una segunda solución es la de incluir todas las API's dentro delmismo proyecto�.

Se pretende que, mediante el uso de una librería, se utilicen de manerahomogénea los servicios que manipulan las mecánicas de juegos de cada unade las API's de cada proveedor. Tal complemento tiene como propósito eli-minar el problema al que está expuesto cada desarrollador de videojuegos enel lenguaje multiplataforma. A continuación, se detallan los requerimientos:

La librería debe pertenecer al lenguaje de programación utilizado porla empresa. Así mismo, la interfaz que provea la solución está ligada alos deseos de la empresa (Cuadro 3.1).

Dicha librería debe permitir utilizar servicios para manipular las dis-tintas mecánicas de juegos de manera transparente en cada uno de losvideojuegos que se desarrollen, mitigando los tiempos de aprendizaje eintegración que impone individualmente cada API de cada proveedor.

58

3. Descripción del problema

La librería tiene que eliminar la necesidad de mantener múltiples ins-tancias de la misma aplicación como así también la de concentrar en elmismo código fuente a todas las librerías de cada proveedor.

Además, a partir de la plataforma objetivo para la cual se compile elproyecto, la librería debe determinar cuales servicios utilizar de la APIcorrespondiente a dicha plataforma.

Mecánicas Métodos Descripción

Puntajes

displayScoreboard Visualizar una tabla de punta-je en particular.

displayAllScoreboards Visualizar todas las tablas depuntajes en el videojuego.

setScore Almacenar el puntaje del ju-gador en una tabla en parti-cular.

getPlayerScore Obtener el puntaje del juga-dor en una tabla en particular.

Logros

displayAchievements Visualizar todos los logros delvideojuego.

unlock Desbloquear un logro en par-ticular.

setSteps Establecer el estado de avancede un logro en particular.

reveal Mostrar un logro en particular(No implica desbloqueo).

increment Aumentar el estado de avancede un logro en particular.

getAchievementStatus Obtener el estado de un lo-gro en particular (Bloqueadoo Desbloqueado).

getAchievementSteps Obtener el estado de avancede un logro en particular.

AlmacenamientostoreData Almacenar el progreso del ju-

gador.retrieveData Recuperar progreso del juga-

dor (Sincronizacion).

Cuadro 3.1: Interfaz de la solución

59


Para llevar a cabo esto, inicialmente, la empresa ya cuenta con dos li-brerías individuales de los proveedores Google y Apple. Cada una posee yutiliza algunos servicios de la interfaz solución. Es necesario completar taleslibrerías con los métodos faltantes, generar una tercer librería individual queutilice los servicios de Amazon, y por último generar la librería que agrupa atodas las anteriores. En el Cuadro 3.2 se muestra un resumen de las libreríascon las que cuenta actualmente la empresa:

Métodos Google Apple Amazon Uni�cadora

displayScoreboard Si Si Posible PosibledisplayAllScoreboards Si No Posible Posible

setScore Si Si Posible PosiblegetPlayerScore Posible Posible Posible Posible

displayAchievements Si Si Posible Posibleunlock Si No Posible PosiblesetSteps Si Si Posible Posiblereveal Si No No Posible

increment Si No No PosiblegetAchievementStatus Posible Posible Posible PosiblegetAchievementSteps Posible Posible Posible Posible

storeData Si No Posible PosibleretrieveData Si No Posible Posible

Cuadro 3.2: Utilidades iniciales de la empresa.

Nótese la siguiente aclaración de cada estado en el Cuadro 3.2:

Todas las celdas que indican �Si�, denotan que la funcionalidad asociadase encuentra implementada.

Las celdas que contienen el estado �Posible� indican que la funcionali-dad no se encuentra implementada pero, a partir de la documentaciónde la API del proveedor, es posible implementarla.

Por último, las celdas que indiquen �No� establecen que no es posiblegenerar la funcionalidad perteneciente a la interfaz solución ya que laAPI del proveedor en cuestión no la provee.

60

Capítulo 4

Solución propuesta

Se propone brindar al desarrollador, una API que permite utilizar ser-vicios para videojuegos de diversos proveedores, de forma homogénea y enlenguaje Haxe.

Esta API, entiende cómo utilizar las mecánicas de juego disponibles encada proveedor; y dependiendo de la plataforma para la cual sea compilado elvideojuego, utiliza la implementación correspondiente sin que esto requieraadaptación alguna por parte del programador (Figura 4.1).

Figura 4.1: Diagrama de la solución en alto nivel.

Dado que cada proveedor utiliza una tecnología y lenguaje de progra-mación diferentes, la solución debió incluir módulos especí�cos para cadaproveedor que permitan la utilización de los mismos desde el lenguaje Haxe(a estos módulos los llamaremos Módulos Puente).

61


Inicialmente, se desarrolló de cero el módulo puente para Amazon GameCircle, y se integraron a la API, los módulos puente ya existentes para GooglePlay Games, y Apple Game Center (Figura 4.2). Estos dos últimos módulosfueron completados implementando las funcionalidades faltantes para podercumplir las necesidades de los desarrolladores plasmadas en la interfaz solu-ción (Cuadro 3.1).

Figura 4.2: API Homogénea.

Para los casos en los que el juego sea compilado hacia una plataformapara la cual no hay un módulo puente integrado con la solución, la APIresulta inocua, permitiendo la compilación y ejecución del juego sin erroresni condicionamientos.

Tanto los módulos puente, como la API homogénea, fueron creados apartir de herramientas facilitadas por el framework OpenFL y por Haxe.

62

4. Solución propuesta

OpenFL permite crear librerías que contienen funcionalidad no provista (lla-madas extensiones). En tanto, Haxe ofrece la compilación condicional y lacapacidad de vincular servicios en Haxe con servicios en otros lenguajes deprogramación.

Desde el punto de vista del desarrollador, la solución es relativamentesimple de utilizar, aunque se destaca la utilización de un sistema de retrolla-madas (callbacks) que aumenta la complejidad de uso para todas las funcionesde las cuales se espera una respuesta o valor de retorno. Esto se debe a quelos servicios de videojuegos utilizados trabajan de manera asíncrona, es decir,la respuesta a una solicitud no es inmediata (puede demorar varios segun-dos). El fundamento de los proveedores es directo: La ejecución asíncrona nobloquea la ejecución de las aplicaciones.

Es por esto que se separa la forma de utilizar las funciones que no en-tregan datos o información al desarrollador (como setScore, displayAllLea-derboards, displayLeaderboard, displayAchievements, setSteps, Increment,Unlock, Reveal, etc); de aquellas que sí lo hacen (getPlayerScore, getAchie-vementStatus y getAchievementSteps).

Para el primer tipo de funciones no se recibirá una respuesta tras suejecución, mientras que para el segundo tipo será necesario procesar la res-puesta (una vez que esté disponible). Para ello, se utiliza la estrategia deretrollamadas (callbacks). La retrollamadas establecen que: en vez de espe-rar el resultado de una función (blocking), o de consultar esporádicamentepor el estado de retorno (polling), el desarrollador debe informar qué funcióndebe ser invocada cuando se obtenga el resultado.

Los conceptos introducidos hasta aquí, se aplican para la solución com-pleta. A continuación de se detallan las particularidades de las componentesprincipales de la solución.

4.1. Módulos puente

Cómo se describió anteriormente, los módulos puente fueron implemen-tados utilizando la herramienta de extensiones de OpenFL. Las extensionespermiten ampliar la funcionalidad de OpenFL, integrando librerías y vincu-lando de otros lenguajes (Java, objective C, C++, etc). En este caso, lasextensiones resultan ideales para integrar los servicios de videojuegos de losdiferentes proveedores, ya que cada uno viene con su propia librería en len-

63


guaje Java (Amazon y Google) u Objective C (Apple).

En el desarrollo de cada módulo puente, se pretende ofrecer la funcio-nalidad completa (o lo más completa posible) que brinda cada proveedor.También se pretende mantener en cada una un enfoque que respete tantolos estándares de desarrollo en Haxe/OpenFL, como los del desarrollador(aunque cuando esto no es posible, se opta por mantener el estándar de lacomunidad de desarrolladores de extensiones de Haxe/OpenFL).

Los módulos puente desarrollados son tres:

4.1.1. Amazon Game Circle

Este módulo, denominado �extension-gamecircle�, se desarrolló de formacompleta (siendo el único módulo puente desarrollado de cero) a partir dela implementación de servicios otorgada por el proveedor. La librería con losservicios de Amazon se obtiene desde su sitio web de manera libre y gratuita.Tal paquete contiene diferentes librerías que dan soporte a los distintos servi-cios provistos por Amazon. Algunos de estos son, por ejemplo, el servicio demapas, redes de publicidades, compras desde la aplicación, uso de mecánicasde juego, etc. Cualquiera de estas librerías se encuentran desarrolladas en ellenguaje de programación Java.

Este proveedor no impone restricciones de redistribución con los ele-mentos que conforman a la librería que otorga, con lo cual, todos estos seencuentran incluidos dentro de este módulo puente, sin que esto impida lalibre distribución del mismo. Esta aclaración es importante para la contribu-ción de esta librería a la comunidad de OpenFL.

Luego de estas consideraciones se desarrolló el módulo como una únicaclase en Haxe. Dicho elemento vincula cada servicio Java del proveedor con sucorrespondiente servicio en Haxe a partir del uso de JNI. Por otro lado, todoslas funcionalidades ofrecidas en la API del módulo puente se correspondencon métodos de clase para simpli�car el uso de estos servicios sin necesidadde crear instancias. De esta forma, el módulo puente implementado proveeuna API que se presenta a continuación:

1 // Inicializacion.

2 public static function init(enableCloudStorage:Bool)

3

64


4 // Almacenamiento.

5 public static function cloudSet(key:String , value:

String)

6 public static function cloudGet(key:String)

7 public static function markConflictAsResolved(key:

String)

8

9 // Tablas de clasificacion.

10 public static function displayAllScoreboards ()

11 public static function displayScoreboard(leaderboardID

:String)

12 public static function setScore(leaderboardID:String ,

score:Int)

13 public static function getPlayerScore(leaderboardID:

String)

14

15 // Logros.

16 public static function displayAchievements ()

17 public static function unlock(achievementID:String)

18 public static function setProgress(achievementID:

String , progress:Float)

19 public static function getAchievementStatus(

achievementID:String)

20 public static function getAchievementProgress(


Dentro de esta API, se encuentran tres servicios que retornan datos aldesarrollador:

getPlayerScore.

getAchievementStatus.

getAchievementProgress.

Para estos tipos de servicios fue necesario establecer funcionalidad adi-cional para las retrollamadas. A partir del enfoque utilizado en este módulo,el desarrollador puede �opcionalmente� informar una función de callback almódulo puente. Si realiza tal acción, este será noti�cado cuando arribe larespuesta deseada. De esta forma, el código fuente del videojuego mostraráel siguiente esquema de sentencias:

65


1 function playerScoreCallback(idScoreboard:String ,

score:Int):Void {

2 trace("Player Score: " + score +" on scoreboard: "+

idScoreboard);

3 }

4

5 function achievementProgressCallback(idAchievement:

String , progress:Float):Void {

6 trace("Progress: " + progress +" for achievement: "+

idAchievement);

7 }

8

9 function achievementStatusCallback(idAchievement:

String , state:Int):Void {

10 trace("Status: " + state +" for achievement: "+

idAchievement);

11 }

12

13 public function new() {

14 GameCircle.onGetPlayerScore = playerScoreCallback;

15 GameCircle.onGetAchievementProgress =

achievementProgressCallback;

16 GameCircle.onGetAchievementStatus =

achievementStatusCallback;

17

18 GameCircle.getPlayerScore("...");

19 GameCircle.getAchievementProgress("...");

20 GameCircle.getAchievementStatus("...");

21 }

Para cualquiera de los tres servicios, el razonamiento es el mismo, peropara explicar el funcionamiento se toma como ejemplo el caso de obtener elpuntaje. Para ello se debe realizar lo siguiente:

1. Asignar a la función onGetPlayerScore del módulo puente una funciónexterna. En el esquema de sentencias anterior, la función externa seríaplayerScoreCallback.

2. Ejecutar el servicio asociado, en este caso getPlayerScore.

Al momento de invocar al servicio, internamente, entre el módulo puente

66


y la implementación nativa utilizando la librería del proveedor suceden lossiguientes eventos:

1. Desde el módulo puente se envía una instancia de sí mismo (un obje-to Haxe) hacia la implementación nativa (Java), para que esta puedarealizar las retrollamadas.

2. Se ejecuta al servicio nativo. Cuando este obtenga los datos deseados,invoca a un método privado del módulo puente utilizando la instanciaenviada. Tal llamado involucra el envío de los datos: identi�cador de latabla de clasi�cación y puntaje asociado.

3. Nuevamente en el módulo puente, dentro del método privado se con-trola la nulidad de la función onGetPlayerScore.

a) Si esta no fue asignada, entonces no se obtienen los datos deseados.

b) Si esta fue asignada, entonces se ejecuta la función externa quefue asignada a tal función onGetPlayerScore (es decir, playerSco-reCallback). De esta manera, se obtienen los datos.

El �ujo anteriormente mencionado se condice con un proceso de suscrip-ción que llamaremos �orientado al servicio� (Figura 4.3). Esto se denominóasí ya que deben haber tantas funciones del estilo onGet dentro del módulopuente (cada una con su correspondiente función de control) como cantidadde servicios que retornen valores haya.

Por último, como se pudo observar, el establecimiento de suscripciónpor parte del desarrollador se realiza una única vez sobre los servicios que éldesee. Entonces, se puede pensar que exista una función de inicialización enla lógica del videojuego donde se concentren todas las suscripciones.

4.1.2. Google Play Games

Para este módulo, se optó por no desarrollar una extensión desde ce-ro, sino que se tomó como base para el desarrollo la extensión ya existente�extension-googleplaygames� (o�cial de OpenFL). Este módulo, si bien esta-ba probado y proveía funcionalidades necesarias, no otorgaba las funcionessu�cientes para el desarrollo de este trabajo, por lo que fue necesario com-pletar su implementación agregando las siguientes funciones:

67


Figura 4.3: Suscripción orientada al servicio.

getPlayerScore (leaderboardID)

getAchievementStatus (achievementID)

getAchievementSteps (achievementID)

Distinto al caso de Amazon, la librería con los servicios de Google, de-nominada Google Play Services, no se obtiene de manera directa desde unsitio web. Para contar con ella, es necesario descargarla desde la aplicaciónAndroid SDK Manager. Tal librería centraliza en un único lugar muchos delos servicios ofrecidos por Google, entre los cuales se destacan los serviciospara videojuegos (Google Play Games), publicidad (AdMob), almacenamien-to en la nube (Drive), entre otros. Por otro lado, esta librería se encuentradesarrollada en el lenguaje de programación Java.

Otra diferencia con respecto a Amazon es que este proveedor imponerestricciones de redistribución. Por ende, no es posible incluir esta libreríadentro del módulo puente si se lo quiere redistribuir libremente. La contri-bución a OpenFL con esta librería incluida al módulo puente, violaría los

68


términos. Para solventar esta situación, es necesario indicarle a Haxe dondese encuentra físicamente la librería para agregarla al videojuego cuando estesea creado.

A partir de estas consideraciones se puso especial cuidado en mantenerel estilo de desarrollo y documentación que la extensión utilizaba previo a lasmodi�caciones incluídas. Esto se realizó con el objetivo de poder contribuirlos cambios realizados en esta extensión de vuelta hacia OpenFL. El estiloque presentaba dicha extensión consistía en la implementación de métodosde clase, vinculación de los servicios nativos del proveedor utilizando JNI ypara las suscripciones se utiliza el enfoque �orientado al servicio�.

Una vez implementados los servicios faltantes, el módulo puente presen-ta la siguiente interfaz:



3


5 public static function discardAndCloseGame ()

6 public static function commitAndCloseGame(key:String ,

value:String)

7 public static function loadSavedGame(key:String)

8


10 public static function displayAllScoreboards ()

11 public static function displayScoreboard(leaderboardID

:String)

12 public static function setScore(leaderboardID:String ,

score:Int)


String)

14

15 // Logros.


17 public static function unlock(achievementID:String)

18 public static function increment(achievementID:String ,

steps:Int)

19 public static function reveal(achievementID:String)

20 public static function setSteps(achievementID:String ,

steps:Float)



69


22 public static function getAchievementSteps(


En la misma, se encuentran tres servicios que retornan datos al desarro-llador:

getPlayerScore.


getAchievementSteps.

Nuevamente, para estos tipos de servicios fue necesario implementar fun-cionalidad para las retrollamadas. Como el sistema de suscripción es el mismoque el utilizado en el módulo puente de Amazon, el procedimiento y funcio-namiento de cada uno es igual. De esta forma, el código fuente del videojuegomostrará el siguiente esquema de sentencias:

1 function playerScoreCallback(idScoreboard:String ,

score:Int):Void {

2 trace("Player Score: " + score +" on scoreboard: "+

idScoreboard);

3 }

4

5 function achievementStepsCallback(idAchievement:String

, steps:Int):Void {

6 trace("Steps: " + steps +" for achievement: "+

idAchievement);

7 }

8

9 function achievementStatusCallback(idAchievement:

String , state:Int):Void {

10 trace("Status: " + state +" for achievement: "+

idAchievement);

11 }

12

13 public function new() {

14 GooglePlayGames.onGetPlayerScore =

playerScoreCallback;

15 GooglePlayGames.onGetAchievementSteps =

achievementStepsCallback;

70


16 GooglePlayGames.onGetAchievementStatus =

achievementStatusCallback;

17

18 GooglePlayGames.getPlayerScore("...");

19 GooglePlayGames.getAchievementSteps("...");

20 GooglePlayGames.getAchievementStatus("...");

21 }

4.1.3. Apple Game Center

Para este módulo, también se optó por no desarrollar una extensión des-de cero, y utilizar la extensión ya existente �extension-gamecenter� (o�cial deOpenFL). Este módulo, si bien estaba probado y proveía algunas funcionali-dades necesarias, no ofrecía las funciones su�cientes para el desarrollo de estetrabajo, por lo que fue necesario completar su implementación agregando lassiguientes funciones:

getPlayerScore (leaderboardID)

getAchievementStatus (achievementID)

getAchievementSteps (achievementID)

En el dominio de Apple, las aplicaciones y extensiones desarrolladas paraiPhone y iPad, deben ser compiladas y probadas dentro de computadorasmarca Apple (líneas Mac, iMac y MacBook) con sistema Operativo Mac OSactualizado a su última versión.

Para el desarrollo de software en las plataformas de Apple (iOS y OS X)se utiliza el entorno de desarrollo X-Code que posee un conjunto de utilidadespara facilitar esta tarea. Además de ser un entorno de desarrollo, X-Codecumple el rol de gestor de componentes y librerías. Una de estos componenteses el Framework GameKit, que permite utilizar los servicios dedicados paramanipular las mecánicas de juego. En dicho Framework los servicios a utilizarse encuentran desarrollados en el lenguaje de programación Objective-C.

Apple, análogo a Google, impone restricciones de redistribución. Enton-ces, tal como se solventó esta situación para el módulo puente de Google, esnecesario indicarle a Haxe nuevamente donde se encuentra tal librería paraagregarla al videojuego cuando este sea generado.

71


Aquí también se puso especial cuidado en mantener el estilo de desarro-llo y documentación que la extensión utilizaba previo a las modi�cacionesincluidas (para poder contribuir los cambios realizados en esta extensión devuelta hacia OpenFL). El estilo que presentaba dicha extensión consistía enla implementación de métodos de clase, vinculación de los servicios nativosdel proveedor utilizando la librería cpp de Haxe y para las suscripciones seutiliza otro enfoque distinto al utilizado en los módulos de Amazon y Google.

Una vez implementados los servicios faltantes, el módulo puente presen-ta la siguiente interfaz:


2 public static function authenticate ()

3


5 public static function showLeaderboard(leaderboardID:

String)

6 public static function reportScore(leaderboardID:

String , score:Int)


String)

8

9 // Logros.

10 public static function showAchievements ()

11 public static function reportAchievement(achievementID

:String , progress:Float)



13 public static function getAchievementProgress(


Cabe destacar que Game Center, no provee la funcionalidad de alma-cenamiento en la nube, por lo que la misma no puede ser agregada en estaextensión.

Por otro lado, dentro de la API se encuentran tres servicios que retornandatos al desarrollador:

getPlayerScore.


72


getAchievementSteps.

En este caso, la funcionalidad para el tratamiento de las retrollamadasutiliza tres componentes propios de Haxe denominados Events, EventListe-ner y EventDispatcher. El objetivo continúa siendo el mismo, permitir aldesarrollador que pueda �opcionalmente� informar una función de callback almódulo puente. El modo para informar esta función establece la diferenciaen relación a los esquemas utilizados en Amazon y Google. En este caso, elcódigo fuente del videojuego tendrá la siguiente apariencia en términos desentencias:

1 function playerScoreCallback(e:Dynamic):Void {

2 trace("Player Score: " + e.data2 +" on scoreboard: "

+ e.data1);

3 }

4

5 function achievementProgressCallback(e:Dynamic):Void {

6 trace("Steps: " + e.data2 +" for achievement: "+ e.

data1);

7 }

8

9 function achievementStatusCallback(e:Dynamic):Void {

10 trace("Status: " + e.data2 +" for achievement: "+ e.

data1);

11 }

12

13 function new() {

14 GameCenter.addEventListener("onGetPlayerScore",

playerScoreCallback);

15 GameCenter.addEventListener("

onGetAchievementProgress",

achievementProgressCallback);

16 GameCenter.addEventListener("onGetAchievementStatus"

, achievementStatusCallback);

17

18 GameCenter.getPlayerScore("...");

19 GameCenter.getAchievementProgress("...");

20 GameCenter.getAchievementStatus("...");

21 }

Nuevamente, para cualquiera de los tres servicios que retornan datos

73


el razonamiento es el mismo. Entonces, siguiendo el ejemplo de obtener elpuntaje, se debe realizar lo siguiente:

1. Utilizando el método addEventListener, asociar a un nombre de evento,por ejemplo onGetPlayerScore, una función externa que tenga comoúnico parámetro de entrada un objeto Dynamic.

2. Ejecutar el servicio asociado, en este caso getPlayerScore.

Al momento de invocar al servicio, internamente, entre el módulo puentey la implementación nativa utilizando la librería del proveedor suceden lassiguientes acciones:

1. Desde el módulo puente se envía el método encargado de noti�car atodas las funciones suscriptas hacia la implementación nativa.

2. Se ejecuta el servicio nativo. Cuando este obtenga los datos deseados,utilizará el método recibido en el paso anterior dándole como parámetroun objeto que contiene el nombre del evento onGetPlayerScore (campotype), el identi�cador de la tabla de clasi�cación (campo data1 ) y elpuntaje asociado (campo data2 ).

3. De regreso al módulo puente, se extraen los valores, se crea un objetode tipo Event y se ejecutan todas las funciones asociadas al nombre deevento onGetPlayerScore enviando este objeto recién creado.

En este caso, a este tipo de suscripción lo llamaremos �orientado a even-tos�. En este caso, con un mismo punto de entrada para el registro de callbacksse cubren todos los servicios que tengan como objetivo retornar datos desdela implementación nativa del proveedor.

4.2. API Homogénea

Para esta API nuevamente se utilizó la herramienta de extensiones deOpenFL combinada con la compilación condicional de Haxe. Este módulose denomina �extension-multigames� y debió ser generada desde cero. Aquíse agruparon en un único servicio, los distintos servicios en común en cada

74


módulo puente. Por ejemplo a partir de la Figura 4.2, para el servicio deno-minado servA_Homogeneo(), utilizando la compilación condicional de Haxe,su implementación es la siguiente:

1 function servA_Homogeneo () {

2 #if amazon

3 servA_HaxeAma ();

4 #elseif android

5 servA_HaxeGoo ();

6 #elseif ios

7 servA_HaxeApp ();

8 #end

9 }

Para la mayoría de los servicios de la API homogénea, el proceso de ho-mogeneización resultó directo. Esto se debió a que cada módulo puente ofrecióel servicio a agrupar. Un ejemplo de este caso, es el método homogéneo en-cargado de inicializar el servicio de juegos del proveedor correspondiente:

1 function initGameService(enableCloudStorage:Bool) {

2 #if amazon

3 GameCircle.init(enableCloudStorage);

4 #if android

5 GooglePlayGames.init(enableCloudStorage);

6 #if ios

7 GameCenter.authenticate ();

8 #end

9 }

El mismo razonamiento se aplicó a los siguientes métodos directamenteagrupables:

Tablas de clasi�cación.

• displayLeaderboard (leaderboardName).

◦ Servicio del módulo puente de Amazon: displayScoreboard.

◦ Servicio del módulo puente de Google: displayScoreboard.

◦ Servicio del módulo puente de Apple: showLeaderboard.

• setScore (leaderboardName, score).

75


◦ Servicio del módulo puente de Amazon: setScore.

◦ Servicio del módulo puente de Google: setScore.

◦ Servicio del módulo puente de Apple: reportScore.

• getPlayerScore (leaderboardName).

◦ Servicio del módulo puente de Amazon: getPlayerScore.

◦ Servicio del módulo puente de Google: getPlayerScore.

◦ Servicio del módulo puente de Apple: getPlayerScore.

Logros.

• displayAchievements ().

◦ Servicio del módulo puente de Amazon: displayAchievements

◦ Servicio del módulo puente de Google: displayAchievements

◦ Servicio del módulo puente de Apple: showAchievements

• getAchievementSteps (achievementName).

◦ Servicio del módulo puente de Amazon: getAchievementPro-gress

◦ Servicio del módulo puente de Google: getAchievementSteps.

◦ Servicio del módulo puente de Apple: getAchievementPro-gress

• getAchievementStatus (achievementName).

◦ Servicio del módulo puente de Amazon: getAchievementSta-tus.

◦ Servicio del módulo puente de Google: getAchievementStatus.

◦ Servicio del módulo puente de Apple: getAchievementStatus.

En el caso de la suscripción para los servicios que retornan datos desdecada implementación nativa, también hubo casos de homogeneización directa:


• setOnGetPlayerScore (func (idScoreboard:String, score:Int)).

◦ Servicio del módulo puente de Amazon: onGetPlayerScore =func.

◦ Servicio del módulo puente de Google: onGetPlayerScore =func.

76


◦ Servicio del módulo puente de Apple: addEventListener (nom-breEvento, func).

Logros.

• setOnGetAchievementStatus (func (idAchievement:String, status:Int)).

◦ Servicio del módulo puente de Amazon: onGetPlayerAchieve-mentStatus = func.

◦ Servicio del módulo puente de Google: onGetPlayerAchieve-mentStatus = func.

◦ Servicio del módulo puente de Apple: addEventListener (nom-breEvento, func).

Sin embargo, para algunos casos que no presentaron tal característicase debió hacer uso de mecanismos que permitieran crear los servicios noprovistos en uno o varios módulos puente.


• displayAllScoreboards (defaultLeaderboard). Este servicio, si bienestablece mostrar todas las tablas de clasi�cación, posee un pará-metro de entrada, que solamente es usado por el servicio �show-Leaderboard� del módulo puente de Apple. Esto se debe a que,este proveedor no ofrece un servicio para mostrar todas las tablasde clasi�cación. Para suplir tal detalle, se le indica al desarrolla-dor del videojuego establecer la tabla de clasi�cación por defectoal momento de querer visualizar todas las tablas.

◦ Servicio del módulo puente de Amazon: displayAllScoreboards().

◦ Servicio del módulo puente de Google: displayAllScoreboards().

◦ Servicio del módulo puente de Apple: showLeaderboard (de-faultLeaderboard).

Logros.

• unlock (achievementName). No todos los proveedores ofrecen ensus librerías tal funcionalidad de manera directa. Los únicos quelo ofrecen son Google y Amazon. Para el caso de Apple se realizóel establecimiento de progreso del 100% para el logro que se deseadesbloquear.

77


◦ Servicio del módulo puente de Amazon: unlock (achievement-Name).

◦ Servicio del módulo puente de Google: unlock (achievement-Name).

◦ Servicio del módulo puente de Apple: reportAchievement (achie-vementName, 100.0).

• reveal (achievementName). La única librería que ofrece el serviciopara revelar un logro determinado es la de Google. Apple, revelaun logro si este consigue un mínimo porcentaje de progreso. Pa-ra este proveedor es posible implementar tal servicio. Amazon encambio, no ofrece forma alguna de revelar un logro. De esta ma-nera, solo para el caso de Amazon, no habrá implementación deeste servicio.

◦ Servicio del módulo puente de Amazon: Ninguno.◦ Servicio del módulo puente de Google: reveal (achievement-Name).

◦ Servicio del módulo puente de Apple: reportAchievement (achie-vementName, 0.0).

• setProgress (achievementName, steps). Para este servicio se tuvoque tener en cuenta las formas de representar el progreso de avancede un logro que establece cada proveedor. Amazon y Apple, utili-zan la noción de porcentaje de avance, cuyo valor va desde el 0%al 100% de completitud. Google utiliza el concepto de cantidadde pasos, cuyos valores van desde 0 hasta un límite que estableceel desarrollador en la consola de desarrollador del proveedor. Pa-ra homogeneizar este servicio, fue necesaria la elección de uno delos dos tipos de representación. Se optó por normalizar el estable-cimiento del progreso de los distintos logros utilizando la nociónde pasos. Esta decisión no afecta al uso de los servicios de Goo-gle para establecer el progreso o incrementarlo. Pero para el casode Amazon y Apple es necesario que el desarrollador establezcaen la lógica del videojuego, el total de pasos de cada uno de loslogros que utilizará. Esto se realiza utilizando el siguiente servicio:

1 Multigames.setAchievementTotalSteps(

nombreLogro , totalPasos)

Internamente se utiliza una estructura de hashing que permitealmacenar, para el identi�cador de cada logro su correspondientetotal de pasos.

78


Para Amazon y Apple, cuando se debe establecer el progreso, seobtiene el total de pasos a partir del identi�cador dado como en-trada y se calcula el porcentaje con la siguiente operación:

1 progress = 100.0 * steps / hash.get(

achievementName)

◦ Servicio del módulo puente de Amazon: setProgress (achieve-mentName, progress).

◦ Servicio del módulo puente de Google: setSteps (achievement-Name, steps).

◦ Servicio del módulo puente de Apple: reportAchievement (achie-vementName, progress).

• increment (achievementName, steps). No todos los proveedoresofrecen en sus librerías tal funcionalidad de manera directa. Elúnico que permite incrementar los pasos de sus logros es Google,mientras que Apple y Amazon no. Para estos dos últimos, se op-tó por implementar tal servicio ya que se cuentan con todas lasherramientas para llevarlo a cabo. Por un lado sabemos que sepermite almacenar el total de pasos de cada logro, y por el otro sepuede obtener la cantidad de pasos de cada uno. Como Amazon yApple almacenan datos porcentuales, es necesario representar talorden de magnitud a pasos. Esto se realiza a partir del total depasos, siendo una operación inversa a la presentada en el servicioanterior:

1 currentSteps = (getAchievementProgress (

achievementName) * hash.get (

achievementName)) / 100

De esta forma, se obtiene el número actual de pasos que poseeun logro dado. A continuación, estos pasos se suman a los pasosa incrementar y posteriormente se realiza el establecimiento delnuevo valor con el servicio homogéneo correspondiente.

1 newSteps = steps + currentSteps

◦ Servicio del módulo puente de Amazon: setProgress (achieve-mentName, newSteps).

79


◦ Servicio del módulo puente de Google: (achievementName,steps).

◦ Servicio del módulo puente de Apple: (achievementName, newS-teps).

Para el dominio de las suscripciones, el único servicio de esta índole quepresentó diferencias fue el siguiente:

Logros.

• setOnGetAchievementSteps (func (idAchievement:String, steps:Int)).La función func posee como segundo argumento un atributo de ti-po entero. Para los casos de suscripción de este servicio en Amazony Apple el segundo argumento es de tipo punto �otante. Entonces,fue necesario suscribir una función (funcFloat) acorde a las nece-sidades de estos dos últimos módulos puente que internamenteobtenga la relación de pasos a partir del porcentaje para, poste-riormente, ejecutar a func enviando esta última representación.

◦ Servicio del módulo puente de Amazon:onGetAchievementProgress= funcFloat

◦ Servicio del módulo puente de Google: onGetPlayerAchieve-mentSteps = func

◦ Servicio del módulo puente de Apple: addEventListener (nom-breEvento, funcFloat)

Luego de homogeneizar los distintos servicios de cada módulo puente, lainterfaz resultante es la que se muestra a continuación:



3


5 public static function discardAndCloseGame ()

6 public static function commitAndCloseGame(data:String)

7 public static function loadSavedGame(name:String)

8


10 public static function displayAllLeaderboards(

defaultLeaderboard:String)

80


11 public static function displayLeaderboard(

leaderboardName:String)

12 public static function setScore(leaderboardName:String

, score:Int)

13 public static function getPlayerScore(leaderboardName:

String)

14

15 // Logros.


17 public static function unlock(achievementName:String)

18 public static function reveal(achievementName:String)

19 public static function increment(achievementName:

String , steps:Int)

20 public static function setProgress(achievementName:

String , steps:Int)


achievementName:String)

22 public static function getAchievementSteps(

achievementName:String)

23

24 //Extra.

25 public static function setAchievementTotalSteps(

achievementName:String , totalSteps:Int)

26

27 // Suscripciones.

28 public static function setOnGetPlayerScore (

onGetPlayerScore: String -> Int -> Void)

29 public static function setOnGetAchievementSteps (

onGetAchSteps: String -> Int -> Void)

30 public static function setOnGetAchievementStatus (

onGetAchStatus: String -> Int -> Void)

Tal y como sucede con cada uno de los módulos puente, la API homogé-nea ofrece dos tipos de servicios. Para cualquiera de los dos tipos, esta APIagrega un nivel más de invocación en el camino recorrido desde el videojue-go a la implementación de cada servicio nativo del proveedor (Figuras 4.4 y4.5). Esto es a costa de eliminar el problema de portabilidad que proponecada módulo puente por separado. Por otro lado se puede apreciar una trans-parencia en la forma de suscripción a eventos que le es totalmente ajena aldesarrollador (Figura 4.5).

81


Figura 4.4: Diagrama de secuencia de servicio sin retorno.

Figura 4.5: Diagrama de secuencia de servicio con retorno.

82

Capítulo 5

Pruebas de campo

La solución fue utilizada por los desarrolladores de videojuegos de lacompañía Sempai Games 1 en los proyectos listados a continuación:

Daktylos.

Puralax.

Techno Pu�er.

The Froggies Game.

(a) Daktylos (b) Puralax (c) Techno Pu�er (d) The FroggiesGame

Figura 5.1: Productos de Sempai Games.

Estas aplicaciones se encuentran en las distintas tiendas, pudiendo serobtenidas por quien lo desee. Esta diversidad se debe a que uno de los ob-jetivos de la compañía consiste en comercializar sus productos en la mayor

1http://www.sempaigames.com/

83


cantidad de tiendas posibles. Por otro lado adicionan a sus creaciones lasmecánicas de juegos que ofrecen los proveedores, siendo este aspecto, el se-gundo objetivo: maximizar el nivel de �enganche� con el público. La compañíaestablece las estrategias para canalizar el nivel de enganche y traducirlo enbene�cios monetarios. Se espera que, abarcando múltiples tiendas con la mis-ma aplicación es esperable que las ganancias sean mayores.

En esta compañía se utiliza el lenguaje Haxe junto con OpenFL paracrear videojuegos. Para poder hacer la inclusión de la API Homogénea esnecesario agregar en el archivo de descripción de proyecto (project.xml) elsiguiente elemento:

1 <haxelib name = extension -multigames />

Al indicarlo en tal lugar, se está en condiciones de incluir la API Homo-génea al código fuente para posteriormente utilizar los servicios que provee:

1 import extension.multigames.Multigames;

A partir de esto, cualquier desarrollador puede realizar invocaciones delestilo Multigames.<servicio>() donde el principal parámetro de entrada, sifuese requerido, se corresponde con el identi�cador de la mecánica de juegosa manipular. Una vez establecidos las sentencias de invocación en el códigofuente, desde la consola o terminal se establece la plataforma para la cualesté dedicada la aplicación y se la genera:

1 openfl test <path_proyecto > android // Aplicacion con

servicios de Google.

2 openfl test <path_proyecto > android -Damazon //

Aplicacion con servicios de Amazon.

3 openfl test <path_proyecto > ios // Aplicacion con

servicios de Apple.

En el momento del desarrollo, el primer paso consiste en iniciar el servi-cio de juegos del proveedor correspondiente a través de la sentencia:

1 Multigames.init();

84

5. Pruebas de campo

En el videojuego Puralax por ejemplo, cuando la aplicación es ejecutadael resultado de tal llamado es mostrado en la Figura 5.2:

(a) Amazon (b) Google (c) Apple

Figura 5.2: Inicializaciones del videojuego Puralax.

Una vez registrado el jugador este puede visualizar todas las tablas declasi�cación y logros del proveedor correspondiente a la plataforma móvil.Esto se realiza con los servicios:

1 Multigames.displayAllLeaderboards ();

2 Multigames.displayAchievements ();

Siendo el resultado esperado el que se presenta en la Figura 5.3 y 5.4).

5.1. Análisis de escenarios

En esta nueva sección se muestra una serie de análisis realizados queayudan a comprender el nivel de impacto que presenta la solución. Paraello, se utilizaron los distintos proyectos realizados por la compañía SempaiGames como modelos de pruebas. El procedimiento para el análisis consistióen generar una comparación de cada aplicación consigo misma en aspectos

85



Figura 5.3: Tablas de clasi�cación del videojuego Puralax.


Figura 5.4: Logros del videojuego Puralax.

como: Tiempo de integración y Líneas de código. Lo que diferenció a unaaplicación con su igual fue:

86

5. Pruebas de campo

A una versión se le integraron los servicios de juegos de los tres provee-dores establecidos en el alcance sin la intervención del módulo homo-géneo. Las aplicaciones de estas características las denominaremos �sinMultigames�.

La segunda versión fue complementada con el módulo homogéneo queagrupa a los mismos tres proveedores. De igual modo que el caso ante-rior, las aplicaciones de este grupo serán clasi�cadas �con Multigames�.

Además de la tarea de integración, se tuvieron en cuenta las tareas queformaron parte del ciclo de desarrollo de cada aplicación: Desarrollo y Testing.A partir de cada una se consideraron las siguientes actividades:

Integración.

• #Días dedicados para incluir cada módulo puente al proyecto.Esta tarea abarca tiempos de desarrollos de nueva funcionalidad,nuevos módulos o simplemente inclusión.

• #Código fuente que adiciona al videojuego el deseo de utilizar lostres servicios de juegos.

◦ Asimismo se tiene en cuenta la cantidad de sentencias utiliza-das para incluir cada módulo al proyecto, este valor, siemprees igual a 2 (directivas <haxelib/> e include).

• #Días de testing utilizados para validar el correcto funcionamientode los servicio de cada módulo puente.

Desarrollo.

• #Días de desarrollo.

• #Código fuente para la creación del videojuego.

Testing.

• #Días de testing utilizados para validar el correcto funcionamientodel videojuego.

El objetivo de este estudio es ver como in�uyó la solución sobre lasdistintas tareas y, transitivamente, determinar como afecta a todo el procesode desarrollo de cada aplicación.

87


Primer Escenario: Sin Multigames

El primer escenario se corresponde con el proceso de integración querealizaba la compañía antes de la existencia de la solución propuesta. Paraeste caso, se deben tener en cuenta las siguientes aclaraciones:

1. A partir de lo establecido en el capítulo de la Descripción del Problemase ve que:

Tanto el módulo puente de Google como el de Apple ya existían.

Asimismo, a partir de la captura de requerimientos, nos encontra-mos que ambos módulos se encuentran incompletos.

2. El único módulo que debe ser creado de cero es el de Amazon con todolo que esta tarea implica (implementación de los servicios en el lenguajenativo e implementación en el lenguaje Haxe).

3. Por último, en el código fuente de cada proyecto se encontrará la mismaimplementación que presenta la API Homogénea. Es decir, se agruparánlos servicios equivalentes de cada módulo puente en un único servicioutilizando la compilación condicional de Haxe.

Si bien en los Puntos 1 y 2 se debe realizar un desarrollo extra en laetapa de integración (creación o completitud de cada módulo), tal actividadsolo se realizará para la primera vez que se deseen usar (es decir, para elprimer videojuego). En cambio, el Punto 3 es aquel que debe repetirse paracada videojuego. Además de esta enumeración, se deben tener en cuentalas sesiones de pruebas a los que debe someterse cada servicio de juegos yeventuales correcciones que deban realizarse en caso que se presenten errores.Estos dos últimos aspectos insumen tiempo extra a la tarea de integración.

En los Cuadros 5.1, 5.2 y 5.3 se presenta resumidamente, para cada unade las aplicaciones, los valores asociados a los aspectos de interés para elestudio.

A partir del Cuadro 5.1 se puede ver que las actividades de los Puntos 1y 2 (completar módulos y crear nuevo módulo respectivamente) fueron pues-tas en práctica en el videojuego Puralax. Esto se encuentra evidenciado porla diferencia en la cantidad de días que demandó tal tarea en comparacióna los otros proyectos. Una vez completados y generados los módulos involu-crados, estos son agregados con menor esfuerzo en los videojuegos restantes

88

5. Pruebas de campo

Tarea: Integración (Amazon, Apple, Google)#Días de #Código fuente #Días deinclusión (Directivas) testing

Puralax 7 230 (+6) 9Daktylos 1.5 230 (+6) 6Pu�er 1 230 (+6) 5Froggies 2 230 (+6) 6

Cuadro 5.1: Tarea de integración - Sin Multigames.

(Daktylos, Pu�er, Froggies) implicando menor inversión de tiempo y desa-rrollo. Nótese que, lo que no varía es la cantidad de código fuente extra encada proyecto necesario para agrupar los tres servicios de juegos.

Tarea: Desarrollo#Días #Código fuente

Puralax 97 ≈ 17000Daktylos 119 ≈ 35000Pu�er 104 ≈ 23000Froggies 132 ≈ 29000

Cuadro 5.2: Tarea de desarrollo - Sin Multigames.

Tarea: Testing#Días

Puralax 18Daktylos 26Pu�er 21Froggies 33

Cuadro 5.3: Tarea de testing - Sin Multigames.

La suma de las magnitudes #Días y #Código fuente entre todas lasactividades para cada uno de los videojuegos se presentan en los Cuadros 5.4y 5.5:

De los dos aspectos se puede apreciar que:

El tiempo total que le demanda a la compañía en generar una nueva

89


#Días Total de Total deIntegración Desarrollo Testing Días Meses

Puralax 16 97 18 131 ≈ 4,3Daktylos 7.5 119 26 152.5 ≈ 5,1Pu�er 6 104 21 131 ≈ 4,3Froggies 8 132 33 173 ≈ 5,7

Cuadro 5.4: Tiempo total - Sin Multigames.

#Código fuente TotalIntegración Desarrollo

Puralax 230 (+6) ≈ 17000 ≈ 17300Daktylos 230 (+6) ≈ 35000 ≈ 35300Pu�er 230 (+6) ≈ 23000 ≈ 23300Froggies 230 (+6) ≈ 29000 ≈ 29300

Cuadro 5.5: Cantidad total de código fuente - Sin Multigames.

aplicación es, en promedio, de 5 meses. El proceso de integración detodos los servicios de juegos conlleva entre una y dos semanas de dichototal.

La cantidad de código fuente generado en el proceso de integraciónes insigni�cante frente a la cantidad de sentencias que conforman a lalógica de cada videojuego.

Segundo Escenario: Con Multigames

Para el segundo caso, se tomó cada aplicación sin servicio de juegos y,posteriormente se le incluyó la API Homogénea creada. En el Cuadro 5.6se presentan, para cada una de las aplicaciones realizadas por la compañía,los nuevos valores asociados a los aspectos de interés a partir del uso de lasolución.

En relación al caso �sin Multigames�, la diferencia más evidente se en-cuentra en el proceso de integración impactando en cada uno de los aspectosque lo conforman:

90

5. Pruebas de campo

Tarea: Integración (Amazon, Apple, Google)#Días de #Código fuente #Días deinclusión (Directivas) testing

Puralax 0.4 0 (+2) 0.7Daktylos 0.5 0 (+2) 0.5Pu�er 0.3 0 (+2) 0.5Froggies 0.4 0 (+2) 0.6

Cuadro 5.6: Tarea de integración - Con Multigames.

Tiempo de inclusión: Al ser fácilmente incluida en cada proyecto, lasolución reduce el tiempo de integración. Este atributo no aumenta deforma proporcional a la cantidad de servicios de juegos que se quie-ran agregar. Al incluirse la API Homogénea, esta posee acoplados losmódulos puentes necesarios (ya sean dos, tres o más).

Cantidad de líneas de código: Como la API Homogénea concentra to-da la lógica para ofrecer los servicios de juegos de los proveedores, eldesarrollador no debe generar código extra que siga el mismo compor-tamiento. Asimismo, para hacer uso de la solución, es necesario utilizarlas dos directivas que permiten incluirla a cada proyecto (include y<haxelib/>).

Testing: Para el caso de este atributo, la API Homogénea se encuentraveri�cada y validada. Los tiempos de pruebas, abarca:

• Recopilar todos los identi�cadores de los recursos.

• Realizar invocaciones de prueba utilizando los identi�cadores contodos los servicios de la API.

• Generar la aplicación para cada plataforma y corroborar si efecti-vamente la integración fue exitosa.

Una vez expuestos los efectos que provoca el uso de la solución, la tareade integración sumado al desarrollo y testing de cada videojuego presenta losvalores plasmados en los Cuadros 5.7 y 5.8.

A partir de los Cuadros 5.7 y 5.8 se puede apreciar lo siguiente: indepen-dientemente del atributo a considerar (#Tiempo o #Código) para las tareasde Desarrollo y Testing, estos no variarán (Cuadros 5.2 y 5.3). Esto se debea que, hacer uso (o no) de la API Homogénea no in�uye sobre dichas tareas.

91


Tiempo (Días) Total TotalIntegración Desarrollo Testing (Días) (Meses)

Puralax 1.1 97 18 116.1 ≈ 3,8Daktylos 1 119 26 146 ≈ 4,8Pu�er 0.8 104 21 125.8 ≈ 4,1Froggies 1 132 33 166 ≈ 5,5

Cuadro 5.7: Tiempo total - Con Multigames.

#Código TotalIntegración Desarrollo

Puralax 0 (+2) ≈ 17000 ≈ 17000Daktylos 0 (+2) ≈ 35000 ≈ 35000Pu�er 0 (+2) ≈ 23000 ≈ 23000Froggies 0 (+2) ≈ 29000 ≈ 29000

Cuadro 5.8: Cantidad total de código fuente - Con Multigames.

Comparación de escenarios

En los Cuadros 5.9 y 5.10 se muestran los resultados obtenidos a partirde la comparación de ambos escenarios.

Tiempo (Días)Sin Multigames Con Multigames Diferencia

Puralax 131 116.1 14.9Daktylos 152.5 146 6.5Pu�er 131 125.8 5.2Froggies 173 166 7

Cuadro 5.9: Diferencia en la cantidad de días entre ambos escenarios.

Poniendo el foco sobre el Cuadro 5.9 se puede apreciar que el proyectoPuralax es el que re�eja las diferencias más evidentes entre ambos escenariosen comparación con los demás videojuegos. Esto es porque, la tarea de desa-rrollo en el proceso de integración para el caso �sin Multigames� se realizauna única vez y luego se reutiliza en los proyectos posteriores.

Como se comentó al inicio de esta sección, la tarea de desarrollo abarca

92

5. Pruebas de campo

#CódigoSin Multigames Con Multigames %Reducción

Puralax ≈ 17300 ≈ 17000 ≈ 1,7Daktylos ≈ 35300 ≈ 35000 ≈ 0,8Pu�er ≈ 23300 ≈ 23000 ≈ 1,2Froggies ≈ 29300 ≈ 29000 ≈ 1,02

Cuadro 5.10: Porcentaje de reducción de código fuente entre ambosescenarios.

lo siguiente:

1. Implementar el módulo puente de Amazon.

2. Completar los módulos puentes de Google y Apple.

3. Generar dentro del código fuente de la aplicación, la interfaz homogéneautilizando la compilación condicional de Haxe.

La primer ventaja que ofrece la API Homogénea es el hecho de que aldesarrollador no le concierne el desarrollo de un nuevo módulo o el agregadode nueva funcionalidad en otros (Puntos 1 y 2). Tal situación se traduce enahorro de tiempos tanto en la tarea de Inclusión como de Testing (Cuadros5.11 y 5.12).

Actividad: Integración (Amazon, Apple, Google)#Días de #Codigo fuente #Días deinclusión (Directivas) testing

Puralax 7 230 (+6) 9

Cuadro 5.11: Integración sobre Puralax - Sin Multigames.

La eventual reducción del tiempo de integración impacta directamentesobre el tiempo total asociado al desarrollo de la aplicación. Esta variaciónse presenta en los Cuadros 5.13 y 5.14.

Para la tarea de integración, el tiempo de desarrollo no solo está deter-minada por las actividades descritas en los Puntos 1 y 2. A este aspecto sele agrega el tiempo que demande generar lo establecido en el ítem número 3,

93


Actividad: Integración (Amazon, Apple, Google)#Días de #Codigo fuente #Días deinclusión (Directivas) testing

Puralax 0.4 0 (+2) 0.7

Cuadro 5.12: Integración sobre Puralax - Con Multigames.


Puralax 16 97 18 131 ≈ 4,3

Cuadro 5.13: Tiempo total Puralax - Sin Multigames.


Puralax 1.1 97 18 116.1 ≈ 3,8

Cuadro 5.14: Tiempo total Puralax - Con Multigames.

que también impacta sobre el segundo atributo de estudio: #Código. Esta esla otra ventaja que ofrece la API Homogénea: contiene en su lógica el códi-go necesario para determinar cual implementación del proveedor incluir a laaplicación �nal, eliminando la tarea de colocar la misma lógica en el códigofuente del videojuego. De esta forma, de tener que desarrollar 236 líneas decódigo fuente para soportar los tres proveedores, solamente se utilizan 2 paraincluir al módulo homogéneo.

Posterior al análisis especí�co sobre el videojuego Puralax y en basea lo plasmado en los Cuadros 5.9 y 5.10 se pueden formular un serie deconclusiones generales para cualquier videojuego que haga uso de la solución:

La ganancia más marcada está en la reducción en el tiempo de inte-gración que ofrece la API Homogénea al desarrollador. Esto se debe aque, al tratarse de un complemento que puede ser incluido fácilmenteen cualquier proyecto y se encuentra veri�cado, desliga al desarrolladora generar código fuente extra e invertir gran cantidad de tiempo enrealizar pruebas de cada servicio de juegos. El uso de la API Homogé-nea provoca que la integración no sea considerada como una actividadextra al ciclo de desarrollo de cada aplicación. En cuestión de horas y

94

5. Pruebas de campo

no días, cualquiera servicio de juegos se encuentra a disposición paraser utilizado en el código fuente de la aplicación.

Por otro lado, si bien no es un aspecto tan signi�cativo como la reduc-ción de tiempo, el módulo acorta la cantidad total de líneas de códigorequeridas para la totalidad del videojuego. Para este caso, el porcen-taje de reducción oscilará de acuerdo a la cantidad total de líneas queconforme cada aplicación (a mayor cantidad de sentencias, el porcentajese vuelve más despreciable).

La mantenibilidad y rehuso de la API Homogénea a partir de su diseñocentralizado ofrece otra ventaja con relación al caso �sin Multigames�.Ante el surgimiento de eventuales modi�caciones, el costo en términosde tiempo y esfuerzo, es menor en el caso �con Multigames� frente alrestante. Así mismo, al realizar los cambios sobre un único lugar, todaslas aplicaciones que lo utilicen se ven afectados. Lo mismo sucede parael caso en que surjan nuevos servicios de juegos, insumiendo menoresfuerzo crear el módulo puente e integrarlo a la API Homogénea queintegrarlo en cada proyecto.

95


96

Capítulo 6

Conclusiones

Se desarrolló e implementó una API que permite utilizar servicios pa-ra videojuegos de diversos proveedores, de forma homogénea y en lenguajeHaxe. Una vez en marcha el producto �nal es posible determinar de formaautomática, a partir de la plataforma objetivo a la que esté orientada la apli-cación, cuál implementación del proveedor utilizar en la aplicación �nal. Deesta manera es posible generar, a partir de un único código fuente, la mismaaplicación con los servicios de juegos otorgados por los distintos proveedoressin perjudicar al lenguaje Haxe.

La utilización de tecnologías de código abierto como Haxe y OpenFLgarantizan la disponibilidad de la solución en términos de licenciamiento ycostos. Un potencial usuario puede disponer del máximo nivel de detalle sobrela implementación. Este aspecto entrega al usuario la libertad de mejorarlao ampliarla para cubrir necesidades más especí�cas con el �n de mantener elproducto funcionando con la aparición de mejoras sobre dichas tecnologías.

Por último, en base a lo que se observó durante las pruebas se obtuvouna idea general del nivel de impacto que se puede esperar de la instalacióny uso de este complemento. Adicionalmente tal herramienta cuenta con ungran potencial de expansión tanto vertical como horizontalmente. De mane-ra vertical signi�ca que es posible incorporar nuevos servicios a cada módulopuente para luego ser agrupados en la API homogénea. Mientras que hori-zontalmente hace referencia a poder generar un módulo puente desde cero apartir de un eventual nuevo proveedor de servicios de juegos para, posterior-mente ser integrada a la API homogénea.

97


98

Capítulo 7

Trabajos futuros

A partir de lo realizado en el presente trabajo �nal, se consideran comoposibles trabajos futuros los siguientes puntos:

Expandir la API homogénea verticalmente, agregando nuevos servicios.Esto implica, si el proveedor lo soporta, incluir cada nuevo servicio encada módulo puente para posteriormente ser agrupados.

Intercambiar el enfoque de suscripción �orientado al servicio� por el desuscripción �orientado a eventos� en caso que se implementen nuevosservicios que retornen datos al desarrollador desde cada módulo puentenuevo y/o existente.

Así mismo, realizar una expansión horizontal, creando nuevos módulospuente para otros proveedores no contemplados en este proyecto. Porúltimo, cada nuevo módulo integrarlo a la API homogénea.

Otorgar la posibilidad de, permutar el servicio de juegos a utilizar des-de el videojuego. Así, cualquier jugador puede plasmar el mismo estadode las mecánicas de juegos en las distintas redes de jugadores. De estamanera, los jugadores no estarán atados a la restricción de tener en supoder los distintos dispositivos móviles conteniendo el mismo videojue-go para mostrar sus avances a las distintas redes.

Agregar el soporte necesario para la persistencia de los datos de unapartida en caso que la aplicación sea utilizada en la plataforma móviliOS. Esta es producto de Apple y tal proveedor no ofrece un servicio

99


de almacenamiento para sincronizar datos entre dispositivos de dichacompañía.

Otorgar la capacidad de permutación entre los servicios de almacena-miento de los distintos proveedores. Por ejemplo, la aplicación utilizael servicio de juegos de Google, pero el servicio de almacenamiento esde Amazon. Este aspecto podría estar ligado a las disponibilidades decada servicio para facilitar la posterior elección.

100

Bibliografía

[9To5Google, 2013] 9To5Google (2013). Google an-nounces new google play games app, available star-ting today. http://9to5google.com/2013/07/24/

google-announces-new-google-play-games-app-available-starting-today/.Accedido: 2016-01-25.

[Adams and Dormans, 2012] Adams, E. and Dormans, J. (2012). Game Me-chanics: Advanced Game Design. New Riders Games.

[Amazon, 2013] Amazon, D. (2013). Get set up for game circle.https://developer.amazon.com/public/apis/engage/gamecircle/

docs/get-set-up-for-gamecircle. Accedido: 2016-01-25.

[AndroidCentral, 2008] AndroidCentral (2008). Android history. www.

androidcentral.com/android-history. Accedido: 2016-01-25.

[AnikiJournal, 2012] AnikiJournal (2012). Amazon announce thegame circle, a new social network for games to take on ap-ple's game center. http://www.anikijournal.com/en/icloud/

2924-amazon-announce-the-game-circle-a-new-social-network-for-games-to-take-on-apple-s-game-center.Accedido: 2016-01-25.

[Apple, 2007] Apple (2007). Apple reinventa el teléfono conel iphone. http://www.apple.com/es/pr/library/2007/01/

09Apple-Reinvents-the-Phone-with-iPhone.html. Accedido: 2016-01-26.

[Apple, 2010a] Apple, D. (2010a). Introduction guide. https://developer.apple.com/library/ios/documentation/LanguagesUtilities/

Conceptual/iTunesConnectGameCenter_Guide/Introduction/

Introduction.html. Accedido: 2016-01-25.

101


[Apple, 2010b] Apple, D. (2010b). Saving a game. https://developer.

apple.com/library/ios/documentation/NetworkingInternet/

Conceptual/GameKit_Guide/SavedGames/SavedGames.html. Acce-dido: 2016-01-25.

[Bartle, 1996] Bartle, R. (1996). Hearts, clubs, diamonds, spades: Playerswho suit muds. Journal of MUD research.

[Catania and Laties, 1999] Catania, C. and Laties, V. (1999). Pavlov andskinner: Two lives in science (an introduction to b. f. skinner's "some res-ponses to the stimulus 'pavlov'"). Journal of the experimental analysis ofbehavior.

[Cedmagic, 2012] Cedmagic (2012). 1971: Computer space - the �rst arca-de video game. http://www.cedmagic.com/history/computer-space.

html. Accedido: 2016-01-26.

[ComputerHistory, 2012] ComputerHistory (2012). Spacewar! http://www.computerhistory.org/pdp-1/spacewar/. Accedido: 2016-01-26.

[Dasnois, 2011] Dasnois, B. (2011). haXe 2 Beginner's Guide. Packt Publis-hing.

[Fernández et al., 2014] Fernández, D. V., Morcillo, C. G., and Talavera,D. F. (2014). Videojuegos Multiplataforma con OpenFL. Edlibrix.

[Gallagher and Park, 2002] Gallagher, S. and Park, S. H. (2002). Innova-tion and competition in standard-based industries: A historical analysisof the u.s. home video game market. IEEE Transactions on EngineeringManagement.

[Gartner, 2015] Gartner (2015). Gartner says smartphone sales surpas-sed one billion units in 2014. http://www.gartner.com/newsroom/id/

2996817. Accedido: 2016-01-25.

[Google, 2013a] Google (2013a). The secrets to app success on google play.https://commondatastorage.googleapis.com/androiddevelopers/

shareables/distribute/play_dev_guide_secrets_en.pdf. Accedido:2016-01-25.

[Google, 2013b] Google, D. (2013b). Achievements. https://developers.

google.com/games/services/common/concepts/achievements. Accedi-do: 2016-01-25.

102

BIBLIOGRAFÍA

[Google, 2013c] Google, D. (2013c). Leaderboards. https://developers.

google.com/games/services/common/concepts/leaderboards. Accedi-do: 2016-01-25.

[Google, 2013d] Google, D. (2013d). Saved games. https://developers.

google.com/games/services/common/concepts/savedgames. Accedido:2016-01-25.

[Haxe, 2005a] Haxe (2005a). Compiler targets. http://haxe.org/

documentation/introduction/compiler-targets.html. Accedido:2016-01-26.

[Haxe, 2005b] Haxe (2005b). General purpose api. http://haxe.

org/documentation/introduction/stdlib-introduction.html#

general-purpose-api. Accedido: 2016-01-26.

[Haxe, 2005c] Haxe (2005c). Haxe language features. http://haxe.

org/documentation/introduction/language-features.html. Accedi-do: 2016-01-26.

[Haxe, 2005d] Haxe (2005d). Introduction to the haxe stan-dard library. http://haxe.org/documentation/introduction/

stdlib-introduction.html. Accedido: 2016-01-26.

[Hipertextual, 2011] Hipertextual (2011). Historia de la tecnología: Nim-rod, un videojuego de 1951. http://hipertextual.com/2011/07/

nimrod-un-videojuego-de-1951. Accedido: 2016-01-26.

[Jansen and Bloemendal, 2013] Jansen, S. and Bloemendal, E. (2013). Soft-ware Business. From Physical Products to Software Services and Solutions,chapter De�ning App Stores: The Role of Curated Marketplaces in Soft-ware Ecosystems. Springer Berlin Heidelberg.

[Joorabchi et al., 2013] Joorabchi, M. E., Mesbah, A., and Kruchten, P.(2013). Real challenges in mobile app development. Empirical SoftwareEngineering and Measurement, 2013 ACM / IEEE International Sympo-sium on.

[Lowood, 2009] Lowood, H. (2009). Videogames in computer space: Thecomplex history of pong. IEEE Annals of the History of Computing.

[Nielsen, 2015a] Nielsen (2015a). So many apps, so much more time forentertainment. http://www.nielsen.com/us/en/insights/news/2015/

so-many-apps-so-much-more-time-for-entertainment.html. Accedi-do: 2016-01-25.

103


[Nielsen, 2015b] Nielsen (2015b). Tops of 2015: Digital. http://www.

nielsen.com/us/en/insights/news/2015/tops-of-2015-digital.

html. Accedido: 2016-01-25.

[Perry and Wallich, 1983] Perry, T. E. and Wallich, P. (1983). Design casehistory: the atari video computer system. IEEE Spectrum.

[Phonearena, 2014] Phonearena (2014). This was the world's �rstcell phone with a game loaded on it. www.phonearena.com/news/

This-was-the-worlds-first-cell-phone-with-a-game-loaded-on-it_

id62920. Accedido: 2016-01-26.

[Pixfans, 2010] Pixfans (2010). Game & watch: Las`maquinitas' de nintendo. http://www.pixfans.com/

game-watch-las-maquinitas-de-nintendo/. Accedido: 2016-01-26.

[Pocketgamer, 2008a] Pocketgamer (2008a). A briefhistory of mobile games: 2000 - a brave newworld. http://www.pocketgamer.biz/feature/10626/

a-brief-history-of-mobile-games-2000-a-brave-new-world/.Accedido: 2016-01-26.

[Pocketgamer, 2008b] Pocketgamer (2008b). A brief history of mobile games:2001 - a mobile odyssey. http://www.pocketgamer.biz/feature/10691/a-brief-history-of-mobile-games-2001-a-mobile-odyssey/. Acce-dido: 2016-01-26.

[Pocketgamer, 2008c] Pocketgamer (2008c). A brief his-tory of mobile games: 2002 - wake up and smell theco�ee. http://www.pocketgamer.biz/feature/10705/

a-brief-history-of-mobile-games-2002-wake-up-and-smell-the-coffee/.Accedido: 2016-01-26.

[Pocketgamer, 2008d] Pocketgamer (2008d). A brief historyof mobile games: 2003 - the future's bright, the futu-re's colour. http://www.pocketgamer.biz/feature/10707/

a-brief-history-of-mobile-games-2003-the-futures-bright-the-futures-colour/.Accedido: 2016-01-26.

[Pocketgamer, 2008e] Pocketgamer (2008e). A brief his-tory of mobile games: 2004 - money for not-hing? http://www.pocketgamer.biz/feature/10710/

a-brief-history-of-mobile-games-2004-money-for-nothing/.Accedido: 2016-01-26.

104

BIBLIOGRAFÍA

[Pocketgamer, 2008f] Pocketgamer (2008f). A briefhistory of mobile games: 2005 - making a bigsplash. http://www.pocketgamer.biz/feature/10712/

a-brief-history-of-mobile-games-2005-making-a-big-splash/.Accedido: 2016-01-26.

[Pocketgamer, 2008g] Pocketgamer (2008g). A brief history of mobile games:2006 - squaring the 3d circle. www.pocketgamer.biz/feature/10719/

a-brief-history-of-mobile-games-2006-squaring-the-3d-circle/.Accedido: 2016-01-26.

[Pocketgamer, 2008h] Pocketgamer (2008h). A brief his-tory of mobile games: In the beginning, there wassnake. http://www.pocketgamer.biz/feature/10619/

a-brief-history-of-mobile-games-in-the-beginning-there-was-snake/.Accedido: 2016-01-26.

[PongStory, 2011a] PongStory (2011a). Arcade pong. http://www.

pong-story.com/arcade.htm. Accedido: 2016-01-26.

[PongStory, 2011b] PongStory (2011b). Noughts and crosses - the oldestgraphical computer game. http://www.pong-story.com/1952.htm. Ac-cedido: 2016-01-26.

[PongStory, 2011c] PongStory (2011c). Tennis for two the story of an earlycomputer game by john anderson. http://www.pong-story.com/1958.

htm. Accedido: 2016-01-26.

[Ponticelli and McColl-Sylvester, 2008] Ponticelli, F. and McColl-Sylvester,L. (2008). Professional haXe and Neko. Wiley Publishing, Inc.

[Retromaquinitas, 2013] Retromaquinitas (2013). Magnavox odys-sey. http://www.retromaquinitas.com/index.php/consolas/

primera-generacion/odyssey. Accedido: 2016-01-26.

[Sergio Gálvez Rojas, 2003] Sergio Gálvez Rojas, L. O. D. (2003). Java atope: J2ME (Java 2 Micro Edition). Universidad de Málaga.

[SourceAndroid, 2008] SourceAndroid (2008). Android open source project.https://source.android.com/. Accedido: 2016-01-25.

[Tapdaq, 2015] Tapdaq (2015). Mobile games: Why social featu-res are key to success. http://blog.tapdaq.com/app-marketing/

mobile-games-social-features-key-success/. Accedido: 2016-01-25.

105


[Techcrunch, 2008] Techcrunch (2008). Tap tap reven-ge approaches 1 million users, music industry ta-kes notice. http://techcrunch.com/2008/07/31/

tap-tap-revenge-approaches-1-million-users-music-industry-takes-notice/.Accedido: 2016-01-25.

[Techtarget, 2014] Techtarget (2014). The develop-ment challenges, enterprise uses of social mobile ga-mes. http://searchsoa.techtarget.com/feature/

The-development-challenges-enterprise-uses-of-social-mobile-games.Accedido: 2016-01-25.

[Wikipedia, 2013] Wikipedia (2013). Golden age of arcade videogames. https://en.wikipedia.org/wiki/Golden_age_of_arcade_

video_games. Accedido: 2016-01-26.

[Wired, 2012] Wired (2012). How to get rich simulating the deaths of bi-llions of people. http://www.wired.com/2012/12/plague-inc/. Accedi-do: 2016-01-25.

[Zichermann and Cunningham, 2011] Zichermann, G. and Cunningham, C.(2011). Gami�cation by Design Implementing Game Mechanics in Weband Mobile Apps. O'Reilly Media, Inc.

106

Librería multiplataforma para videojuegos en dispositivos ...

Documents

Transcript of Librería multiplataforma para videojuegos en dispositivos ...