User talk:Nat/Free code
Movement Predictor
Ugh... all that distanceRemaining and so on stuff seems so overcomplicated an unnecessary. I'm guilty of doing overcomplicated movement predictors myself before, but I've found that really, what you REALLY want in a movement predictor can be experessed in 10 lines of code, because in reality you never really feed a movement predictor data which would exceed what's possible in robocode physics anyway... --Rednaxela 15:16, 6 June 2009 (UTC)
Well, not if you are creating a Go-To surfer. You will need to know exactly time that you will be arrived at your destination. DrussGT's one is by far more complicate (it has the BasicSurfer one running first, then using it own far more complicated one).
Actually, it is suppose to have one more method, the predict(PredictionStatus start, Point2D destination, double maxVelocity) method is the most useful for GT Surfer, but I'm having my head messing in the DrussGT.futureStatus(...) function which have the precise way to calculate travelling distance when you are turning. » Nat | Talk » 15:33, 6 June 2009 (UTC)
I think I mentioned it before, but the first set of precise predictions are only a useful way of getting a bunch of Goto points. I've played with other methods, and none of them seemed to work quite as well, so I left it with just using a hacked BasicSurfer movement. I would have a simpler method for doing my second set of future predictions, but the trouble is that a simpler method would involve sin, cos, and atan2 for every single tick of prediction, whereas my method only requires acos and sqrt, and even that only for as long as it is turning. If you want to understand it better, draw a triangle, one side being distanceRemaining, another being the current (absolute) velocity, and the angle between them being the amount of 'offset' the bot currently has from its goTo point. The last side would be the new distanceRemaining for next tick, and can be calculated by using the Cosine Rule. The new offset would be the external angle between the velocity and the new distance remaining, which is PI - the internal angle, and the internal angle can also be calculated by the cosine rule. By keeping track of the total amount of heading change, and the distance away and offset from the goto point, I can transform this 'linear' simulation back into Cartesian Co-ordinates. The nicest part about this simulation is that once my offset becomes nothing (due to the bot turning towards the target point) I can skip all the fancy Trig work and simply subtract from distanceRemaining every tick. I suppose this would also be possible in a linear simulation by caching the results for the sin/cos, but the use of atan2 in the initial turning section makes it too slow for the hundreds of simulations I need to perform in every tick when surfing the second wave. Although I may try it for surfing the first wave, just to make it a little more accurate for Rambotesque situations where the hitTime between my goTo point and the bot vary significantly. --Skilgannon 23:06, 6 June 2009 (UTC)
I think I need to read that for at least 20 times to understand. I really, really don't know any rules of trig. Well, from my past benchmark, I figure out that (Java's) acos and sqrt is quit expensive and atan2 is not as expensive as acos (1:4). But actually the simpler way will need sin/cos/atan2/sqrt I think. Thanks for the information. » Nat | Talk » 13:02, 8 June 2009 (UTC)
