Talk:DustBunny

If you manage to fit that Random/Linear gun into it, will you entered it to NanoRumble (not melee)? This bot may kill the DoctorBob records!! » Nat | Talk » 14:52, 1 June 2009 (UTC)

It fits :) - I just need to find 2 more bytes to enter it into the normal rumble due to it no longer being able to call getBattleFieldWidth() and Height(). The other problem being random/linear is poor for melee - linear reduction linear is better (Infinity style.) To make it melee proof will require another 4 bytes or so. Hmmm --Miked0801 15:36, 1 June 2009 (UTC)

OMG, I found my 2 bytes. I had e.distance() cached in a register, but wasn't using it. Next release will have random linear gun with battleField sizes taken into account. Going for overall best rating next. --Miked0801 17:06, 2 June 2009 (UTC)

Congrats on the Nano crowns! =) That didn't take very long. --Voidious 15:45, 2 June 2009 (UTC)

Great work! Number one in both... very impressive, especially in a nano! --Skilgannon 16:10, 2 June 2009 (UTC)

Good job man! --zyx 20:57, 2 June 2009 (UTC)

Awesome stuff! I really should try more nano and more melée --Rednaxela 23:07, 2 June 2009 (UTC)

Wall Avoidance

I recently saw this code from DustBunny:

// Use a very simple running average system.  /2 is as cheap as I can get this
xForce = xForce *.9 - Math.sin(absoluteBearing) / distance;
yForce = yForce *.9 - Math.cos(absoluteBearing) / distance;
		
// Get our turn angle - factor in distance from each wall every time so we get
// pushed towards the center when close to the walls.  This took a long time to come up with.
setTurnRightRadians(Utils.normalRelativeAngle(Math.atan2(xForce + 1/getX() - 1/(getBattleFieldWidth() - getX()), 
					   yForce + 1/getY() - 1/(getBattleFieldHeight() - getY()))
						- getHeadingRadians()) );

I was wondering... what's up with the 1/getX() - 1/(getBattleFieldWidth()-getX()), and the same with the Y? —Preceding unsigned comment added by Abalabazn (talk • contribs)

It is a Anti-Gravity Movement system. If you want to learn about this more, I don't suggest your to learn from NanoBot, because they are obfuscated to gain as much codesize possible. --Nat Pavasant 13:06, 2 June 2010 (UTC)

I completely understand the antigrav movement. I just don't get the relationship that the 1/getX and 1/getBFWidth-getX has.—Preceding unsigned comment added by Abalabazn (talk • contribs)

Well, we can start with how Math.atan2 works in Robocode's coordinates. For instance:

public double absoluteBearing(Point2D.Double target) {
    return Math.atan2(target.x - sourceLocation.x, target.y - sourceLocation.y);
}

So it produces an angle based on delta x and delta y like that.

In this case, (1/getX() - 1/(getBattleFieldWidth()-getX())) produces a positive value if your bot's along the left wall (say, x=50), 0 near the center, and negative along the right wall. Similarly with y. Adding a positive value to the first argument of Math.atan2 will produce a more positive angle, so when you're along the left wall, you'll turn to the right. So I think this will cause a bot to turn right along the bottom and left walls, left along the right and top walls? How much it affects the turn depends on its size relative to xForce and yForce, which I'm not familiar with. But I can definitely see it as some semblance of wall avoidance that would fit in a nano. --Voidious 17:31, 2 June 2010 (UTC)

It is indeed wall avoidance. It doesn't work well enough though without the setMaxVelocity line which slows me down (to speed up turn rate) if I need to turn a bunch. The idea behind the (1/getX() - 1/(getBattleFieldWidth()-getX())) code is to create a force to push you hard away from the edge of the board as you get close to it. There are 2 force terms being added 1/getX() positive and 1/(getBattleFieldWidth()-getX()) negative. Each of these terms gets large enough to quickly effect the overall rolling average of force as the position approaches 0 or getBattleFieldWidth(). These forces then act to push the bot back towards the center, yet as the force is a 1/x type force, it backs off very quickly as you get away from the edge. It also has a harmonic frequency unfortunately that makes DustBunyy orbit in the corner opposite of its opponent at the end of the match - a very inefficient movement pattern that gets its trounced. That's why some version add an additional random number to the mix each tic. It makes the circle larger and much less hittable at the cost of a few more wall collisions and/or closer to the center movement.

I can discuss any portion of the code you'd like at length. Just ask. DustBunny is one of my favorite bots. --Miked0801 00:06, 3 June 2010 (UTC)

Thanks for the detailed explanation. In these lines of code:

Math.atan2((-5 * Math.sin(absoluteBearing) / distance) + 1/getX() - 1/(getBattleFieldWidth() - getX()), 
	(-5 * Math.cos(absoluteBearing) / distance) + 1/getY() - 1/(getBattleFieldHeight() -getY()))
	- getHeadingRadians()) );

and 

setMaxVelocity( 12 / getTurnRemainingRadians() );

What is the significance of -5 in the antigrav calculation, and what is the significance of 12 in the maxVelocity statement? How would changing these values affect the robot? —Preceding unsigned comment added by Abalabazn (talk • contribs)

Both are somewhat arbitrary tuning values. The -5 just scales it relative to the wall-avoidance factors. If it was -1 for instance, it would avoid the walls more strongly I believe. The 12 is the attempted velocity if the remaining turn in radians is 1, but since velocity caps at 8, it only takes effect once the remaining turn is 1.5 radians or greater. The 12 basically affects how much the robot slows when doing tight turns, decrease it to make it slow down more when turning. That make sense? --Rednaxela 05:01, 3 June 2010 (UTC)

Yeah, it makes sense now. Thanks. But there still must be SOME rationale as to why you would use the exact values -5 and 12? --Abalabazn 05:27, 3 June 2010 (UTC)

The exact values? Well the general area of those numbers happens to tune the tradeoffs reasonably well I'd guess, but as for why those exact numbers.... that they're integers perhaps? Integers take less codesize which is good for restricted nanobots like DustBunny. --Rednaxela 12:24, 3 June 2010 (UTC)

-5 is cheaper than mul by 0.2 on the flip side of the ratio and 12 Rednaxela is completely correct on. They are literally trial and error numbers I've placed in there to tune behavior. The -5 turns the rolling average force to be more important than the wall pushing force. It is cheaper to multply my this constant than to use a decimal. 12 is interesting. If I make it smaller, the bot hits the walls less often because it turns quicker, but it also tends to move slower which gets it hit more often. Making it larger means it hits walls more often - especially corners, but it does better getting away from enemies as it moves faster overall. I wish there was more magical signifigance to these numbers, but they are just trial and error entries. If I get the time, I may setup a new sim where I vary these numbers across lots of battles and see if they can be slightly improved. --Miked0801 16:39, 4 June 2010 (UTC)