Difference between revisions of "Talk:Random Movement"

From Robowiki
Jump to navigation Jump to search
m (Moved discussion)
 
(Robobot 0.1 : correcting user page links)
 
Line 12: Line 12:
 
Many succesful 1vs1 bots use this kind of movement.
 
Many succesful 1vs1 bots use this kind of movement.
  
[[Albert]]
+
[[User:Albert|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?
 
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]]
+
--[[User:Nano|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]]
+
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 [[User:Kawigi|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. =) -- [[User:PEZ|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]]
 
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]]
+
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...  --[[User:Voidious|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]]
+
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?  -- [[User:GrubbmGait|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]]
 
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]]
+
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.  -- [[User:GrubbmGait|GrubbmGait]]

Latest revision as of 08:44, 22 May 2009

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