View source for RoboResearch/Development

This page will keep the current design for the next phase(s) of [[RoboResearch]].  I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas.  This page exists to solicit such input, so please don't be bashful!

=== The GUI ===
[[Image:RoboResearch.JPG]]

This is the current development GUI for RoboResearch.  In the top section you add and orginize which challenges will be run.  All the buttons should be obvious except "Group".  When you select multiple challenges and press group, they all get the same number in front of them (that's the group number).  An effort will be made to complete the battles for all challenges in the same group at about the same time.  As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.

In the bottom section you control what each of your concurrent battle-running threads does.  The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group.  If it does not, it will default back to running from group 1.  So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above.  One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.

There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES.  After all bots in the rumble have that many battles, RoboResearch would consider that entry "done".  You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".

'''What Works:'''
* Adding challenges
* Removing challenges
* Adding threads
* Starting, pausing and killing threads
* The "Prefer Group" feature
* Dynamically updating results for any item in the battle queue
* Bulk thread operations
* Re-organizing the queue
* A button to copy from the results table into wiki format
* Adding/removing bots from the results window of a challenge
* Seeing scores from each season of a challenge
* The "tied-for-best" scores for each reference bot are highlighted in the results window (currently defined as within two standard deviations of each other)

'''To-Do:'''
* Editing challenges in the queue
* Adding "the rumble" as an option for the queue
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])

=== Running Networked ===

The RoboResearch clients (the GUI and CLI) now interact with 3 distinct entities to accomplish their task: a BattleQueue, ScoreHistory and BotRepository.  These are 3 interfaces, with current implementations that can run within the same virtual machine.  Some of them take listeners in their arguments, for example a ResultsListener (defined by another interface) that receives any updates submitted to the ScoreHistory for a given challenge.  The greatest hurdle to running distributed across the internet is writing proxies for these interfaces that will pass the requests from one machine to the next.  Once we have something like that we can almost immediately run networked, with further efforts required to make fair battle queue policies and automatic uploading/downloading of required bots.  Then comes icing like the ability to specify "I want to prefer battles submitted by Simonton" (just as a random, hypothetical example).

Development work on the proxies has been started.  Basically I'm creating my own remoting system.  Is this necessary?  Does the world need another remoting framework?  Nope.  But it's fun.