The game is fairly simple. It's being hosted over here. You get a new sequence of 10 alphabets and 60 seconds to make as many words as you can with it. If you can make the high score board you've achieved greatness for yourself and your clan. But this won't last forever. Somebody could beat your score eventually. So play long enough and hard enough and if you're lucky you could get the right combination of letters that will allow you to stay on top.
- Baseline release
- Totally random sequence of 20 letters!
- Scoring by word length
- high scores board
- Improved look and feel (barely)
- Random sequences shortened to 10 letters
Version 3 - current release.
- Update to the data model - Game entity has a unique id
- Game entity now store the words submitted
- High scores board improved - added link that takes you to the Game entity's page to see the words submitted as part of the game.
- Sharded counters for game, score and word stats and stats widget
Feb 12th, 2014 - earlier today the app went over quota on DataStore read ops. This is in part due to the ajax calls that were occurring for the stats and high scores table updates at every word submission. With almost 10 words per minute being submitted you would expect at least 3 ajax calls / word submission x 10 calls / minute = 30 calls / minute. That is with just no words being submitted at all. I'm not sure how 50,000 read ops was hit so quickly. Since my read access to my datastore admin is not working due to exceeding the limit, I'll have no way of knowing how many read ops per call were being used up. Maybe tomorrow I will have some answers on this front.
Updated 2nd March, 2014. Figured out the cause for this. In a nutshell: too many sharded counters eat up the quota broth. How I keep track of the stats (number of games, number of words, average score per game) in the app is through sharded counter entities in the App Engine datastore. I was using one Entity per stat to do this at first, but then I saw the potential problems from a scalability standpoint. If more people started using the app, all would be contending for access to those 3 entities. So if there are more entities available to share the workload then the access contention and locking issues will be minimized. Take a look at the list of entities for Game counter.
So where do we go from here? I must reduce the number of sharded counters for one. Only create a new counter entity. when your counters cross a threshold value. Have a scheduled task to consolidate the totals into fewer counters that will speed things up as app has more counters than it needs.