They work in the following way:
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.
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
![[Home]](/images/RoboWiki.png)