Difference between revisions of "LiteRumble"
Skilgannon (talk | contribs) (Introduction) |
Skilgannon (talk | contribs) (updates) |
||
| Line 1: | Line 1: | ||
| − | + | The LiteRumble is a lightweight, easily deployable roborumble system which is designed to run on the free tier of the Google App Engine. | |
| + | The fill out automagically as they are given battles - no hardcoded rumble names or configurations. Because of this and the ease in deploying it should be perfect for in-class or in-office competitions. One of my goals for this was to be able to have a rumble setup which would never need any maintenance. | ||
| − | It is designed to serve vanilla HTML - no | + | It is designed to serve vanilla HTML/CSS (w3c validated) - no JavaScript or anything fancy. All sorting of columns is done server side through linked GET arguments - so click on column headers to sort by that column! |
| − | + | Here's the link for my 'official' hosted version: [http://literumble.appspot.com LiteRumble.appspot.com] - feel free to create new rumble categories on it as you want! Also, let me know on the comments page if you do, I'm interested to see what is happening. | |
| − | + | I've released the code under <i>[http://creativecommons.org/licenses/by-nc-sa/3.0/ Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License]</i>. It is hosted on [https://bitbucket.org/jkflying/literumble/src BitBucket]. If you want to deploy your own just change the name to whatever you want in <code>app.yaml</code>, create the newly named app on the app engine and deploy! All you need to do then is point your upload client at it, run the client and the rumbles should appear with whatever wild, fancy configurations you want automagically appearing. If you want specific rumbles not to get priority battles (eg. mini, micro and nano) you need to set that manually using the Datastore Viewer in the App Engine admin console. | |
| − | + | Some of the scoring I've done differently to Darkcanuck - I have Win% instead of PL (so it doesn't fluctuate with number of bots), and in Melee my survival is not as a bot-specific %, but rather as an 'out of total rounds' % (the 1v1 won't be affected). The scores ANPP (Average Normalised Percentage Pairs), Vote (percentage you are best against), NPP (Normalised Percentage Pairs) and KNNPBI (K-Nearest-Neighbours Problem Bot Index) are all calculated as a batch run twice a day, so you won't see the latest results from them immediately. | |
| − | + | Due to the restricted writes on the free tier of the App Engine I haven't got any per-client data correction - in fact, it may just occasionally lose 1 or 2 uploaded battles due to my memcached delayed writes. I initially put this in, but had to take it out again as it was taking too many writes to work decently. If I have to put this in again it will be based on keeping separate scores for each uploader, and then blacklisting uploaders if I find they have bad results and making a new master scoreset from the valid uploaders. The uploaders would be merged into the master every now and again and their history dropped - perhaps in two stages to allow for us to spot errors. | |
| − | + | Take a peak around and tell me what you think. Submit battles if you have spare cycles, it should handle it OK as long as you don't use more than a couple clients per person =) If it does run out of writes the quota will reset once every 24 hours. I have it designed to just write the changes to memcache once the write quota is reached, and when the quota is reset it will dump all of the changes the first chance it gets. So if you see "Quota Reached" messages in your client, don't worry, it is handling it all gracefully behind the scenes. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 19:58, 27 October 2012
The LiteRumble is a lightweight, easily deployable roborumble system which is designed to run on the free tier of the Google App Engine. The fill out automagically as they are given battles - no hardcoded rumble names or configurations. Because of this and the ease in deploying it should be perfect for in-class or in-office competitions. One of my goals for this was to be able to have a rumble setup which would never need any maintenance.
It is designed to serve vanilla HTML/CSS (w3c validated) - no JavaScript or anything fancy. All sorting of columns is done server side through linked GET arguments - so click on column headers to sort by that column!
Here's the link for my 'official' hosted version: LiteRumble.appspot.com - feel free to create new rumble categories on it as you want! Also, let me know on the comments page if you do, I'm interested to see what is happening.
I've released the code under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. It is hosted on BitBucket. If you want to deploy your own just change the name to whatever you want in app.yaml, create the newly named app on the app engine and deploy! All you need to do then is point your upload client at it, run the client and the rumbles should appear with whatever wild, fancy configurations you want automagically appearing. If you want specific rumbles not to get priority battles (eg. mini, micro and nano) you need to set that manually using the Datastore Viewer in the App Engine admin console.
Some of the scoring I've done differently to Darkcanuck - I have Win% instead of PL (so it doesn't fluctuate with number of bots), and in Melee my survival is not as a bot-specific %, but rather as an 'out of total rounds' % (the 1v1 won't be affected). The scores ANPP (Average Normalised Percentage Pairs), Vote (percentage you are best against), NPP (Normalised Percentage Pairs) and KNNPBI (K-Nearest-Neighbours Problem Bot Index) are all calculated as a batch run twice a day, so you won't see the latest results from them immediately.
Due to the restricted writes on the free tier of the App Engine I haven't got any per-client data correction - in fact, it may just occasionally lose 1 or 2 uploaded battles due to my memcached delayed writes. I initially put this in, but had to take it out again as it was taking too many writes to work decently. If I have to put this in again it will be based on keeping separate scores for each uploader, and then blacklisting uploaders if I find they have bad results and making a new master scoreset from the valid uploaders. The uploaders would be merged into the master every now and again and their history dropped - perhaps in two stages to allow for us to spot errors.
Take a peak around and tell me what you think. Submit battles if you have spare cycles, it should handle it OK as long as you don't use more than a couple clients per person =) If it does run out of writes the quota will reset once every 24 hours. I have it designed to just write the changes to memcache once the write quota is reached, and when the quota is reset it will dump all of the changes the first chance it gets. So if you see "Quota Reached" messages in your client, don't worry, it is handling it all gracefully behind the scenes.
