Talk:Watermelon

Saving Data

My suggestion with "Saving Data" is, don't. I've never bothered with it because the gains made are rather small, AND perhaps most importantly, it makes the effectiveness of your bot vary with stupid factors like how many rumble clients are running, since the data isn't shared between clients. In fact, I'd personally vote to ban saving data between battles in the rumble (at least until it's possible for clients to share data to make it actually fair). Really... it's just not worth the hassle... --Rednaxela 23:56, 11 June 2009 (UTC)

Thanks for the input! I'm glad to hear this reinforcement of my suspicions. Barring some convincing evidence to the contrary, my mind's pretty well made up. -- Synapse 03:52, 12 June 2009 (UTC)

My next release should make it up even further :) --Miked080104:07, 12 June 2009 (UTC)

Surfing Multiple Waves

My current strategy for multi-wave surfing is to proportionally add the danger from the next wave, varying by how soon the next wave is arriving and by its relative power. What I've observed is that while this does help when the second wave is close to the current one, it causes the bot to behave... tenatively. It will dodge the hot spot on the current wave by just enough to clear the worst of the factors, then hover in place, having found a minimum point where it would be reasonably safe on both waves. The thing is, it could do better by travelling further from the safe point on the current wave, then swinging back to a clear point on the next wave. The current behavior also sometimes prevents the bot from seeing other good solutions that involve movement after the current wave is past.

Is there a "cheap" solution that doesn't involve branching my prediction at each tick in the future? -- Synapse 22:47, 14 June 2009 (UTC)

Well, one idea I've had that I've never tried, was making a list of 5 to 15 "candidate" spots on the first wave, and for each of those, find the reachable GF range for the second wave, adding the lowest danger within the range, to the danger of that candidate spot. --Rednaxela 23:03, 14 June 2009 (UTC)

Rednaxela, that doesn't cheap by the way. I think the way you mentioned is the cheapest way. Just weight it by inverse distance squared should make it behave better. I actually have faced that problem too. My BlackHole, when the forwardDanger and reverseDanger are equals, it choose the backward so after the first hit, first wave will have cw danger but the later will have ccw later, cause my bot to have at HOT =) » Nat | Talk » 12:50, 15 June 2009 (UTC)

Well, current version of RougeDC is reasonably fast I think, and when there are 3 waves out there evaluates 9 paths after branching. What I purpose with "candidate" spots would only require 2 branches for each spot, so with 5 "candidate" spots from which to check the second wave would be about the same speed as current RougeDC, which is not really a slow bot compared to some. --Rednaxela 13:05, 15 June 2009 (UTC)

I like the suggestion about using inverse distance squared; I'll try that. I checked DrussGT's old wiki page and he mentions something very useful - he rolls with a smaller depth at higher segmentation, so that the segments that get data more often are also rolled more accurately. Maybe a good way to do this would be a time-based rolling average, where each segment knows how long since it has been updated, and data is weighted less heavily depending on how old it is. -- Synapse 22:32, 15 June 2009 (UTC)