Introduction to Project Waterloo

As I hinted earlier, I'm finally getting round to describing how we implemented our first Facebook game, Microsoft Research Project Waterloo. The game is between two players, each having one turn. The game board is a number of fields of play - in our case, the five cities; each player has some number of resources, here one hundred soldiers, and a turn is allocating all of your resources across the fields. For example, one very simple (and quite dumb!) strategy is to put all 100 soldiers in the first city and zero elsewhere; another simple (and not much better) one is 20 in each city. This game is quite well known and many people have explored the notion of optimal strategies, or performed experiments with real people, typically in laboratories. What we wanted to do was take this to more people (we're not the first, but I think we are the first to use a social network like Facebook.)

Because we wanted to integrate with Facebook, we were pushed towards exposing the game as some sort of web application: I'll cover server-side implementation for the next few posts, then spend a little time on the client.

I think it's pretty obvious that the server(s) will consist of some sort of database component, a game engine, and a web-facing layer - there are other architectures, but this one if fairly common (besides, we like databases). There are a number of technology options at each layer and even sticking within the Microsoft ecosystem and aiming to deploy on Azure, there are still a few decisions to be made before starting the implementation.

Starting with data: we could use SQL Azure or Azure table or blob storage. I'm fairly familiar with database programming, and felt that using a SQL database would be easier for me than using table storage. Our game's data load is very small, so the smaller size limits in the database than table/blob storage aren't a problem. The one thing I didn't do was evaluate the expected running costs of one vs the other but, again, I wouldn't expect data costs to be particularly high. Next, the modern way to talk to databases seems to be via the Entity Framework. However, our game data structure is so simple that that seems like overkill and, as I said, I'm quite happy using databases "directly" so that's what I chose to do instead. In fact, we aimed to push as much of the game logic into the database (I'll talk about this in a later post), so I used old-fashioned ADO.NET rather than even bothering with Linq to SQL. I'm not sure if all those were the right decisions, but the game does seem to be working just fine...

Because I was intending to put the bulk of the game login into the database itself, I felt that I didn't need to introduce any worker roles, and so just have a web application to essentially connect the user to the database. In other words, no communications mechanisms in there apart from ADO.NET to talk to the database and the web front end to talk to the client - no other inter-process communications at all.

As with the database, there are numerous options for the web application: I chose ASP.NET MVC 3 mainly because I wanted to see how different it was to ASP.NET, which I had used in the past. In the end, either would have worked well for this application, and there's not a lot to choose between them - again, I think this is because our application is so simple. Some aspects of the implementation would have been easier in Web Forms than using MVC, and vice versa.

In terms of getting hold of these tools to use yourself, you can get ASP.NET MVC at the ASP.NET site linked above, and the Visual Studio Azure tools from the Azure SDK page.

Incidentally, you might have come across the Windows Azure Toolkit for Social Games - unfortunately for us, we came across it after about 90% of our game was implemented, so it didn't make a lot of sense to switch...

As I said, we wanted to integrate with Facebook - we could have rolled our own C# connection mechanism based on the Facebook documentation but it seemed sensible to make use of the Facebook C# SDK. You can download relevant binaries (or source) from that site, but we chose to use NuGet. If you've not come across NuGet before, there's a good overview in the MSDN Magazine - it really is a convenient way to manage component dependencies when developing .NET applications (at least, as long as those components have been packaged for NuGet, and a lot of useful ones have). When I created the game web application, I added the NuGet packages FacebookWebMvc and Facebook.JavascriptMvcWebsite - NuGet's dependency checking automatically slurped in the other packages those depend on. For the client UI, we were able to specify jQuery and jQueryUI in the same way.

I think, at the end of all that, the development PC is ready to do some development on - I'll start that next time.