Thread history

From Talk:RoboRunner
Viewing a history listing
Jump to navigation Jump to search
Time User Activity Comment
09:45, 28 August 2012 Wompi (talk | contribs) New reply created (Reply to Can i ask you to have a look at ....)
02:11, 28 August 2012 Voidious (talk | contribs) New reply created (Reply to Can i ask you to have a look at ....)
22:38, 27 August 2012 Voidious (talk | contribs) New reply created (Reply to Can i ask you to have a look at ....)
22:05, 27 August 2012 Voidious (talk | contribs) New reply created (Reply to Can i ask you to have a look at ....)
22:00, 27 August 2012 Skilgannon (talk | contribs) New reply created (Reply to Can i ask you to have a look at ....)
20:21, 27 August 2012 Wompi (talk | contribs) New reply created (Reply to Can i ask you to have a look at ....)
18:59, 27 August 2012 Voidious (talk | contribs) New reply created (Reply to Can i ask you to have a look at ....)
18:11, 27 August 2012 Wompi (talk | contribs) New reply created (Reply to Can i ask you to have a look at ....)
16:09, 27 August 2012 Voidious (talk | contribs) New reply created (Reply to Can i ask you to have a look at ....)
15:45, 27 August 2012 Wompi (talk | contribs) New thread created  

Can i ask you to have a look at ....

Hi mate. I'm not sure if i can bother you to have a look at the roborunner changes i made. Maybe the development state is a little to early, but i would like to know what you think.

What is new:

  • configuration - included, no need for external scripts and Windows should be supported as well
    • just type CONFIG and go through the options
    • this will make all internal robocode directories (depended how many installations you want)
    • it should be quite fail prof and checks the input for validity
    • you also can re configure it if you want to switch to another robocode version or something
  • challenges - can be switch on the run
    • type CHAL to go through the options
    • the challenge file format should be the same as it where before
    • all missing bots will be copied to the instances (well not new but it works like before)
  • the processes stay initialized
    • that means if you have once started the instances they are ready to take more battles after the challenge is over
    • or you can switch to another challenge and run it on these instances as well
  • you can stop running challenges
    • if you type STOP while the challenge is running all processes stop the current battles and can be restarted (they stay initialized)
  • with DEBUG you get additional informations (about the messages and some standard output from the processes) - i plan to make this configurable so you can see what you want
  • with AUTORUN the next time you start the program it takes the last configuration and challenge and runs it automatically
  • with STATUS you get the configuration and running state of all processes
  • HELP shows some help (not much yet)

What is not ready yet:

  • everything with result output is not finished yet
  • the results are coming back from the processes (and will be printed to the console) but there is no processing on these informations right now
  • i plan to take your code and then it will be possible to print results with whatever output you prefer (also offline results)
  • basically this means - you can say: show me result bla (avgDmg,score,cats,dogs - whatever) and it will be extracted from the current available results

I would be interested if it runs with all the cpu you have and has no concurrency issues. And if the usability is ok.

I had to change quite a lot but it has still the spirit of your RoboRunner and should work as same as yours. It is based on a very basic communication protocol to make it extendable for later needs.

You can find it here: roborunner_wompi.zip. To start it just run the ./rr.sh (same as yours)

If you don't trust the class files, the sources are included or available from GitHub as well.

You don't have to play much with it, just a quick start and configuration and one of the example challenges would be great. This should only take a couple of minutes.

Take Care

Wompi15:45, 27 August 2012

Cool, I'd be happy to take a look! I particularly like the idea of having a Windows-compatible setup. I think my main concerns from your changes are:

  • If RoboRunner stays running after finishing a challenge, that would screw up how I often use it, which is having multiple dev versions queued up in separate runs via shell script. So I'd either need to make that configurable, or also add support for running batches (which I guess would also be necessary if ever we have a GUI).
  • The interactive commands sound really powerful and I would definitely use them :-), like when a dev version is tanking and I want to just kill it and move onto the next one I have ready to go. But I also like simplicity and not having a big learning curve to using RoboRunner, so I just want to make sure it doesn't feel like "you have to learn a bunch of commands" in order to use it. So I'd like to make sure you can get by without knowing them, and/or that they're really easy to find and learn about. A lot of how I use RoboRunner is queueing up a few runs and leaving it for hours, so I definitely want to keep full support for non-interactive batch runs too.

Thanks man! Very cool to have someone else using and contributing to this. :-)

And I promise I have not forgotten about the custom scoring, I just haven't gotten to trying out some of my ideas with it. I was curious if you're still using that in your development? And if so, what kind of stuff do you collect and how do you like it?

Voidious16:09, 27 August 2012
 

Yes i rewrote most of the original stuff to be highly configurable. I'm a little unhappy with all the changes right now but i hope in the end it will pay off to have something really nice to run test beds. It's fairly easy to provide batch runnings with multiple dev versions. I just have to make the challenger input ',' separated and then it runs all challengers against the current challenge. Or maybe a input file where all challengers are included (linked to whatever challenge).

I guess i use RoboRunner in a sightly different manner right now. While writing on my bot i make a quick dev jar and let the runner make a couple of battles against my test bets. Therefor i can still make changes - and in the background the first results can show me if i was wrong or if i'm on the right track with my changes. That's why i wanted the processes alive. What i had in mind was having RoboRunner running infinitely and if a new version arrives he just grab it and runs the challenge against the new bot version . I also can switch the challenge on the run so if i think i need another view of my development state its just one switch to the console. I'm defiantly on your side of having RoboRunner making its stuff without maintainance. The console is just to have a tool to make changes if you think you have to. And beside of the config stuff its just a run command now.

The main reason because i switched to a communication protocol, is having the possibility to improve later versions with more fancy stuff like diagrams on certain battle states and such stuff. I don't know if you run some melee tests as well but for me its better to have just a couple of precise test beds rather than just let the challenger run against everyone above a certain level. I guess this will be more important if i go for an appropriate 1v1 strategy (someday :)).

About the custom scoring, its more custom battle field statistics for me. It's still one of my main targets for RoboRunner. Some of my statistics gave me a quite nice view of whats going on on the battle field and for what i should watch out. Like average field population (where are the most crowded spots and how was my survival at this spots) or bullets fired far away from me with more as 6 opponents on the field (how much did i catch a hit of these bullets and where would be a better place to stay). Yes its quite a bunch of other stuff to and most of it is just not worth it but, you know, sometimes you have to think strange.

Wompi18:11, 27 August 2012
 

Oh no - real tabs, braces on their own lines, lines over 80 chars?! :-) It's funny, at my last job, almost every file had its own different code style, so I was very flexible. My current job is much more rigid on code style, and now I realize I've also become more rigid... Might have to reformat some stuff, at least in the main package. :-) I just took a quick look for now, though. I'll look more and test out your stuff when I get home later. Btw, should I hold off playing with the code much if you're still making major changes?

The first thing I wanted to do with custom scoring was to track start positions for Diamond in 1v1, to see if there was any pattern to which rounds he lost. Like, when he loses 1 random round out of 35 to Raiko, is it because we started near each other? Or I started in a corner? Or I didn't start in a corner? Or is it just always the first round before we have much data? Seems like there could be a lot to gain just shoring up some of the "unlucky" stuff that can happen in a battle. But yeah, I realized most of the useful stuff you'd do with it would be custom stats like that, not traditional "scores" like with percent score or bullet damage. Passing values back from RoboRunner and storing them in the XML should be no problem, I just want to come up with a nice/simple/flexible API for the listener to log the values and RoboRunner to format them. I might want to peek at some of your code for the dynamic class loading, since I haven't done much of that before.

Voidious18:59, 27 August 2012

If you're wondering about Raiko (or any other multi-mode random movement bot), what I find is that I win the first round because of their Musashi trick / stop-n-go / anti-simple movement, and then whether I win the next two rounds is a matter of luck, until I can unlearn their anti-simple movement and learn their actual movement. Simultaneously, these rounds are the ones where their non-rolling-average VCS guns are still adapting quickly, so they get a decent hitrate against the surfing still.

Skilgannon22:00, 27 August 2012
 

Ah, very good points. The Musashi trick shouldn't last long (stops as soon as they're hit once), but certainly the 1+ rounds of stop and go would screw up my guns. Maybe it's worth special casing that and clearing gun data once you detect the switch.

And the relative fast-learning of their guns in early rounds isn't something I'd thought about much. Maybe there's a place for some light flattening early on as soon as you know they're using something besides simple targeting.

I've just been thinking a lot about all these bots that take 1-2 rounds off of Diamond (and DrussGT). If you're winning 95% of rounds vs a given bot, maybe you’re just a little consistency away from 99%. And it could be from simple stuff, like starting a round cornered or too close. But it might take some real research to figure out some causes (or just give up and accept "randomness" =)).

Voidious22:38, 27 August 2012
 

Hehe the formatting style discussion i know all to well :). I have no problem if you reformat it to whatever you think is appropriate, i'm used to read all kind of code style (working on it is another discussion :) ). I don't know if you develop with eclipse but if so, just give me your formatting file and we will see how it works :). I started programming when all these formatting rules made sense (80x40 terminals). You wouldn't come far with braces at there own line and lines over 80 chars but these days are long long gone :) and with todays monitor resolutions i don't see why i shouldn't use it. I'm surprised that you still have discussions on code style at work. We had some check in format at work and every one had to use it before checking in files to cvs. If you check out the files, just format it to whatever you like and thats it. Maybe i can convince you to give up the 80 char per line rule, because with all these method().method().method() calls it is quite hard to maintain a readable code line. Well, like said format to whatever you think is good :).

If it comes to changes, don't hold you back do whatever you want (in your branch or in mine no matter). This Git stuff is way more fail resistant to merges than cvs/subversion and i have no doubt that i can handle the changes. The code right now is still draft status and i haven't looked where i could bring some things together or should more open and bring it apart. I just wanted to bring it to life and start the improvements from there. I'm thinking of changing the communication anyway to RMI or TCP but for now i'm fine with the process in/out like you did. It's also ready to take a GUI (but thats not really something i'm thinking of right now). I'm not sure if i have the dynamic stuff included right now i guess it is still in another project but i think i will bring it over within the next couple of updates.

Reading about Diamonds start positions made me think if it would be rewarding to use the start position feature of the RoboCodeEngine. This would give you the opportunity to set all kind of interesting start positions and just rumble it out.

Wompi20:21, 27 August 2012

I basically use the default Oracle/Sun format and style guide, just with 2-space tabs (no real tabs). 2-space tabs makes 80 char lines a lot more reasonable, too. I generally don't auto-format because some stuff is still a judgement call, like breaking lines in the clearest way.

I certainly learned a long time ago that code style is just something you have to compromise on to get anything done in a collaborative setting. =) I didn't quite realize I’d become so accustomed to one Java code style until browsing your code. And yeah, I was also surprised at first that code style was so enforced at my current job. It was an adjustment after having the exact opposite situation at my previous job (just stay consistent within a given file). But now I like it, and/or am brainwashed. At a large enough company with a lot of code sharing, it kind of makes sense to just settle on something. Deep down I’m not actually a psycho about code style, but maybe keeping it consistent within each package makes sense, and wouldn't be too painful for either of us.

Voidious22:05, 27 August 2012
 

Ok, gave it a shot and everything seems to be working fine with 8 threads on my Linux box. Actually I like the feel of this environment more than I expected to, it's very cool. And I like the extra stuff you save in roborunner.properties now. Looks like some of the output is just incomplete for now (I didn't see overall scores at all?), and there's definitely plenty of room to polish up the usability side of things, but that stuff's a pleasure to work on once you have all the core stuff working. =)

I'd be happy to take a pass at improving some of the usability stuff, or just writing up a list of ideas, but maybe I'll wait a bit if you've still got some stuff in progress with this. Nice work man!

Voidious02:11, 28 August 2012
 

Thanks man. Sure thing, your improvements and ideas are very welcome. The current design is open for quite a lot of directions.

Like said, everything that relates to score processing (collect,save,average,overall score,smart battles) is not implemented yet. The results you can see, are the results of every battle and contain all available data field of onCompleted() BattleResults. They just have to be parsed and processed now. I just wanted to have the config, chal and messaging stuff to be ready because i know myself to well. Once implemented i probably don't touch it ever again because i don't like writing code around path, file and input checks. After thats finished now i can spend all time in doing the result/statistics stuff smooth and fluffy. Thats why i wanted to have your opinion about it, to make the related changes now.

Wompi09:45, 28 August 2012