Facebook Trumps

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!

Labels: guice, java, wideplay warp

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:

1. When you add Facebook Trumps it will save your Trumpstack.
2. 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.
3. 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.

Labels: application

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!

Labels: browser compatibility

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 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.

Labels: approach

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.

Labels: gwt, java, javascript