Difference between revisions of "User talk:Pedersen/Hubris"
(normalizing vectors) |
(update) |
||
| Line 14: | Line 14: | ||
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 | 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. --[[User:Pedersen|Martin]] 16:07, 11 May 2009 (UTC) | ||
Revision as of 17:07, 11 May 2009
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)
