Improvements

Jump to navigation Jump to search

Improvements

Wow! This is probably the closest a stable PM bot has ever gotten to dethroning LBB 1.69e. It only has about .3 APS to go!

It seems like we could gain that much just by fine-tuning constants. Any suggestions?

Sheldor16:26, 28 April 2013

Yeah, clearly less aggressive distancing and bullet power helps out a bunch here. Now that we've changed the default distance we also need to change the reverse probability, all those need to go to 29. Also, I really wonder if there isn't some way to reduce the number of sacrifice rounds at the beginning against top-bots. Perhaps have something like what I do in Toorkild with using total enemy damage received to trip the movement modes instead of number of deaths.

Skilgannon21:52, 28 April 2013

Hmm, fewer exploitative rounds would almost certainly increase PL--er, PWIN, but it might reduce APS against weak bots. I suppose we could try going back to four rounds of exploitative movement and see if that helps.

I don't see any plausible mode-selection other than the one we have now. The amount of Codesize we have to work with is far too small to even implement something like Splinter's, let alone Toorkild's.

Sheldor23:47, 28 April 2013
 

You could always enter a few new bots that LBB doesn't have data on. ;) Seems kinda cheap, but hey, you live by the black book, you die by the black book...

Voidious23:09, 28 April 2013

Not with any particular intent, but I have been helping in this direction by updating my nanobots and adding a few new ones ;-)
There is at least one more under development which should eventually get uploaded provided the idea doesn't completely fail in benchmarking.

Nz.jdc (talk)14:11, 27 May 2013
 

I wonder what would happen to the ranking if hideEnemyNames was set to true.

MN15:26, 29 April 2013
 

Would we be able to save a few bytes by eliminating unnecessary casting? For instance, we could make BULLET_POWER an int constant so the anti-ram doesn't have to be cast to a double. (Plus, 2 hard-coded as an int is two bytes cheaper than 2 hard-coded as a double.) Also, we could make DISTANCE_FACTOR a double constant so it doesn't get cast as a double when we use it to divide getVelocity().

I'm somewhat surprised by the ~0.1% drop in APS after changing match length reduction. It seems it tried too hard to predict random movement and got fooled more easily. I guess we'll go back to 1.1.4's method, unless you have any other ideas.

Sheldor (talk)02:39, 27 May 2013

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:Yatagan/Source/Improvements/reply (6).

I might have another byte for you. I have been doing some experimenting my my movement code and obviously also looking at yatagan since it is the best. One tweak I have tried (but not yet benchmarked or verified) that looks like it saves one byte is to not use infinity for direction. This then allows you to use direction rather than getVelocity() in the turning code, which should save a byte. Something like:

 private final static double VERY_BIG            = 1e+200;
private final static double CLOSE_FACTOR = VERY_BIG * 430;
...
turnRadarRightRadians(direction = VERY_BIG);
...
setTurnRightRadians(Math.cos((rd = e.getBearingRadians()) - (e.getDistance() - PREFERRED_RANGE) * (direction / CLOSE_FACTOR)));


This should work provided there is nothing weird in the robocode radar which will cause issues without the infinity.

Nz.jdc (talk)14:07, 27 May 2013

That's a very cool idea. The only thing I'd be concerned about is the radar, since it will subtract the amount it turns from the getRadarTurnRemainingRadians() and could eventually run out (although not really an issue if it is 1e200). Perhaps by reading in degrees and writing in radians for the infinity lock we could negate that, though. In fact, we could probably get away with a smaller value. I'll give it a spin when I get home.

Skilgannon (talk)14:24, 27 May 2013

Looks like it works ok. I was worried about depletion too, especially when I saw you use 48 (any reason for that number in particular?), then I actually thought about it and noted the rad/deg growth, so anything down to 2PI should be ok :)

Nz.jdc (talk)01:45, 29 May 2013

48 is the distance of a stop-and-go move, so my thoughts are that it will be big enough that on the enemy death it will avoid HOT, but won't go into walls.

Skilgannon (talk)08:19, 29 May 2013

Ah, clever. I keep forgetting that once an opponent dies you will stop getting scan events.
I also remember some comment about stopping on radar slips being a reason not to set it too small.

Does the recent ++integer and inversion of the matching actually work? It looks like it should always terminate the loop by setting matchPos = -1.

Nz.jdc (talk)12:10, 29 May 2013

Apparently not. I guess I should've tested that before I published it.

Sheldor (talk)14:01, 29 May 2013
 
 
 
 
 
 
 

Is there any way we could store a negative char value and get rid of the

- (1.1 - 1e-8)

code?

Sheldor (talk)19:11, 27 May 2013

I don't think so. That is there for the bullet detection, and the char value is multiplied by the random so if we used it for bullet detection it wouldn't be reliable. We're down to 246 bytes though, so any ideas of what else to add?

I think I identified where the score difference between 1.1.6 and 1.1.4 crept in, it was from Yatagan stopping if the radar slipped. My local tests show that increasing the direction to 48 fixes the bots that had the biggest score discrepancies.

Skilgannon (talk)20:09, 27 May 2013