Anterior Post
Siguiente Post
Hay un nuevo release del Windows Azure Toolkit for Social Games:
http://watgames.codeplex.com/releases/view/70342
Examinemos un cambio clave en esta versión. Hay un nuevo punto de entrada en Tankster.GamePlay\Services\IGameService.cs:
[WebInvoke(Method = "POST", UriTemplate = "command/{gameId}")]
HttpResponseMessage Command(Guid gameId, HttpRequestMessage request);
[WebInvoke(Method = "POST", UriTemplate = "command/v2/{gameId}")]
HttpResponseMessage Command2(Guid gameId, HttpRequestMessage request);
Hay DOS puntos de entrada para enviar comandos de juego desde los clientes. ¿Por qué? Al tener dos URIs el servidor puede ser usado por los clientes antiguos y por los nuevos. Noten el uso de “v2” en el UriTemplate.
El nuevo código (parcial) de Command2 en su implementación (GameService.cs):
// Add gameAction
var gameAction = new GameAction
{
Id = Guid.NewGuid(),
Type = commandType,
CommandData = commandData,
UserId = this.CurrentUserId,
Timestamp = DateTime.UtcNow
};
// Cleanup game actions lists
for (int i = 0; i < game.GameActions.Count(); i++)
{
if (game.GameActions[i].Timestamp < DateTime.UtcNow.AddSeconds(-10))
{
game.GameActions.RemoveAt(i);
i--;
}
}
game.GameActions.Add(gameAction);
this.gameRepository.AddOrUpdateGame(game);
return SuccessResponse;
Si comparamos éste con el viejo código (que sigue estando en el método Command) con el código de arriba, la principal diferencia es:
- El servidor no maneja la lógica de “quién es el próximo jugador en la ronda de turnos”
- El servidor no distribuye los comandos recibidos usando un GameActionProcessor
Y otro cambio: el tipo de una acción de juego es ahora un entero, un int. En la anterior versión del ejemplo era un enum, reflejando un conjunto fijo de tipos.
Todavía actualiza el blob de estado del juego agregando el nuevo comando (un comando puede ser un mensaje de chat, o un disparo). De esta nueva manera, el CODIGO DEL SERVIDOR es más independiente de la lógica del juego: el código cliente tiene la responsabilidad de elegir el próximo jugador. La noción de turno se deja al desarrollo del código cliente. Ahora, el código servidor puede ser usado para OTROS juegos multi-jugador. Y podríamos tener nuestro propio “Social Game”! ;-)
Entonces, los roles web y worker de Windows Azure están a cargo de la autenticación federada, la formación de nuevos juegos (al sumar jugadores que quieran participar), etc. Pero el motor es más “game agnostic” en este nuevo release.
Repasando como queda ahora. El código cliente envía comandos:
Pasos:
1- El código cliente envía una nueva Game Action en JSON (por ejemplo, información de un nuveo disparo (posición, ángulo, fuerza)).
2- Una de las instancias del web role recibe el Game Action y la agrega a la lista de acciones en el correspondiente blobg del juego (guardando solamente las acciones de los últumos 10 segundos)
3- Los otros jugadores están “poleando” el estado del juego, notando cuándo una game action implica un cambio de turno. Y si reciben disparos, los van mostrando en cada browser.
El código cliente podría manejar también el caso de un jugador que pasa a “offline”, mediante un “timeout”.
Pros de esta nueva forma de manejar las acciones:
- El código del servidor es más genérico, y puede ser usado para otros juegos
Cons:
- El código cliente puede ser engañado (no hay controles, validaciones en el servidor)
- Más complejidad a implementar en el código cliente: manejo de turnos, “timeouts”, latencia, control de “cheat”.
La prueba ácida: implementar un nuevo juego usando el mismo código servidor. Algunos puntos para pulir: el modo Skirmish (cada jugador entra en un juego, esperando a que otros también entren) está todavía “hardcodeado” a un máximo de 5 jugadores; la ventana de 10 segundos para las acciones es arbitraria. Posibles soluciones: cada cliente de juego crea un nuevo juego (esperando a otros jugadores, o invitándolos) especificando el número mínimo, máximo de jugadores, el “timeout” en segundos, y la ventana de tiempo para mantener las acciones.
Pero recuerden: es todavía una beta. Una nueva versión está en camino.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez