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

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/

Labels: google code, gwt, java

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.

Labels: approach, guice, gwt, java

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