Difference between revisions of "RoboResearch/Development"
(Networking Progress) |
(A little more progress) |
||
| Line 10: | Line 10: | ||
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". | 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 | + | '''What Works:''' |
* Adding challenges | * Adding challenges | ||
* Removing challenges | * Removing challenges | ||
| Line 17: | Line 17: | ||
* The "Prefer Group" feature | * The "Prefer Group" feature | ||
* Dynamically updating results for any item in the battle queue | * Dynamically updating results for any item in the battle queue | ||
| + | * Bulk thread operations | ||
| + | * Re-organizing the queue | ||
| − | To-Do: | + | '''To-Do:''' |
* Editing challenges in the queue | * Editing challenges in the queue | ||
| − | |||
| − | |||
* Adding "the rumble" as an option for the queue | * Adding "the rumble" as an option for the queue | ||
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]]) | * More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]]) | ||
| − | * | + | * A button to copy from the results table into wiki format |
=== Running Networked === | === Running Networked === | ||
The RoboResearch clients (the GUI and TUI) 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). | The RoboResearch clients (the GUI and TUI) 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). | ||
Revision as of 16:27, 26 September 2008
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
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
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)
- A button to copy from the results table into wiki format
Running Networked
The RoboResearch clients (the GUI and TUI) 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).
