Social Online Games Programming (Part 4) Processing arbitrary Game Actions

Previous Post
Next Post

There is a new release of Windows Azure Toolkit for Social Games:

Let examine a key change in this version. There is a new entry at 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);

There are TWO entry points to send game commands from client. Why? Having two URIs the server can be used by old clients and new ones. Note the “v2” in the UriTemplate.

The new Command2 (partial) code at implementation (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))
return SuccessResponse;

If you compare the old code (Command method) with the above code, the main difference is:

– The server doesn’t manage the logic of “who is the next player in turn”

– The server doens’t distribute the received command via a GameActionProcessor

And another change: game action type is an int, now. In the previous release, it was an enum, reflecting a fixed set of action types.

It still updates the game status blob adding the new game command (it could be a chat message, or a new shot). In this new way, THE SERVER CODE is more independent from game logic: the client code has the responsibility of select the next player. The notion of turn is leave to game client development. Now, the server code could be used for other multi-players games. Yes, we could have our own Social game! 😉

Windows Azure and worker/web roles are in charge of federated authentication, the formation of  new games, etc. But the engine is more “game agnostic” in this new release.

The client code sends commands:


1- Client code sends a new Game Action in JSON (i.e.: shot information (position, angle, force)).

2- A web role instance receives the Game Action and updates the list of actions in the corresponding game blob status (saving the actions of the last 10 seconds)

3- The other players are polling the game status, until they notice a new game action that implies turn change.

Client code could manage the case of timeout of its player, or the “going offline” of one the other browsers.


– Server code is more generic, and it could be used for other games


– The client code could be cheated (no server control, validation over game actions)

– More complexity (turn logic, timeout management, offline and latency issues, cheat control) at client code.

The litmus test: implementing a new game using the same server code. Some points to polish: skirmish mode is still hardcoded to a maximum of 5 players; the 10 seconds windows for game actions is arbitrary. Possible solutions: each game client code creates a new game (waiting for other players) specifying the minimum, maximum number of players and a timeout in seconds, and time window for game action status.

But remember, the example code is still in beta. A new version is coming.

Keep tuned!

Angel “Java” Lopez

1 thought on “Social Online Games Programming (Part 4) Processing arbitrary Game Actions

  1. Pingback: Social Online Games Programming (Part 5) New Azure Toolkit « Angel “Java” Lopez on Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s