Thread history
Viewing a history listing
One thing that surprise me is that even if everything else is the same, GoTo movement typically scores worse than True Surfing. Does anyone reproduced this discover? Or I must made something wrong somewhere, which feels really bad.
Again, when a True Surfer adds second wave surfing, the score increases a lot. When a GoTo Surfing adds second wave surfing, the score decreased a lot. Is this phenomenon common? Or is that just because adding another wave exploits some hidden bug in my code?
It might be causing you to skip turns. Goto surfing does a lot more calculations in a single tick.
Otherwise I would say it is a bug, maybe with the starting conditions of your second wave surfing. Most difficult to get right for me was aligning the time I switch to surfing second wave with when I actually stop surfing the first wave in my real movement.
I would say it's perfectly aligned, from the debug graphics the predicted next wave path is exactly the same as when it really happens.
However, I create a billion of new objects per surf ;p for every predicted new position, every stop status, etc.
But I never ever skipped a turn on my computer :( whereas I see a lot of very low score on the literumble which I can never reproduce on my computer.
May be I should eliminate all the object allocation in loops ;( I used to thought Java would use stack allocation for those objects after escape analysis (which is available since Java 6 update 14), but it doesn't.
My thought are, why take the risk? Making an allocation pool or hoisting the allocation outside of the loop for frequently created/deleted objects is fairly easy. Also less pressure on the GC will make a GC run during your tick less likely, so you are less likely to skip turns. Stack analysis is good, but I'm not sure how it deals with nested objects. I suspect there is still a heap allocation internally, which can be hoisted out of most loops quite easily.
I'm probably having the same problem as you. I'm not using my GoTo code right now just because it won't work, it's always worse. Anyway, visually I feel like I'm wasting too much dodging potential when I arrive to the destination and stop (of course if you choose a point further away, you will hit the wave while moving there, but it's just a consequence). In practice my robot never moves to more than, like, 25% of my MEA, which is pretty weird. Maybe it have something to do with this time aligning thing after all, may be it have to do with my point picking strategy.
A important question: in usual GoTo movement, if moving to a point clockwise, it's impossible to hit the wave while reversing (ie, going counter-clockwise), right?
You don't have to stop, just adapt your speed that you arrive when the wave hits. Really stopping decreases your MEA.
Maybe I understand GoTo wrong and it must be more complex than I thought to give a decent result. Anyway I decided to stick to a True Surfing-like approach that evaluates a bunch of points instead of only the extreme points and then I let the surf smooth the movement by itself. Does the GoTo movement should feel almost smooth like that? Mine just doesn't and when I see DrussGT in action I feel like it should.
Exactly what GrubbmGait said. Take your predicted end velocity from the first wave and use it as start conditions for the second wave.
Yes, I do that. But still, your initial state for the second wave surfing will be restricted by the GoTo movement you did to your destination point. It's not like you could be going backwards instead. You will for sure be going in the direction of your GoTo point. So that's actually a characteristic of GoTo surfing and is that what differs it from the approach I mentioned below or there is some other difference?
Oh, and of course, there is the difference that you are not restricted to a specific path of points.
Yes, your later movement options are restricted by what you choose to do earlier. I think this reflects what happens in the game physics too :-p
But the whole point of the second wave surfing is just to find the smallest second wave danger given the restriction of trying to go to the first wave point first. You don't actually need to know where that best second wave point is, you just need it's danger as an extra heuristic for evaluating how dangerous the first wave point is. Once the first wave passes you recalculate all the dangers, treating second wave as first wave, third wave as second wave etc. So the actual location of that second wave point doesn't really matter outside of the danger calculation.
It make me do bad specially against close rangers, which is pretty sad and makes me feel I have a bug or there is some twist in the movement I'm not getting,
Basically, I see it as a way of choosing a movement path. For N ticks try to go to this point, then after that for N ticks try to go to this other point. This gives you some movement path which is repeatable and easily defined. As long as numerically your simulation of the robot behaviour is correct, you never have to actually reach the point you are aiming at. Just make sure you are evaluating the danger for the point you actually reach and not the end point that you gave to your go-to method.
Oh, and don't base your work on the go-to basicsurfer. Rather read the Understanding DrussGT page and read how it works there. Goto surfing has come a long way since those early experiments.
