Programando Juegos Sociales en Línea (Parte 7) Procesamiento de las Jugadas

Published on Author lopezLeave a comment

Anterior Post

Quiero en este post presentar el procesamiento de las jugadas del ejemplo simple de Ta Te Ti. Involucra varias partes, desde la vista Razor que usa Javascript, hasta el Web Role, hasta el Azure Blob Storage.

Estos son los archivos javascript referenciados en la vista TicTacToe (en el archivo SocialGame.Web/Areas/Samples/Views/TicTacToe/Index.cshtml):

<script src="@Url.AreaContent("Scripts/jQuery.tmpl.js")" type="text/javascript"></script>
<script src="@Url.AreaContent("Scripts/knockout-1.2.1.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/game/ServerInterface.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/game/GameService.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/game/UserService.js")" type="text/javascript"></script>
<script src="@Url.AreaContent("Scripts/game/TicTacToeBoard.js")" type="text/javascript"></script>
<script src="@Url.AreaContent("Scripts/game/TicTacToeGame.js")" type="text/javascript"></script>
<script src="@Url.AreaContent("Scripts/game/TicTacToeViewModel.js")" type="text/javascript"></script>
<script src="@Url.AreaContent("Scripts/game/TicTacToeController.js")" type="text/javascript"></script>

Como escribí en el aterior post, tanto ServerInterface, GameService como UserService son agnósticos del juego, pueden reusarse para cualquier juego. Para cada nuevo tipo de juego X, lo que tenemos que programar son los XBoard, XGame con la lógica del juego, el XViewModel y el apropiado XController.

Al final de esa vista, se encuentra la creación de los servicios agnósticos del juego a usar desde el cliente:

var apiURL = "@this.ViewBag.ApiUrl";
var blobURL = "@this.ViewBag.BlobUrl";
var si = new ServerInterface();
var gs = new GameService(apiURL, blobURL, si);
var user = new UserService(apiURL, blobURL, si);

Las propiedades @this.ViewBag son llenadas en el servidor, en el controlodor de ASP.NET MVC (ver BaseController.cs)

La creación del controlador del juego:

// check for canvas, show an "Upgrade your browser" screen if they don't have it.
var canvas = document.getElementById('board');
if (canvas.getContext == null || canvas.getContext('2d') == null) {
    $("#game").toggle();
    $("#notSupported").toggle();
    return;
}
var board = new TicTacToeBoard(canvas);
var game = new TicTacToeGame();
var controller = new TicTacToeController(viewModel, gs, board, game);
controller.setGameQueueId(gameQueueId);
controller.start();


Pero la parte interesante está en el constructor del controlador:

function TicTacToeController(viewModel, gameService, board, game) {
    this.viewModel = viewModel;
    this.gameService = gameService;
    this.board = board;
    this.game = game;
    this.started = false;
    var controller = this;
    this.board.onMove = function (x, y) { controller.onMove(x, y); };
};


Notemos el this.board.onMove: el controlador se registra a sí mismo para procesar las nuevas movidas detectadas por el componente que maneja el tablero. En su método start(), el controlador se registra a sí mismo para procesar las actualizaciones detectas por el servicio de gameService:

controller.gameService.process(
        gameQueueId,
        function (queue) { controller.processGameQueue(queue); },
        function (action) { controller.processAction(action); }
        );

Examinemos el procesamiento de las jugadas.

1 – El componente del tablero detecta un click, determina la casilla, y envía una nueva movida al controlador, usando el callback onMove

2 – El controlador envía la nueva movida para la lógica del juego, para actualizar el estado (he omitido el view model en este gráfico)

3 – El controlador envía la nueva movida al game service.

4 – El game service envía un nuevo comando al web role, usando el server interface

5 – La API del web role recibe el nuevo comando

6 – La información del comando es agregada al blob que refleja el estado del juego, almacenado en el Azure Storage

Ahora, veamos el procesamiento en el otro cliente:

1 – El game service, usando un timer, va leyendo reiteradamente el stado del juego, usando la service interface

2 – La service interface, usando JSONP, recupera el estado actual del juego, desde un blob de Azure Storage

3 – Si una nueva movida es detectada en ese estado, el game service llama a una función callback provista por el controlador (el game service no tiene referencia al controlador).

4 – El controlador envía la nueva movida a la lógical de juego, que actualiza su estado (omití el view model en este gráfico)

5 – El controlador envía la nueva movida al componente de tablero, para actualizar el canvas

Un punto clave: el controllador no conoce NADA acerca de la service inteface, la API de WCF Web, el blob storage. Entonces, podemos cambiar el game service para que procese las movidas de otras maneras. Próximo post: modificar el game service para usar a Node.js como servidor de las movidas del juego.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

Leave a Reply

Your email address will not be published. Required fields are marked *