Thread:Talk:RoboResearch/GitHub/reply (4)

Sorta off-topic, but some food for thought...

I took what I think is a somewhat novel approach to the GUI for the automation API in BerryBots. As background, you're writing a program that is run by BerryBots, like a bot - as opposed to Robocode, where you're writing a stand-alone program that embeds the Robocode engine. A big reason for this is so you can write automation code in the same language as the bots. But it also lets me do some of the heavy-lifting needed by most automation code, like multi-threading and user inputs.

So the Game Runner API provides the GUI/input functionality. You get a RunnerForm object when your Game Runner executes. You set what inputs you want, you decide when to show the form to the user, and after that you can fetch the values. The engine dynamically creates the appropriate GUI, shows it to the user, blocks until they hit OK/Cancel, and then the Game Runner resumes execution. You can see an example in simpletourney, which lets you run a tournament. I could also present a fully text-driven form, like if/when I write an ncurses UI.

I'd like to also provide the flip-side, so you could easily write a stand-alone program that uses BerryBots. That's actually not far off from the binary in use for the web UI. The script hit by the web UI is a stand-alone program that runs a BerryBots match from the command line and processes the results.

Lastly, it might also be cool to write a Game Runner-ish API for Robocode, maybe on top of RoboRunner. Something like running a Twin Duel tournament couldn't really be specified as a challenge file, but it would benefit from the multi-threading and some of the score details stuff that RoboRunner already has. Note that simpletourney offers the same tourney functionality as Twin Duel/Tourney Runner, but it's less code, everything's configurable at run-time via a GUI, and matches run multi-threaded.