Message Broker
 
API Reference: Message Broker

1.           Estructura

Explicaremos el orden y tipo de mensajes que se van a intercambiar.

La Api consta de dos librerías principales:

·         web.js:                encargada de controlar los mensajes y llamar a los métodos que tendrán que tener los juegos.

·         webVar.js: variables globales de la Api.

Todos los mensaje que llegan al API serán en formato String y se usar un separador para las distintas partes del mensaje, este será “;”.

1.1.    Librerías

1.1.1.  webVar.js

Código que tiene las variables de la API, aquí se podrá cambiar el puerto e IP del servidor, entre otras cosas, no cambiar mensajes, puesto que estos son los que se comunican con el servidor.

En esta clase habrá dos parámetros que se podrán cambiar según donde se quiera llamar:

·         var MAIN_SERVER_ADDRESS = '213.37.1.75';

o   Dirección del servidor.

·         var APP_ID = '47d97160f684716248223337348f11a6';

o   Id aplicación, este se proporciona cuando se registra una App en la web.

1.1.2.  Web.js

Código que gestiona la API, mensajes, socket etc.….

1.1.3.  JQuery

Librería JavaScript.

1.2.    Mensajes

1.2.1.  Tipo mensajes

Mensajes de comunicación con el servidor:

·         INICIO = 0                                          recibido en receivingData

·         BEGIN_SESSION = 1                      recibido en receivingData

·         ACTION = 2                                       recibido en receivingGameData

·         END_SESSION = 3                           recibido en receivingGameData

·         NEW_SALA = 4                                recibido en receivingData

Mensaje de error con el juego:

·         OK = 200            

·         ERROR_NO_APP = 501

·         ERROR_NO_SESIONES = 502

·         ERROR_NO_SALAS = 503

·         ERROR_NO_SALA = 504

·         ERROR_SALA_REP = 505

Ejemplo de mensajes con la API:

·         MEN_ULTIMO = "ultimoJugador"

·         MEN_CONECTADO = "conectado"

Estos mensajes se reciben a través de los métodos de la API:

·         function receivingData(socketId)

·         function receivingGameData (socketId)

1.2.2.  Mensaje INICIO

Mensaje inicial que lanza el Api para comunicarse con el servidor, este le contestara las salas que hay actualmente, esta información se muestra en una tabla.

La respuesta del servidor vendrá dada en forma de json, el Api tratará este json y mostrará la información en formato HTML.

Este mensaje se estará enviando continuamente para que la información se actualice, cuando realice una acción, ya sea entrar sala o nueva sala, el mensaje de inicio se deja de enviar, cuando se realice en el juego una acción “terminar sala” este mensaje automáticamente se empezara a enviar de nuevo, este mensaje se manda por socket UDP de inicio, con el puerto de inicio que se convenga.

Se podrá controlar el intervalo con el cual se envía este mensaje, esto se hará con la variable “limitLatencyToInicio”, esta variable esta en el archivo webVar.js.

En la Tabla se muestra el nombre de la sala, el puerto que usa para esa sala, el estado, las sesiones que admite y las que tiene, la fecha de creación y la opción de entrar si estuviera abierta.

 

 

Mensaje al servidor:

·         function callInicioSocket (pNameSala)

·         INICIO: tipo mensaje.

·         APP_ID; id aplicación (juego).

Esto genera el mensaje al servidor, este creara un json con las salas y le devolverá al API un mensaje con la siguiente información:

·         typeMen: tipo mensaje.

·         Mensaje de error: OK si va bien, ERROR_NO_SALAS si no hubiera salas, ERROR_NO_APP, error no existe aplicación en bbdd, ERROR_SALA_REP, sala repetida para esa app.

·         json: información en formato json de las salas.                              

1.2.3.  Mensaje NEW SALA

Este mensaje se inicia al darle a la opción Nueva sala y será para iniciar una nueva sala. Antes se tendrá que indicar el nombre de la sala a crear y el número de jugadores, el mx es cuatro y si no se indica nada en este campo por defecto serán dos.

Mensaje al servidor:

·         function callNewSalaSocket(pNameSala)

·         NEW_SALA: tipo mensaje.

·         APP_ID; id aplicación (juego).

·         MAX_PLAYER: usuarios max.

·         pNameSala: nombre sala.

Esto genera el mensaje al servidor, este creara una sala con el nombre indicado, se le asignara un id, un máx. de jugadores y le devolverá al API un mensaje con la siguiente información:

·         typeMen: tipo mensaje.

·         Mensaje de error: OK si va bien, ERROR_SALA_REP si el nombre estuviera repetido, ERROR_NO_APP, error no existe aplicación en bbdd.

·         Sesión Id: id de la sesión, el usuario conectado.

·         Puerto de la sala: puerto al que se abrirá el nuevo socket para empezar la comunicación con el juego.

·         Numero de usuarios conectados a esa sala.

·         Nombre sala.

·         Max usuarios.                                                 

Hasta aquí todo lo controlaba el API, se para el socket principal y se creara un socket para el juego con el puerto del mensaje, a partir de aquí, cuando al API le llegue el mensaje del servidor con contestación al mensaje NEW SALA, esta iniciara el juego, llamándolo a través de un método que el juego tendrá que tener implementado:

·         preInit(ROOM_NAME, USER_NUMBER, MAX_PLAYER);

o   ROOM: sala a la que se conecta.

o   USER_NUMBER:  id usuario que será en el juego

o   MAX_PLAYER: usuarios máx. de esta sala.

Cuando se lanza el nuevo socket, el API también lanza un mensaje al servidor de nueva acción, es un mensaje de ACTION al nuevo socket que se ha creado, llega al servidor y este contesta a todos los usuarios de esa sala.

Es te mensaje contendrá información que desde el juego se ha escrito dependiendo de los usuarios conectados o si es el ultimo en conectar, esto lo controla el juego y este deberá decir cuando se conecta un usuario correctamente y cuando es el ultimo, opcionalmente dependerá del juego establecer un MASTER o no. Esto se explicara mas adelante con más detalle.

 

·         priorWriteAction(MEN_TYPE_BEGIN + : + userId + : + MEN_ULTIMO);

·         priorWriteAction(MEN_TYPE_BEGIN + : + userId + : + MEN_CONECTADO)

 

Al igual que con el anterior mensaje de inicio, se podrá controlar el intervalo con el cual se envía este mensaje, esto se hará con la variable “limitLatencyToInicio”, esta variable esta en el archivo webVar.js.

1.2.4.  Mensaje BEGIN SESSION

Este mensaje se manda cuando se da la opción de entrar sala.

Mensaje al servidor:

·         function callBeginSocket(idSala)

·         BEGIN_SESSION: tipo mensaje.

·         APP_ID; id aplicación (juego).

·         MAX_PLAYER: usuarios max.

·         idSala: id sala a la que te unes.

·         USER_ID: id usuario que se te asigna.

Esto genera mensaje al servidor,  se genera un usuario con el puerto e ip del que llama, se le asigna un id, se unirá a la sala y se devolverá al API un mensaje con la siguiente información:

·         typeMen: tipo mensaje.

·         Mensaje de error: OK si va bien, ERROR_NO_SALA si la sala no existiera, ERROR_NO_APP, error no existe aplicación en bbdd.

·         Sala Id: id de la sala a la que se conecto.

·         Sesión Id: id de la sesión, el usuario conectado.

·         Puerto de la sala: puerto al que se abrió el nuevo socket para empezar la comunicación con el juego.

·         Numero de usuarios conectados a esa sala.

·         Nombre sala.

·         Max usuarios.                                                 

Esto es igual al mensaje de nueva sala, se para el socket principal y se creara un socket para el juego con el puerto del mensaje, a partir de aquí cuando al API le llegue el mensaje del servidor con contestación al mensaje NEW SALA, esta iniciara el juego, llamándolo a través de un método que el juego tendrá que tener implementado:

·         preInit(ROOM_NAME, USER_NUMBER, MAX_PLAYER);

o   ROOM: sala a la que se conecta.

o   USER_NUMBER:  id usuario que será en el juego

o   MAX_PLAYER: usuarios máx. de esta sala.

Cuando se lanza el nuevo socket, el API también lanza un mensaje al servidor de nueva acción, es un mensaje de ACTION al nuevo socket que se ha creado, llega al servidor y este contesta a todos los usuarios de esa sala.

Es te mensaje contendrá información que desde el juego se ha escrito dependiendo de los usuarios conectados o si es el ultimo en conectar, esto lo controla el juego y este deberá decir cuando se conecta un usuario correctamente y cuando es el ultimo, opcionalmente dependerá del juego establecer un MASTER o no. Esto se explicara mas adelante con más detalle.

·         priorWriteAction(MEN_TYPE_BEGIN + : + userId + : + MEN_ULTIMO);

·         priorWriteAction(MEN_TYPE_BEGIN + : + userId + : + MEN_CONECTADO)

 

También se podrá controlar el intervalo con el cual se envía este mensaje, esto se hará con la variable “limitLatencyToInicio”, esta variable esta en el archivo webVar.js.

1.2.5.  Mensaje ACTION

Este mensaje es el encargado de comunicarse con el juego y las  acciones que en este se realicen, a partir de este mensaje se comunicaran por el método de la API receivingGameData y esta se comunica con el juego por el método readResponse, que tendrá este que tener implementado el juego.

Este mensaje que llega al juego contendrá los movimientos de los jugadores.

Mensaje al servidor:

·         function callActionSocketGame (message)

·         ACTION: tipo mensaje.

·         ROOM_ID; id sala.

·         actualMessage: mensaje de las acciones.

·         USER_ID: id usuario que se te asigna.

·         currentLatency: latencia del jugador

Esto genera mensaje al servidor,  no se trata, este mensaje se devolverá directamente a todos los usuarios de esa sala, la API solo manda al método readResponse el actualMessage, que es el que tiene la acción del movimiento.

1.2.6.  actualMessage

Este mensaje es el que lleva la información del movimiento de los jugadores, el separador que se usa es “:”, este mensaje es libre para el programador, nosotros ponemos aquí ejemplos de mensajes que hemos usado para la implementación de los juegos que aportamos, y se compone de:

·         MEN_TYPE_TECLAS: tipo acción para todos menos para el que lo manda.

·         MEN_TYPE_TECLAS_ALL: tipo acción para todos.

·         userId: numero del jugador que se mueve.

·         e.keyCode =  tecla que pulsa.

·         posX: pos x del jugador que ha mandado el mensaje.

·         posY: pos y del jugador que ha mandado el mensaje.

·         Direction: dirección en la que se mueve, para el disparo.

Con esta información el juego deberá hacer las acciones oportunas para mover a los usuarios (enemigos). Se explicara con más detalle en el apartado 3  “uso del API”.  

1.2.7.  Mensaje END SESSION

Este mensaje se mandara cuando un usuario termine su sesión, provocara que todos los usuarios dejen la sala y se vuelva al menú de las salas.

Mensaje al servidor:

·         function callEndSocketGame ()

·         END_SESSION: tipo mensaje.

·         APP_ID; id aplicación (juego).

·         ROOM_ID: id sala.

·         USER_ID: id usuario.

Esto genera mensaje al servidor,  se borra la sala, se para el socket en servidor y se devolverá al API un mensaje con la siguiente información, este mensaje se devolverá a todos los usuarios de esa sala:

·         MEN_END

Tras esto se empezara de nuevo a mandar el mensaje de inicio para actualizar la lista de salas. El juego deberá tener un método endSala(), en este se hará lo necesario para poder reiniciar el juego. 

 

2.           Uso del API

En resumidas cuentas, el API intenta abstraer al programador del juego de funciones de mensajería con el servidor y de control de parámetros de la red, si bien el programador deberá tener en cuenta los distintos métodos que tendrá que tener su app, para una correcta comunicación con la API:

Métodos a implementar:

·         function preInit(String pRoom, String pUser, String pNumUser)

·         function readResponse(String pData)

·         function endSala()

Métodos a llamar:

·         function writeAction(message)

·         priorWriteAction(String pMen);

2.1.    Métodos a llamar

2.1.1.  Método writeAction

Método que se encarga de enviar los mensajes, este método enviará el mensaje siempre que la latencia lo permita, si retorna un 0 se podrá realizar la acción porque el mensaje se habrá enviado, sino se retornara un 1 y se tendrá que esperar o mandar de nuevo.

2.1.2.  Método priorWriteAction

Este método enviara el mensaje igual que el anterior, pero pasara por encima de la latencia o las limitaciones de la red, solo se usara cuando se quiera poder mensajes prioritarios.

2.2.    Métodos a implementar

2.2.1.  Método preInit

Este es el método que el API llamará cuando se comience un juego, por dos lados, si comienza una nueva sala o si entra en una creada, la dinámica es la misma como hemos explicado mas arriba, el juego en este método deberá realizar las acciones oportunas para que se inicie y para iniciar al jugador correspondiente que el API le diga que es.

En este método el juego  podrá (esto una vez mas es un ejemplo de un posible uso) ver que jugador es y si lo cree conveniente sacar mensajes por pantalla, seria obligatorio mandar un mensaje por medio del método “priorWriteAction”, para saber si el usuario se conecto correctamente o si es el último, esto se realizara de la siguiente forma:

if (pUser == maxSess) {    //Eres el ultimo

       priorWriteAction(MEN_TYPE_BEGIN + SEP + userId + SEP + MEN_ULTIMO);      

}  else {                  //Me conecto y se lo digo a los demás  

       priorWriteAction(MEN_TYPE_BEGIN + SEP + userId + SEP + MEN_CONECTADO);    

}

De esta forma cuando el mensaje retorne al método “readResponse”, este sabrá si se conecto alguien o se conecto el último.

Parámetros:

·         pRoom: sala a la que te conectas.

·         pUser: usuario que serás.

·         pNumUser: usuarios máx.

2.2.2.  Método readResponse

Este método es el encargado de recibir los mensajes del API, que ha su vez lo ha recibido del servidor, será el encargado de gestionarlos y hacer las acciones oportunas para el juego.

A este método le llegara un String, un mensaje, este vendrá siempre con un formato simple separado por “;”, este siempre llegara con el mismo orden, mas arriba en la sección “actualmensage” ya explicamos como sería un posible formato, ampliamos la información en este apartado, este mensaje es el que podría llevar la información del movimiento de los jugadores, el separador que se usa es “:”, y se compone de, es este ultimo mensaje el que le llegará al método y el que el programador escogerá a su elección, este mensaje es libre y según lo que él mande es lo que le retornara en el método readResponse, aquí explicamos el usado en los juegos aportados como ejemplos:

·         Tipo de mensaje:

o   MEN_TYPE_BEGIN = "01";

o   MEN_TYPE_TECLAS = "02";

o   MEN_TYPE_JUGAR = "03";

o   MEN_TYPE_TECLAS_ALL = "04";

·         userId: numero del jugador que se mueve o realiza una acción.

·         e.keyCode =  tecla que pulsa.

·         posX: pos x del jugador que ha mandado el mensaje.

·         posY: pos y del jugador que ha mandado el mensaje.

·         Direction: dirección en la que se mueve, para un posible disparo.

Mensaje tipo MEN_TYPE_BEGIN seria para indicar que un usuario ha mandado un Begin y quiere conectarse, se conectara MEN_CONECTADO, en esta caso se añade al juego un jugador y si se considera oportuno se saca un mensaje, esto será a elección del programador del juego o bien será MEN_ULTIMO, en este caso se deberá mandar un mensaje “priorWriteAction(MEN_TYPE_JUGAR + SEP + MEN_JUGAR);”, para que el servidor lo renvíe  a todos los jugadores, esto hace que le lleguen a los demás el tipo de mensaje MEN_TYPE_JUGAR.

Mensaje MEN_TYPE_JUGAR, cuando esto llegue significa que el juego puede comenzar.

Mensaje MEN_TYPE_TECLAS, este llegará cuando un jugador realice un movimiento, con los parámetros descritos arriba y se usara para mandar las teclas, este mensaje manda a todos menos a uno mismo.

Mensaje MEN_TYPE_TECLAS_ALL, este llegará cuando un jugador realice un movimiento, con los parámetros descritos arriba y se usara para mandar las teclas, este mensaje manda a todos los usuarios.

Ejemplo método:

function readResponse(data) {

                var messageData = data.split(SEP);

               

                if (messageData[0] == MEN_TYPE_BEGIN) {                   //Mensaje tipo BEGIN

                               var idCon = parseInt(messageData[1]);                          //Usuario conectado

                               var men = messageData[2];                                             //Mensaje de begin

                                                                                                                            

                               if(men == MEN_CONECTADO){                                        //Si Conectado

                                               if(idCon != idUltimoConectado){      //Si id distinto ultimo que me mando este mensaje se hace caso

                                                               idUltimoConectado = idCon;

                                                              

                                                               numUsuarios = numUsuarios + 1;

                                                              

                                                               if(MASTER){

                                                                              messageGeneral = "Esperando Oponentes. MASTER. Conectados: " + (numUsuarios) + "/" +maxSess;   

                                                               } else {

                                                                              messageGeneral = "Esperando Oponentes. Conectados: " + (numUsuarios) + "/" +maxSess;       

                                                               }

                                                              

                                                               players[idCon] = new Enemy(idCon);

                                               }                                                                                                                           

                               } else if(men == MEN_ULTIMO){                      //Si Ultimo           

                                               if(idCon != idUltimoConectado){      //Si id distinto ultimo que me mando este mensaje se hace caso

                                                               idUltimoConectado = idCon;

                                                              

                                                               messageGeneral = '';

                                                              

                                                               if(MASTER){                                                                                                        //Si Master mando a todos men jugar

                                                                              addListener(document, 'keydown', keyDown);

                                                                             

                                                                              //Men jugar

                                                                              priorWriteAction(MEN_TYPE_JUGAR + SEP + MEN_JUGAR);                   

                                                               }             

                                                              

                                                               players[idCon] = new Enemy(idCon);

                                               }                                                                                                                           

                               }                                                                                                                           

                } else if (messageData[0] == MEN_TYPE_TECLAS) {      //Mensaje tipo TECLAS

                               //Teclas - MEN_TYPE_TECLAS + SEP + userId + SEP + e.keyCode + SEP + posX + SEP + posY;

                               var userIdAux = parseInt(messageData[1]);

                               var keyCodeAux = parseInt(messageData[2]);

                               var posXAux = parseInt(messageData[3]);

                               var posYAux = parseInt(messageData[4]);

                               var direction = parseInt(messageData[5]);   

                               var playerAux = new Object();

                              

                               for(var i=0;i<players.length;i++){

                                               try {

                                                               if(players[i].id == userIdAux){

                                                                              playerAux = players[i];     

                                                               }

                                               } catch (e) {}

                               }

                              

                               if(userIdAux == playerAux.id){

                                               doAnythingEnemy(playerAux, keyCodeAux, posXAux, posYAux, direction, userIdAux);         

                               }                                             

                } else if (messageData[0] == MEN_TYPE_JUGAR) {       //Mensaje tipo JUGAR

                               addListener(document, 'keydown', keyDown);           //Se le da teclas

                              

                               messageGeneral = '';

                }

}

2.2.3.  Método endSala

Este método se le llamará desde la API cuando a esta le llegue algún mensaje de END_SESSION, este método tendrá que tener lo necesario para reiniciar el juego sus variables o lo que se estime oportuno.

 

3.           Uso en Chrome

3.1.    Configuración y carga

Tenemos que tener instalador Chrome, la versión para desarrolladores, Chrome dev channel, también habrá que habilitar API de extensiones experimentales, esto se habilita en chrome://flags/, en herramientas, extensiones, aquí tener el modo de desarrollador activado sino no se vera nada, tras esto damos a cargar nueva extensión descomprimida, buscamos la carpeta de nuestro proyecto y le damos a aceptar, ya tenemos cargado el juego en Chrome.

3.2.    Esqueleto y juegos

Se proporciona ejemplos prácticos de juegos en JavaScript usando esta  API, estos son tres juegos y un esqueleto. El juego de Cowboys, Pong y un ejemplo básico solo de movimiento parecido al Cowboys, un documento explicativo y este tutorial.  Estos son ejemplos que se podrán o no seguir para la realización de un juego, son plantillas, ayudas, para el uso de esta API, habrá que meter los métodos obligatorios, después de eso cada programador podrá hacer su juego como más le convenga.

El esqueleto lleva lo necesario para que funcione con Chrome extensiones, archivos necesarios:

main.js: se le dice la página de inicio y el tamaño.

manifest.json: información del juego

inicio.html: pagina de inicio.

css: carpeta para las css.

images: carpeta para imágenes.

Js: carpeta para las js, esta llevara dentro el API.

3.3.    Tutorial BasicGame

Crearemos un proyecto JavaScript en Eclipse, por supuesto se podrá usar cualquier IDE o simplemente usar un editor de texto, ya que los juegos van en JavaScript y no necesitan de compilación, en este caso usaremos Eclipse Juno.

Creamos el proyecto, le damos un nombre,  y crearemos la estructura, esta será similar a la proporcionada en el proyecto BasicGameSkeleton, es una estructura simple para que funcione en las extensiones de Chrome.

Creamos las carpetas, css, para dejar los archivos css, la carpeta images, para las imágenes y la carpeta js, para los archivos js, aquí es donde estará el API de Smart Stream Menssage Bróker, este API consta de la librería JQuery, la librería del Q4S y la librería del Menssage Bróker, web y webVar, en esta carpeta js es donde meteremos los archivos del juego en nuestro caso game.js.

Los archivos que van en la raíz serán, inicio.html, una pagina simple de HTML que contendrá el juego, en ella importamos los css y los js, y ponemos un estructura simple proporcionada en BasicGameSkeleton, esta se podrá cambiar a gusto del programador, lo que si tendrá que contener son los elementos esenciales con los ids correspondientes, opciones, div_salas_insertar, div_salas, nameSala, maxJug, nuevaSala, labelMen, juegoCanvas, canvas, exitSala, idRomm, idPlayer, idLatencia.

Main.js, este archivo contiene información para Chrome respecto a la página de inicio y el tamaño.

Manifest.json, este también contiene información para el Chrome referente a descripciones, versiones, icono.

Con estos archivos ya tenemos lo necesario para comenzar la programación de nuestro juego usando el API Menssage Bróker con el Q4S.

En este caso practico todo lo meteremos en game.js, esto será a gusto de cada uno, cada uno creara sus clases o lo que crea conveniente, nosotros como hemos dicho usaremos game.js.

Se proporciona una plantilla que es la que seguiremos para este tutorial, en el cual realizaremos el juego BasicGameSkeleton que se proporciona con la información.

La copiamos en nuestro nuevo proyecto, una vez más esto es solo un guía, una posible forma de hacer las cosas, primero este código será para controlar las pulsaciones del juegos, después se pondrá una variable JavaScript para el control del juego, en esta meteremos todos los métodos los propios y los necesarios para la comunicación con el API.

Definimos variables, del juego, definimos teclas, definimos variables de control, definimos márgenes, definimos variables de los jugadores

Definiremos los métodos obligatorios para el API y para poder llamarlos desde esta, preInit, readResponse, endSala.

Definimos los métodos para pintar, para Las teclas y para los que controlaran a los jugadores.

Vamos ya con la implementación de cada uno de ellos:

·         preInit: a este método llegara el id de la sala, el id del jugador y el número de jugador, este ultimo lo guardamos en un variable, ponemos una variable de control a true para saber cuando pintar, precargamos las imágenes, inicializamos el canvas del juego, creamos la animación …

·         Cargamos con los datos obtenidos las etiquetas de HTML e iniciamos los jugadores.

·         iniciarJugadores: en este método se muestra una posible forma de inicializar los jugadores, guardamos el id del jugador, si fuera el 1, seria el MASTER, sacamos mensajes del juego e iniciamos el localplayer, también podemos aquí inicializar la animación, sino seria otro jugador, no el MASTER, le damos al localplayer el id que nos llega y llenamos los demás jugadores en un array, animaciones y mensajes, aquí según sea el usuario que nos llega, este será el ultimo o no, habrá que mandar los mensajes pertinentes al API “priorWriteAction”.

·         readResponse: dividimos el mensaje que nos llega del servidor, si fuera MEN_TYPE_BEGIN, esto significa que un usuario se ha conectado, sino es el último se mete en el array de jugadores, si fuera el ultimo MEN_ULTIMO, se mandaría un mensaje al API como que ya se conecto el ultimo y se guarda el jugador, si el mensaje fuera MEN_TYPE_JUGAR, se le dan las teclas y se empezaría el juego, si fuera del tipo MEN_TYPE_TECLAS, habría que realizar lo oportuno para mover al jugador que el mensaje diga que se ha movido, sacamos las variables del mensaje, sacamos el jugador que se moverá y lo movemos.

·         endSala: este método será llamado cuando algún usuario termine el juego, en el habrá que poner lo necesario para reiniciar el juego, removemos las teclas, sacamos mensajes, reiniciamos variables.

·         keyDown: cada programador usara el método que mas le convenga para la captura de teclas, nosotros aquí usamos addListener simple, lo que si se tendrá en cuenta es el movimiento de los jugadores, este no se podrá realizar si el API no lo permite, calculamos la futura posición del localplayer, formamos el mensaje al servidor, con el tipo de mensaje, el id del jugador que se quiere mover, la tecla pulsada, las posiciones y la dirección que leva, este mensaje lo mandamos con writeAction y si este retorna un 0 se moverá el jugador sino no.

·         LocalPlayer: jugador local, pondremos sus márgenes, iniciamos la imagen, su dirección y su id, según este le daremos una posición e imagen, le damos una velocidad definida mas arriba, y el método doAnything, que define su movimiento.

·         Enemy, es muy similar al anterior, lo único que el método doAnything va fuera para poder controlarlo desde el readResponse.

Una vez terminado el código nos dirigimos a la web de SSMB, aquí registraremos nuestra aplicación, pondremos un nombre y el numero mx de jugadores, le damos a guardar y nos aparecerá un identificador, este lo guardamos porque hay que ponerlo en el webVar de la API porque es el identificador de nuestra aplicación.

En webVar.js buscamos la variable APP_ID y ponemos el identificador que la plataforma nos ha proporcionado.

Con esto nos dirigimos al Chrome, en herramientas, extensiones, aquí tener el modo de desarrollador activado sino no se vera nada, si tenéis algún problema y el Chrome os da un error de permisos experimentales, tenéis que ir a chrome://flags/ y buscar API de extensiones experimentales y habilitarlo, tras esto damos a cargar nueva extensión descomprimida, buscamos la carpeta de nuestro proyecto y le damos a aceptar, ya tenemos cargado el juego en Chrome, solo abrir una pestaña y darle al juego.

Contenido