Difference between revisions of "Talk:Watermelon"

From Robowiki
Jump to navigation Jump to search
(One idea)
(→‎Surfing Multiple Waves: inverse distance squared)
Line 14: Line 14:
  
 
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. --[[User:Rednaxela|Rednaxela]] 23:03, 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. --[[User:Rednaxela|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 =) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:50, 15 June 2009 (UTC)

Revision as of 13:50, 15 June 2009

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)