Previous Post
Next Post
In my previous post I wrote about the Windows Azure Social Gaming Toolkit, and its example multi-player online game Tankster. See:
http://watgames.codeplex.com/
http://www.tankster.net/
There are two interesting posts by @ntotten about the inner guts of the game:
Architecture of Tankster – Introduction to Game Play (Part 1)
Architecture of Tankster– Scale (Part 2)
It’s worth to mention Nathan’s text here:
Before we begin with an explanation of the implementation, it is important to know what our goals where for this game. We had three primary goals when building this game.
- The game must scale to handle several hundred thousand concurrent users.*
- The architecture must be cost effective.
- The architecture must be flexible enough for different types of games.
* This is the goal, but there are still some known limitations in the current version that would prevent this. I will be writing more about that later.
Now, I want to write about the use and implementation of blob storage in Tankster.
Why to use blob storage? If you play Tankster in practice mode, the Javascript client doesn’t use the Azure backend. Javascript can access web role and blob storage via Ajax/JSON calls. But in multi-player game (there is one kind of game, named Skirmish), each player client code polls the blob storage to get the game status (tank shots, chat messages, other status). But again, why blob storage? There are money reasons (cost of each access to Web Role service API vs. cost of read a blob), but I don’t know about Azure prices (you know, MVPs don’t touch the money 
. But there is another reason: to spread the workload, given some air to web role instances.
There is an AzureBlobContainer class in Tankster.Common library project:
public class AzureBlobContainer<T> : IAzureBlobContainer<T>
{
private readonly CloudBlobContainer container;
private readonly bool jsonpSupport;
private static JavaScriptSerializer serializer;
public AzureBlobContainer(CloudStorageAccount account)
: this(account, typeof(T).Name.ToLowerInvariant(), false)
{
}
public AzureBlobContainer(CloudStorageAccount account, bool jsonpSupport)
: this(account, typeof(T).Name.ToLowerInvariant(), false)
{
}
public AzureBlobContainer(CloudStorageAccount account, string containerName)
: this(account, containerName.ToLowerInvariant(), false)
{
}
//....
The class use generics. Type T could be a Game, GameQueue or another .NET type. You can reuse this class in other projects: it’s “game agnostic” code. The many constructors add flexibility for testing purpose.
This is the code to save a typed object to a blob:
public void Save(string objId, T obj)
{
CloudBlob blob = this.container.GetBlobReference(objId);
blob.Properties.ContentType = "application/json";
var serialized = string.Empty;
serialized = serializer.Serialize(obj);
if (this.jsonpSupport)
{
serialized = this.container.Name + "Callback(" + serialized + ")";
}
blob.UploadText(serialized);
}
The object (type T) is serialized to JSON. AND not only JSON: note that a there is a Callback (you could remove this part if you don’t need this feature in your project). Then, a game object is saved as (I stolen …errr… borrowed this code from Nathan’s post):
gamesCallback(
{"Id":"620f6257-83e6-4fdc-99e3-3109718934a6"
,"CreationTime":"\/Date(1311617527935)\/"
,"Seed":1157059416
,"Status":0
,"Users":[
{"UserId":"MxAb1iZtey732BGsWsoMcwx3JbklW1xSnsxJX9+KanI="
,"UserName":"MxAb1iZtey732BGsWsoMcwx3JbklW1xSnsxJX9+KanI="
,"Weapons":[]
},
{"UserId":"ZXjeyzvw7WTdP8/Uio4P6cDZ8jmKvCXCDp7JjWolAOY="
,"UserName":"ZXjeyzvw7WTdP8/Uio4P6cDZ8jmKvCXCDp7JjWolAOY="
,"Weapons":[]
}]
,"ActiveUser":"MxAb1iZtey732BGsWsoMcwx3JbklW1xSnsxJX9+KanI="
,"GameRules":[]
,"GameActions":[]
})
Why the callback? To support JSONP:
http://en.wikipedia.org/wiki/JSONP
JSONP or “JSON with padding” is a complement to the base JSON data format, a pattern of usage that allows a page to request data from a server in a different domain. As a solution to this problem, JSONP is an alternative to a more recent method called Cross-Origin Resource Sharing.
Under the same origin policy, a web page served from server1.example.com cannot normally connect to or communicate with a server other than server1.example.com. An exception is the HTML <script> element. Taking advantage of the open policy for <script> elements, some pages use them to retrieve Javascript code that operates on dynamically-generated JSON-formatted data from other origins. This usage pattern is known as JSONP. Requests for JSONP retrieve not JSON, but arbitrary JavaScript code. They are evaluated by the JavaScript interpreter, not parsed by a JSON parser.
If you are a newbie to JSON and JSONP, this is a short tutorial/example using JQuery (the same library used by Tankster client code):
Cross-domain communications with JSONP, Part 1: Combine JSONP and jQuery to quickly build powerful mashup
But (you know, there is a “but” in every software project Azure blob storage doesn’t support the JSONP URL (that has a randomly generated callback id):
Query JSON data from Azure Blob Storage with jQuery
There is a proposed solution in that Stack Overflow thread. Agent Maxwell Smart would say: ah! the “old trick” of having the callback in the blob!
dataCallback({"Name":"Valeriano","Surname":"Tortola"})
You can read a more detailed description of problem/solution with example code at @woloski’s post (good practice Matthew! write a post!):
Ajax, Cross Domain, jQuery, WCF Web API or MVC, Windows Azure
One problem to point: note that the callback name is “hardcoded” in blob storage. The gamesCallback present in game status blob should be the name of a global function. But you can change the blob text to whatever valid Javascript code.
And the client code? You can study the gskinner code at Tankster.GamePlay web project, under src\ui\net\ServerDelegate.js:
(function (window) {
goog.provide('net.ServerDelegate');
goog.require('net.ServerRequest');
var ServerDelegate = function () {
throw new Error('ServerDelegate cannot be instantiated.');
};
var p = ServerDelegate;
p.BASE_API_URL = "/";
p.BASE_BLOB_URL = "http://tankster.blob.core.windows.net/";
p.BASE_ASSETS_URL = "";
p.load = function (type, data, loadNow) {
var req;
if (p.CLIENT_URL == null) {
p.CLIENT_URL = window.location.toString();
}
//....
There is an interesting switch:
switch (type) {
//Local / config calls
case 'strings':
req = new ServerRequest('locale/en_US/strings.js',
null, 'jsonp', null, 'stringsCallback'); break;
//Game calls
case 'endTurn':
req = new ServerRequest(apiURL+'Game/EndTurn/',
null, 'xml'); break;
case 'leaveGame':
req = new ServerRequest(apiURL+'Game/Leave/'+data.id,
{reason:data.reason}, 'xml', ServerRequest.POST); break;
case 'playerDead':
req = new ServerRequest(apiURL+'Game/PlayerDead/',
null, 'json'); break;
case 'gameCreate':
req = new ServerRequest(apiURL+'Game/Queue', data,
'xml', ServerRequest.POST); break;
case 'usersGame':
req = new ServerRequest(blobURL+'sessions/'+data,
null, 'jsonp', null, 'sessionsCallback'); break;
case 'gameStatus':
req = new ServerRequest(blobURL+'games/'+data,
null, 'jsonp', null, 'gamesCallback'); break;
case 'gameQueueStatus':
req = new ServerRequest(blobURL+'gamesqueues/'+data,
null, 'jsonp', null, 'gamesqueuesCallback'); break;
case 'notifications':
req = new ServerRequest(blobURL+'notifications/'+data,
null, 'jsonp'); break;
//User calls
case 'verifyUser':
//...
See the ‘gameStatus’ polling: it uses ‘jsonp’ as format. My guess: the ‘gamesCallback’ parameter is not needed: you can use any other name, the function to call resides in the blob content.
I think there are alternatives to game status. The blob reflects the Game entity (see Tankster.Core\Entities\Game.cs). But it could be implemented in two blobs by game:
- One, having the initial status (players, positions,etc…) and the list of ALL the history of the game (think about to implement a chess or go game, you need to save the history).
- Another one, having the “news” (last 10 seconds of game actions). So, the data to poll should be shorter.
The price to pay: web role service should update both. But that update only occurs when a player sends a move (shot, chat…). The poll of game status occurs in every client, triggered by a repeated timeout. Actually, the game blob keeps the last 10 seconds actions AND initial status, weapons, etc…. Each client polls that info. In case a client disconnects and reconnects, it could poll the “complete game” blob to be in sync again.
The separation of that info in two blobs should improve the scalability of the solution. But you know: premature optimization is the root of all evil . If you take that way of store and retrieve games, you should run some stress or/and load tests to have a really measure of such decision impact.
More Tankster code analysis, patterns, and social game dev in general: coming soon.
Some links:
WAT is to Social Gaming, as Windows Azure is to… | Coding4Fun Blog | Channel 9
Thanks! They mention my post
Episode 52 – Tankster and the Windows Azure Toolkit for Social Games | Cloud Cover | Channel 9
Microsoft tailors Azure cloud services to social game developers | VentureBeat
Windows Azure Toolkit for Social Games Released to CodePlex – ‘Tankster’ Social Game Built for Windows Azure
Tankster, a Social Game Built for Windows Azure | Social Gaming on Windows Azure | Channel 9
Social Gaming on Windows Azure | Channel 9
Build Your next Game with the Windows Azure Toolkit for Social Games
Microsoft delivers early build of Windows Azure toolkit for social-game developers | ZDNet
http://www.delicious.com/ajlopez/tankster
Keep tuned!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
