Talk:Robocode

The following 2 comments are from the "Robocode/Welcome" talk page, before moving it to "Robocode".

This article should be merged with Robocode Basics. --AaronR 23:19, 12 November 2007 (UTC)

• I agree, and thank you for doing the merge job. :-) I have just started putting stuff into this new Wiki, so I will continue extending the Robocode part of the Wiki with the old one provided here Robocode Online Help, but in a total updated version of course. My intension is that all the stuff I put in this new Wiki will contain all information about Robocode in the future, and then I will redirect the old web page to point on this new one, when it is finished. ;-) --FlemmingLarsen

The Wikipedia entry for Robocode

Somebody should update the http://en.wikipedia.org/wiki/Robocode page for Robocode some day. :-) --Flemming N. Larsen 23:31, 13 November 2007 (UTC)

1.7.1.2

I've been doing a bit of local testing, both with new and 'know problem' archaic bots (SandboxDT, SilverSurfer), and all the results seem to match 1.5.4. Also, it seems to run a LOT faster. I've been testing the rumble with UPLOAD=NOT and it also seems to match everything within what I would think is the margin of error. Can we have a consensus that 1.7.1.2 is safe for the rumble and challenges? --Skilgannon 19:15, 14 May 2009 (UTC)

I bet even 1.7.1.1 are ready for RoboRumble. I've been asked Darkcanuck about newer version and he said we should wait. One thing that change is survival score, 1.6.1.4 and earlier use 1st as survival score but 1.7.x use either survival or survival bonus score instead. » Nat | Talk » 23:32, 14 May 2009 (UTC)

Whoah, did the survival scoring really change? Man, I don't like that at all. I wouldn't support any scoring change being allowed into the RoboRumble. Where is there info about this?--Voidious 02:40, 15 May 2009 (UTC)

Indeed, the result doesn't change. (because it a percent) It just switch from 1st to survival bonus, which is the same for 1v1 battle (but not for melee rumble) Here are some result from my result file (1.7.1.1alpha)

roborumble,35,800x600,Nat_1711,1239165160631,SERVER
stelo.UnfoolableNano 1.0,2748,1475,900
robar.nano.BlackWidow 1.3,2685,1479,850
roborumble,35,800x600,Nat_1711,1239165163655,SERVER
robar.nano.BlackWidow 1.3,4848,2290,1750
sul.Pinkbot 1.1,640,640,0

The older version look like:

roborumble,35,800x600,Nat,1242355746718,SERVER
zyx.mega.YersiniaPestis 1.6.2.4,3746,1707,29
ak.Fermat 2.0,1529,1102,6
roborumble,35,800x600,Nat,1242355781553,SERVER
darkcanuck.Gaff 1.34,3559,1612,28
apv.AspidReloaded 0.6,2159,1638,7

Score in format total score, bullet damage, survival » Nat | Talk » 02:53, 15 May 2009 (UTC)

Ah, cool, thanks for that info. So it's just the representation that changed. I'll chill out now. =) --Voidious 03:08, 15 May 2009 (UTC)

He he, just found that 1.7.1.2 beta isn't ready yet, see http://robocode.svn.sourceforge.net/viewvc/robocode?view=rev&revision=2983 for more detail. Be should wait for final release before make it a rumble client. And, as I wrote this many times already, 1.7 is a LOT faster for sure. I've once run it with UPLOAD=NOT and I ran 60 battle/minute! » Nat | Talk » 23:41, 14 May 2009 (UTC)

Thanks for pointing out the scoring change, I didn't know about that. Do you know why it was done? I'd still consider this to be a bug, since it does change functionality without apparent cause. If we want the survival bonus it should be reported as a separate value.

1.7.1.1 wasn't ready because there were known bugs (e.g. melee rumble broken). Some of the movement gurus out might want to take a close look at 1.7.1.2 because the movement formulas were changed slightly to fix the quirks that Simonton had pointed out. Happily this new version does fix a problem with the rumble client that could cause mass removals and also adds smart battles for melee. --Darkcanuck 03:46, 15 May 2009 (UTC)

Oh! I am wrong, it is actually survival, not survival bonus. But we still can't use current beta for the bug that fixed in r2983. It's is your server now, you don't want the new way so it is a bug. I've a patch now, see if you want. » Nat | Talk » 04:41, 15 May 2009 (UTC)

Robot Entry Sorting (in Robocode)

Regarding to this recent bug report I made, I want to ask you that, according to this issue (please refer to the comments on the report for detail, I don't want to repeat here), which solution do you prefer? Because I saw a lot of robots do like Diamond, and very few do like the current solution (like GrubbmGait's robots) --Nat Pavasant 13:15, 5 November 2009 (UTC)

Name	Keep	Change
Nat		X
Rednaxela	X

I'm afraid I have to be strongly in favor of 'keep', since I think versioning which keeps closer to what real numbers would sort to makes far more sense. I personally also think it's silly to use a designation scheme which restricts to 10 levels for any given level of versioning. I think more than 'very few' like the current solution, for a few examples see bots of: GrubbmGait, Skilgannon, Simonton, Wcsv, Mue, ABC, and myself. Also, many bots use versioning that ensures 'sane' ordering with either sorting (Shadow seems to), or simply don't have high enough versions to tell what the versioning scheme is. --Rednaxela 13:36, 5 November 2009 (UTC)

I personally prefer the current version, but feel that it does have a bug, in that if you append a letter to the end of a version name it messes the numerical section up. Eg it will sort in the following order:

1.1.1
1.1.10y
1.1.2
1.1.10

instead of

1.1.1
1.1.2
1.1.10
1.1.10y

As such, I don't support the change Nat proposed, but don't particularly support keeping it either, because I think there's a bug in it =) --Skilgannon 14:27, 5 November 2009 (UTC)

Ahhh, I didn't realize that about lettering. Agreed :) --Rednaxela 18:01, 5 November 2009 (UTC)

Oh, that's how the current sorting works? =) I don't really care much either way. And I actually agree that the other (Mue/Skilgannon) style makes more sense, I just haven't decided how/when to change over to it in my bots. --Voidious 15:54, 5 November 2009 (UTC)

Actually... There's no reason code couldn't sort any mentioned version styles all correctly. I'll write code for this in a moment...--Rednaxela 17:41, 5 November 2009 (UTC)

• Wait, nevermind, I was being braindead. But... there IS actually no conflict WHEN people using Voidious-style versioning keep the number of digits constant, which they (almost?) always seem to do. --Rednaxela 18:01, 5 November 2009 (UTC)

I definitely prefer the current alpha-numerical ordering. However, it should be like the last/2nd example given by Skilgannon, not the first one, which seems to be a bug. I already have a fix for this one. But I will wait will fixing it, till I know if we should keep the current sorting. --Fnl 22:39, 5 November 2009 (UTC)

Just updated and....

SYSTEM: chase.na.Seraphim uses static reference to a robot with the following field(s):
	chase.na.Extension.bot, which points to a robocode.AdvancedRobot
	chase.na.Extension.bot, which points to a robocode.AdvancedRobot
	chase.na.Extension.bot, which points to a robocode.AdvancedRobot
SYSTEM: Static references to robots can cause unwanted behaviour with the robot using these.
SYSTEM: Please change static robot references to non-static references and recompile the robot.

What a fun error, probably my fault, and it is easy to fix, but assuming I assign it every round, how is this bad? Aside from the game not being able to dispose of the robot easily due to the java equivalence of a dangling pointer. — Chase-san 22:10, 24 June 2010 (UTC)

Ever since some architecture changes, holding old instances caused more overhead than in old versions. If you assign it every round reliably it's probably not a problem in practice. The reason this warning was added was at least one or two robots who had old references hanging around in a problematic way were found. That answer your question? --Rednaxela 23:00, 24 June 2010 (UTC)

Jikes vs. ECJ

I know for a lot of the codesize restricted bots it was advantageous to compile with Jikes because it gave a slightly smaller codesize. Has anybody done any comparisons on the codesize of bots compiled ECJ vs. Jikes vs. Sun javac? I suspect Jikes still gives the smallest code... although I'd love for somebody to prove me wrong. I'm not on my usual computer or I'd be putting up some results myself =) --Skilgannon 00:03, 29 June 2010 (UTC)

Didn't think I'd have time for this, but here's what happens with Waylander:

	Code	Class	Class
Nr	size	size	files	Location
--------------------------------------------------------------------
1	742	3945	1	jk.Waylander_0.3.7jikes.jar
2	753	4828	1	jk.Waylander_0.3.7ecj.jar
3	756	5057	1	jk.Waylander_0.3.7sun.jar

So better than the sun 1.6.0 jdk, but worse than jikes. I'll tinker with this... I'm sure this still has debugging info in it. --Skilgannon 00:22, 29 June 2010 (UTC)

Personally what I think would be most interesting would be seeing exactly where the different sizes of each come from, using a java disassembler. Anyway, I'm pretty sure one can only use jikes when compiling against an old robocode version though. --Rednaxela 01:40, 29 June 2010 (UTC)

I am pretty sure that some tricks to reduce codesize only works for Jikes. Many of my nanobots compile on Jikes and Ejc have the same codesize. --Nat Pavasant 12:45, 29 June 2010 (UTC)

I have waited as long as I could with replacing the Jikes compiler - especially due to Jikes ability to produce small code size. But unfortunately lots of users has made complaints in several years about Jikes giving strange compiling errors (I got one or two every week), and these users don't care about the code size. Hence, I suggest you still use Jikes for reducing the codesize. You can always set this up Jikes manually in Robocode, if you wish to - in fact any compiler you like. But I will only include one compiler into Robocode, and it has to be the best free "stand-alone" compiler, which I believe is currently ECJ. ECJ also provides much better compiler errors. :-) --Fnl 21:59, 29 June 2010 (UTC)

Bullet/Bullet intersection

Having written the one in roboflight, I now find it interesting that bullets intersect each other as lines in Robocode, meaning their collision chance even when fired directly at each other, is a bit low. Of course firing bullets to intercept bullets is also difficult. I wonder what the game would of been like if the bullet interception routine looked like this.

	/**
	 * Moving Circle test, reduced dimensionality version of the bullet/bullet intersection code in Roboflight.
	 * Tests two moving circles s1r1 s2r2, with directional vectors <s1x,s1y> and <s2x,s2y>, over a give time.
	 */
	public static final boolean testCircle(Point2D s1, double r1, Point2D s2, double r2,
			double s1x, double s1y, double s2x, double s2y, int time) {
		double rVx = s1x - s2x;
		double rVy = s1y - s2y;
		double a = rVx*rVx + rVy*rVy;
		double dx = s1.getX() - s2.getX();
		double dy = s1.getY() - s2.getY();
		double c = dx*dx+dy*dy;
		double rSum = r1 + r2;
		double rSumSqr = rSum * rSum;
		if(a > 0.0) {
			double b = dx*rVx+dy*rVy;
			if(b <= 0.0) {
				if(-time * a <= b)
					return a * c - b * b <= a * rSumSqr;
				return time * (time * a + 2.0 * b) + c <= rSumSqr;
			}
		}
		return c <= rSumSqr;
	}

— Chase-san 00:57, 29 June 2010 (UTC)

I think it would be much different, and using bullets to shield would be much more common. Note though, even with current line-based collisions, one author has had a great deal of success with it via an interesting technique (BulletCatcher), not sure if you've seen that one or not. --Rednaxela 01:52, 29 June 2010 (UTC)