Post on 20-Jun-2020
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.
4 CHAPTER 1. INTRODUCCION
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:
6 CHAPTER 1. INTRODUCCION
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
16 CHAPTER 4. DESCRIPCION INFORMATICA
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
18 CHAPTER 4. DESCRIPCION INFORMATICA
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.
4.3 La logica del juego (requisito 6) 19
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).
20 CHAPTER 4. DESCRIPCION INFORMATICA
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.
4.3 La logica del juego (requisito 6) 21
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.
22 CHAPTER 4. DESCRIPCION INFORMATICA
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).
4.3 La logica del juego (requisito 6) 23
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.
24 CHAPTER 4. DESCRIPCION INFORMATICA
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
26 CHAPTER 4. DESCRIPCION INFORMATICA
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-
28 CHAPTER 4. DESCRIPCION INFORMATICA
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
30 CHAPTER 4. DESCRIPCION INFORMATICA
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).
4.6 El modo multijugador 31
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
32 CHAPTER 4. DESCRIPCION INFORMATICA
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.
4.6 El modo multijugador 33
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