desarrollo de un juego html5 multijugadoroa.upm.es/43127/4/tfm_robin_giles_ribera.pdf ·...

Escuela Tecnica Superior de Ingenierıa de Sistemas

Informaticos

Universidad Politecnica de Madrid

Desarrollo de un juego HTML5multijugador

por Robin Giles Ribera

tutor Luis Fernando de Mingo Lopez

Presentado en cumplimiento de los requisitos para el grado de

Master Universitario en Ingenierıa Web

Proyecto �n de master

Julio 2015

ii

Proyecto �n de master

iii

Este documento se publica bajo la licencia Creative Commons

Reconocimiento-Compartir bajo la misma licencia 3.0 Espana

h�p://creativecommons.org/licenses/by-sa/3.0/es/

Copyright © 2015 Robin Giles Ribera

iv

A mis padres,les dedico todo mi esfuerzo,

gracias por todo el sacri�cio puesto para que pueda estudiar.

Resumen

Este proyecto presenta un videojuego con una interfaz muy intuitiva y jugabilidad

muy sencilla. El objetivo principal es el recreativo, esto es, el de entretener a los usuar-

ios. Hemos decidido optar por tecnologıas bastante populares para poder cumplir

nuestro objetivo. Para satisfacer el hecho de ser entretenido, se permitio a los usuarios

poder jugar el juego en lınea, al que nos referimos como el modo multijugador.

Otro de los objetivos alcanzados con este proyecto fue el de profundizar en los

fundamentos del desarrollo de juegos y el de conocer la estructura basica de un mo-

tor de juego. En concreto, nos hemos centrado en conocer los pilares basicos de la

programacion de juegos en HTML5.

v

Contenidos

Resumen v

Lista de Figuras ix

Lista de Abreviaturas xi

Agradecimientos xiii

Chapter 1 Introduccion 11.1 Cocos2d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Chipmunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Perspectivas de los juego 2D . . . . . . . . . . . . . . . . . . . . . 2

1.4 Asteroids (de Atari) . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2 Objetivo 72.1 Planteamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 3 Aspectos del desarrollo 93.1 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 XMLH�pRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 WebSockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5 Socket.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.6 Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.7 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.8 Heroku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.9 Otros Aspectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.10 Disponibilidad del Proyecto . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 4 Descripcion informatica 134.1 Conceptos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 La arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 La logica del juego (requisito 6) . . . . . . . . . . . . . . . . . . . 17

4.3.1 La tortuga . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3.2 Los enemigos: Buggers . . . . . . . . . . . . . . . . . . . . 20

4.3.3 Los proyectiles (Requisito 7 y 8) . . . . . . . . . . . . . . . 23

4.3.4 Las explosiones . . . . . . . . . . . . . . . . . . . . . . . . 24

4.4 Las colisiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

vii

viii CONTENIDOS

4.5 Los niveles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.6 El modo multijugador . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.6.1 Sincronizacion de los enemigos . . . . . . . . . . . . . . . 28

4.6.2 Sincronizacion de los jugadores . . . . . . . . . . . . . . . 31

4.6.3 Mensages con Socket.io . . . . . . . . . . . . . . . . . . . 32

Chapter 5 Conclusiones 355.1 Lıneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Anexo A Detalles para con�gurar el juego 39A.0.1 Install Chromebrew (along with Ruby and Git) . . . . . . 39

A.0.2 Instalar Node.js . . . . . . . . . . . . . . . . . . . . . . . . 39

A.0.3 Instalar socket.io . . . . . . . . . . . . . . . . . . . . . . . 39

A.0.4 Descargar el proyecto . . . . . . . . . . . . . . . . . . . . 40

A.0.5 Iniciar el juego en el servidor . . . . . . . . . . . . . . . . 40

Lista de Figuras

1.1 Example of a �gure. . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Perspectiva isometrica . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Perspectiva planimetrica . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Perspectiva ¾ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Top-Down View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.6 Captura del juego Asteroids de Atari . . . . . . . . . . . . . . . . 5

4.1 Conceptos referenciados con frecuencia en este proyecto. . . . . . 13

4.2 Arquitectura del codigo fuente . . . . . . . . . . . . . . . . . . . . 14

4.3 Arquitectura del orden de las clases JavaScripts . . . . . . . . . . 15

4.4 Flujo de las capturas de pantallas del juego . . . . . . . . . . . . . 16

4.5 Flujo de las capturas de pantallas del juego en modo multijugador 17

4.6 Sprite sheets animado de la imagen del jugador . . . . . . . . . . 19

4.7 Las teclas que controlan en movimiento del jugador . . . . . . . . 19

4.8 Rotacion del jugador . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.9 Avance del jugador . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.10 El jugador lanza un proyectil . . . . . . . . . . . . . . . . . . . . . 20

4.11 Enemigo con movimiento aleatorio . . . . . . . . . . . . . . . . . 21

4.12 Enemigo con movimiento de persecucion . . . . . . . . . . . . . . 22

4.13 Enemigo con movimiento de ataque . . . . . . . . . . . . . . . . . 23

4.14 Proyectiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.15 Las explosiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.16 El Sprite Sheet animado de las explosiones . . . . . . . . . . . . . 25

4.17 Las colisiones: sin chipmunk vs chipmunk . . . . . . . . . . . . . 26

4.18 Sincronizacion de los enemigos por tramos . . . . . . . . . . . . . 29

4.19 Arquitectura de las clases de JavaScript en el servidor . . . . . . . 30

ix

x LISTA DE FIGURAS

4.20 Actualizacion y calculo de las posiciones de los enemigos . . . . . 31

4.21 La conexion del usuario con el servidor . . . . . . . . . . . . . . . 32

4.22 La conexion del usuario con el servidor: nuevo jugador . . . . . . 33

4.23 Bucle principal de sincronizacion del servidor . . . . . . . . . . . 33

Lista de Abreviaturas

HTTP Hypertext Transfer Protocol (protocolo de transferencia de hipertexto).

URL Uniform Resource Locator (Localizador uniforme de recursos).

JSON JavaScript Object Notation (Notacion de Objetos de Javascript).

XML eXtensible Markup Language (lenguaje de marcas extensible).

AJAX Asynchronous Javascript And XML (Javascript Asıncrono y XML).

XHR XMLH�pRequest.

HTML HyperText Markup Language (lenguaje de marcas de hipertexto).

RAD Rapid Application Development (Desarrollo rapido de aplicaciones).

API Application Programming Interface.

xi

Agradecimientos

En primer lugar, agradecer a mis padres, sin su esfuerzo y colaboracion esto no hu-

biese sido posible. Mi familia desde el otro lado del charco, por el animo y la alegrıa

que me muestran dandome la energıa necesaria para seguir adelante.

Agradecer tambien a los companeros del trabajo, por los momentos de risa que

pasamos.

Tambien agradecer a mis companeros de piso, Youssef y Dani, gracias por la

amistad y por estar ahı en los momento de estres. Por ultimo agradecer tambien a

profesores, companeros y amigos de la Universidad y todos los que me permitieron

llegar hasta aquı.

Robin Giles Ribera

Universidad Politecnica de Madrid

Julio 2015

xiii

CAPITULO 1

Introduccion

El proyecto esta enfocado en profundizar en el desarrollo de un juego sencillo para

la web en HTML5. En este capıtulo hablaremos sobre el motor de fısica que hemos

usado, Cocos2d, Tambien conoceremos la librerıa de fısica chipmunk de cocos2d y

por ultimo hablaremos sobre las perspectivas de los juegos en 2d.

1.1 Cocos2d

Cocos2D es un framework utilizado para construir juegos en 2D, demos y otras ap-

licaciones gra�cas/interactivas. Es una librerıa OpenSource que permite crear juegos

multiplataformas. Uno programa el juego en un lenguaje, por ejemplo en JavaScripts,

y cocos2d permite exportar a Android, iOS, etc. La �losofıa de los creadores de esta

librerıa se basa en que los desarrolladores dejen de preocuparse por la parte compleja

del back-end para centrarse en el desarrollo del juego en sı, ahorrando tiempo y

dinero.

Figure 1.1: Example of a figure.

Existen dos versiones bien diferenciadas de cocos2d, la version escrita en C++,

con el nombre de cocos2d-x, y la version HTML5, con JavaScript, con el nombre de

1

2 CHAPTER 1. INTRODUCCION

cocos2d-js. Pese a la popularidad de cocos2d-x, esta librerıa carece de accesibilidad

en los navegadores. Estamos en una era en la que los juegos HTML5 se estan con-

virtiendo cada vez mas importante en la industria de los videojuegos, especialmente

en las plataformas moviles. Es por ello, que la version de cocos2d en version HTML5

viene a suplir esta carencia, ya que se trata de un motor de juego 100% HTML5, el

cual esta basado en el Canvas/WEBGL.

Ademas, la version de JavaScript, se supone que ofrece la misma funcionalidad que

la version en C++. Es por ello que esta version es la ideal, incluso si se quiere ejecutar

tambien para plataformas como Android e iOS.

Dado que nosotros estamos interesados en desarrollar juegos casuales para la web,

solo nos hace falta la version de Cocos2d-js Lite, mucho mas ligeras.

Entre las principales caracterısticas generales del framework se encuentran las

siguientes:

• Facil manejo del control del �ujo entre diferentes escenas.

• Manejo e�ciente de sprites.

• Transiciones elegantes (con estilo) entre escenas

• Interprete Python incluido (no incluido en la version Lite)

• Tambien incluye otros productos: como Cocos Studio, Cocos IDE, and Cocos

Shop que permiten ahorrar tiempo y dinero.

1.2 Chipmunk

Se trata de una librerıa de fısica escrita principalmente en C (tambien existe en JavaS-

cript), forma parte de cocos2d como una extension. Esta librerıa permite que los

objetos se comporten como objetos de la vida real, ya que pueden verse afectados

por la gravedad, pueden colisionar con otros objetos, pueden rebotar, etc.

Todo empieza en el espacio de chipmunk, para tener los objetos fısicos que ofrece,

debemos anadir nuestros objetos a este espacio, ademas de indicarles la fuerza de

gravedad, friccion, masa, velocidad, entre otras, para simular la fısica de los objetos

de manera aproximada a la fısica que presentarıa ese objeto en el mundo real. Prin-

cipalmente se usa para detectar colisiones.

1.3 Perspectivas de los juego 2D

El problemas de las perspectivas en juegos 2D es muy frecuente (1).

1.3 Perspectivas de los juego 2D 3

La perspectiva mas simple es la Axonometrica. En esta representacion del espacio,

un objeto es representado con tres coordenadas (X, Y y Z). Existen un in�nito numero

de perspectivas axonometricas, debido a que los disenadores pueden colocar los tres

ejes en la direccion que deseen.

Por ejemplo, en la �gura podemos apreciar la perspectiva isometrica, en la cual el

eje Y deberıa formar 30º con la horizontal.

Figure 1.2: Perspectiva isometrica

En esta otra �gura vemos la perspectiva planimetrica. Esta vez, el eje Y forma 45º

con la horizontal.

Figure 1.3: Perspectiva planimetrica

Luego tenemos la famosa perspectiva ¾, en donde el eje Y se confunde con el eje

Z.


Figure 1.4: Perspectiva ¾

Perspectiva Top-Down

Figure 1.5: Top-Down View

Tambien se re�ere a veces como vista de pajaro (bird’s-eye view), Overworld , vista

aerea o la vista del helicoptero, cuando se usa en los videojuegos se re�ere a un angulo

de camara que muestra el jugador y el area alrededor de ellos desde arriba (�gura 1.5).

Esta es la perspectiva que hemos usado.

1.4 Asteroids (de Atari) 5

1.4 Asteroids (de Atari)

Figure 1.6: Captura del juego Asteroids de Atari

Asteroids es un juego minimalista de arcade, del genero tiros, creado en 1979 por

Atari, Inc. El jugador controla una nave espacial, durante el juego, asteroides y

platillos voladores van apareciendo por la pantalla, el objetivo es el de disparar y

destruir estos objetos, con la precaucion de no colisionar con ellos. El punto de vista

del juego es en dos dimensiones, los asteroides se mueven en diversas direcciones

de la pantalla, por ejemplo, los asteroides que se van fuera de la pantalla por el

borde superior, aparecen por la parte inferior moviendose en la misma direccion. Los

platillos voladores aparecen periodicamente por la pantalla y ademas disparan a la

nave del jugador. El jugador empieza con 3 vidas y gana una vida extra por cada

10,000 puntos. El juego aumenta de di�cultad aumentando el numero de asteroides.

Si el jugador pierde todas sus vidas, el juego termina.

1.5 Estructura de la memoria

El presente trabajo se divide en 4 capıtulos:


En el Capıtulo 1, “Introduccion”, como ya pudimos apreciar, detallamos principal-

mente el motor de juegos que usamos en este proyecto, ademas explizamos algunas

de las perpectivas que existen en el mundo de los juegos 2d, y hablamos del juego

Asteroid de Atari, que tiene ciertas similitudes con este proyecto.

En el capıtulo 2, describimos el planteamiento y el objetivo del proyecto, ademas

de los requisitos necesarios para la consecucion del mismo.

En el capıtulo 3, explicamos las principales tecnologıas y herramientas utilizadas

en el proyecto y se muestra como acceder al codigo de la aplicacion.

En el capıtulo 4, describimos y explicamos toda la implementacion desarrollada del

proyecto.

En el capıtulo 5, extraemos las conclusiones respecto a los requisitos cumplidos y

se propone trabajos futuros sobre este proyecto.

CAPITULO 2

Objetivo

En este capıtulo describiremos el planteamiento principal del proyecto, ademas pas-

aremos a enumerar los requisitos que debemos cumplir para la consecucion de los

objetivos del mismo.

2.1 Planteamiento

El proyecto esta enfocado en implementar un juego sencillo para navegadores web,

en HTML5 en especial, principalmente por la caracterıstica multiplataforma de esta

tecnologıa. Ası que uno de nuestros primeros pasos es el de de�nir las reglas del

juego a desarrollar. Esto nos llevara a conocer la arquitectura basica de los juegos.

Para desarrollarlo, nos apoyamos en el motor de fısica Cocos2d, en su version de

JavaScript.

Como segundo objetivo, tenemo la mision de conseguir que nuestro juego sea

multijugador, esto es, que los jugadores jueguen en lınea al mismo tiempo a traves de

la red. Para ello debemos de estudiar las tecnologıas disponibles que nos facilitaran

dicha tarea. Tanto una tecnologıa de servidor y una de comunicacion para sincronizar

a los diversos usuarios.

2.2 Requisitos

A raız del planteamiento anterior podemos desglosar los principales requisitos en los

siguientes puntos:

1. Disponer de un menu principal que nos permita navegar por los escenarios del

juego.

2. Poder iniciar el escenario del juego desde el menu principal.

3. Poder iniciar el escenario del juego desde el menu en modo multijugador.

7

8 CHAPTER 2. OBJETIVO

4. Tener siempre la posibilidad de volver al menu principal, es decir implementar

un boton que siempre se encuentre visible, el cual nos lleva al menu principal.

5. Visualizar las puntuaciones maximas obtenidas.

6. De�nir las reglas y logica del juego a desarrollar.

7. El usuario puede disparar a enemigos.

8. Los enemigos pueden tambien disparar al jugador.

9. Finalizar la partida en modo unico jugador.

10. Finalizar la partida en modo multijugador.

CAPITULO 3

Aspectos del desarrollo

A continuacion describiremos la principales tecnologıas que hemos utilizado en el

proyecto. Indicaremos la disponibilidad del proyecto, en cuanto al codigo fuente y

la aplicacion en funcionamiento, a la vez que mencionaremos alguno aspectos del

desarrollo.

3.1 Javascript

Javascript: Es un lenguaje de programacion orientado a los navegadores, porque

fue ahı donde se origino y donde goza de la mayor popularidad.La mayorıa de los

lenguajes de programacion que hacen uso de la web, hacem uso de JavaScript. AL

ser de distribucion gratuita y multiplataforma, tambien se esta usando para crear

aplicaciones y para el uso en servidores.

3.2 Node.js

Node.js (a partir de ahora Node) es un programa de servidor basado en el motor

JavaScript V8 (es el motor ultrarapido escrito en C++ que usa Google Chrome). Gra-

cias a JavaScript, Node utiliza lo que se llama programacion orientada a eventos,

permite escribir codigo que es potencialmente no bloqueante. Es decir, que Node

esta disenado para situaciones en que se espere una gran cantidad de tra�co y donde

la logica del lado del servidor y procesamiento requeridos no sean necesariamente

grandes antes de responder al cliente. Node tiene una gran comunidad muy activa y

en constante crecimiento, goza de muy buena popularidad y existen un un centenar de

modulos que extienden su funcionalidad (desde plantillas, APIs, conexiones seguras,

bases de datos, gestores de contenido, etc.). Adicionalmente tenemos el Node Package

Module (NPM), una forma integrada de instalar y administrar los modulos de Node,

asegurando que cualquier modulo se instale correctamente.

9

10 CHAPTER 3. ASPECTOS DEL DESARROLLO

3.3 XMLH�pRequest

Actualmente las aplicaciones web son muy dinamicas, permiten actualizar parte de

las paginas, sin que el mismo usuario tenga que refrescar la pagina, es lo que se

llama como el metodo Ajax (Asynchronous Javascript And Xml). XMLH�pRequest

(XHR) es el corazon de Ajax, es una interfaz empleada para realizar peticiones HTTP

y HTTPS a servidores Web. La interfaz se implementa como una objeto JavaScript en

el cliente, del cual se puede generar tantas instancias como se necesite para manejar

el dialogo con el servidor. La informacion intercambiada entre el cliente y el servidor

puede estar en multiples formatos, ademas de XML, texto, HTML y JSON. Principal-

mente se usa para proporcionar contenido dinamico y actualizaciones asıncronas en

aplicaciones web.

3.4 WebSockets

Es una de las caracterısticas de HTML5. El protocolo HTTP fue concebido desde sus

orıgenes para ofrecer comunicaciones en un solo sentido, desde el servidor hacia el

cliente. Sin embargo las aplicaciones web de hoy en dıa demandan mas que eso para

poder ofrecer una experiencia de usuario mas rica, necesitan �ujo de informacion en

ambos sentidos. Los WebSockets permiten crear un canal de comunicacion que es

bi-direccional, economizando recursos y reduciendo latencias. Esta disenada para ser

implementada en navegadores y servidores web, pero puede utilizarse por cualquier

aplicacion cliente/servidor.

3.5 Socket.io

Se trata de una librerıa para comunicacion web en tiempo real. Es una librerıa escrita

en JavaScript principalmente para Node.js, la cual permite una comunicacion bidirec-

cional entre cliente y servidor. Para ello se basa principalmente en Websockets, pero

tambien puede usar otras alternativas como sockets de Adobe Flash, JSONP polling

o long polling en AJAX. En el polling el cliente se mantiene haciendo preguntas al

servidor sobre un determinado evento.

3.6 Canvas

El canvas es un elemento de HTML5 que permite manipular los pixeles en un area en

particular, permite dibujar formas, imagenes, vıdeos y animaciones.

3.7 Git 11

3.7 Git

Es un so�ware de control de versiones creado originalmente por Linus Torvalds,

disenado para manejar proyectos muy grandes con velocidad y e�ciencia, pero igual

de apropiado para repositorios pequenos. GitHub es una de las razon de la popular-

idad de Git, es un excelente servicio de alojamiento de repositorios de so�ware que

utiliza Git para el mantenimiento y versionado del codigo fuente, anadiendo una serie

de servicios extras para la gestion del proyecto y el codigo fuente.

3.8 Heroku

Es un servicio PaaS (Platform as a Service), una plataforma como servicio de com-

putacion en la Nube, en principio solo soportaba el lenguaje de programacion Ruby,

pero posteriormente se ha extendido el soporte a Java, Node.js, Scala, Clojure y Py-

thon. La base del sistema operativo es Debian y el despliegue de la aplicacion se hace a

traves de Git. Su �losofıa es la de que el programador emplee su tiempo desarrollando

la aplicacion y no con�gurando servidores o preocupandose del despliegue.

3.9 Otros Aspectos

Estas son las principales tecnologıas que hemos usado en nuestro proyecto. Para

empezar, JavaScript es el lenguaje, el unico que hemos usado, en el que esta escrito

practicamente todo el codigo fuente del proyecto.

Hemos usado el control de versiones pese a que se ha trabajado en solitario, Git es

una herramienta que permite disponer de copias de seguridad del proyecto, tener la

capacidad de volver hacia atras, son caracterısticas muy utiles durante el desarrollo

del so�ware. Otro motivo para el uso de Git, es que este es necesario para usar con

Heroku. Heroku es el el servidor en la nube donde hemos alojado nuestra aplicacion.

Para ello hemos usado Node.js como servidor (2). Hemos tenido un problema con

socket.io en Heroku, en lugar de usar websockets, heroku utiliza comunicaciones por

XMLH�pRequest, no sabemos el por que de esto, pese a ello, el juego no se ve afectado.

3.10 Disponibilidad del Proyecto

Hemos clonado el proyecto de cocos2d-js1, el cual se encuentra en Github. Nosotros

tambien hemos alojado el codigo fuente allı. Por otra parte, tambien tenemos la

aplicacion en funcionamiento alojada en Heroku.

1h�ps://github.com/cocos2d/cocos2d-js

12 CHAPTER 3. ASPECTOS DEL DESARROLLO

# Source code

h�ps://github.com/robinparadise/turtle vs buggers

# Aplicacion

turtle-vs-buggers.herokuapp.com

CAPITULO 4

Descripcion informatica

En este capıtulo detallaremos todas las caracterısticas implementadas, entre ellas,

todas las que daran solucion a nuestros objetivos y requisitos, explicando las tareas

que fueron necesarias para implementarlas. Durante el desarrollo podemos diferen-

ciar dos partes. Por un lado tenemos el desarrollo del juego (modo unico jugador),

y por otro el desarrollo del juego en modo multijugador. A pesar que durante el

desarrollo hubo etapas en las que las dos partes fueron desarrolladas paralelamente

(unico jugador y multiples jugadores), en el capıtulo explicaremos en la medida de lo

posible, primero las caracterısticas relacionadas con el modo unico jugador y luego

las caracterısticas del modo multijugador.

4.1 Conceptos previos

Figure 4.1: Conceptos referenciados con frecuencia en este proyecto.

13

14 CHAPTER 4. DESCRIPCION INFORMATICA

Antes de pasar a la descripcion, debemos de explicar conceptos que usaremos con

mucha frecuencia y que son imprescindibles para el correcto seguimiento de lo que

describiremos en este capıtulo.

Usaremos con mucha frecuencia nombres y sinonimos de los objetos que nos en-

contramos en el juego. Por ejemplo, como se puede apreciar en la �gura 4.1, a la

tortuga nos referiremos con el nombre de jugador, es por supuesto, el objeto contro-

lado por el usuario. A los insectos los llamaremos principalmente enemigos, aunque

tambien nos referiremos a ellos con el nombre de monstruos (ası los llamamos en

el codigo fuente) o con el nombre de buggers (en relacion al nombre del juego y

los nombres de las imagenes que representan a estos objetos). Luego tenemos los

proyectiles, tambien nos referimos a ellos cuando los enemigos o el jugador realizan

un ataque, es decir, lanzar un proyectil es sinonimo de realizar un ataque. Por ultimo,

debido a la forma en que se llama en cocos2d, a todos estos objetos tambien nos

referiremos por el nombre sprite, cuando nos referimos principalmente a la imagen

que representan. Las imagenes de los sprites estan sacados de openClipArt [6]

4.2 La arquitectura

Figure 4.2: Arquitectura del codigo fuente

4.2 La arquitectura 15

En la �gura 4.2 podemos apreciar la arquitectura del codigo fuente. Empezando

por el archivo html principal (index.html), en el cual se encuentra de�nido el canvas(una de las caracterısticas de HTML5 que ya explicamos anteriormente) y tambien

se indican los archivos JavaScripts a descargar. En estos archivos, se empieza por

los archivos relacionados con el engine de Cocos2d, luego tenemos el archivo de

con�guracion ( con�g.js) en el cual se de�nen aspectos relacionados con el juego,

tales como los niveles que tiene el juego, los jugadores, el numero de enemigos, la

velocidad, la salud, etc. Luego tenemos las capas y escenas del juego (llamado “scene”

y “layer”). La principal escena es la de game.js, en la cual transcurre el juego, luego

tenemos la escena del menu principal (sysMenu.js), y el resto en las que, por lo general,

se muestran mensajes de texto, como la de gameOver.js, about.js, highscores.js, etc.

Otros archivos javascript importantes son los sprites, que son los objetos visuales que

aparecen en el juego, como el jugador (playerSprite.js), los enemigos (monsterSprite.js),

las explosiones (explosion.js) y los proyectiles (projectileSprite.js). Luego tenemos las

clases de los movimientos, encargados de los movimientos de los enemigos. Por

ultimo, tenemos el resto de clases, como la de levelManager.js, encargada de los niveles

del juego; la clase scoreLabel.js, encargada de la puntuacion del juego; y por ultimo

la clase multiplayer.js, encargada de comunicarse con el servidor apoyandose en la

librerıa socket.io.

Figure 4.3: Arquitectura del orden de las clases JavaScripts

En la �gura 4.3 podemos apreciar la arquitectura en relacion al orden y lugar

donde se usan las clases. Empezando por la escena del menu (la cual cumple nuestro


requisito 1), en este escenario se puede iniciar el escenario de juego (game, requisito

2), el escenario de las puntuaciones (highscore, requisito 5) o el escenario about. El

escenario del juego hace uso de las siguientes clases: la clase multijugador, en caso de

que se haya seleccionado esta opcion desde el menu principal (requisito 3); se hace uso

del scoreLabel, para mostrar la puntuacion del usuario; tambien hace uso de la clase

levelManager, la cual se encarga de anadir el sprite del jugador y los sprites de los

enemigos en el escenario del juego. Cuando el escenario del juego termina (requisito

9), pueden ocurrir dos escenarios: se muestra el escenario de message, indicando el

siguiente nivel o se muestra el escenario gameOver, indicando el �nal del juego.

Figure 4.4: Flujo de las capturas de pantallas del juego

En la �gura 4.4 podemos observar el �ujo de los distintos escenarios del juego.

Siempre se muestra el menu principal en el inicio, en este, el usuario del juego elige

entre inicar el escenario del juego (ya sea modo unico o multijugador), entre iniciar

el escenario de las puntuaciones o iniciar el escenario del about (acerca del juego).

En estos tres escenarios, tenemos la posibilidad de volver al menu principal desde

un boton en la esquina superior derecha (requisito 4). Desde el escenario del juego,

podemos mostrar el escenario message o el escenario gameOver, estos se muestran

durante un espacio de tiempo su�ciente para que el usuario pueda leer el mensaje que

se le muestra. El escenario message muestra la informacion acerca del siguiente nivel,

es por ello que volvemos a iniciar de nuevo el juego despues que se haya mostrado.

En cambio, cuando mostramos el escenario de gameOver, volvemos al menu principal,

dado que el juego ha acabado (requisito 10).

4.3 La logica del juego (requisito 6) 17

Figure 4.5: Flujo de las capturas de pantallas del juego en modo mul-tijugador

Existe una pequena diferencia en el escenario del juego en el modo multijugador.

Dado que en el modo multijugador no existen niveles, cuando el escenario del juego

termina, puede ocurrir dos escenarios: el escenario gameOver o el escenario highscore.

En caso de que el jugador pierda el juego debido a que ha muerto en el juego, se vuelve

al menu principal, de igual manera que ocurre en el modo unico jugador, es decir, se

inicia el escenario de gameOver con el mensaje en concreto durante un espacio de

tiempo determinado y luego de forma automatica se vuelve al menu principal. En

cambio, si el jugador acaba el juego multijugador (gane o pierda), se pasa al escenario

de highscores inde�nidamente, hasta que el usuario decida volver al menu principal.

4.3 La logica del juego (requisito 6)

Se trata de un juego muy simple. El usuario controla una tortuga, siempre se empieza

en el centro de la pantalla, el equivalente a la nave espacial en el juego de Asteroids,

con la que igualmente puede disparar, en nuestro caso, lanzar proyectiles. El escenario

del juego sucede en lugares reconditos del universo, por las imagenes de galaxias

lejanas que apreciamos. Igualmente, si en Asteroids aparecıan asteroides y platillos

voladores, en nuestro juego tambien aparecen enemigos, eso sı, en forma de insectos, a

los cuales les llamamos buggers (de ahı el nombre de nuestro juego: Turtle vs Buggers).

El principal objetivo del juego es que el usuario destruya a todos los enemigos. El

juego es bastante corto, solo tres niveles, en contraste con Asteroids, el cual no tiene

�n en cuanto a niveles. Los enemigos aparecen periodicamente, existen enemigos

muy faciles de destruir, los cuales siguen una trayectoria aleatoria, luego estan los que

constantemente persiguen al jugador y por ultimo tenemos los que atacan lanzando

proyectiles al jugador. El juego se inicia con la salud al 100%, y este va aumentando


de di�cultad en cada nivel, aumentando el numero de enemigos y el tipo de enemigos

que aparecen, ademas de aumentar la velocidad del juego. Si la salud del jugador se

acaba, el juego termina. La perspectiva es en dos dimensiones, con un punto de vista

en Top-down. Ademas, los objetos del juego no pueden salir del escenario, es como

si se encontraran encerrados en la pantalla, esta es una de las grandes diferencias con

el juego Asteroids de Atari.

Los personajes que aparecen en el escenario del juego son los que describimos a

continuacion:

4.3.1 La tortuga

Es el objeto controlado por el jugador, para este hemos de�nido su velocidad en

funcion de la frecuencia de actualizacion del juego, es decir, como tenemos con�g-

urado nuestro juego para que funcione a 60 herzios, esto es, que nuestro juego se

actualiza cada 0.016 segundos aproximadamente. Si indicamos que nuestro jugador

se mueve a 2 pixeles por cada paso, lo que estamos diciendo es que su velocidad es de

120 pixeles por segundo. En el tercer nivel y en el modo multijugador, el jugador se

mueve a 3 pixeles por cada paso.

Para crear la animacion de la tortuga, con el objetivo de que parezca que se esta

moviendo (3), Cocos2d proporciona con su API una forma facil de crear animaciones,

las cuales llama Sprite Sheets, que no es mas que una imagen mas grande que la ori-

ginal, en la que ponemos nuestro sprite (nuestra imagen de la tortuga), por supuesto,

ponemos varios de nuestros sprites ligeramente modi�cados para que de la sensacion

de que la imagen esta en movimiento en cada salto. Ademas, viene con un archivo de

texto (con la extension .plist), en el cual se especi�ca las posiciones de los diferentes

sprites que se ha anadido al Sprite Sheet.La razon de su uso se debe, principalmente, a que Cocos2d esta optimizado para

ello, es mucho mas rapido que si se usara imagenes animadas tipo GIF (las cuales no

estan soportadas [5]), o hacer las llamadas manualmente para cambiar la imagen.

Existe un programa para crear estos Sprite Sheets animados, el programa se llama

Texture Packer, pero no hemos podido hacer uso de el (ademas de que se trata de

un programa de pago). Es por ello que hemos decidido crearlo manualmente, tanto

el sprite sheet, ası como el archivo donde se especi�ca la posicion de cada sprite. El

resultado �nal se puede ver en la �gura 4.6.


Figure 4.6: Sprite sheets animado de la imagen del jugador

Para controlar el movimiento de la tortuga necesitamos de un teclado:

Figure 4.7: Las teclas que controlan en movimiento del jugador

Con las teclas de las �echas izquierda y derecha se controla el movimiento de

rotacion del objeto (ver �gura 4.8).

Figure 4.8: Rotacion del jugador

Con las teclas de las �echas arriba y abajo se controla el movimiento de avance

hacia adelante y hacia atras en funcion de la rotacion que disponga el objeto. Se

puede combinar el uso de las fechas para realizar un movimiento curvilıneo (�gura

4.9).


Figure 4.9: Avance del jugador

Con la tecla de la barra espaciadora se realizan disparos de proyectiles hacia la

direccion a la que apunta la tortuga (�gura 4.10), la cual cumple el requisito 7.

Figure 4.10: El jugador lanza un proyectil

4.3.2 Los enemigos: Buggers

Son un total de 3 enemigos, cada uno con un tipo de movimiento y ataque distinto.

Para destruirlo es necesario que un proyectil lanzado por el jugador los alcance.

Bugger 1:

Aparece en el nivel 1, es el enemigo mas facil de destruir, su movimiento es aleatorio y

practicamente no molesta al jugador. En la �gura 4.11, podemos ver una aproximacion

del movimiento.


Figure 4.11: Enemigo con movimiento aleatorio

El movimiento consisten en ir generando numeros aleatorios correspondientes a

puntos en la pantalla, estos corresponden a los puntos donde se dirigira el enemigo,

solo cuando llega al punto calculado sequencialmente se calcula el siguiente punto.

Bugger 2:

Aparece en el nivel 2, su movimiento consiste en perseguir al jugador. En la �gura

4.12 podemos apreciar en que consiste el movimiento.


Figure 4.12: Enemigo con movimiento de persecucion

El movimiento se basa en perseguir siempre al jugador, para ello, se va calculando

puntos aleatorios cercanos cada cierto tiempo. Aquı, la aleatoriedad esta en la dis-

tancia, es decir, se obtiene un punto aleatorio situado entre la posicion en la que se

encuentra el enemigo y el punto medio equidistante entre el enemigo y el jugador.

Cuando el enemigo se encuentra muy cerca, el punto objetivo es directamente la

posicion del jugador.

Bugger 3:

Aparece en el nivel 3, igual que el enemigo 2, su movimiento consiste en perseguir

al jugador, pero ademas de manera periodica ataca al jugador lanzando proyectiles

(requisito 8).


Figure 4.13: Enemigo con movimiento de ataque

Este es el movimiento que menor velocidad tiene. En realidad es una combinacion

entre el movimiento aleatorio y el de persecucion, solo que ademas, en este se calcula

el tiempo en el que el enemigo debe lanzar el proyectil para atacar al jugador. Cuando

el enemigo se encuentra lejos del jugador, el movimiento y el ataque es aleatorio,

tanto en tiempo como en distancia. En el caso en que el enemigo se encuentre a

una distancia cercana del jugador (aproximadamente a una distancia 35% maxima

del ancho de la pantalla), el punto objetivo es la posicion del jugador. El ataque

con el proyectil se produce en un tiempo aleatorio entre cero y un segundo, desde

el momento en el que se calcula el punto objetivo.

4.3.3 Los proyectiles (Requisito 7 y 8)

Los proyectiles (�gura 4.14) tienen un papel importante en el juego, tratan de manera

indiferente al jugador y al los enemigos, ya que desde el punto de vista del proyectil

solo existe el origen del disparo y los objetivos del proyectil, los cuales pueden ser

tanto el jugador como los enemigos. Cuando el proyectil es lanzado por el jugador,

se presenta de color naranja, y solo puede colisionar con los enemigos. En el caso

que fuera lanzado por el enemigo, presenta un color verde oscuro, y al estar espe-

cialmente dirigido hacia el jugador, no puede colisionar con el resto de enemigos.

Automaticamente se destruyen cuando sobrepasan las dimensiones de la pantalla

o cuando colisionan con los objetivos a los que fue dirigido, en este ultimo caso,

producen explosiones, de las cuales se explican en la siguiente seccion.


Figure 4.14: Proyectiles

4.3.4 Las explosiones

Las explosiones (�gura 4.15) las encontramos cuando los enemigos aparecen aleat-

oriamente en alguna posicion de la pantalla y cuando un proyectil colisiona con

un objetivo (el jugador o los enemigos). El color de las explosiones depende de los

personajes, cada enemigo tienen asignado un color especı�co, el enemigo 1 tiene

como color caracterıstico el rojo, el enemigo 2 el amarillo y el enemigo 3 el verde

oscuro, el jugador tiene el color por defecto de la explosion, color amarillo.

Figure 4.15: Las explosiones

4.4 Las colisiones 25

Podemos observar que todas las imagenes de las explosiones solo varıan en su

color. Serıa un autentico error tener imagenes para cada explosion que ocurre en el

juego, sin contar el tiempo que nos llevarıa crearlas. Por suerte, la API de cocos2d (4)

dispone de herramientas para poder cambiar los colores de imagenes por codigo. Su

funcionamiento es que el color de cada pixel se multiplica por un valor de tinte el cual

cambiara el color del pixel, por supuesto los pixeles que son todo negro no tendran

ningun cambio, ası los pixeles de colores claros son los mas faciles de polarizar.

La imagen de la explosion no es nada mas que un Sprite Sheet, el cual ya explicamos

en la seccion para el sprite de la tortuga. Este Sprite Sheet lo obtuvimos de los juegos

de ejemplo que Cocos2d no ofrece (en concreto, del juego Moon Warrior), en la �gura

4.16 podemos ver la animacion.

Figure 4.16: El Sprite Sheet animado de las explosiones

4.4 Las colisiones

Para las colisiones hemos hecho uso de la librerıa Chipmunk (la cual ya explicamos

anteriormente). Para ello hemos de�nidos el espacio fısico con paredes donde el

juego va a tener lugar. Logicamente, dado que el juego tiene lugar en el espacio y

ademas tenemos un perspectiva top-down, la gravedad debe ser nula. Lo unico que

nos interesa son las colisiones de los objetos con las cuatro paredes y las colisiones

entre los propios objetos (enemigos y el jugador), para ello, anadimos los objetos al

espacio simulado como objetos dinamicos, luego la librerıa se encarga de aplicar toda

la fısica de colisiones de forma automatica por nosotros.

Sin embargo, hemos hecho una excepcion con los proyectiles. Estos no estan

de�nidos en el espacio fısico, no lo hemos hecho por el rendimiento, sino porque el

control de las colisiones es mucho mas sencillo sin chipmunk. Por ejemplo, queremos

que los proyectiles lanzados por el enemigo no colisionen con el resto de enemigos

ni con las paredes del espacio. En Chipmunk, para lograr esto, tenemos que de�nir

el proyectil y eliminar su evento de colision para que no tenga efecto sobre el resto de

enemigos, pero de las iteraciones que la librerıa realiza por detras no nos libramos,

para ello debemos realizar con�guraciones mas complejas. Es por ello que hemos


decidido realizar de forma tradicional el bucle de colision para que cada proyectil

itere solo sobre sus objetivos, en este caso, el proyectil lanzado por el enemigo solo

itera sobre los jugadores que existen e ignora al resto de enemigos y a las paredes del

espacio.

Figure 4.17: Las colisiones: sin chipmunk vs chipmunk

Como vemos en la �gura 4.17, nuestra implementacion de la colision es mucho mas

sencilla que la forma en que trabaja chipmunk. En nuestro caso, estamos calculando

la distancia entre un punto (el proyectil) y un cırculo (los objetivos), el cual es mas

facil de entender y es un evento de colision mas rapido que el usado por chipmunk, en

el que los eventos de las colisiones se utilizan rectangulos delimitadores. Ademas, en

chipmunk todos los eventos de colision ocurren, es por el tipo de etiqueta de los cuer-

pos que decidimos si deseamos ignorar la colision o no. Obviamente, para un motor

de fısica esto no supone ningun problema y ni siquiera deberıamos preocuparnos por

problemas de rendimiento, salvo que estemos usando miles de cuerpos a la vez en un

espacio colisionando entre sı. Simplemente decimos que se requiere de mucho mas

esfuerzo en chipmunk con�gurar los cuerpos para que se comporten de la manera

en que nos gusta, es decir, que para nada estamos diciendo que los motores de fısica

sean un mal sistema, nuestro juego es muy simple para que ocurra un problema de

rendimiento de este tipo.

4.5 Los niveles 27

4.5 Los niveles

Para saber el momento en que debemos pasar al siguiente nivel hemos realizado un

bucle que comprueba en cada momento si el jugador ha conseguido pasar el nivel, eso

sı, el bucle no esta de�nido en el bucle principal del juego, eso serıa un derroche de

recursos, para este caso lo hemos programado cada segundo en un bucle secundario.

Los niveles estan de�nidos en un archivo de con�guracion. En este archivo de�n-

imos el numero de enemigos a mostrar, los tipos de enemigos que disponemos, el

tipo de jugador, los colores de las explosiones, cuando se debe terminar el juego

y muchas otras con�guraciones como la salud, el numero mınimo de enemigos, el

tiempo especı�co en el que aparecen enemigos, etc.

La con�guracion de la di�cultad de los niveles la hemos de�nido en funcion de la

velocidad de los objetos (enemigo y jugador) sobre el campo de juego, en funcion del

numero de enemigos, y por el tipo de enemigos que aparecen.

En el primer nivel solo mostramos enemigos con movimiento de tipo aleatorio,

muy faciles de destruir. Se muestran un total de 4 enemigos. Si el jugador los destruye

pasa al segundo nivel. El segundo nivel, el numero de enemigos se incrementa a

6, y aparecen los enemigos de tipo 1 y tipo 2, con el movimiento aleatorio y el de

persecucion, ademas de incrementar la velocidad de los mismo.

En el ultimo nivel aparecen los enemigos de tipo 3, es decir, en este ya tenemos

los tres tipos de enemigos en el escenario, hasta un total de 8 enemigos. En este nivel

los enemigos tienen su maxima velocidad y los enemigos de tipo 3 pueden atacar al

jugador.

Luego tenemos el nivel multijugador, en este los enemigos son los mismos del nivel

3, pero el lımite de enemigos que hay que destruir para que termine el juego es de 30,

El jugador que mas puntuacion obtenga es el ganador. La puntuacion se mide por el

numero de enemigos destruidos, los disparos certeros y la salud del jugador.

4.6 El modo multijugador

Para implementar la parte multijugador hemos reutilizado gran parte del codigo

JavaScript del cliente. Se ha anadido la clase multijugador.js (mirar �gura 4.3).

Esta clase se encarga de la sincronizacion con el servidor a traves de websockets

apoyandose en socket.io.

Para no reescribir nuevas clases, permitimos iniciar a las clases en modo jugador

unico o multijugador, pasandole un parametro. De esta manera, podemos tener el

objeto de la clase jugador local y una lista de objetos que representan al resto de

jugadores remotos. La distincion es necesaria, ya que los jugadores remotos no neces-


itan, por ejemplo, el bucle de actualizacion ni tampoco controlar el evento de colision

con los enemigos, eso es tarea del resto de usuarios que deben controlar su propio

jugador.

De la misma manera necesitamos indicar que los objetos de los enemigos se inicien

en modo multijugador, principalmente para que no se inicien con el movimiento que

tienen asignado por defecto (aleatorio, persecucion o ataque) y que tampoco se inicie

el bucle de actualizacion que se encarga de ejecutar el movimiento. En el modo mul-

tijugador, es el servidor el que se encarga de actualizar las posiciones de los enemigos.

Ademas de iniciar el objeto enemigo en modo multijugador, hemos creado otro tipo de

movimiento, el “movimiento remoto”, el cual tiene la simple mision de tratar con las

posiciones aleatorias que llegan desde el servidor para recrear los movimientos en el

lado del cliente. De otra manera, serıa casi imposible sincronizar los movimientos

de los enemigos, es necesario que el servidor se encargue del movimiento de los

enemigos.

4.6.1 Sincronizacion de los enemigos

La sincronizacion de los enemigos fue la parte mas compleja del desarrollo del juego.

Durante el desarrollo surgieron varias aproximaciones para esta tarea:

• La primera idea que surgio para sincronizar los movimientos de los enemi-

gos, fue la de sincronizar de golpe todas las posiciones aleatorias, es decir, si

pensamos en que lo unico que da problemas con el resto de los jugadores son

la generacion de posiciones aleatorias, con este modelo se intento sincronizar

todas las posiciones aleatorias generadas desde el servidor con todos los usuar-

ios conectados. Por ejemplo, enviamos en rafagas de periodos largos la lista,

por poner un ejemplo, con 1000 posiciones aleatorias; en un mundo ideal, en

el que los jugadores se sincronizan a tiempo, todos deberıan ver exactamente

el mismo mundo. Para solucionar los problemas de sincronizacion cuando los

usuarios se conectan a destiempo, el servidor calcularıa e indicarıa la posicion

y el espacio de tiempo por el que va el juego. Pese a lo complejo y extrano

que parece, esta idea es la que menos problemas nos ha dado de todas las que

hemos descartado, de todas maneras es una idea horrible, ya que los problemas

de sincronizacion son evidentes. Igualmente el servidor tendrıa que saber en

todo momento la situacion del juego.

• Otra idea por la que pasamos, fue la de intentar que exista siempre un jugador

piloto que sincronice las posiciones de los enemigos, en otras palabras, que el

juego se juegue del lado del cliente en un usuario conectado en concreto. De

esta manera, el servidor solo se encargarıa de difundir los mensajes al resto de

4.6 El modo multijugador 29

jugadores. La idea fue descartada muy rapido, dado la complejidad de asegur-

arse que siempre exista un usuario piloto que se encarge de la logica del juego.

• El otro modelo en que se penso, fue el de sincronizar solo en los tramos no

predecibles, es decir, cuando generamos los numeros aleatorio para calcular la

siguiente posicion del enemigo.

Figure 4.18: Sincronizacion de los enemigos por tramos

Este modelo tambien nos dio problemas de sincronizacion evidentes. Por ejem-

plo, cuando un usuario se conecta en mitad de la “no sincronizacion”, ver �gura

4.18, la solucion en este caso es la de sincronizar tambien cada vez que un

usuario se conecte. Aunque la idea en teorıa parece idonea, en la practica lleva

a problemas de sincronizacion, por ejemplo, cuando se producen colisiones o

cuando ligeramente los enemigos van mas adelantados que en el resto de usuar-

ios, provocando que durante ratos los usuarios perciben mundos ligeramente

diferentes.

• Al �nal, la idea a la que hemos llegado (una idea que desde un principio

querıamos evitar), es la de que en todo momento exista un bucle de actualizacion

en el servidor, actualizando todo lo necesario y principalmente, actualizando

los movimientos de los enemigos. Es la idea mas sencilla de implementar de

todas, pese a que la evitamos desde el principio, mas que todo, por el hecho de

que tener un bucle de actualizacion nos lleva a la idea de llevar el juego entero

al servidor. Aunque el hecho de que el juego se juegue en el servidor, es el

modelo mas aceptado y recomendado por la mayorıa de los desarrolladores,

el juego esta en el servidor y los usuarios solo envıan los eventos del teclado,

ası los usuarios solo reciben “pantallazos” del juego. Sin embargo, este no es


el modelo que llegamos a realizar, pero con mas tiempo es lo que hubieramos

terminado implementando.

Para llegar al modelo que tenemos (�gura 4.19), hemos llevado primero las clases de

los movimientos de los enemigos al servidor. Dado que los movimientos hacen uso

de muchas funcionalidades de la API de Cocos2d, tuvimos que volver a implementar

gran parte de las funciones. Aunque otra idea serıa llevar toda la librerıa de Cocos2d

al servidor, pero esto es algo que no quisimos hacer, aunque es perfectamente valido.

Figure 4.19: Arquitectura de las clases de JavaScript en el servidor

Si observamos la �gura 4.19, mientras que en el cliente tenıamos 3 clases de movi-

mientos (ver �gura 4.3), en el servidor la reducimos a 2 clases de movimientos (movi-

miento aleatorio y persecucion), el movimiento de ataque ha desaparecido, esto es

porque el movimiento de ataque es el mismo que el de persecucion, y el lanzamiento

de proyectiles los calculamos en el controlador de los enemigos (llamado monstersController). Este controlador se encarga de actualizar todas las posiciones de los

enemigos y tambien de generar enemigos aleatorios cuando sean necesarios (prin-

cipalmente, si hay menos de 3 enemigos en el escenario, el controlador de enemigos

envıa mas enemigos hasta un lımite de 30 enemigos, o el que se indique en el archivo

de con�guracion con�g.js).


Figure 4.20: Actualizacion y calculo de las posiciones de los enemigos

El unico problema que tenemos a la hora de actualizar las posiciones de los enemi-

gos, es saber cuando se deben calcular y actualizar las nuevas posiciones de destinos.

Tenemos dos opciones aquı, que los usuarios difundan la posicion de los enemigos

al servidor, o que el servidor lo calcule. La primera opcion es la menos e�ciente,

en el caso en que existan muchos usuarios conectados, el servidor recibirıa muchos

mensajes en vano. Por tanto, la segunda opcion es la adecuada, el servidor se encarga

de calcular, por cuenta propia, donde deberıan estar los enemigos, es decir, el servidor

debe simular el movimiento de los enemigos. Para ello, ver �gura 4.20, simplemente

realizamos el calculo de la distancia entre el punto de origen y el destino, con esta

distancia y la velocidad (la cual es constante), podemos calcular el tiempo que durara

el movimiento, es decir, el servidor calcula la nueva posicion de destino del enemigo

cuando pasa este intervalo de tiempo, que es cuando el movimiento �naliza. Si el

intervalo de tiempo no se ha cumplido, tan solo calculamos la posicion en la que

se encuentra el enemigo, como sabemos el tiempo que ha pasado desde la ultima

actualizacion, y con ese tiempo conocemos la distancia que ha recorrido el enemigo,

podemos calcular el punto exacto en el que se encuentra el enemigo. Este bucle de

actualizacion ocurre cada 250ms (es el que hemos decidido por simple observacion),

aunque se podrıa reducir para tener mas precision.

4.6.2 Sincronizacion de los jugadores

La sincronizacion del movimiento del jugador con todos los usuarios es muy simple.

Cada usuario emite su mensaje de actualizacion cuando se producen los eventos del


teclado. Ası cuando el servidor reciba el mensaje, lo difunde al resto de usuarios. De

esta manera, todos los usuarios ven de manera sincronizada todos los movimientos

de los usuarios.

4.6.3 Mensages con Socket.io

Figure 4.21: La conexion del usuario con el servidor

En la �gura 4.21 podemos ver desde el punto de vista de un usuario lo que ocurre

cuando se inicia el modo multijugador. El jugador envıa el mensaje de conexion

al servidor, este al recibirlo inicia eventos que escucharan a este usuario en con-

creto (vemos la lista de eventos en la �gura bajo la caja “listeners”). Ante cualquier

mensaje que emita el usuario, en el servidor existira un escuchador para ese mensaje

en concreto. El servidor procesa el mensaje recibido y los difunde al resto de usuarios

conectados. Solo existe una excepcion, en el caso de que el usuario emita el mensaje

de actualizacion de la salud (mensaje “update player health”), el mensaje se procesa

pero no se difunde, esto es ası ya que en el juego no sabemos el nivel de salud del

resto de jugadores.


Figure 4.22: La conexion del usuario con el servidor: nuevo jugador

En la �gura 4.22, vemos con mas detalle lo que ocurre despues de la conexion. El

usuario emite un mensaje, “new player”, indicando que se trata de un nuevo jugador

(obviamente re�riendose a sı mismo). Dado que se trata de un nuevo jugador, el

servidor difunde el mensaje al resto de usuarios, y despues envıa al nuevo usuario

los jugadores existentes y los enemigos existentes en el juego, y de esta manera el

usuario queda sincronizado.

Figure 4.23: Bucle principal de sincronizacion del servidor

En la �gura 4.23, observamos la dinamica del bucle de actualizacion implementado

en el servidor. El servidor, en este bucle, emite mensajes a todos los usuarios conecta-

dos. Estos mensajes pueden referirse a nuevos enemigos, “new monsters”, en el juego

(solo en caso de que se necesiten mas enemigos), pueden referirse a la actualizacion de

las posiciones de los enemigos, “update monster”, o la actualizacion la puntuacion del

usuario que va en cabeza, “leader”. El ultimo mensaje que el servidor puede difundir

es cuando el juego termina, “game over”, este provoca que el juego termine en todos

los usuarios conectados, esto ocurre cuando ya se han destruido 30 enemigos (ası es

como se de�nio en el archivo de con�guracion).

CAPITULO 5

Conclusiones

Durante el desarrollo del proyecto hemos pasado por varias etapas. Desde un prin-

cipio tenıa claro con que tecnologıa querıa trabajar, descarte realizar el proyecto con

Cocos2d-x (en el lenguaje C++), tenıa claro que el lenguaje deberıa ser JavaScript.

Es un acierto, dado que el equipo de desarrollo de Cocos2d esta muy activo con esta

tecnologıa. El hecho de tener decidio esto, me ahorro mucho tiempo, ya que luego esto

desenboco en la decision de usar las tecnologıas Nodejs como servidor y socket.io para

la comunicacion, la popularidad de estas tecnologıas y que casi siempre van ligadas

la una con la otra, hizo que me interesara por ellas.

La segunda etapa fue la mas difıcil, pase mucho tiempo decidiendo que tipo de

juego deberıa hacer, dado que nunca habıa desarrollado un juego antes, por ello

dedique un gran tiempo a investigar y aprender de tutoriales.

Una vez decidı la logica del juego, llego la parte divertida del proyecto, tenıa

bastantes ideas, que al �nal por falta de tiempo no las pude incluir. Pero la satisfaccion

de acabar el proyecto fue enorme.

En de�nitiva, podemos dar por satisfecho nuestro objetivo, nos hemos familiariz-

ado con el desarrollo y funcionamiento de videojuegos desde el inicio hasta el �nal.

No es un trabajo facil, se requiere de mucho esfuerzo, pero al �nal el resultado vale

la pena.

5.1 Lıneas futuras

En este apartado existen un sin �n de posibilidades. Hemos descartado una gran

cantidad de ideas, obviamente el tiempo es un factor que da prioridad a ciertas cosas.

Principalmente, una de los aspectos que menos me gusta, es la simplicidad del

juego. El juego cae rapidamente en el aburrimiento, ya que es bastante corto y

ademas bastante repetitivo. Ası que, una de las lıneas futuras esta por enriquecer

este apartado, con nuevos elementos interactivos, tales como, nuevos enemigos,

incluir obstaculos, escenarios que se extiendan mas alla de los lımites de la pantalla o

experimentar con nuevas perspectivas, ası como un sin �n de posibilidades.

35

36 CHAPTER 5. CONCLUSIONES

Tambien el modo jugador deja mucho que desear, no existen salas para los

jugadores, no se pueden ver los nombres del resto de jugadores conectados.

Uno de los aspectos mas curiosos, es que no existe base de datos, la persistencia es

tan solo el almacenamiento local que HTML5 nos proporciona. Incluir persistencia,

principalmente en el servidor, es posiblemente una de las tareas futuras primordiales.

Por ultimo, debido al indiscutible dominio del mundo movil, es un completo error

no pensar en estas plataformas moviles. Esta es una de las lıneas que fortalece nuestra

decision de haber elegido JavaScript, en lugar de una alternativa nativa, ya que en este

aspecto es por la que Cocos2d destaca, es multiplataforma. Pese a ello, no nos ha dado

tiempo a intentar siquiera probar alguna otra plataforma.

Bibliografıa

1. Pespectivas de los juegos: h�ps://en.wikipedia.org/wiki/Video game graphics

2. Nodejs + Socket.io + Heroku: h�p://robdodson.me/deploying-your-�rst-node-dot-js-and-socket-dot-io-app-to-heroku/

3. Animaciones con sprites: h�p://stackover�ow.com/questions/23140277/a-simple-sprite-sheet-animation-in-cocos2d-js

4. Coloring sprites: h�p://www.brandontreb.com/cocos2d-tutorial-dynamically-coloring-sprites/

5. GIF is not supported on Cocos2d: h�p://discuss.cocos2d-x.org/t/how-to-display-gif/2714/7

6. Imagenes sin copyright: openclipart.org

37

CAPITULO A

Detalles para configurar el juego

Como hemos usado un ordenador con sistema operativo ChromeOS, expliaremos las

aplicaciones necesarias para arracar el juego en este sistema operativo.

En la tabla tenemos las caracterısticas de este portatil.

Toshiba CB30 Chromebook

Specifications

• CPU: Haswell Celeron 2995U. 1.4GHz, dual-core, 2MB Cache

• RAM: 2GB or 4GB DDR3 (Not upgradeable)

• Display: 13.3” 1366x768 Disk: 16GB SSD (Not upgradeable)

• HDMI port 2 x USB 3 SD slot (SDXC compatible) Headphone/mic combo jack

Camera & mic Keyboard & touchpad Connectivity: WiFi: 802.11 a/b/g/n

A.0.1 Install Chromebrew (along with Ruby and Git)

wget -q -O - h�ps://raw.github.com/skycocker/chromebrew/master/install.sh | bash

# necesario para instalar Node.js

A.0.2 Instalar Node.js

crew install node

A.0.3 Instalar socket.io

npm install socket.io

39

40 ANEXO A. DETALLES PARA CONFIGURAR EL JUEGO

A.0.4 Descargar el proyecto

git clone h�ps://github.com/robinparadise/turtle vs buggers

cd turtle vs buggers

A.0.5 Iniciar el juego en el servidor

node game.js

# ahora el juego esta escuchando en el puerto 5000

# desde un navegador ir a:

h�p://localhost:5000

desarrollo de un juego html5 multijugadoroa.upm.es/43127/4/tfm_robin_giles_ribera.pdf ·...

Documents