Talk:Geomancy

Pages: Main page · Code · Version History · Discussion

General Questions

What is the difference between this and Watermelon? I first think this is Go-to surfing, but it is true surfing anyway. » Nat | Talk » 13:08, 19 June 2009 (UTC)

This is the next iteration of Watermelon - I conquered kid.Toa (finally!) and fixed some bugs in my distancing that allowed me to get rid of some rambot special-case code, improving my survival against rambots to nearly 100%. The main reason for the rerelease was twofold: I wanted a more serious name, and I wanted an excuse to rip out all the old bits of commented-out code I had stopped using a while ago. Answering your other concern: Geomancy does use true surfing, determining the best direction to orbit each turn. Soon I plan to make a change to the movement that will increase the resemblance to a go-to bot somewhat. If my best location for the upcoming wave is very close to where I am now, I'll delay movement until the last moment, giving the opponent less information about my intentions. -- Synapse 22:59, 19 June 2009 (UTC)

Debug Graphics

Those have to be the nicest wave graphics I have ever seen! --Darkcanuck 18:03, 19 June 2009 (UTC)

Glad you like them! It's important to me that the graphics be readable enough that even at 30tps I can get a feel for why the bot is making the movement choices it does. I did recently fix a positioning issue with the graphics that caused each circle to be off-center - that will fix the varying offset between the wave and the bullet you can see in the version 1 screenshot. -- Synapse 22:59, 19 June 2009 (UTC)

I have to figure how you made those nice circles. Mine look like they were drawn on an Apple ][... --Darkcanuck 03:29, 20 June 2009 (UTC)

If you are talking about the circle of the bins. I think it depend on the system. Sometimes I see the anti-aliased circle but sometimes it doesn't. Very strange. Anyway, I think using g.draw(new Ellipse2D.Double(...)) or use AffineTransform on Point2D is way more beautiful than g.drawOval(); » Nat | Talk » 04:12, 20 June 2009 (UTC)

Haha... just take a look at the robocode preferences Darkcanuck... there's a little group of settings that makes all debugging graphics look much prettier... Go to "Rendering Options", and turn on your anti-aliasing, or just hit the big pretty "Quality" button in the middle of the tab ;) --Rednaxela 05:09, 20 June 2009 (UTC)

(slaps forehead) I always set mine up for "speed", never tried the other settings... --Darkcanuck 07:40, 20 June 2009 (UTC)

Memory Usage

My rumble client just died due to java.lang.OutOfMemoryError while running synapse.Geomancy 1 vs nat.BlackHole 0.1.11. Yours is the newer bot so I thought you might want to know in case there's a memory usage issue? My client uses 512M of heap space. I'll let you know if it happens again. --Darkcanuck 13:48, 20 June 2009 (UTC)

Nope, BlackHole 0.1.11 is really a memory eater. BlackHole 0.1.11 right after finish the development consumes around 600GB. It just, too much bins to surf and result in really bad movement though. I may remove this robot from since since it worse than OcnirpSNG ;) » Nat | Talk » 14:08, 20 June 2009 (UTC)

600GB? ARe you sure you don't mean 600MB? If it's 600GB... I'd really want your computer ;P --Rednaxela 15:54, 20 June 2009 (UTC)

I really mean 600GB. When I finished the development, I tried to run it and I can't make it run. I even used the Eclipse debugger and now both Robocode and Eclipse froze so I decided to calculate the memory usage. The result is 600GB, which make me understood instantly why it doesn't run. So I decide to comment out most buffer and leave only light one, and it worked. But still I couldn't run it together under -Xmx512M. » Nat | Talk » 16:05, 20 June 2009 (UTC)

I ran Geomancy vs itself, and Java used 50mb of memory. Then I ran BlackHole vs itself, and one of them crashed due to exceeding the memory allotment of 512mb. -- Synapse 16:42, 20 June 2009 (UTC)

A memory singularity? :) --Darkcanuck 17:36, 20 June 2009 (UTC)

Suspicious Battles

(moved from Talk:Darkcanuck/RRServer)

apv.TheBrainPi 0.5 vs synapse.Geomancy 1 -- Synapse 05:46, 20 June 2009 (UTC)

synapse.Geomancy 1 vs elvbot.ElverionBot 0.3 -- Synapse 05:46, 20 June 2009 (UTC)

Ok, a second battle for Geomancy-vs-ElverionBot (on a different client) came up with a similar result, so you may want to do some local testing to see if there are any problems with that matchup. ElverionBot is a known crasher, so I'm not surprised to see it get that kind of score. TheBrainPi isn't too stable either, so it could be a similar issue? I'll try to force a client to run that pairing again. --Darkcanuck 17:40, 21 June 2009 (UTC)

Do I need to be checking that I handle crashed opponents gracefully? What's the difference from my bot's perspective between a crashed opponent and a dead one? -- Synapse 22:40, 21 June 2009 (UTC)

Crashed bots are immediately disabled by robocode, so would probably show as still alive but with 0 energy I belive (just as if they had used up all their energy firing). --Darkcanuck 02:39, 22 June 2009 (UTC)

Out of curiousity, I fired up 1.6.1.4 and setup a battle between Geomancy and ElverionBot. The latter was disabled immediately (appears to be using a function which only exists in later versions of robocode) and then my system went to 100% cpu before java crashed with java.lang.OutOfMemoryError (set at 512MB, went up to 600MB). I repeated the test using one of my bots set to crash with an array index exception. Similar deal, except robocode was able to stop Geomancy before java could crash. Although as I write this it's still stuck at 100% cpu on one core and 600+MB. So I think you have a bug regarding disabled opponents... --Darkcanuck 02:39, 22 June 2009 (UTC)

The bug has been resolved -- I wasn't creating new Enemy objects correctly, so when I saw an enemy for the first time and it was already disabled I was entering an infinite loop. The next release won't have this issue. -- Synapse 08:52, 28 August 2009 (UTC)

Segmentation

I'm adding segmentations to Geomancy, starting with lateral velocity orthogonality. I was reading about Crowd Targeting and will be experimenting with Multiple Choice applied to the top 10% of my segmentations. I'll post more here when I have results! -- Synapse 20:56, 7 September 2009 (UTC)

Backsliding

I'm not sure what the last release (5) broke. I added two segmentations generally considered to be quiet useful - orthogonality and bullet flight time. Can someone with a little more experience maybe take a look at the version comparison or at my bot's behavior and suggest some things to focus on? I'd really appreciate it. -- Synapse 20:53, 9 September 2009 (UTC)

To clarify: looking at the comparison, it seems like the bots against which I gained ground were my former problembots - Phoenix, Fermat, Cigaret, Banzai, MirrorMicro, and SHAM.WOW. Why did this change hurt me against so many other bots? -- Synapse 20:57, 9 September 2009 (UTC)

There are a few details that I would want to know before offering much specific feedback:

• By orthogonality, you mean something like (enemy heading minus bearing to enemy), right? I've had mixed results with this - in Dookious, I settled on just using lateral velocity, while in Diamond, I use abs(velocity) and relative heading. If you already have lateral velocity in there, this attribute might be slightly redundant, but it's an attribute worth trying.
• I think bullet flight time is better than just measuring distance. Did you already have distance? Are you using them both now?
• I'm not too familiar with how your stat buffers are setup. Maybe adding more attributes also decreased learning speed? Or if you have distance + BFT and orthogonality + lateral velocity, maybe the redundancy is giving undue weight to some of these attributes?

The comparison details are indeed kind of hard to interpret, but it looks like the bots you scored high against are still mostly unchanged.

--Voidious 15:41, 10 September 2009 (UTC)

For orthogonality I was using abs(sin(enemyheading + enemybearing)), which should have been abs(sin(enemyheading - enemybearing)). Fixing that just got me back the score I was missing. That also explains why adding these segments was mostly a wash - the damage from adding a meaningless axis and the benefit from adding a good one were offsetting each other. The way my stat buffers work, all buffers are kept updated when new information comes in, so adding more axes shouldn't slow down learning at all. Now that orthogonality has been fixed things should improve nicely. Answering your other question, I don't have a distance segmentation - just bullet flight time. I did get some nice gains from weighting the velocity axis as better by about 12%. -- Synapse 18:06, 10 September 2009 (UTC)