Programando Juegos Sociales en Línea (Parte 5) Nuevo Azure Toolkit

Published on Author lopezLeave a comment

Anterior Post 
Siguiente Post 

Dos semanas atrás, fue publicada una nueva versión del Windows Azure Toolkit for Social Games. Vean los posts de @ntotten:

Windows Azure Toolkit for Social Games Version 1.1.1
Windows Azure Toolkit for Social Games Version 1.1

La nueva versión implementa dos juegos simples en HTML5: Ta Te Ti, y Cuatro en Raya, usando vistas ASP.NET MVC, servicios WCF Web API, seguridad federada usando ACS, y Azure Storage. Pueden jugar en línea en:

http://watgames4.cloudapp.net/

Pienso que éste es un ejemplo más claro que el anterior (Tankster) que era una gran aplicación pero algo excesiva ;-). Veamos de entrar en algunos detalles de implementación de este nuevo ejemplo.

Totten escribió:

The biggest change we have made in this release is to separate the core toolkit from the Tankster game. After we released the Tankster sample game we received a lot of feedback asking for a simpler game that developers could use to learn. To meet this need we developed two simple games, Tic-Tac-Toe and Four in a Row, and included in the toolkit. The Tankster game is now available separately as a sample built on top of the toolkit.

While the new games included in the toolkit are much simpler than Tankster, they still show the same core concepts. You can easily use these samples as a starting point to build out any number of types of games. Additionally, you will find that many of the core components of the game such as the leaderboard services, game command services can be used without any modification to the server side or client side code.

En mi anterior post, mencioné un pequeño pero importante cambio en el proceso de acciones de juego: toda la lógica fue removida del código del servidor. Adoptando este camino, podemos escribir nuevos juegos sin cambiar el código del servidor. Podemos seguir agregando código en el servidor si lo necesitamos (por ejemplo, para agregar control al juego, detectar operaciones inválidas enviadas desde algún cliente, etc) pero es interesante tener una base de código que sea agnóstica del juego.

Abriendo la solución en Visual Studio, encontraremos archivos Javascript usados por los dos juegos. Podemos escribir un nuevo juego, reusando estos archivos sin cambios:

Los juegos están implementados como áreas:

Podríamos escribir nuevos juegos y publicarlos como paquetes NuGet.

Visualmente, el código Javascript cliente está organizado de esta manera:

Cada juego X (X = Ta Te Ti, Cuatro en Raya, uno nuestro) tiene:

XGame: la lógica del juego

XBoard: para dibujar el tablero en un elemento canvas de HTML5, y para detectar eventos de click en el mismo.

XViewModel: contiene el jugador actual y otros datos para ser usandos en el armado de la vista (los ejemplos usan  knockout.js, como MVC en Javascript)

XController: para procesar nuevos eventos y para coordinar los elementos de arriba.

La parte genérica:

UserService: métodos relacionados a usuarios: login, lista de amigos, etc…

GameService:  jugar las movidas, recibir movidas de otros jugadores, otras acciones (por ejemplo, se podrían enviar mensajes de chat).

ServerInterface: Llamadas Ajax (usando GET, POST, JSONP, Azure storage….) que son usados por la implementación de User y Game Service.

Temas para próximos posts: analizar el código Javascript, el uso del Canvas, tests de Javascript usando QUnit, comunicación con el servidor usando Ajax, cambio del Game Service (en Javascript) para usar un Node.js como servidor que reciba y reparta las acciones de 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 *