Facebook Trumps

I have deployed the first "fully working" test version of my game onto my webhost- and everything seems OK!

I've tested it in IE7, Firefox, Safari and Opera. I've tested it on the three laptops I have access to (2x Windows XP and 1x Vista) with no issues, and also it works on my Nintendo Wii(!). I've tried it with the two Facebook logins I have access to and 2 freinds so far have tried it out.

Next thing is to get about 20-30 testers and see what their comments/issues are- whilst I think about the next iteration of the game, as initially mentioned two weeks ago.

Labels: facebook api, Gameplay

I'm finding the idea of fixing everything before moving on a little tedious, but really its the right thing to do. Fixed Windows at present include:

• The stylesheet on this site: why was it orange? It is now blue.
• The link on this page now goes to "add application" rather than "play game".
• Upgraded host to Tomcat 6 (this was very involved).
• I can now view the Tomcat logs from the web.
• The logfile output location no longer throws an error everytime the game is started.
• The game is properly deployed and working.

Still more to do before I dabble with the next iteration!

• Complete "Finish Screen", displaying winner and option to restart.
• Present "Return to Game" button on Browse Trumps screen.
• Change last few "orange" links on this page.

So work to do ... the good thing is any of the 39 million people on Facebook can click the link on the right and actually play the game!

Labels: approach, facebook api, java, tomcat

I now have a "working and complete game component". I am going to deploy it to the server and perhaps get some people to try it. The architecture and logic of the application I am pleased with, however the look and feel of it is quite ropey! I need to engage in a process of gentrifying the game, which due to the component based architecture will be straight-forward.

For the next version of the game, which I would want to be of a sort of "beta" quality I am after the following:

• More on the server-side. I'm already using Guice (http://code.google.com/p/google-guice/), but I want to add things like persistence, for the game scores etc, but also to keep track of users who have successfully accessed the game (just their names and UIDs).
• Look and feel. I need it look more polished, I want to present an option to go "full screen", using a maximized browser window with just a control bar and URL field. Need more ques for the user to orient them to where they are in the game. Especially need to be more clear during opponents turn.
• Iron out issues which arise from testing. I need other people to test it live off the server and see what issues it throws up.
• Client Side Refactoring - I am tempted to make some alterations to the Event code and some major work on the EventCapableComposite which all the View components inherit from. Also to move the framework code into its own package.

Labels: facebook api, guice, gwt, hmvc, java

I need to put the conclusions of the past two posts together- I need to decompose the application structure implied by my flow diagram into a set of HMVC triads as described below.

The top level triad will have responsibility for moving the application from one phase, i.e. the game creation stage or the end game stage, to the next, and also for providing RPC functionality - I don't want that kind of code just spotted round the place. The Root/Container Triad:

• Model: Contains RPC methods and global state.
• View: Practically none - contains "Loading..." view.
• Controller: Co-ordinates transistions from one Triad to another.

After the Root triad has obtained the stack of Trumps for that appropriate player, it creates a child Triad to "setup" the game: The Create Game Triad:

• Model: Instantiate Game, Set players, Shuffle cards, Deal Cards, Toss Coin.
• View: Welcome and display outcome of game initialisation.

Next the Create Game Triad signals it is finished and the Root controller destroys that entire triad, replacing it with the Game Triad, which again is a child of the root controller. Due to the complexities of this view it is decomposed into further HMVC triads which are orchestrated by the Game Triad Controller:

• Player Turn VC Triad
• Opponent Turn VC Triad
• Show Result VC Triad

These are "cut-d0wn" HMVC triads, consisting only a view and a controller. All of the model code however is contained within the higher level Play Game Triad. Messages are passed between components and the Play Game Controller will create and destroy the alternate child Triads as required. Therefore the Play Game Triad looks like this:

• Model: Evaluate winner of turn functionality, Determine if game has been won functionality.
• View- Several View/Controller Triads as above.
• Controller: Manage interactions between all these! Create/Destroy child Triads.

Finally there is a End Game Triad to display the winner of the game and offer the oppotunity to return to the beginning of the game.

• Model: Send result via RPC (I will actually leave this until the next iteration of the game).
• View: Show End Result.
• Controller: Allow to go back to the start.

The structure described above will allow me to decompose my code into disgestible modular chunks and also due to the separation of functionality and standardisation of messaging will allow easy modification and improvement later. It won't be a matt of spaghetti.

Labels: approach, facebook api, gwt, hmvc, java

Again, with the aim of getting things straight in my mind, here is very rough and broad grained flow chart of how the client will work.

Labels: facebook api, gwt, hmvc, java

The model view controller pattern is the classic pattern adopted for GUI and client applications (http://en.wikipedia.org/wiki/Model-view-controller). MVC however, is quite a broad pattern, and so I went in search of further detailed recommendations and architectural guidance. Luckily, Java seems to be a language which is adopted by people with an interest in software engineering principles, therefore a great many resources are available.

The client component needs to obtain a stack of trumps via RPC, compute the various outcomes in the game, communicate rich perspective on the game state to the user and accept interactions from the user. The most appropriate framework I could find is the HMVC (Hierarchical MVC) which is treated at length here: http://www.javaworld.com/javaworld/jw-07-2000/jw-0721-hmvc.html.

Following MVC principles the view (GWT Widgets) are delineated from the controller (flow logic) and the model (rpc, game logic). HMVC however fills in some of the gaps with respect to how these elements are composed and structured, and how these elements can communicate amongst one another. The heirarchical aspect allows a root controller encapsulating global concerns (such as the game and the trump stack) to control various children, such as turn screens, scoreboards or outcome views.

A concrete and usable example of HMVC is availible here, tp://www.thecentric.com/wiki/index.php/HMVC_Tutorial, which can easily be adapted to work with GWT.

Labels: approach, facebook api, gwt, java

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 is keen to allow developers to build application on top of Facebook and integrate with their site (http://developers.facebook.com/). They have a ready made Java client library my application can use as an interface to obtain data and getting a developer key is free of charge. There is an easy web interface on Facebook for managing your application.

Facebook applications can operate according to a number of models. Desktop or external web applications can make API calls - given a session has been authenticated via the Facebook site. This is the one extreme of "separateness" from the Facebook site.

There is also the option of having you application generate "FBML" (http://developers.facebook.com/documentation.php?v=1.0&doc=fbml) which is passed to a Facebook server. Facebook then in turn renders this as part of the user's profile screen. This option is perhaps the other extreme, least "separate" from the Facebook site.

The third option, which I have adopted, has the application run inside of a "canvas" page (http://wiki.developers.facebook.com/index.php/Your_callback_page_and_you). A user who is "on" Facebook follows a link to a specific page within of Facebook. This page appears as a normal Facebook page with menus etc, but contains an IFRAME which dominates the major content area. It is here I shall have the Facebook Trumps application run.

Labels: facebook api, java