View source for User talk:Bnorm

Hey, nice to see you around again! --Voidious 05:24, 12 November 2007 (UTC)

• Thanks! It's nice to know that somebody still remembers me, I never really was that active on the wiki... but it is nice to be back. This new wiki really got my attention, hope I can help out somehow. --KID 05:35, 12 November 2007 (UTC)

"I am a now 19 year old PSEO collage student who sends all his free time on his laptop programing robots." Same here, just in middle school and 13! =) At least you probably know trig. --Awesomeness 00:46, 4 May 2009 (UTC)

Google code

Anybody else around here use google code for a subversion server for their robocode source code? I just started getting into subversion and had a local server for awhile and just recently made the switch to google code. Just curious to know if I'm the only one... --KID 23:23, 4 January 2010 (UTC)

Personally I don't use Subversion or any SCM for Robocode robot, but I have seen people who have Google Code project for their miscellaneous code. One sad thing about Google Code is it isn't support RWPCL :P --Nat Pavasant 13:09, 5 January 2010 (UTC)

A*

So I'm currently taking an AI class and we've been talking a lot about search algorithms lately. As I am also currently involved in the VirtualCombat competition, I was curious to see if I could take one of these methods to help me find the best path from starting position to flag to home base. I know that the battlefield is constantly changing so I just couldn't find one path and stick with it, I'd have to be doing some recalculating every tick. I guess my question is if anybody knows of any robots that use this kind of method for movement or if any authors have done some research into this area. It would be great to know what you guys think.

It also just-so-happens that my next writing assignment for the class is on this very subject. :-P I'll find something to write either way, but I just thought other opinions wouldn't hurt.

--KID 20:33, 14 February 2011 (UTC)

This is a pretty important algorithm in path-finding: wikipedia:Dijkstra's algorithm. We covered it in an algorithms class I took in college. You could try to frame the problem in a form that algorithm could solve - at least that's probably where I'd start. I don't really know of any bots that do this, since the only obstacles in most Robocode battles are other bots, which pose other concerns than just pathing around them. :-) --Voidious 20:39, 14 February 2011 (UTC)

We have not actually talked about that algorithm yet. Maybe he's saving it for later. And you actually hit on the problem that I'm having the most trouble with: framing the problem. As Robocode is a continuous space, I have to come up with some way to put it into a discrete space for most of the algorithms we've talked about to work. My current idea is to use the limitations of a robots movement to help and only consider the extremes of heading change which should yield a branching factor of 9 at most I believe. (3 choices for heading, 2-3 choices for velocity) The other question is with a branching factor like that, how deep do I go? I think you would at least have to consider 20-30 ticks ahead. Which is way to many nodes. Thoughts? --KID 20:53, 14 February 2011 (UTC)

Ah, I actually didn't know what A* was, but after some Googling, it sounds superior to Dijkstra's. So I guess you can ignore that suggestion. Anyway, you could split the field up into squares and estimate a cost for moving through each one. Or just come up with a few random movement options and evaluate them, instead of all options. That starts to sound a lot like min risk, though. I might just try a min risk type movement with some factor to favor getting close to the base. Though that wouldn't satisfy a desire to implement an A* solution... And 20-30 ticks sounds like a lot, but might not be that bad with an efficient algorithm. Ok, I'm done rambling. =) --Voidious 21:12, 14 February 2011 (UTC)

I am currently using min risk for my team in VirtualCombat but what I have noticed is that they tend to have a hard time of moving around an object. They also like to get stuck on outside corners of objects too... Maybe I could combine the two in some way, find a point that I want to move to, then find the best path on how to get there. This path would only have to be calculated once as if something happens, I will have to pick a new point anyways. This could lead into some interesting thread use... hmm... I've always wanted to use those things in Robocode... Anyways, the problem that I have with splitting the field into a grid is that the bot won't be able to make it to some boxes and then how do you smooth the path you choice to make it efficient? The random movement option sounds interesting... I guess I'm just going to have to go do some Robocode programming in the name of homework... bummer... :-) --KID 21:24, 14 February 2011 (UTC)

Regarding how to split the continuous space of robocode into discrete space, rather than splitting into squares I'd suggest you consider the approach of "navigation meshes" in this article which I came across a while ago. With axis-aligned rectangles/squares as the only obstacles, as I believe is the case in VirtualCombat, it would be easy to set up. In addition, perhaps the techniques in this article may be relevant for how to route through the space? --Rednaxela 01:23, 15 February 2011 (UTC)

Doesn't the negative mesh pathfinding relay on collision mesh for actual movement? For example, wouldn't run into robots if you place a few, simple negative meshes? About A*, I think your original idea of searching is the best, but add a few angle between extremes too. And I don't think you have to do it on graph (i.e. you don't need to split battlefield), you could just take Manhattan distance (or Euclidian) of point to be the cost. If you have five angle and two accls. (accl and decel), you would yield ten branches. With just ten ticks or fifteen ticks you could do Dijkstra anyway (it is just A* without cost, just traditional BFS). --Nat Pavasant 12:30, 15 February 2011 (UTC)

Another idea that I had to stir the pot: what about waypoints? If we statically create a bunch of waypoints throughout the map at the beginning of a match and remove paths and nodes as objects are discovered this might provide a waypoint system that would be a lot simpler to find a path through. Then the bot could just be told which waypoint it's trying to get to next. This of course would only have to be used as long as the path between the bot and it's destination is blocked by some object, otherwise just go straight for it. --KID 22:55, 16 February 2011 (UTC)

I'm not sure who I should contact about this but I would like to change my username to "bnorm". I read online that an admin has to do that but I'm not sure who that is around here anymore.

Looks like we need to install Renameuser extension? Or did you see info on some other way to do it?

FYI - main admins are me / Skilgannon / Rednaxela. Well, we're the ones with RoboWiki admin access and SSH access to the server. A few other trusted folks recently got admin privs just to the wiki itself. (So they could rename if we had that extension, but couldn't install it.)

Yeah, that's what I saw too. If you don't want to install it I could always just create a new profile and redirect everything. But I do like having a User ID of 7... :-)

No it's fine, I'm happy to install it. But in that case it will have to wait a few hours until I'm home from work and dog park. ;)

No rush. I didn't think I would get a response for a couple days anyways.

Any update?

Sorry man, I'll try to remember to take care of this tonight.

Thank you sir!

Yep just copy the whole directory of robocode and you can run as much rumble clients as you want. About the could not load robot.. is this while you start the client and he wants to load the missing bots? This is quite normal because robocode repository (some main bot source) is down again. You should be fine if you grab the current bot zip from the rumble start page this one should be up to date (just copy the bots to your robots directory)

take care

You can get missing bots here, thanks to Rednaxela: [1] - we should link this somewhere.

I'd try deleting robots/robot.database (and maybe robots/.data) so that it rebuilds the cache and see if that fixes the missing bot issue. I've been copying my RoboResearch dir to a RamDisk lately and seems like sometimes I have to rebuild if I run from a new location.

I run 1 instance per core in tests, sometimes with a slightly increased CPU constant, but for the RoboRumble, I think the consensus is to err on the side of caution and 1 run less than the number of cores, since Java / Robocode / operating system incur some overhead.

Several times when a particular rumble directory has seemed to get spotty on me, I've opened the actual robocode client in that directory, had it clean the robot cache and then shut it down. This has worked like a charm every time, since (I think) it deletes the relevant directories and fully rebuilds the robot database from the available .jar files. Cleans up the place, as it were.

It is linked on RoboRumble/Starting_With_RoboRumble its the "latest bot archive" :)

@kid you can use the same user name for all your configurations.

I think I just needed to have the robot directory rebuilt. When I deleted the directory and grabbed the latest bot archive it started working again.

So I have three instances running on the server (rinzler) and one running on my personal computer (tron). I should be looking at actual cores and not threads, right? Because the Xeon in the server has 4 cores but 8 threads. And the Xeon in my personal computer has 4 cores and 4 threads. Three instances each?

I don't have much experience with hyperthreads, so I would say to experiment with it to see how many you can run without a performance hit. People posted some good benchmarks here for multi-threaded Robocode on their systems, some with hyper-threading: User_talk:Voidious#CPU_benchmark_advice_47. You may well be able to run 5-6 without any issues.

But 3 on each system is already quite a few rumble clients. :-)

I found threads can help a lot. However, I manually double the CPU constant to account for the edge case where the threads aren't helping.

I was watching the CPU usage last night and I saw spikes as high as 70% but it averaged around 30-40%. I'll have to double the CPU constant and run 6 and see what happens.

Be aware that just increasing the CPU constant will make battles take longer too, for bots that ever skip turns. I'd use the same CPU constant when testing different numbers of threads if you're trying to deduce if the increased threads caused a decrease in performance per thread.

I increased the CPU constant from about 7M to 9M and am running 6 instances. Really turning out the results now!

Now I just need to start programming a robot again...

Man... I still feel obligated to run a client when I have a new version in the rumble, but damn, once your clients pick it up, it feels pretty useless. :-) You've got me yearning for a quad core "Robocode machine" again, maybe I'll actually pull the trigger this time.

These aren't actually "my" machines... I have two servers at work that I'm not using for anything useful so I thought I would help out a little. Now that I have two servers running 6 instances each I'm trying to be the top contributor in each area of the rumble. Silly goal, I know, but it makes me happy. :-)

I avoid messing with the CPU constant in "production" clients. It favors slowbots over the others, affecting scores and possibly the ranking.

But if you want to know how to completely disable turn skipping, add -Ddebug=true to the command line. I use it a lot during testing/benchmarking.

Hi mate. very impressive indeed. I hope you can keep it up for a while, its nice to see how fast the rumble stabilizes.

As for the CPU constant, as far as i can say it for my bots, they are still at the same APS after a couple of 1000 battles so to me it looks ok.

take care

I miss KID's rumble clients! =) Might have to pause my benchmarks and go to full RoboRumble power until we're caught up. I've been running just 1 client on my laptop when my bots have enough battles, but if I add the 3 clients on my new box, I can do ~1200 battles / hour (depends on the bots of course). And I've been doing BATTLESPERBOT=3000, so there are 6 bots that could use battles right now.

LiteRumble has full pairings (and is stabilizing quicker due to my more aggressive priority battles), I've been keeping track of my progress there =)

Neat! I definitely need to start working on my KNN ProblemBots - that's the killer feature of LiteRumble for me right now. =) I'd also like to see what it's like to setup a separate instance of it, too.

The bot/version comparison is a must have feature for me in normal RoboRumble usage, though. I spend more time looking at those than actual rankings.

I was planning to do that this week, but got distracted by somebody making very nice progress in 1v1.

Hmm, that's quite a disparity for Diamond 1.8.1 between the two servers: 89.93 @ 2300 battles vs 89.76 @ 1400 battles. Maybe after the score comparison for bots/versions, we need a comparison between servers. =)

Yeah, I was noticing that. It could be due to the 1.7.3.0 vs 1.7.4.2 clients. I could whip up something simple similar to Darkcanuck's QueryAPI, although obviously it would have a few less fields.

Haha, ok, I was mostly kidding about the cross-server comparison app. =) 0.17 isn't that far beyond what I'd consider possible margin of error, and we've already established a few bots are acting differently in 1.7.3.2+. But on that note, your full-pairing RR server running on 1.7.4.0 may prove to be a great way to figure out which bots are having issues.

6 clients are up! I have been so busy at work lately that I have been forgetting to run these when I can. I did lose one server temporally but will hopefully be able to get it back this weekend. Then 12 clients will be cranking out results.

Wow, cool! Thanks KID!

I didn't realize you were running 6 per machine. I'm pretty sure I could push it on my new machine - I'm running 6 threads in RoboResearch with no issues - but so far I've stuck to 3. (It's a quad core with hyperthreading.)

How long is it taking a new robot to stabilize with my clients running? Right now I have 6 running one-on-one and 6 running melee. I'm thinking about changing up the ratio though.

Well, my clients do ~1200 battles per hour for 1v1 and when I compare to yours, your 1v1 clients are slightly faster. So a couple hours to get to ~2500 battles with just yours. Though having this much power, I've realized that scores can swing as much as .05 even beyond 3000 battles, which is kind of crazy. Feel free to dial it down however you'd like. =)

I was actually thinking about doing 8 clients on one-on-one and 4 on melee. A couple hours is too long... I'll have to dial it up. :-)

Well, even your 6 1v1 clients was enough for me to say, "hmm, I'm in no rush, I'll just leave my quad core box running benchmarks, and let my laptop and KID's clients handle Diamond 1.8.7." But you won't hear me complaining about going to 8. =)

Man, over a million 1v1 battles in 30 days. Congrats! Maybe you should be mining Bitcoins or something? =)