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. --Miked0801 23:53, 2 June 2010 (UTC)