July 2011 - Posts
Anterior Post
Siguiente Post
El miércoles pasado, 20 de Julio, Microsoft liberó una versión “preview” del Windows Azure Toolkit for Social Games, y publicó una versión beta (con código) de un primer juego de demostración.
Pueden bajar el código desde Codeplex: http://watgames.codeplex.com/
Pueden jugar el juego en línea en: http://www.tankster.net/
La solución actual tiene estos proyectos:
Tankster.GamePlay es un Web Role. Hay un único WorkerRole. Tankster.Core es una librería de clases. Hay código interesante en Tankster.Common: utilitarios Azure para acceder a repositorios, un “job engine”, y más; todo ese código es independiente del juego, podría usarse en cualquier proyecto Azure.
Estos son mis primeros cortos comentarios sobre el código y la implementación de las “features” de este juego (recuerden, es un beta! Algunas de estas implementaciones podrían cambiar en el próximo “release”):
- Tecnología cliente: HTML5, Javascript, EaselJs (para programación del canvas, que permite implementar la parte gráfica).
- Tecnología servidor: ASP.NET MVC 3, algunas vistas Razor para pruebas (tema interesante: ¿Cómo probar el juego cuando sin usar el juego REAL), WCF Web API (otro tema interesante: ver tecnologías alternativas para manejar la actividad del juego. Es importante: un tema a cuidar en este tipo de aplicaciones es cómo responder a una gran carga desde el cliente)
- Hay un modelo en el cliente y entidades en Javascript. Vean See src/model, src/game.
- Hay un modelo del juego There is a server game model (see Tankster.Core class library project)
- Pueden jugar en modo “single player” o pueden elegir “multi-player online”. En este caso, el juego usa el ACS Portal para permitir la autenticación usando Federated Authentication:
- El código cliente reside en una sola página: index.html (con montones de archivos javascript referenciados desde ahí)
- El código cliente envía JSON (comandos) a los WCF Web API endpoints, usando Ajax/JQuery. Hay varios servicios publicados, exponiendo una interfaz tipo REST
routes.MapServiceRoute<GameService>("game");
routes.MapServiceRoute<AuthService>("auth");
routes.MapServiceRoute<UserService>("user");
routes.MapServiceRoute<TestService>("test");
- Mucha de la actividad del juego es enviado al servicio game/command. El servicio (en el web role) actualiza el estado del juego guardándolo en un blob en el Azure Storage. Fragmento de código:
// 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);
- El estado del juego es “poleado” por los clientes javascript consultando directamente el blob storage. De esta forma, el Web Role ASP.NET MVC tiene menos carga.
- El blob reside en el mismo dominio, así que no son necesarias llamadas Ajax cross-domain. Pero el juego está preparado para ese tipo de llamadas, reemplezando el objeto XmlHttpRequest por un componente Flash.
- El modo de juego Skirmish (cinco jugadores en una batalla) está hecho encolando los jugadores hasta llegar a cinco. Ese trabajo lo hace el Worker Role. Va publicando el estado en un blob que es “poleado” por los clientes.
- Las estadísticas son procesadas en el worker role: los clientes javascrip envían comando al Web Role, éste selecciona algunos para estadísticas y los envía a una cola Azure. No se ocupa de las estadísticas en el momento, para no afectar al cliente. Finalmente, esos datos para estadísticas se manejan en el Worker Role.
- User status, Game status, Skirmish Game Queue status son blobs.
- Las estadísticas se guardan en SQL Azure.
- El único worker role tiene un Job Engine (motor de trabajos) para procesar varias tareas, ejemplo “fluent”:
// Game Queue for Skirmish game
Task.TriggeredBy(Message.OfType<SkirmishGameQueueMessage>())
.SetupContext((message, context) =>
{
context.Add("userId", message.UserId);
})
.Do(
new SkirmishGameQueueCommand(userRepository,
gameRepository, workerContext))
.OnError(logException)
.Start();
Hay varios puntos para comentar y discutir, alimento para futuros posts. Seguramente la solución actual evolucionará y nuevas versiones serán publicadas (¿esta semana? ¿la próxima?). Pero es interesante ver publicado un juego en línea y su código disponible para analizarlo.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Ya saben, soy un gran fan de Farmvill. Me empuja a organizarme los días, usando los ritmos de las cosechas. Es un control de mi agenda diaria: si planto algo en mi granja, entonces reservo el tiempo para luego cosecharla. Y es un juego en línea donde uno puede jugar solo, sin molestar a otras personas. Pero hay vecinos, que son otros usuarios, registrados en la red social de Facebook.
Pero “I digress”, el tópico es la programación de este tipo de juegos, como Farmville: los problemas y desafíos de programar juegos sociales en línea. Curiosamente, los más exitosos juegos de la historia de la industria son juegos en línea, pero no los más sofisticados: en vez de juegos en tiempo real y 3D, Farmville es un jugador, con simple rendering 2D. Los desafíos en juego sociales no están en los gráficos o en la experiencia de usuario.
En esta serie, quiero enumerar los patrones y soluciones que podemos usar en juegos sociales y en línea. No soy un experto en el tema: el desarrollo de juegos no es mi parte de mi “expertise” (todavía ;-). Pero para mí, es una forma de ganar conocimiento de los problemas y posibles soluciones en este tipo de desarrollo. Me lleva a estudiar nuevas tecnologías, librerías, herramientas y conceptos.
Algunos subtemas que voy a visitar (con enlaces, ejemplos de otros, puede que algún código propio):
- Tecnologías cliente
- Tecnologías servidores
- Comunicación, mensajes
- Cloud Computing (para asegurar escalabilidad, rendimiento, disponibilidad)
- Estilos arquitectónicos y patrones a usar (mi tema preferido)
- Tipo de juegos: jugador en solitario, juego basado en turnos, tiempo real
- Tests (TDD, y otro tipo de tests)
Podría escribir dos ejemplos simples (un jugador, y otro de turnos), pero tengo que revisar mis tiempos para ver si puedo desarrollar esos entregables. Sería una buena excusa para ejercitarme en REST, Javascript, JQuery, HTML5 (y su canvas?), PHP, Azure, inteligencia artificial? ;-)
Es una larga viaje, pero este es el primer paso.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Este fin de semana, comencé a escribir un intérprete Lisp usando Javascript, para practicar el lenguaje. El código está quedando en
https://github.com/ajlopez/AjLispJs
Quiero destacar un tema: estoy usando TDD (Test-Driven Development). No podría comenzar un proyecto como eso usando el desarrollo tradicional: no soy “proficient” en Javascript, todavía. Usando TDD es la manera de comenzar a dominar los patrones y giros de Javascript. Mientras tanto, estoy escribiendo un intérprete Javascript en C#, para entender su sintaxis y semántica. El código está ahora en:
https://github.com/ajlopez/AjScript
La semana pasado, comencé a usar el framework de TDD en Javascript QUnit, en un proyecto de un cliente. Pueden bajarlo desde:
https://github.com/jquery/qunit
Despues de expandir el contenido (yo bajé el archivo .zip), pueden lanzar el index.html en el directorio test. El resultado:
¿Cómo empezamos con nuestros propios tests? Copié los archivos qunit.js, qunit.css a un nuevo directorio, y también copié ahí el código JQuery. Escribí un nuevo index.html con el contenido:
<html>
<head>
<meta charset="UTF-8" />
<title>QUnit First Test</title><link rel="stylesheet" href="qunit.css" type="text/css" media="screen"><script type="text/javascript" src="jquery-1.6.2.min.js"></script>
<script type="text/javascript" src="qunit.js"></script>
</head>
<body>
<h1 id="qunit-header">QUnit First Test</h1>
<h2 id="qunit-banner"></h2>
<div id="qunit-testrunner-toolbar"></div><h2 id="qunit-userAgent"></h2>
<ol id="qunit-tests"></ol><div id="qunit-fixture">test markup</div></body>
</html>
El archivo referencia a JQuery y a QUnit. El contenido de la página es importante: QUnit llenará esas secciones con los resultados de los tests. Si ven el index.html en el navegador:
No hay tests, todavía. Antes del tag de cierre </body> agregué el test más simple:
<script type="text/javascript">
test("First Test", function() {
same(3-1,2);
});</script>
Refrescando la página, el test está en verde:
Noten que uso el $ de JQuery para registrar código que se ejecuta AL FINAL de la carga del documento.
Pueden agregar algún test para el clásico Calculator:
test("Calculator", function() {
var calculator = new Calculator();
equal(calculator.add(3,2), 5);});
Ahora, el test da rojo:
Escribí el nuevo archivo calculator.js, con código casi mínimo para pasar el test:
function Calculator() {
this.add = function(x, y) { return x+y; }
}
Lo agregué referenciado en el index.html:
<script type="text/javascript" src="calculator.js"></script>
y recargué la página:
Todo Ok! Pueden usar su editor preferido. No hace falta una IDE.
Y pueden seguir aprendiendo Javascript (funciones como clases, prototipos, namespaces, alcance de variables, closures, etc..) escribiendo código Y USANDO TDD.
Enlaces que consulté:
Script Junkie | jQuery Test-Driven Development http://msdn.microsoft.com/en-us/scriptjunkie/ff452703.aspx
QUnit - jQuery JavaScript Library
http://docs.jquery.com/QUnit
Mis enlaces
http://delicious.com/ajlopez/javascript+tdd
Pueden bajar este ejemplo simple desde mi Skydrive: QUnit01.zip. Próximos pasos: escribir sobre AjLispJs, el intérprete Lisp que estoy escribiendo usando TDD.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez