Talk:Movement Weaknesses

"Bots that orbit an enemy without closing distance or that run away at orbit."
"Bots that dodge based on a timing pattern instead of enemy energy drop."

I argued. Ocnirp does orbit without any distance controlling, and at about exactly same pattern. It reverse its direction when:

1. Math.random() exceed 0.92 (I have test with 0.6, 0.8, 0.85, 0.88, 0.9, 0.92, 0.95, 0.99 and 0.92 work best)
2. Hit wall.
3. Enemy fire

... and it still stayed at #16 (first release is at #13, but later pushed down by several HUNRobar's bots) According to my test, this movement style dodge StatistBot better than Waylander/Toorkild flattener. » Nat | Talk » 15:21, 22 May 2009 (UTC)

Hmm. Does StatistBot segment on distance? And have you compared when segmenting on velocity? Using 0.92 would work for a certain distance, but closer than that and you will have a spike at GF1, and further than that and you will have a spike at GF0. --Skilgannon 18:07, 22 May 2009 (UTC)

StatistBot has only rough distance segmentation. » Nat | Talk » 15:56, 23 May 2009 (UTC)

your 3rd assertion, dodge on enemy fire means you are not dodging based on a fixed interval, which is weak. Adding .92 random makes your intervals very difficult to PM, making the movement even stronger. On orbit without closing range - watch your bot when it starts towards a corner. It will quite often corner death (hit wall, reverse, hit wall, ... die) because it isn't moving towards the enemy (and away from the walls). Bots the retreat will do this even more often.

The other half of my idea is I have done bots that reverse every say 16 ticks - the time it takes for a 3.0 power bullet to respawn. Works great for the first 10% of the fight, but gets ineffective quickly, and gets destroyed by 2.5 fire bots which take only 15 ticks to respawn. --Miked0801 22:13, 22 May 2009 (UTC)

Unrelated, but I'm curious. When did you figure out 2.5 fire power? This seem to be used a lot among top nanobots.I'd say, if we are talking only about top nanobot author, that NZ would get it first, then Robar, then me, then you. I don't think neither you, Robar, NZ nor me get this ideas from the other, as I test several fire power and this one seem to work best. And I later know that if we score each firepowers base on energy loss, energy gain, damage, time to recharge and velocity, 2.5 will get the highest. » Nat | Talk » 15:56, 23 May 2009 (UTC)

This is just a thought. Why would 16 ticks need to be hard-coded? Why not use something like this:

 public void onHitByBullet(HitByBulletEvent e) {
     double power = e.getPower();
     if(power >= 2.6) { movementTickMultiplier = 16; }
     else if(power >= 2.1) { movementTickMultiplier = 15; }
     etc...

--HACKhalo2 19:36, 23 May 2009 (UTC)

You are right, that would be better normally. However, in a nanobot it's more code size effective to just use a value like 16--CrazyBassoonist 19:54, 23 May 2009 (UTC)