GitHub
I finally put this up on GitHub, I know a lot of us have moved over to RoboRunner/Jogger, but it doesn't quite feel as well polished as RoboResearch. Also this way we can all put our hacks in one place.
On that note I have made a new build. It has a new and shiny Challenge Creator function now, right in the program. I still don't have all the new features RoboRunner added to the rrc format yet. In fact a spec should probably be decided one at some point. But I digress.
It still has some bugs I have to work out. I know a lot were reported here, but I somewhat lost track of which are fixed and which are not.
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.
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/reply (2).
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.
