About

The Robotypo platform.

Welcome proposals for new sub-platforms.

For ideas, questions and suggestions, please let me know in forum. It's highly appreciated that you can share more ideas about a new sub-platform, with good feature from math perspective.

If you have fun stuff to share, I'd like to add it to the Other fun stuff page.

By Verilocos, a coder who loves fun stuff.

verilocos@gmail.com

Behind-the-scene stuff of Robotypo

• Live within free quota.
  • Storage
  • CPU time
  • Count of API call
• Run arbitrary user-input Java code on GAE.
• Deadlock prevention. User can write arbitrary program. How about deadlock? It should be properly handled, for function call, class static initialization, and class instance initialization.
• Exception handling and logging.
• Mal-robot. Robots with errors are marked as malrobot, and are excluded from fights forever. For example, it takes too long to do a round (probably deadlock), or throws exception.
• Exception tolerance. Calculation time out of robots should be identified. However, sometimes the Google Appengine server is slow. It also leads to time out, especially for some complex robots. This should be tolerated, and gradually erased if such robots behave well.
• Secured environment. For both system security, and robot security. User robot should not change opponent's data by tricks.
• Time limit per each request. Performance is important on GAE.
• Auto fight. Robots are automatically arranged to fight others. There are several criteria for choosing robots:
  • There are not too many previous fight records (Do not fight more if they have already fought for many times).
  • The delta rating of the two robots are not too much. A strong robot does not need to fight with a weak one. This helps to protect strong robots from being pulled down by specifically designed robots only to beat them.
  • New robots will be arranged for auto fight with higher priority.
  • Centralized Auto fight occurs daily, and it is handled by back end server
  • Quick auto fight occurs periodically, which is handled by front end server. It helps to reduce the back log.
• Daily capacity maintenance. Entities in some kinds have a designed cap. A daily task checks them and cleans up old items when it goes out of designed capacity. For example, old fight results are deleted if there are too many of them. This helps keeping the storage within quota.
• Deletion maintenance. When a robot is deleted, it may have many associated result records. To assure quick user operation, the results are not deleted when a robot is deleted. A daily task checks all deleted robots. If any of the associated results is an orphan result (with both robots deleted), it will be deleted. It prevents the storage from always going up.
• Compression. Result compression shrinks the blob size 10 times smaller. So more results can be reserved.
• GAE Datastore maintenance handling.
• Browser support. Chrome, Firefox, IE, Safari, Opera.
• Opponent selection. Only opponents within reasonable rating range can be selected to fight. The data is dynamically retrieved and cached when selecting different robots.
• Statistics, monitoring, and notification.
• Compilation failure logging and reporting. Robots which failed in compilation are logged. User can mark the result as a system bug, so that Robotypo developer can improve the platform.
• Guest login, and switching.

Resources

Robotypo on Google Code
Robotypo on Github
Robotypo on Sourceforge

Software Libraries

SyntaxHighlighter (MIT license)
JQuery (MIT license)
OpenID Selector (New BSD License)
Beanshell (LGPL)