Facebook Trumps

At first the idea of challenging your friends to a game of Trumps appealed to me. A "My friends are better than yours", "no they're not", "let's prove it!" scenario. This would clearly have some humourous appeal and capture the imagination, however there is tension between this goal, the actual game "Trumps", technical possibilities and the requirements of internet privacy.

Playing Trumps "head to head", so far as I can reason, would require the following:

1. Player 1 and Player 2 each have a different set of card representing respective friends.
2. The game would need to be remotely multiplayer.

Just these two things are massively problematic. If Player 1 trumps Player 2, then does Player 1 "gain" that friend from Player 2? Player 1 could then cycle through their entire stack and trump Player 2 with one of Player 2's own cards! Completely undermines the "my friends better" principle.

What about privacy! Where Player 1 is playing a card who Player 2 is not friends with, or worse has blocked, you are revealing statistics derived from the private part of that friends profile. While the statistics are not going to be greatly revealing this goes against an important principle and most likely breaches the terms of the Facebook API.

If you were going to challenge someone to a game of "My friends are better than yours" you would want to play live. I will have more to say on this in the future, but the kind of asychoronous messaging system involved in this are beyond what my webhost can provide at present (I would probably need to use Jetty http://www.mortbay.org/ rather than Tomcat, otherwise I would need 1 thread per connection and likely the limited resources provided by my webhost would crash under load). At least for the first iteration of the game I want to play vs. a CPU.

Labels: facebook api, multiplayer, privacy, scalability, Trumps

Facebook Trumps is a game, which would imply quite a great deal of interaction between the user and the web application. For scalability reasons I wanted the client part of the web application, running in the browser, to do a lot of the work. If a HTTP roundtrip is required everytime an action occurs or decision needs to be made my server is going to get very busy.

This implies quite a "fat" client, however the option I was anxious to avoid was applets (http://java.sun.com/applets/). I've seen some applets which work well - but their major pitfall is that they are basically desktop applications- albeit running in a sandbox spawned "through" a browser. Also you that "clunk" delay as the JVM initialises and the applet loads (that is if the user has a JVM installed!).

Much better to my mind is the Google Web Toolkit (http://code.google.com/webtoolkit/). GWT allows GUI and other code written in the Java language to be compiled down to Javascript and then run through a browser. This seems an ideal approach for this problem, given that I have decided on Java. Any standards based browser can display the interface created, and yet I can work in the Java language.

Labels: applets, gwt, scalability