User talk:Pedersen/Hubris

Hubris seems a promising entry, especially when it will be capable of fighting in a team. I noticed that Hubris is a Java6 bot, as my client lets it loose by 350-0. I think it is time to upgrade my Java from 5 to 6, because my exclude list is becoming quite big now. I also noticed that User:Pedersen/Ugluk has passed GrubbmGrb. Maybe it is an idea to make a final update of GrubbmGrb and find out where the limit of a non-surfing, non-GF, non-DC, non-PM bot really is. GrubbmGait 12:56, 13 February 2008 (UTC)

I had made a note of the Java 6 compilation with the first posting to the Rumble, but I ran into a few issues and made reposts. Apparently you cannot use greek characters in your versions and have it work in the roborumble@home mechanism. It displays in the client, though it is a ? in the bot console. Then I noticed seriously low scores against some opponents and realized that I'd left the profiles active for historically troublesome opponents .. only at present the movements they use are not all functional. Hence the Beta 2 release. I haven't released a bot in about a year, so I was lucky to only flop once.

At present Hubris can fight as a team with other bots. It is a boolean away from sending every message it receives to the bot console. It presently broadcasts its position, enemy scans, bullets fired, and enemy waves detected. Anyone wishing to test their communication with it is able to as is.

I'd love to see another version of GrubbmGrb. It is still my competitor of choice for testing. It's not really fair though since I've been using guess factor style targeting for the past two years. I'm usually beating 1.2.4 by about 1000 points in local tests. But that's when things are working. When he clobbers me, I get to go bug hunting.

I've been dragging my feet for a while now on the movement code. There are two main parts: deciding where to go, and deciding how to get there. My favorite movement style is flawed, and my get-there algorithm is a simple substitute for the real work I want to do. I'm finding it hard to concentrate on the entire picture. Well, back to work... -- Martin

Hubris Beta 2 gives strange behaviour on my machine. In the rumble it gives very low scores (like 6200 to 200 loss against deewiant.Anomaly)and when I checked in my dev-environment, the only thing it did was running in very small circles. No messages were outputted to the console and the radar was turning continuously. I'll exclude it for now. Note that I just updated to Java6_03. GrubbmGait 01:54, 14 February 2008 (UTC)

Definitely odd. On the other hand it has a 45% average across 14 battles vs. the latest abc.Shadow, so it's doing something right somewhere. I just tested the beta 2 bot vs. Anomaly 0.2 and it scored 3366 to 1589 on Robocode 1.5.2. Dunno what to tell ya. I've fixed some minor bugs during the day, but Beta 2 was still pretty strong. -- Martin

One of the changes I made in Hubris was to start every round with my movement vector (direction and velocity) normalized to a positive velocity. Likewise, my new 'a to b' movement system used a normalized vector for b. Things were going mostly fine until I tracked down a teensy tiny bug that had some ugly effects. When iteratively predicting my robot's future position, if my velocity hit 0.0, I no longer really knew which direction my bot was facing. It seems like a trivial issue, because I could consider my bot to be facing either way I wanted at that point, but in practice I just couldn't get the prediction to reflect what ended up happening in that situation. So.. I commented out the normalization occuring at the beginning of the turn and between iterations, and things are working smoothly again. I am getting a score of ~99.5% vs. Bot A. I've still got some 'bad starting position' code to add in, to cut that in half. I often lose 1 or 2 rounds out of 500 round battles due to really bad starting positions that my movement code just can't get out of. Yet. - Martin

Well, the refactoring marches on. I'm happy with some adjustments to the wave recording mechanism, and I'm going to try once more to mark the intersections of outgoing bullets with incoming waves to see if there's any value to hiding in the known safe regions. If you are new to the concept, it is basically that while you are firing at each other, you can learn angles that your opponent did not fire at because your bullet didn't collide with theirs. The infamous Paul Evans claimed to have attempted it (a technique known as bullet shielding) and dismissed it as not viable. That's reason enough for many to abandon it, but for me Robocode has always been about trying to do things. Though I keep dragging my feet on this (as well as my super-nifty-in-theory movement algorithm) I will include it in the key-press toggled visual debugging. --Martin 16:07, 11 May 2009 (UTC)

http://home.comcast.net/~kokyunage/robocode/tangent%20vs%20orbit.jpg

Something that has nagged at me for a long time is the question of whether orbiting a bullet's point of origin is better than moving at a tangent to it. In the diagram above, the left side represents turning so that the midpoint of the robot's path is the tangent to the bullet's origin. Or whatever the correct phrasing is. It turns out that I was right in the assumption that turning is disadvantageous, but only by about 10%, which is reminiscent of how much padding Voidious said he added to his guess factor bins. My measure of 'advantageous' being the largest firing arc that someone needs to consider when firing at you. Given that we are fighting in a battlefield with walls, traveling at a tangent until the wave passes is rarely an option, so I think orbiting is generally the best bet. --Martin 18:29, 8 February 2010 (UTC)

Yeah... that's something which has bothered me personally quite a bit as well. It's for that reason that the next time I code a surfer, it will use a (hopefully?) novel method for surfing. It's intended to make whether it orbits or follows a tangent at any moment in time, an emergent behavior based upon realistic evaluation of a wide variety of movement options, not just along a single path. It's based on calculating a precise 2D shape bounding the entire area the bot could escape to before the wave passes. The detail I haven't quite decided is how to account for the second wave and such (which will become critical if I want it to work for 'melee surfing' as I intend to), though I have a few ideas. But anyway, as far as whether the best path at any given time is orbital or a tangent or somewhere in between, I feel that an important part of "the way forward" to new surfing frontiers involves making bots more flexible about choosing between such paths. --Rednaxela 19:39, 8 February 2010 (UTC)