MovementProfile

This is a term describing a movement as it is observed from a robot shooting with StatisticalTargeting in general and GuessFactorTargeting in particular. To trick these targeting methods you should try get as "flat" a profile as possible. To illustrate what it means let's look at a movmenet profile of Mako 1.3.1:

This profile graph is drawn from data collected by StatistRobot. Never mind the blue curve. The red curve shows the "guess factors" visited by Mako as measured after StatistRobot has fired a virtual bullet, or 6792 virtual bullets to be more exact. Like so:

1. StatistRobot fires a bullet and looks at where the enemy bot is heading lateraly.
2. When the bullet is at the same distance from the firing location as the enemy the bullet can be said to be "finished".
   1. If the enemy bot has continued in the same lateral direction as it was when the bullet was fired it registrers a point at the far right end of the graph. (Guess factor 1.0)
   2. If the enemy bot has changed direction and traveled the full distance it possibly could a point is registrered at the far left of the graph. (Guess factor -1.0)

A bot that manages to flatten this curve distributes its movement evenly over the guess factors from -1.0 to 1.0. The Mako graphed above obviously fails to do this and is often moving near guess factor 0.0 (meaning you would hit it a lot using HeadOnTargeting). Other profiles might show spikes at guess factor 1.0 (meaning the bot is very often traveling in the same lateral direction for the full BulletTravelTime, like Walls). Or spikes at -0.3 (meaning the bot often changes direction after being fired at, but doesn't travel the full distance).

For a comparison check this profile which is from Mako 1.5 (not released as of June 8 2003). It is from a longer run against StatistRobot so it looks smoother. But it's also much flatter. I think it's the flattest I've managed to create so far.

The curve showing SandboxDT 1.81 at this distance (and near and far distances) for a comparison can be found on the SandboxDT page.

You will note that acording to statistRobot, Mako's movement at this range is better than DT's - (acording to DT's internal stats Mako has better movement than DT between the range of 360 and 440) alot of battle takes place in this range. Why does Mako lose?

Is it:

• DT does not fire 3.0 bullets at this range (and Mako is good at movement only against 3.0 bullets).
• DT has better movement against 3.0 bullets than Mako at ranges 0-360 and 440 and above.
• StatistRobot only does guess factors for what I call Absolute GuessFactorTargeting and not Linear GuessFactorTargeting (see SandboxMini source for more details). (if your robot does not always move at right angles it is more susceptable to linear guess factors and StatistRobot underestimates the hit rate.
• DT has better guns
• all of the above :)

Even so Mako has reasonably sound movement and is not very susceptable to the highly segemented guns of DT well done PEZ. However the bad news is that Mako has also shown that there is room for DT movement to improve (especially against 3.0 Bullets) so watch out for the next version of DT if you fire 3.0 bullets. -- Paul Evans

Thanks! I don't mind making you feel you must improve DT. =) After all DT has been forcing me to keep improving my bots all the time. Also thanks for feeding the wiki with all this valuable knowledge of yours. I have suspected Mako is weaker against bullets fired with other power than 3. I will work on that. Though I think most of the difference between Mako and DT performance is due to the guns. Especially the later versions of Mako have crippled guns and they can never even start to compare with the best guns in the population. It's amazing Mako gives DT the fight it does. -- PEZ

---

OK PEZ, according to Paul's latest post on the repository you have managed to flatten your curve out to the point you are close to matching DT. Would you care to share some tips? jim

Did I say that - I think I was refering to DT1.81 --Paul Evans

Sorry jim, but right now I'll keep it a secret. It has been hard work for my PowerBook and straining on my sanity to tune this movement and I think it right now gives Marshmallow an edge that it needs to kling on to a top-5 ranking. I can say this much:

• Make heavy use StatistRobot
• Don't misinterpret the scale of StatistRobot's graphs
  • Think of -49 as -1.0 and +49 as +1.0. They are guess factors. A spike at the +1.0 end says that you often complete your travel in the same direction as you where traveling at the time the virtual bullet was fired at you. Negative factors occur when you have changed direction since the virtual bullet was fired.
• Try different tuning factors and be careful with how you measure their performance.
  • I use a simple but slow measure: the win ratio of my robot. Like so:
    • Choose a factor
    • Run 1000 rounds against SandboxDT
    • Note the factor and the win ratio
    • Repeat (I think I have gone through this loop 100 times, and that on my Java-slow PowerBook...)
  • I combine this with DynamicFactors, much like Kawigi does with his DynamicDistancing

Further, if you run Marshmallow against StatistRobot you will notice that it is not a very flat profile at all. I've seen other bots have flatter profile, including some of my own. Flattness is only a means to an end. The end in my case being to avoid DT's bullets. -- PEZ

Paul has also tested Kawigis HT-movements and said that it is good, even better than DT 1.71 at close ranges. So it can be worth studying the movement code in MakoHT/Code. All of Kawigis' bots are OpenSource so you could also check FloodMini I guess. -- PEZ

Thanks for the pointer guys. I am interested in techniques on controlling my movement profile and these are all good suggestions. I am going to suspend development on Jekyl a bit as I work on my Poison movement system. These are all ideas that should find their way into it. Thanks again. (PS: Congrats PEZon getting M to #4) jim

---

I'm still confused about the blue curve. What does 'the more increasable probability' mean? - Vuen

I can't remember precisely how it's done, but i remember reading somewhere that the blue curve shows the data when the virtual bullets are weighted according to some factor. All i know for sure is that the blue curve tends to make my movement look bad so i tend to ignore it... --Brainfade

The red curve is the entire history of dodging statistics. However, the blue curve is the curve the bot actually uses to fire. It is "weighted" in a sense in that the most recent values get the most weight. It uses what Paul Evans calls "rolling averages". -- nano

Just ignore the blue curve as long as you are using the graphs to tune your movement profile. It's impossible to keep the blue curve flat. -- PEZ

can someone explain the graph in a little more detail?i'm completly lost-andrew

Have you read GuessFactorTargeting? If not, you should, because without knowing about GF the graphs will make absolutely no sense at all. -- Tango

---

What is the best way to awoid 0 guess factor spikes. Any suggestions are well come. --SSO?

With a simple movement system, GF0 spikes occur when you change direction too often, from what I've found during my testing. Of course, if you change direction too rarely, you get spikes at GF1. That's the key to a good simple movement, getting the balence right. Most people seem to be going in the direction of AdaptiveMovement though, which I would guess has different problems. -- Tango

• I think that AdaptativeMovement? is a term that can be used very widely, afterall what is AM? I could called MusashiTrick or AntiMirrorSystem as AMs (just to be clear: i'm not claiming it), since they are adaptative movements. The real AM should be able to deal, on-the-fly, equaly well with GF, PM, HeadOnTargetingGun? , etc... -- Axe

A common source of GF0 spikes is problems with CornerAvoidance. -- PEZ

I changing the directions quite often couses this problem, as least in my case I think. I'll further look at the two sugesstions. --SSO?

Another source of GF0 spikes has been from ramming bots I recall somone not being able to explain their own GF0 spike only to discover it was as a result of ramming when the enemy had stopped firing. -- Paul

That was me... Switch of ramming when profiling your movement is the lesson. -- PEZ

Yep, Thats an other lesson learned. Are there any small code sniplet that I can get better negative spikes. In my tests I get negavie spikes when deselating over all I have posive spikes. -- SSO?

Ask the secretive ABC about it. =) -- PEZ

I can tell u that a good thing to give you negative spikes is synchronizing your turns with the enemy firing. But i can tell u that this would make you a hell-good-tasting bot to PM guns (like mine:). I am very truthly convinced that the search for the negative GF is like a saint-graal search (i believe in The Graal, but stop searching). -- Axe

I actually stumbled across a movement yesterday (quite on accident, I assure you) that's almost flat from GF -.4 to 1.0 and doesn't react to bullet fire in any way. The problem is that it's still not a good movement - under further segmentation (acceleration to be exact), it's just awful. If you have FloodGrapher 2, you can download it [here] and look at it (I was trying it with F-Micro). It's in FloodGrapher format. It just goes to show how you can make a movement that looks good at first glance in FloodGrapher but still be way too predictable, even for a guess factor gun. -- Kawigi

I've had a similar experience. I even produced one which could be tuned to produce a spike in the negative-GF range with no reaction to bullet fire, while always either moving at max velocity or turning. It was plain lousy, regrardless.

One way to produce negative peaks may be to go forward, say, half a bullet travel time at velocity 2, then change direction and go at max velocity. Unfortunately you will obviously be murdered by acceleration segmentation and pattern matchers, unless you can see some way of introducing a good random component to it. -- Jamougha

I saw somewhere discussion about predicting when your enemy will fire by keeping track of their gunHeat, so you can dodge the bullet a tick or so before it is fired, so start the decceleration earlier (just be careful not to start it so early that you are going the other way by the time they fire). It is also vulnerable to acceleration segmentation, of course. -- Tango

This one just kind of came up that way with very little tweaking (the first version of it had a spike at +1.0 and was exactly flat from about -.5 to .8, but still had the weakness it has now, of course). I don't know why it happens, but maybe you could give it a shot, Jam, as you are a little more sound than me in analyzing mathematical functions.

I was participating in your "excercise for the reader" and trying to figure out how to generate the Raiko movement with a function that tells me how long to go in one direction at a time. I thought that maybe using a function with the Poisson distribution would work, and so I looked around for code that generated a poisson distribution and eventually found some. I used projected bullet flight time as the supposed average and tried it out (later I tweaked it to .85*projected bft). Then I figured out that the code I was using was basically equivalent to some I could use to decide to change directions on any turn, but unlike Raiko, it doesn't have a uniform chance of changing direction at any chance. Basically, I have a variable called "product" that starts out at 1, and every turn I multiply it by Math.random(). Once it gets to be less than a certain boundary, e^(-.85*bft), it switches direction and sets product back to 1. Any idea why that would give me a big, gradual hump on the negative side? -- Kawigi

Interesting problem... I have no idea how to model successive calls to Math.random() analytically, but intuitively it will give you a generally fairly constantly declining factor with large local variations. So, for a given value of bft you will hit the e^(-.86*bft) factor at, say, an average time of x with most values quite close to x, though probably not normally distributed, more like evenly close to x and tailing off super-exponentially far from it. However this is all basically (not-so) educated guesswork. I know from experience that this sort of movement gives you negative humps, but I'm not 100% sure why; partly because I've never bothered analysing it, as it's clearly not a good movement type. :-) Part of the reason is that you're spending so much time turning; more time turning gives more time at low velocities, which makes it easier to reach low guess factors. But then acceleration segmentation cuts that up pretty well. -- Jamougha

please check the link https://www.honeylocust.com/RngPack/ it says "RngPack? is a pseudorandom number generator package for Java. Pseudorandom means that the "random" numbers are generated by a deterministic mathematical process, not by a fundamentally random physical process such as radioactive decay or Johnson noise." may be of the intrest. SSO?

Hmm, never knew about StatistRobot...now I see have have spikes around -20 and positive 20-30..around guessfactor 0.5...must be my StopAndGo --Starrynte

Ok using FloodGrapher, so far the flattest i've ever been able to get was some dev version of Lasers: As you can see im trying to fix that horrible 0.5 spike...oh and the red is Lasers, green is SnippetBot's graph, I just added it for reference... --Starrynte