Robo Home | BenHorner | Changes | Preferences | AllPages

Is it possible that two event handlers are running simultaneously? I'm not 100% on how the threading stuff works... In an AdvancedRobot, you tell it the stuff to do, then call execute(), and your thread is blocked, but events still get kicked off right? So those events are running in a different thread than your run() method right? If so, does that mean that they could each be running in their own threads, and might be running at the same time? I'm particularly curious about onScannedRobot() in melee, when multiple robots might be scanned in a single turn, do I need to be careful about updating state? --BenHorner

In melee, onScannedRobot will be called once per robot that you scanned, in order of distance from you. The closest robot will be the first call while the farthest will be the last call. --David Alves

Ok, does the second call wait until the first is complete before it starts? If so, does that count against the amount of processing time your bot is allotted each turn? --BenHorner

Yes and yes. --David Alves

Thanks. --BenHorner

If two robots are moving in the same direction (and both forward), but the one in front is moving more slowly, and the one behind hits it, is that counted as a ram for both of them? --BenHorner

This is from the [[Robocode FAQ]]:

Q: What happens when a my robot hits another robot?
A: If your robot was moving towards the other robot when hitting it (i.e. ramming), your robot's move is marked as
   complete, and your robot receives 1.2 score points.   Both robots takes a constant 0.6 damage.
I don't know why I was considering to be a better source of information than the javadoc comments... Just because I read it before I knew the javadocs existed I guess. =) Now I will have to test it to find out which is right! --BenHorner

Ok, I just did a test, I rammed SittingDuck to death with Interactive before the countdown started... Interactive was disabled at the end (both received 0.6 damage per ram) and it scored 290.
Total Score 290
Survival 50
Surv Bonus10
Bullet Dmg0
Bullet Bonus0
Ram Dmg * 2 200
Ram Bonus 30
I'm thinking the non survival score 230 = 290 - 50 - 10 comes from: 30% bonus for the 100 actual damage done, and then 2 score points for each point of damage. So ram damage is the same for rammer and rammee, and I think the multiplier for score has changed from 1.2 to 2 since the FAQ was written... each point of ram damage is worth 2 score points (as opposed to the 1 for 1 ratio on bullet damage), so for a single ram of 0.6 damage, you get 1.2 score points. --BenHorner

Read carefully, per ram you get 0.6 damage and 1.2 scoring 'bonus'. That is a factor 2. Totally you ram 100 damage and thus get a 200 scoring points. -- GrubbmGait

Cool, thanks, a little bad math on my part. In fact, I think I'll edit it out right now so it doesn't confuse anyone else. --BenHorner

Has anyone noticed a "half turn advantage" in 1v1 matches? I was just going to try to do a modified RamFire to get something in the Rumble, because what I want to end up with seems so far away... So I have a "new" bot which is a copy of RamFire, going up against RamFire, I expected them to split pretty much 50-50, strangely though it seems like whoever I enter in the list first ends up winning about 2-1 (very consistently). Is that screen where you pick the bots also defining some kind of initiative (who gets to do their stuff first each turn)? If so, does the Rumble account for that? (I know I could look this up in the source code myself, and if no one knows off the top of their head, I probably will eventually) --BenHorner

For a while, I had myself quite convinced that a bot in a JAR file will win against the same bot compiled from source. Look at this list of 50 randomly generated coin flips, from http://shazam.econ.ubc.ca/flip/index.cgi?50:

 T H T H H H H H H H T T H H T H T H T T T T H T H H T H H T H T T T H H H H H T H T T T T T H T T T
Does it seem like there are more heads or tails? Actually, there are exactly the same number of each. As it turns out, most of the oddities in scoring results are simply random fluctuations (i.e. the run of seven heads near the beginning, and the result of exactly 25 heads and 25 tails, are both highly improbable as individual events yet still occur when looking at a large enough sample). It sounds like the placebo effect has struck again.

P.S. It's probably a good idea to write a program that will run battles and score results for you. Whenever I run the battles myself I am convinced that the latest version of my bot is the top performer.

-- AaronR

Yeah, I hear you, I try to be scientific about things, not always successful but... I just ran two battles of 1000 rounds each, the first with RamFire selected first, the second with RamFireCopy? selected first. Even if I did mess up in the copying... or if inside or outside a jar mattered, and one bot won more often, shouldn't it at least be the same one? My results were that the first one in the list won 666-334 the first time, and 643-357 the second time.

battle selected order selected 1sts
1 1 RamFireCopy? 666
1 2 RamFire 334
2 1 RamFire 643
2 2 RamFireCopy? 357

Well, it appears you found a bug - in the ramming code! Check out these results from 500 rounds:

Robot Name Total Score 1sts
sample.RamFire (1) 93705 315
sample.RamFire (2) 82440 185

Robot Name Total Score 1sts
sample.SpinBot (1) 41077 257
sample.SpinBot (2) 40444 254

So the first RamFire outperforms the second by a huge margin, but the non-ramming SpinBots have an almost even score. I guess I'll file a bug report with Fnl.

-- AaronR

Yeah, the SpinBots? would have a lot more chance thrown in, two RamFires? vs each other can't really miss, so every shot counts, so there should be some ties, but aren't. The SpinBot thing is consistent with the selection order also defining bullet evaluation order or something... I'm glad you saw it on your system as well! --BenHorner

This behaviour is already present in the (ancient) version 1.0.6. My experience is that the bot listed first most of the time has a slight advantage (up to 2%). In the rumble this does not matter, as it will even out over the battles fought. The reason I think that it is so obvious to see with rambots, it that they probably die the same tick or maybe one tick apart. The bullet of the first bot is handled first, causing the second bot to die, while in the same time (tick) the bullet of the second (killed) tank destroys the 'winner' tank 1. This is no 'bug' in the ramming code, it is just the way Robocode handles things. It is not very important, but you should keep it in mind when testing things. -- GrubbmGait

This has been fixed. Wow, this is a very alive opensource project! --BenHorner

Yes, Fnl is quite active solving things and extending robocode. On the other hand, you are just stirring things up with all your questions about things we were just taking for granted. ;-) -- GrubbmGait

The bugfix is confirmed (same test, 500 rounds):

Robot Name Total Score 1sts
sample.RamFire (2) 88504 251
sample.RamFire (1) 88059 249

-- AaronR

I just wanted a little confirmation, from some tests I did with the Interactive and SittingDuck sample bots, it seems that you get credited with a ram whether you are moving backwards or forwards. Are there any differences whatsoever between moving backwards or forwards? (Aside from the method you call to go that direction...) --BenHorner

I have just discovered a way to accelerate more than 1 pixel in a single turn... ;) just curious, how common is this knowledge, and is it a bug? --BenHorner

Is there anything that happens only once per round? I'm interested in initializing some things at the beginning of each round, but I don't see an onRoundStart?() event handler or anything... If there's nothing like that, I'll have to initialize a variable, and then change it in run(), but I'd rather not be checking it every time through the event loop... --BenHorner

Check me on this... Hitting a bot with a bullet of power bp, where bp <= 1, causes a 7 * bp swing in the energy tug of war, right? Does that mean that if you can guarantee a hit within six shots, you should take those shots every time? Unless the other bot is doing something that is causing a bigger swing, that you have to make up for... like hitting you with higher power bullets...

Is the radar accuracy (likelihood of tripping an onScannedRobot() event) related to it's "speed", by which I mean, the number of degrees per turn that it is spinning at...? Ok, simply: If I spin the radar faster, am I less likely to see opponents?

I notice that on the Radar page, many people like to use turnRadarRight?(Double.POSITIVE_INFINITY), is this better in any way than turnRadarRight?(45)?

If I turn the gun it's maximum of 20 degrees, and the radar it's maximum of 45 degrees, all in the same turn, does this allow me to scan 65 degrees in a single turn?

Turns, how is this actually turn based?

Drawing on the screen for debugging purposes... It looks like in the code of the Interactive robot that it should be drawing a red 'x' and / or oval on the battlefield, but I don't see any such graphic... Do some people actually see these drawn graphics?

Why are the Consciousness check: questions so hard? Should I go to bed after I get one wrong 3 times in a row?

Robo Home | BenHorner | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited October 7, 2007 4:21 EST by BenHorner (diff)