Talk:Random Movement

This kind of behaviour tries to create a random movement, in such a way that you can not predict the future position of the bot based on its previous behaviour.

They work in the following way:

• You calculate how much will take an enemy shot to hit you.
• You pick some new random coordinates close enough to reach them in the given time frame.
• You move to the new position.

Of course, you must have a clever strategy to select your new coordenates. A completely random movement means that at least 1/4 of times you move almost-straight to the enemy, and 1/4 you follow an almost-linear path, so you are easy to hit. Also, corners and preffered distance must be taken into account. Adding some criteria to filter the possible destinations and selecting a good one is the key for a good random movement.

Many succesful 1vs1 bots use this kind of movement.

Albert

Yeah, RandomMovement seems to me to be a bit of a misnomer. Actual random movement would be ridiculously easy to hit. Perhaps someone would like to give the guidelines that good movement should follow, and where to add randomness?

--nano

Now, since I obviously fail in all my attempts to create random movement I should shut up in this issue. But shutting up is not my style. =) Anyway, my assumption is that the gunner must eventually always choose an angle for shooting and that this angle should be hard to predict if the target can manage to make it random. Marshmallow tries to figure out the EscapeArea it has available - you can't go past walls and traveling to straight towards or away from the gunner is seldom a good idea. Then Marshmallow chooses a random angle perpendicual to the enemy within this escape area. The escape area varies in size also with the power of the bullet fired so this is also taken into account. Versions 0.9.9.x of Marshmallow also kept book on what angles it had ended up in (using VirtualBullets) and favoured segments with less frequencies. This actually worked quite well, and I will put that back into Marshmallow soon. The aim is to flatten the fire angle curve for the enemy so much that fireing with HeadOnTargeting will be as good as any other method. The best flattener so far must be SandboxDT, but I have big hopes for the SandboxFlattener that Kawigi is working on. And who knows, with all the time I am putting into these efforts I just might succeed some day. If I do I will let you all know of course. =) -- PEZ

If you wanted RandomMovement to work randomly but not move linearly or anything, why not randomize your velocity each turn? That way, even if you DID move in a predicable way, you wouldn't be there at the predicted time. --Bayen

I have done some randomized velocity a little in some earlier versions of Dookious... Although it's not in there now, it really helped in some of my other movement schemes. One thing I did was to not randomize every single frame, since your acceleration/deceleration are limited, and thus you end up not being so 'random' on average if you change it every tick. (E.g., if you "randomize" from velocity 8 to 0 for a single frame, you'll actually just decelerate to 6 for one frame and then randomize again.) And while Dookious in his current form doesn't explicitly change his velocity, the nature of his WaveSurfing makes it so that his velocity does fluctuate a bit, anyway... --Voidious

When you start randomizing your velocity, you probably do it on a random interval, say once in 5 till 20 ticks. Also it seems wise to randomize from velocity 2 to 12 instead of 0 to 8. Everything higher than 8 will be cut off to 8, so a large part of the time you will travel at fullspeed. I do not think there are any advantages at traveling at low speeds ( < 2). You don't want to be a SittingDuck for 20 ticks, do you? -- GrubbmGait

Oh there aren't advantages to moving slowly? It tricks guns like heck. Python 3.4 uses an optimized VelocityTrick (nothing like the one on the VelocityTrick page, which he used to use.) -- Xero

There are some situations (mainly against some specific bots) where using very low speeds is benificial. See for example gh.mini.Gruwel against pe.SandboxLump. Also moving at a very low speed in one direction and switching direction when the enemy fires can be quite effective. These type of movements come close to a StopAndGo movement, alas I still have not found the time to create a well-written page for it. -- GrubbmGait

obviously that brownian motion is a worse random movement, but how about Levy flight? Has anyone tried this formula? ;)

http://www.cs.gmu.edu/~sean/research/mersenne/MersenneTwisterFast.java http://www.cs.gmu.edu/~sean/research/mersenne/MersenneTwister.java

The strength of the RNG doesn't have a massive bearing on the effectiveness of random movement. Also I am pretty sure most of us are already well aware of the Mersenne Twister.

why not

The main issue seems to be that you can't move to a random independent GF on all waves because waves are fired faster than their travel time.

Because:

1. So few random numbers are generated that even a pretty mediocre pseudorandom number generator would be pretty much impossible to predict. You need to capture a decent chunk of data to crack even a bad PRNG's state.
2. Battles have other confounding factors (i.e. walls) which may hide what random number a bot chose.

As an aside, that mersenne twister implementation is not a suitable replacement for Math.random() even if PRNG quality mattered, because it's not really more notably secure. If that was an issue, you'd want a cryptographically secure pseudorandom number generator, not a mersenne twister.

Also, an out-of-the-blue link to a mersenne twister page isn't really a useful post.