aggressive changes

Jump to navigation Jump to search

aggressive changes

Nice to see you're going for some pretty major changes in recent versions. =) Hoping to get away from the tweak train soon, myself.

Your changes sound vaguely along the lines of Talk:Wave_Surfing#The_Next_Level. My vision along those lines is more about predicting the firing situations presented to the enemy during the surfing options, then factoring the danger of those situations into the surf danger. For instance, if clockwise is moving towards the wall, the enemy's next bullet will have a precise MEA of 0.5 / distance 400 / normalized hit rate of 10, while counter-clockwise is a precise MEA of 0.9 / distance 550 / normalized hit rate of 8 for those firing attributes. At first glance, it seems like multiplying those right into the surf danger makes sense. But if you have multiple firing situations, the values should probably be added together before being multiplied in.

I tried implementing this a while back, with just the precise MEA / distance stuff, but I couldn't get any improvement out of it. It was also a HUGE pain trying to do this in such a way that preserves the "if we exceed max danger on the first wave, don't calculate the second wave" optimization, because you have to also account for the fact that different movement options will end sooner and have different numbers of firing situations to factor in.

Voidious18:26, 20 July 2012

Not to say that the approach I tried / might try again (which was based on your post) is mutually exclusive to what you're doing here...

Voidious18:34, 20 July 2012

Yeah, I've never had enormous gains from tweaks, so I think aggressive is the way =)

In my precise prediction I now keep a record of my path, so when I get to the time that they are predicted to fire I can calculate what the wave surfing attributes are and fire a wave. The biggest issue at the moment is predicting what their movement will be so that I can give the wave a realistic center. Right now I'm just using linear prediction. Note, this is just for the first wave. There are some major issues in the structure I've introduced, it seems, but my goal is to be able to make intelligent decisions not just for how surfing this wave will affect the second wave, but also how to move before any waves are surfed/when there are no waves in the air so that I can dodge whatever they throw at me.

Skilgannon19:46, 20 July 2012

Definitely agree with focusing on big changes vs tweaks. But I also can't resist trying to tune things up constantly. Part of me just feels like the only way to really show the true value of a big change is on a bot with all the small stuff already optimized. =) For instance, when you first wrote a go-to surfer, it seemed cool that it could be competitive. Once you were #1 and miles beyond the rest of us, that's when it really started to seem like there was something to it. =)

And my recent surge has, from my perspective, been the product of something else entirely: code quality and bug fixes. It was just two months ago I started a big code overhaul with no features or performance gain in mind, just trying to clean up my code so it was something I could be more proud of. I just found lots of stuff to fix and improve along the way. And the improved code base made it much easier and more pleasant to do lots of the new things I've been playing with.

Voidious21:04, 20 July 2012

Welllll.... sometimes it seems changes are just too aggressive. I'm going to leave this idea to mull in the back of my mind for now, and concentrate on other things. I still don't understand why it didn't work as expected, or why I get a lower score predicting a fake wave when there are no waves in the air than even plain old orbiting.

Skilgannon20:31, 23 July 2012

The only thing that comes to mind is attack angle control. Do you use the same in no-wave cases as for surfing cases? I know I move towards my desired distance more aggressively when there are no waves in the air.

Voidious21:40, 23 July 2012

I did think of that, but never got around to it. Perhaps I should breath some more life back into the 2.6.x line. I have a few more experiments I want to try with the 1.7.x's first though. And... if I do get the 2.6.x doing better than 2.5.6, it should be easy to merge the changes across. Then onto 2.8.x for some data poisoning ideas!

Skilgannon21:48, 23 July 2012