Tuesday, June 28, 2011

fat client architecture

imagine you are organizing a solitaire league with your friends. the rules are simple, each of of you gets a deck of cards with some initial setup and plays at home. after each session your friends call you and tells you if he was successful or not and the time it took for him to end the game. as the host you keep a ranking of the times. after one month of competition the friend which successfully completed the game in less time is the winner.

there is nothing wrong with this story, right? no, wrong! What if one of your friends just cheated and told you a imaginary time? you know your friends, what about Allan he would probably do that to take the prize. obviously you and your friends would want to see how each one have played to ensure the time is even possible not to say true.

the story sound odd, and it really is. but when you see facebook games, sites with flash games like miniclip and even MMOs like World of Warcraft ALL of them, no exception, does that in some degree! they hand to the player their client (a deck of cards), the player plays it for sometime and then tells the server what he just did. the server, most of the time, doesn't do more then just accept what the client said and update the game state.

what happens, in your solitaire league, if you doubt your friends time? a good way to ensure that would be to tape the game session and send it over for audition. that is what a serious of posts in this blog will talk about in the next few days. i am going to use an ontology called game ontology project to record game sessions and a production system named Drools Expert to audit it and make sure no one is cheating...