Difference between revisions of "LiteRumble"

From Robowiki
Jump to navigation Jump to search
(Introduction)
 
(updates)
Line 1: Line 1:
Something I've been working on over the last week, it's still quite rough but it's the thought that counts ;-)
+
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 JS, CSS or anything fancy. All sorting of columns is done server side through linked GET arguments.
+
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!
  
Through much hard work and thinking I've managed to get it to run in the free tier of Google App Engine. There is still work that needs to be done, but the main stuff is all up and working, if quite messy inside.
+
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.
  
Here's the link:
+
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.
  
[http://literumble.appspot.com LiteRumble]
+
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.
  
The other rumbles on the home page should fill out automagically as they are given battles - no hardcoded rumble names or configurations. One of my goals for this was to be able to have a rumble setup which would never need any maintenance.
+
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.
  
I'm also releasing 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].
+
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.
 
 
Some of the scoring I've done differently to Darkcanuck - I have Win% instead of PL, 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).
 
 
 
Due to the restricted writes 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. I may put it back in now that I have improved caching.
 
 
 
Take a peak around and tell me what you think.
 

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.