GitHub
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:RoboResearch/GitHub.
Any chance you feel like elaborating on what you like about RoboResearch over RoboRunner? It would take a heck of a lot to convince me to waste 25% of my CPU time on JVM restarts again. From the command line, I honestly feel like RoboRunner is superior in every way. I haven't used the RoboResearch GUI or RoboJogger much though.
On that I agree. RoboRunner is definitely better on the command line. However I tend to live in the GUI world, and I feel it's GUI is quite a bit ahead of RoboJogger.
Though I now consider I could have just made my own front end for RoboRunner. Since that would probably be much easier then trying to hook it into RoboResearch.
Eh... I'm sure plenty of the RoboResearch UI code could be applicable to a RoboRunner frontend.
Just to chime in on the UI comparison. I recently came back to Robocode, and having been using the RoboResearch GUI in the past, I decided to try RoboRunner w/ RoboJogger. While I like RoboRunner's performance, I prefer the RoboResearch GUI over RoboJogger... but I think I'll end up going with RoboRunner CLI now, as I don't normally live in the GUI world anyway.
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.
