Talk:Precise Prediction

Credits - Precise Prediction Old wiki page: WaveSurfing/PrecisePrediction Original author(s): PEZ

Old Wiki

A technique used by I think all expert wave surfers. Using Robocode physics to precisely predict your bots position when the surfed wave hits gives you the richest information possible. Then it's up to the descision mechanism to move accordingly. Look at the pages FuturePosition and Apollon for ways to implement this. Also try PPP and check its source code for an implementation of the Apollon published code. PPP also has RobocodeGLV014 debug output code which might make it easier to experiment with this. -- PEZ

Bots using:

• Aleph
• Apollon (MiniBot)
• Ascendant
• BasicSurfer
• CassiusClay
• Chalk
• Cyanide
• Crusader
• DarkHallow
• Dookious
• Engineer
• RaikoMX
• Komarious (MiniBot)
• Krabby2
• Okami
• Pear
• Phoenix
• PowerHouse
• PPP - The name is short for Precise Prediction Pugilist
• PulsarMax
• Shadow
• Strength
• Toad
• SilverSurfer
• WaveSerpent
• YALT

---

Comments anyone?

You are right about Shadow, PEZ. In it's first WaveSurfing versions (2.31) it didn't acount for wallSmoothing, though. -- ABC

Added a few bots, but I'm sure plenty are still missing. I'm just guessing about Ascendant... hehe. =) -- Voidious

Sub-page of Wave Surfing

I think this page should be moved to Precise Prediction, since it really is not specific to Wave Surfing. I've used precise prediction for calculating max escape angles in my gun for a long time now, and in Diamond I even use it in the melee movement for wall avoidance. Any objections? --Voidious 16:02, 25 August 2009 (UTC)

Agreed :) --Rednaxela 16:05, 25 August 2009 (UTC)

No objection » Nat | Talk » 13:16, 26 August 2009 (UTC)

Code Size

I have done a little work and determined the codesize of various implementations (cut down a bit).

Each of these I have removed code that handles looping, and kept only prediction code with the most options. So obviously not a perfect measure, but definitely ballpark.

Rozu's code required the most `rewiring` (for obvious reasons). But I didn't touch any base logic in any of them. But the main difference between all of these is the feature list.

Chase's Simulate: 353 bytes
Chase's NanoSim: 168 bytes :(
Rozu's ApollonSim: 148 bytes (approximate)
Albert's MovSim: 854 bytes (wow)
Nat's MovementPredictor: 457 bytes

— Chase-san 15:41, 20 November 2011 (UTC)

On that topic if anyone wants to lend a hand to my short todo list on my nano predictor. :)

package cs;

import robocode.Rules;
import robocode.util.Utils;

/**
 * My attempt to make a very very small modern precise predictor
 * Codesize: 168 bytes
 * @author Chase
 */
public class NanoSim {
	public double x, y, heading, velocity;

	public void simulate(double angleToTurn, int direction) {
		//HEADING AND SUCH
		double turnRate = Rules.getTurnRateRadians(Math.abs(velocity));
		heading = Utils.normalNearAbsoluteAngle(heading + Math.max(-turnRate, Math.min(angleToTurn, turnRate)));

		//VELOCITY AND ACCELERATION

		//TODO find a better way to handle stopping (direction 0)
		//direction hack; causes vibration over zero
		if(direction == 0)
			direction = -(int)Math.signum(velocity);

		//If it's sign does not match, it needs to slow down, so apply deceleration instead
		//I admit it, I took this one from Apollon, it's just too good not to!
		double nvelocity = velocity + ((velocity * direction < 0) ? Rules.DECELERATION*direction : Rules.ACCELERATION*direction);

		//TODO find a better way to do this (maybe avoid making the variable if possible)
		//if it's sign changes (pass over zero), divide it in half
		if(nvelocity * velocity < 0)
			nvelocity /= 2.0;

		//TODO find a nice (small) way to handle a user max velocity

		//limit it to the max velocity
		velocity = Math.max(-Rules.MAX_VELOCITY, Math.min(nvelocity, Rules.MAX_VELOCITY));

		//UPDATE
		x += Math.sin(heading) * velocity;
		y += Math.cos(heading) * velocity;
	}
}

— Chase-san 15:41, 20 November 2011 (UTC)

Hi. Not sure if this is still in progress, but i touched it a little and came up with this (128 byte and max user velocity) :

class NanoSim {
    public static double	x, y, h, v;
    
    public static double simulate(double att, double d, double maxv) {
      if (d == 0) d = Math.signum(v);
      if (v * d < 0) d *= 2;
      if (((d = v + d) * v) < 0) d /= 2.0;
      double r = limit(Rules.getTurnRateRadians(v), att);
      x += Math.sin(h = Utils.normalNearAbsoluteAngle(h + r)) * (v = limit(maxv, d));
      y += Math.cos(h) * v;
      return att - r;
    }

    private static double limit(double minmax, double value) {
      return Math.max(-minmax, Math.min(value, minmax));
    }
}

At least it makes the same as the old NanoSim. Not sure if it is sound i have to check it later a little more seriously. But eventually it helps a little and shows the direction.

EDIT: Well after playing with the LocationBot it turned out i had to change it. Simulate now gives the rest att back and can be used for the next step. If the direction (d) is correct it works quite nice (there is a little glitch if the bot begins to get straight but most of the time he is right and ends up at the the predicted coordinates). One issue is still to find the right direction. Has anyone an idea how to get the right direction?