Talk:Wave Surfing

The Next Level

Quite a while ago I had an idea that could bring Wave Surfing to a new level, but I never got around to implementing it. Since the wiki's been quiet the last few days, I thought perhaps something like this might provide a kick to get things rolling again. My idea is Wave Surfing with a twist: not only do you surf the wave(s) that have been fired, but you also take into consideration the waves that have not yet been fired. By predicting your movement, you can predict what the enemy will see, and thus by looking at your movement stats you can see where they are likely to fire. Now, for the interesting part: by varying where you go, not only do you vary what GFs you reach, but you also vary what the enemy sees, and thus where they shoot. Danger can be calculated not only as a low point on a graph, but also on the entropy of the enemy's firing stats when presented with this movement. The more peaked the profile, the better this movement option (provided we can get to a low point). A system like this could basically 'figure out' how to do a movement type like Stop And Go, and probably other amazing types of movement we haven't thought of yet. There! How's that for some food for thought? =) --Skilgannon 20:23, 9 July 2009 (UTC)

Some interesting thoughts here. I'm initially skeptical (as usual =)) because it reminds me of the diminishing returns on surfing waves beyond the first couple. But ignoring that... One hurdle with this is that while you can predict your own movement, you can't (accurately) predict the enemy's movement, which also impacts what they "see" -- distance, lateral velocity, wall distance, etc. depend on enemy location as well as your own. It's a funny thought to use your gun to predict their movement to assist in your own movement. =)

So let's say you can guesstimate the enemy movement -- and maybe the full range of their movement options are pretty similar for our purposes anyway. So for each of my movement options, I'd figure out if/when the enemy would fire (based on gun heat) during that prediction, check my stats of the enemy's bullets fired / bullets hit, factor in the precise max escape angle of that firing situation, and multiply the probability he would hit into the danger calculation. Kinda similar to how many of us factor in distance (and maybe instead of distance, since these two factors would not be independent). I'm still skeptical, but this sounds really interesting!

Good to see I'm not the only one still pondering the next big thing. =) I still want to find a breakthrough in Anti-Surfer Targeting... I know it's there!

--Voidious 20:52, 9 July 2009 (UTC)

Gaff's anti-surfer score in the TC2K7 isn't enough? I have a dev. version that scores 82.93 against surfers (15 seasons) but worse overall once the random movers are averaged in. If you create a new Anti-Surfing Challenge I'll be happy to keep looking for improvements. =) --Darkcanuck 21:49, 9 July 2009 (UTC)

Hmm, those are some pretty sick scores. Besides the scores themselves, it's particularly impressive that you nail Shadow and RaikoMX so well with one gun. I'm guessing not by the description, but do you simulate enemy surf stats in any way? That's the main area where I think a breakthrough might await, but even my best efforts haven't yielded much. That Anti-Surfing Challenge sounds pretty appealing, actually, even if it will do squat in closing the gap to DrussGT. =) --Voidious 00:34, 10 July 2009 (UTC)

Thanks, I'm very pleased with that gun. There's no simulation involved, besides a rough calculation of the min + max reachable GFs -- the rest is all NN magic. I promise to write it up one of these days, I'd like to see what tangents others might take. --Darkcanuck 03:58, 10 July 2009 (UTC)

I was once tried simulating the surfer stats, but the result with normal bin smoother will have a load of empty bins that have no data. So you can't really decide where to fire unless, of course, you are simulating a surfer movement too. But next generation Go-To surfer can kill that instantly. Note the next generation go-to surfer is not this next generation wave surfer, it will be like when you may chose a point that close to you, and stay still until the last moment and move to that spot in time when the wave reach or something more that that.

We can have anti-surfer challenge in Challenge 2K9, I think we should have one. I'll continue working on Challenge 2K9 when I have time (October, when the school holiday arrive.) » Nat | Talk » 05:15, 10 July 2009 (UTC)

Yep, you probably shouldn't use only enemy surf data to shoot at. But there's important data there that I really think can be factored into the gun. I'd definitely account for what GFs they can still reach on each wave (ie, the "simulate their movement" part). I don't think an Anti-Surfer Challenge needs to be a subchallenge of another challenge, since most of our movement and targeting challenges aim to gauge rumble performance, while this one clearly would not. --Voidious 13:44, 10 July 2009 (UTC)

If you look closely, the Challenge 2K9 is main challenge plus a bunch of subchallenges. I think most Anti Surfer gun indirectly simulating enemy surf stats already. Since we usually reduce twice on hit, it would result like the simulated enemy surfing stats plus normal stats to decide where to shot in a load of empty bins. However, we can assume that the enemy will not changes its direction until one wave passed over. Then we may assume which direction the enemy will go next, etc. » Nat | Talk » 14:47, 10 July 2009 (UTC)

Fiddlesticks, this was going to be my killer idea once I made a wavesurfing bot!...Creating misleading spikes--CrazyBassoonist 21:10, 9 July 2009 (UTC)

Approaching this from a slightly different direction, you could "snap" your movement to certain points when you know they're about to fire, essentially reducing the resolution of their segmentation. In a single turn you can do that with velocity, snapping it to 8, 5, 2, 0, -2, -5, or -8. In two turns you can also keep acceleration constantly at 0. With a few more turns' warning you could limit velocity to even fewer values. This would be easiest against bots that fire slow, infrequent shots since your movement would be disrupted less often. -- Synapse 23:29, 9 July 2009 (UTC)

Interesting... for a simple movement (stop&go, flat, singlebuffer flattenerless wavesurf), it is possible to predict a reasonable accurate location in future. Thus it needs a lot of processing so I don't sure if it will run in time. But it may make up to 100 rounds to learn how they move. I never tried (but I'm writing a library that do this in past 2 months. It's call BattlePredictor, originally I will use it for melee)

One thing that should be consider when creating a wave surfing robot that use this generation, it should be totally useless against a simple gun and probably loss score (I'm highly doubt that using this may lead to another performance enhancing bug). » Nat | Talk » 01:28, 10 July 2009 (UTC)

I think you guys might have gone off on a tangent here... I don't think Skilgannon's idea really involves "creating misleading spikes" so much as factoring in which movement profile will be presented to the enemy and trying to choose an advantageous one. A best guess at the enemy's movement would be simple and might work well enough in most situations, so it need not be slow. It would be augmenting normal surfing instead of replacing it, so you shouldn't lose score against anyone. I like the idea of snapping velocity, Synapse; I think you might gain performance against simple learning guns but lose performance against bigger guns (which have fancier segments / attributes that could "see through" the trick). --Voidious 13:44, 10 July 2009 (UTC)

Still if we augment it, not replace, the augmented result can make you drive into danger with some type of gun. I don't know that it will happen, but I highly doubt (with some hunch though) that this will not improved the score. But it doesn't mean that I'll not tried to do it. Synapse, if you limit the acceleration to zero, wouldn't it just goes back and forth? I know that velocity is the most popular segment, if distance isn't. But I don't think there is many guns that use n ticks acceleration (I know there is some bot use distance in last few/several turns). » Nat | Talk » 14:47, 10 July 2009 (UTC)

Nat, the velocity and acceleration limitations would only be applied for two turns starting immediately before gunheat zero, so the enemy is forced to put all his battle data into a small number of segmentations. -- Synapse 16:19, 10 July 2009 (UTC)

The reason I think this might be a big improvement over regular surfing is against the simple targeters: before we were just acting reactively, responding to the enemy bullets in the air, whereas now we could act pro-actively, by actually forcing bots to shoot where we want them to. This would eliminate all the 'lucky shots' that are the usual cause of being hit, due to not having enough room to manoeuvre (from walls) or being too close to dodge. Against other surfers, this bot could have a large advantage if it stayed at close distances, where it can still predict enemy shots a large number of ticks ahead, but the enemy would only have distance/bulletVelocity ticks to work with. Then there's the false spikes that were mentioned: I don't think these are really feasable, as the only way to make them is to create real spikes, and the more predictable stuff you do, the worse =) --Skilgannon 16:15, 10 July 2009 (UTC)

Questions

1. I don't understand why you use the absolute bearing from two ticks ago. From what I could tell, an enemy fires the tick its energy drop, which is also the tick you detect it, so shouldn't you use the absolute bearing from one tick ago?
2. To compensate for the edges or not?

--Starrynte 05:11, 17 October 2009 (UTC)

I don't quite understand the second question, but as number 1 goes. He fired one tick ago, you are right, but he aimed at you two (or even more if he waits the gun to align) ticks ago. Something like this.

• Tick 0, enemy calculates an angle to aim (high chance of it being a GF anyway). Sets his gun to turn to that angle.
• Tick 1, enemy's gun is now, ideally, aiming at his desired angle. Sets his gun to fire.
• Tick 2, you detect enemy's energy drop. You know he fired from his last position, but aimed at you at least two ticks ago.

Hope it helps. --zyx 05:43, 17 October 2009 (UTC)

Also not sure what you mean by the second question, but to elaborate on Zyx's explaination:

• Tick 0, enemy calculates an angle to aim (high chance of it being a GF anyway). Sets his gun to turn to that angle.
• Tick 0-to-1 transition, Robocode engine runs. Moves the enemy and turns the enemy's gun.
• Tick 1, enemy's gun is now, ideally, aiming at his desired angle. Sets his gun to fire.
• Tick 1-to-2 transition, Robocode engine runs. Moves the enemy and fires.
• Tick 2, you detect enemy's energy drop. You know he fired the position after the 1-to-2 transition, but aimed at you during tick 0 (using locations generated in the tick -1 to 0 transition) or earlier.

I personally find it sometimes helps to conceptualize it to also consider the transitions. Maybe I'm weird though --Rednaxela 06:29, 17 October 2009 (UTC)

We should have this posted on the page. It is almost exactly the same I asked before. To Red, you are not weird, it helps me too. To make it exactly what most do:

• Tick -2: Enemy aim his gun and call setFire();
• Transition: Gun is hot so it can't fire. Gun turned.
• Tick -1: Enemy aim again and call setFire();
• Transition: Gun is cool now. Robocode execute firing *before* gun turning. Enemy's energy drops.
• Tick 0: Energy drop detected.

Don't know if it help, though. --Nat Pavasant 12:02, 17 October 2009 (UTC)

OK, I understand it now - when aiming, the enemy is always using the absolute bearing from the previous tick. Anyways, my second question was whether the fact that GF 1 and -1 have fewer neighbors affected surfing at all, and whether you should compensate for that. --Starrynte 15:43, 17 October 2009 (UTC)

• Also a third question - you only log a hit in the surfing stats when you are actually hit by a bullet, correct? --Starrynte 15:52, 17 October 2009 (UTC)

I don't think anything is needed to compensate for edges like that. As far as when to log hits, normally you log when you're actually hit, many bots also log BulletHitBullet events since they also reveal where the opponant aimed. If you're making a flattener, the flattener will log every wave whether it hit or not. --Rednaxela 16:22, 17 October 2009 (UTC)

Aahh, finally I understand what a flattener is used for. But hey, I'm only a newcomer ;P --GrubbmGait 18:11, 17 October 2009 (UTC)

=D I don't believe you. --Nat Pavasant 12:43, 18 October 2009 (UTC)

I'm not sure if they always use the bearing from two ticks ago, there are bots that predict their and your position for the next tick, maybe some of them use that bearing for aiming, and some use an older bearing if they wait for the gun to align. But the bearing of two ticks ago seems like the most accurate if you have to settle for one of them, and most bots will actually use that one. --zyx 19:43, 17 October 2009 (UTC)

Direct message to Starrynte. User:Nat/WaveSurfingQuestion may have answer to your future question if any.

No offence, but if I'm newcomer I won't understand what Rednaxela said. If you are newcomer you would want reason. I don't know if Starrynte wants, though, but here it is anyway.

You only log for bullet hit, yes, because you know exactly which angle they are firing, and avoid them. So it isn't exactly the same as a reversed GF gun. This is suppose to dodge simple gun like LT/CT/HOT and very basic GF. But when you faced advanced GF gun, you will need a flattener, which you will log for every wave passed. This way you are simulating enemy's GF gun.

As for second question, this is used to call 'edge smoothing' IIRC. I think just normal smoothing will do fine. just don't update anything when you reached the edge. But actually many advanced GF guns don't have bin smoothing at all. --Nat Pavasant 12:43, 18 October 2009 (UTC)

I had been thinking about gathering more information about the enemy gun and finally found a way to do it. If we know that a bullet shadow is safe, can't we add it to safe points to learn. A robot would be able to learn without getting hit. What do you think?

shadowed area isn’t really safe until your bullet passes enemy wave. so just do it every time enemy wave breaks.

keep tabs on shadowed area as in keeping track of hits, and retrieve them in the same way. then shadowed area could be handled like real shadows, but weighted.

I am going to do it like that in Oculus 1.3.3. Also I was too lazy to calculate without bullets passing the waves so I did it by simulation. It will be easier to add.

I made this for a micro bot. It is wave surfing but it is not Goto or True wave surfing. It is something more like gravity surfing.Is there a name for this? Sorry for pasting the all code.

    public static double[][] m = new double[3][5];
    double enemyEnergy = 100;
    ArrayList<Wave> waves = new ArrayList<>();

    public void run() {
        setTurnRadarRightRadians(Double.POSITIVE_INFINITY);
    }

    public void onScannedRobot(robocode.ScannedRobotEvent e) {
        double bulletPower;
        double absoluteBearing = e.getBearingRadians() + getHeadingRadians();
        double lateralVelocity = getVelocity() * Math.sin(getHeadingRadians() - absoluteBearing + Math.PI);
        if ((bulletPower = (enemyEnergy - (enemyEnergy = e.getEnergy()))) <= 3 && bulletPower >= 0.09) {
            waves.add(new Wave(bulletPower, getHeadingRadians() + e.getBearingRadians() + Math.PI, e.getDistance(), (int)Math.round(lateralVelocity / 8)));
        }
        double max = 0;
        double dir = 0;
        for (int i = 0; i < waves.size(); i++) {
            Wave w = waves.get(i);
            w.move += getVelocity();
            w.time--;
            if (w.time <= 0) {
                waves.remove(w);
                i--;
            } else {
                dir -= w.dir / w.time;
                max += 1 / w.time;
            }
        }
        dir /= max;
        setAhead(Math.max(-1, Math.min(dir, 1)) * 36);
        setTurnRightRadians(normalRelativeAngle(wallSmoothing(getX(), getY(), getHeadingRadians() + e.getBearingRadians() + Math.PI / 2, (int)Math.signum(dir)) - getHeadingRadians())); //Staying perpendicular to the enemy to have a large escape angle
        setTurnRadarLeftRadians(getRadarTurnRemaining());
        System.out.println(Arrays.deepToString(m));
    }

    public void onHitByBullet(robocode.HitByBulletEvent e) {
        if (!waves.isEmpty()) {
            Wave w = waves.get(0);
            m[w.segment][w.segment2] += Math.signum(w.move);
        }
    }

    public void onHitWall(robocode.HitWallEvent e) {
        onHitByBullet(null);
    }

    public double wallSmoothing(double x, double y, double currentAngle, int dir) {
        if (dir != 0) {
            currentAngle += Math.PI / 20 * dir;//This is optional. I use it to get away from the enemy
            Rectangle2D battleField = new Rectangle(25, 25, 775, 575);
            while (!battleField.contains(x + Math.sin(currentAngle) * 160 * dir, y + Math.cos(currentAngle) * 160 * dir)) {
                currentAngle -= Math.PI / 45 * dir;
            }
        }
        return currentAngle;
    }

    public class Wave {

        double speed;
        double mea;
        double time;
        int segment;
        int segment2;
        double dir;
        double move = 0;

        public Wave(double power, double angle, double distance, int segment) {
            time = distance / (speed = (20 - 3 * power));
            mea = 8 / speed;
            this.segment = segment + 1;
            dir = (int)Math.signum(m[segment + 1][segment2 = (int)Math.round(time / 91 * 5)]);
            if(dir == 0) {
                dir = Math.random() < 0.5 ? -1: 1;
            }
        }
    }

I'm not sure I follow your logic with this. Could you explain how the pieces are meant to work?

Also, there might be a bug with w.move += getVelocity();, since that is the velocity of the robot not the wave.

To predict where to move: robot sums the predictions of the waves weighted by time since fired. After if it is positive it moves ahead, if it is negative it moves back.

To learn: Every wave gets the total velocity of the robot while it moves, not deleted. If the wave hits, it gets the sign of the total velocity and add it to it's slices.

When a wave is fired it gets the value in it's slices and sets it's prediction to it.

Sorry if the weighted sum is positive, it moves back.