Facebook Trumps

Time

2007-11-20T21:41:00.000Z

It is amazing how much time I don't have .. it has been two months since the big push lead to th "alpha version"!

At the moment I am working on a different project, a sort of web-forum based around old picture postcards - a favour for my father.

All of this is to gather skills, so anything learnt about building a more conventional web app can be farmed back into Facebook Trumps.

I hope a better version of Facebook Trumps will arrive soon! At the moment it averages about 1 add per day, and I do have some people who have a couple of games a week!

That old chestnut.

2007-10-24T22:22:00.000+01:00

See: http://www.facebooktrumps.com/2007/08/my-friends-are-better-than-your-friends.html

My friends are better than your friends! That was the original idea, as it came to me - and lo and behold, the subject of the first comment I have had from a stranger on the Facebook Application page:

write.....so you dont actually play against your friends.......maybe thats the reason why im the only user [sic]

This guy has a point. The fun of it comes from challenging your friends. Thus I propose:

When you add Facebook Trumps it will save your Trumpstack.
When you challenge another friend who has added Facebook Trumps you will still play against the AI (if you can call it that), but rather than the Robot you will see your friends face and play against their friends.
People who have the app will get a "challenge me at Facebook Trumps" button on their profile, so I can get a bit of viral growth going.

So that's the plan. No requirement for live multiplayer, but an added dimension nonetheless.

Doesn't work with IE6!

2007-10-24T22:19:00.001+01:00

So what have my tests determined? The game doesn't work with IE6. The problems are twofold:

Styles on Trumpcards all over the place, need to work out why as doesn't look right.
Timeout on first attempt to get trump cards via RPC. Not on second.

This has been one thing which has stopped me progressing this application for a month. In honesty the other things were wanting to let it gestate for a bit and spending time doing exciting things with my lovely girlfriend.

Given my approach has been not to leave "broken windows", I needed to fix this - until Facebook came to the rescue! They are not supporting IE6 any more, recommending an update to IE7. This is great for me - if the platform does not support IE6 then there is not necessity for my application to.

What I do need however, is to have a check and then display "this browser not supported" when IE6 is found. Window not so much fixed but boarded up!

Alpha Version: Working!

2007-09-16T13:18:00.000+01:00

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.

More Fixed Windows.

2007-09-16T11:30:00.000+01:00

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!

Good Principles

2007-09-08T20:42:00.000+01:00

I was randomly reading the website for Tapestry, which is a Java web application framework. I make no use of Tapestry on this but I like their principles:

Simplicity - web applications shouldn't be rocket science!
Consistency -what works in small applications should work in large applications. Different developers should find similar solutions to similar problems.
Efficiency - applications should be performant and scalable
Overall: The simplest choice should be the correct choice.

Sounds good to me.

Broken Window Number 1: Replaced.

2007-09-08T18:27:00.000+01:00

I had a strange bug in the client part, which only occured when running the code after it was compiled to Javascript by GWT (GWT Web mode) and not when running in hosted mode (GWT Hosted mode). It was a pain to pinpoint the location of the error - I had to place popup messages stepped through the application to determine its location as all I got from the browser was "uncaught exception" and a GUI which failed to display. When I ran it in Hosted with the Eclipse debugger for support, well it was pointless as it worked perfectly.

I discovered the problem was with the code which deals the cards to the two players. This makes use of the .clone() method of the TrumpStack object, basically just an Arraylist which represents the stack of Trump Cards. Another method shuffles the cards, the deal method then gives the entire card deck to to player, clones a copy to the opponent, deletes the top half of the cards from the players deck and the bottom half from the opponent's deck.

private void dealPack() {
// Give opponent half cards.
_session.setOpponentStack((TrumpStack) _session.getPlayerStack().clone());
_session.getOpponentStack().clearFirstHalf();
_session.getPlayerStack().clearLastHalf();
}

Turns out the behaviour of .clone() differs between web-mode and hosted. In the hosted implementation .clone() makes a copy of the TrumpStack object (which is basically an Arraylist) and all the elements too. In the web mode version the elements are not cloned but just the object (?!). This is doubly odd as the Sun API (Sun API Documentation) implies that the web behaviour is correct, although when running in Java that is not what happened.

What happens is, when the code accesses the first card in the opponent's stack of cards it gets a null value, which causes an error in Javascript. That at least, in the absence of better Javascript debugging tools, is what I think is happening.

In any case I have implemented my own method called .copy() which does copy all the elements, which I have then been able to give a return type of TrumpStack, getting rid of the need to cast in the dealing code above. I have also place a check for nullity in method which accesses the opponents first card. This might happen for example if the player only has one friend.

Google Code

2007-09-08T16:46:00.000+01:00

I've created a Google Code project and put all the source code of my Facebook Trumps game onto it.

http://code.google.com/p/facebooktrumps/

Broken Windows

2007-09-02T15:44:00.000+01:00

I read the following from a book on Safari (http://safari.oreilly.com/):

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment- a sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality.

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

This seems like wisdom to me and at this point in the project I need to focus on this implications of it. Before I start on adding the new features I need to deploy and iron all the creases out of the current version.

Third Version of the Game

2007-09-02T12:30:00.000+01:00

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.

Overlaying application flow onto HMVC

2007-08-19T12:58:00.000+01:00

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.

Application flow

2007-08-19T12:34:00.001+01:00

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.

The client/GUI Framework.

2007-08-19T10:52:00.000+01:00

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.

Building the next iteration of the Game

2007-08-18T12:12:00.000+01:00

So far I have:

Created a foundation capable of authenticating to the Facebook API, and making extracted data availible to a GWT application.
Written a routine to, given a set of Facebook friend profiles, return a set of Trump cards - which is to say a set of statistics determined by the underlying profiles for each friend.
Developed/Stolen/Borrowed a UI framework sufficient for the Facebook Trumps game.
Created a module which displays a user's Facebook friends, the representation approximating a real playing card.
Deployed the above to a "live" host rather than a "developmental" one (i.e. webhost rather than my laptop).

All of the above is pretty solid, and was so before I started this site. In addition I also have the following:

Working but buggy and incomplete Game component.

Progress on this component has been stalled by a lack of clarity on my own behalf with respect to the two subjects taken up in previous posts. The rules of Trumps and my desire to allow you to play "against" someone, right away.

Having thought that through, the further steps are as follows:

Develop module to allow players to play a game of Trumps with a set of cards representing their own friends, vs. a CPU opponent.
Allow game to post back win/lose to server when done (and persist).
Deploy to webhost and ensure compatiblity with major browsers.
Invite people to use and deal with inevitable issues.

At this point I can start to entertain some of the diversionary thoughts about the future:

Multiplayer (who's set of cards?)
Scoreboard.
Integrate into profile (challenge me! button).

My friends are better than your friends?

2007-08-18T11:32:00.001+01:00

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:

Player 1 and Player 2 each have a different set of card representing respective friends.
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.

Gameplay, opponents, scoring, and winners.

2007-08-18T10:52:00.000+01:00

On the face of it Facebook Trumps is a straightforward idea. You play Trumps with cards representing Facebook friends, with statistics derived from thier Facebook profile. When you get into the detail of it, however, to implement it as a computer game, you have to flesh out a bit of the detail.

Trumps is a traditional game which has been played for centuries (http://www.phrases.org.uk/meanings/come-up-trumps.html). It is suggested that "Trump" is a 17th Century abbreviation of "Triumph", plausably- and that reference is made to the game in Shakespeare. The game was played with a traditional set of cards (http://en.wikipedia.org/wiki/Playing_card) with one suit being arbitarily declared as the "trump" suit. If two players hold cards of the trump suit the highest card is taken as winner. The game is more familiar when played with a set of statistics. There is more on some of the familiar modern interpretations of Trumps here: http://www.ultimate-top-trumps.co.uk/, the website of a modern commercial variant of the game, "Top Trumps" is availible here : http://www.toptrumps.com/.

Broadly, the game is played with a stack of cards where each card displays a set of unique statistical values representing an individual entity- the statistics shown are uniform and comparable between cards. The game begins where the cards are shuffled and dealt between two or more players. A player then takes a turn, selecting the most fortuitous looking statistic on the top card of their own deck. Each other player declares their own value for that statistic, the player with the highest value winning the round. The winner of the round takes the losing cards of all the other players and places them on the bottom of their deck. The next player will then take their turn. You then lose by running out of cards. You win by collecting the entire pack.

Server Side Technologies

2007-08-12T22:50:00.001+01:00

Java can be used on the server side via a servlet container- I chose http://tomcat.apache.org/ for the time being, as it is well documented, free and widely used.

The Facebook API

2007-08-12T22:49:00.001+01:00

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.

Client Side Technologies.

2007-08-12T22:40:00.000+01:00

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.

Language Choice: Java

2007-08-12T15:59:00.001+01:00

Plain HTML would not cut it for an interactive Trumps game. Many alternate web technologies exist however, many choices. For the client the instant favorite is Flash (http://en.wikipedia.org/wiki/Macromedia_Flash) and for the server most straightforward would be PHP (http://en.wikipedia.org/wiki/Php).

I chose Java. Java is a "proper" programming language - it is object oriented, typesafe and it is backed by two massive corporations (http://java.sun.com/ and http://www.ibm.com/developerworks/java). As I see in my day to day job massive corporations use Java to create complex business systems.

Skills gained in this language I believe will have more value than more lightweight languages such as PHP or "designer" oriented packages like Flash. Java is also free, unlike .Net, but very similar both in syntax and architecture (http://www.google.com/search?q=java+c%23).

The real alternate which offered itself was Ruby, or its web component, Rails (http://www.rubyonrails.org/). So many comments about this language rave about it and say how productive it is, and how it encourages you not to reinvent wheels. Both of these arguments are tempting, however for now I feel Java is more established, and for now, a better skill to learn.

Platform Choice: The Web

2007-08-12T15:52:00.001+01:00

The cart here comes slightly before the horse. Strictly, I believe a desktop application would be a more suitable form for a game. The Facebook API, which is required to access the friends this game is predicated upon, supports desktop applications so this certainly would have been an option.

The web, however, is the future- that is plainly how it seems to me. The web primarily is where I should like to gather skills and so I have chosen that this game will be browser based.

Other advantages exist, of course. The game becomes more accessible as the user does not have to download installation packages and run installers. The web has a far greater propensity to allow code to be platform neutral. The game must use the web as its platform.

Sensible Design

2007-08-12T14:39:00.001+01:00

I'm not a professional programmer, I did some programming at university and am exposed to the consequences of other people's code at work. Making a Trumps game from Facebook friends is not the most complex or difficult thing to do - however I want to do it right; as simple and as sensible as I can.

This is for two purposes - First in order that I can finish it, that it does not become lumpen and unmanageable and lead me just to give up - Second to learn, to spend sometime absorbing other people's experiences and hopefully improve my own skills. I want to become a professional programmer, and perhaps this can help.

My sources of wisdom, in other words what I have studied, are books blogs and articles from the Internet. O'Reilly have a service called Safari (http://safari.oreilly.com/) which I have been able to join. There are masses of software engineering and coding books on there. I have alse been able to follow discussions on usenet (via http://groups.google.com/) and application programming discussion websites (such as http://www.theserverside.com/). Other sources of information include developer blogs and API documents.

Facebook Trumps

2007-08-11T08:40:00.000+01:00

Facebook Trumps is a game which makes use of the Facebook platform. The client part of the game is written in GWT and the backend which queries Facebook is written in Java.

I am Jim Gumbley (http://www.jgumbley.com/) and have been creating this game for over a month now. This page is intended to support some of the decisions I have made. To actually play the game you need to log into Facebook and add it as an application.