knackFX posterous

it's good to have the balls

Can't wait for the 6.7.1

Netbeans 6.7 is out, the integration with kenai is really nice and there is still no javafx version of Netbeans 6.7: it's a shame!
The connection with kenai and the integrated chat window is a really usefull improvement. As we were to impatient to work with this new version we googled for hours and finally founded a release candidate for netbeans 6.7.1 with javafx (don't try to find it again, we tried with no success!). Just try it yourself: http://bits.netbeans.org/netbeans/6.7.1/rc/2009-07-16_23-01-10/

All your bases are belong to REST

So, after some work, user scores can finally be saved using some REST calls. Obviously, due to the very starting nature of our server side code, I won't type the URL here, since it could potentially result in DoS attempts (which is only due to the fact that, as any naive programmer, I underestimate the security cost and did not though security first). Suffice to say calling the right URL in POST mode will store a score, while calling the very same URL in rest code would output the following XML

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<list>
   <scoreDesc gameName="jezzballfx" score="1000" userName="Nicolas"/>
   <scoreDesc gameName="jezzballfx" score="1001" userName="Serj"/>
</list>

Next steps ? Well, there are some

  • Implementing guards for me to display quietly the publish URL without any risk.
  • Going from native GAE data storage to JDO storage (since the current code base implies many code copy)
  • Building a web UI for users to see their scores, and some other featuires ...

Besides, my friends should tell you soon that jezzballfx starts to have a knackIT look ...

REST in game

So, now a RESTFul hello world exists on Google App Engine, I can start woring on this brand new (to me) architecture : rest.
According to restlet documentation, the first step is to define what urls will be visible, before to define which services they will provide.
Obviously, before to define these urls, we have to define what we want to do server side.
For that, the wiki provides infos. Namely, what to do in first iterations. So, we have to
  • save player score each time he wants it to be saved (and has a login)
  • return a list of matching scores for
I do think all can be done with one URL call.
This call would be something like
http://knackfx.appspot.com/rest/scores
  • PUT will add a new player score for a game, it would require : player id, game name and score and would return list of nearby scores
  • GET with a score would display nearby scores
Obvously, we have to maintain a good enough code for allowing future versions to add things like game replay, comments, and so on ...
Well, now, it's time to say "This feature is just a bunch of code lines away !" and to start monkey coding :-)

Serve me good games

So, now my friends of the front-end team are starting to build walls, I think it's time for the server team to wake up from its eons long sleep, deep in the walls of the fabulous R'lyeh city.So let's start by some general considerations.
As mentionned in the wiki, one of the most required features is the ability to save scores server-side, and to comapre score between players in a (expected social) way (like, say, using geoip to get scores of players nearby).
To implement these features, our team has decided to rely upon, some buzzwords (which, in fact, can be considered as some serious players in their games) :
  • Google app engine for the infrastructure, hosting, admin, ... Indeed, we know that JavaEE free hosting providers are not that many. And we also know we will use Java for server-side. Obviously, there are more "modern" and "dynamic" languages. However, after having used them on other attempts, we know their dynamism come at the cost of maintainability (yep, this is a troll).
  • So we'll use Java on server
  • And, since we want to communicate with a client, we rely upon a REST architecture, implemented using restlet.
So, here are our bricks. Now come the hard part : how will we link them together ? Let REST it ...
In first multiplayer steps, user will have its score saved for each game it plays, so we will have to have a PUT with player name, game name, and score.
Obviously, a second call should be able to send last scores, and scores around player (say the 100 before and the 100 after).
Finally, since we rely upon Google architecture, and since we want to be good google-tizens, we may implement a request limiter, maybe based upon some restlet features ... But this will be the subject of an upcoming post.