[Home]Kenneth/Movement

Robo Home | Kenneth | Changes | Preferences | AllPages

Ok, so here's how it works at the moment (i would paste the source, but it's on a different computer and i can't transfer it right now. I'll do it at some point)

Using 3 magic formulas, i make 3 estimations of how long i have to move before a hypothetical bullet fired that second would hit me. These are quite random, but have logic embedded somewhere:

I find the biggest of these 3 numbers, this is used as a timeout on the current move. It is then multiplied by 8, and then by Math.random() to decide on the distance i am to travel this go. I then decide on the distance i want to be from the enemy (at the moment this is simply ((Math.random()*100)+ 350). if my distance from the enemy is more than i want, then i aim for a spot 50 units closer. If i'm too close i aim for a spot 50 units further away (or if my move distance is less than 50, then it is half my move distance either way).

Having deicded on these 2 values, i run them through a formula along with my current position, and the enemy current position to find out an intersection point where the required distance from enemy and required move distance is met. This generates 2 coordinates. I randomly slect one of the two, check to see whether it is inside teh battlefield. if so then i move to it, if not then i check the other. If neither are inside then i call the fucntion again, and all distances are re-calculated. this will loop for a maximum of 50 times.

If i still don't have a coordinate inside the battle ground, i pick a bearing that is not closely heading towards a wall set the moveTime to 10, so hopefully when the next move is done i am in a more hospitable position. In order to try and flatten the movement i have been playign around with different maximum velocities.

Ok, so the things i'm not sure about are:

  1. Is this a lousy idea, or have i just not found a set of variables for which it works??
  2. Are my spurious moveTime formula's just a bit too contrived??
  3. is it really a good idea to try and stay at a fixed distance from the enemy??
  4. Are move timeout's a good idea?? (especially if i'm staying at a fixed distance as it will probably created a spike in my movement profile)
  5. Is it a good idea to randomly select the direction that you move in, or should you force an oscillation by alternating it??
  6. Does using coordinates and a goTo statement limit the possibilities for curve flattening?? (As you are fixed into a destination when you start the move, rather than being able to change it at will).

Any input would be greatly received, as this is making my poor little brain hurt -- Brainfade


I would start with simplifying the calculation where you figure out how long you can travel. Many good movers use only for this. But I know iiley also uses: The first one is for when you are traveling at a straight line along the right angle of the enemy bearing. The second for when you are moving in a circle around your enemy.

Then I would try to not use a fix distance to your enemy. You can add it later if you think you need it.

Move timeouts are used by many with various success. Griffon does it.

I think it is an excellent idea to randomly choose direction. You "only" need to find the right timing of when to choose a new direction to create a flat profile. Forcing oscillation is probably not a good idea.

I often vary the max robot velocity, but I know the two best movers out there (Lacrimas and DT) doesn't, so it's probably not needed.

To answer your last question. Many bots do this. And Lacrimas does it too. You can at least start out that way I think.

-- PEZ

About the maxEscapeAngle?,i think

would be the maxEscapeAngle? when you are moving in a circle around your enemy.The second of PEZ said in my bots it mean the maxEscaplAngle? when i traveling at a straight line to keep the destination's distance to enemy same to the current distance(it means enemy point,my start move point,destination make up of a trigon with two same length side). -- iiley


I think your best bet to improve your movement is to simplify it (KISS). If you allways stay roughly at the same distance from the enemy, the max movement timeout until a shot arives can be simplified to distance/lastBulletSpeed?. The most important factor in that type of movement is the inversion probability, and if you stop or not between each run (and how much time). Another important factor, imho, is the distribution of the random function used. Math.random() will give you a linear distribution (every value has the same probability), but you can make it have a tendency for the large or small values using Math.pow(Math.random(), factor). For example, Math.sqrt(Math.random()) will still give you a 0<x<1 random number but with a big tendency for the large ones (closer to 1). Another nice transformation (wich I use a lot in Tron/Shadow?) is -Math.log(Math.random()), wich will result in an exponential distribution with a very strong tendency for the smaller values and very rare big values (>1). But first, smplify! Try to make your movement depend only on 2-3 factors, that way you can play around with them searching for a "flat" movement. Use the grapher bots to find out how each of those factors affect your movement profile. Good luck, the key is dedication, when you become obsessed it means you are on the right track. ;) -- ABC

I utterly agree! Make it just one tweaking factor if you can. And obsession is the key. Let yourself be dragged down deep in te robocode fanatics swamp. =) Jim is an example on how far determination can take you. Already after a week or so after downloading the environment he told me about his plans to rise to the top-10! -- PEZ


I have been working along this lines for a form of movement too. I think it is worth a shot. My version has has simplified to Math.asin(8/bulletV). I think it has merit but I have not totally implimented it yet. I wish I had more time to work on it I really believe that movement is what is holding Jekyl back -- jim


I work on the KISS principle also - I decided my main rule would be to move either clockwise or anticlockwise around an opponent and wrote a movement system that would do that - the core system has an overide so that it won't crash into the wall or an opponent who is on the edge of a battefield - it also has a move nearer/further away angle setting so that distance can be controlled. Once these factors are in place I could concentrate on the tweekable part of the movement which is simply how long to move clockwise or anticlockwise - of which the main influence should be how long the enemies bullet flight time is - but there are others... Good Luck -- Paul
On the advice given above (one of the things i love about robocode is that you can actually get advice from the best in the world) i have recently been working on a new simpler movement. It now only has 1 variable that i control, that is the factor of the maximum travel time that is used. I have been tweaking this parameter in 250 round battles against StatistRobot. This seems to improve my performance against some robots, yet hamper my performance against others. In order to check that i am on the right kind of lines, i have released a modified Kenneth with this movement, that is called Slain. When i see how it's performance compares with taht of kenneth i will remove him from roborumble and continue to work on Kenneth. Thanks for the support --Brainfade

The difficulty with an meximum travel time is that it offers some predictability - e.g if you set the maximum travel time to 20 ticks and have been traveling in the same direction for 18 ticks - an opponent knows you are about to change direction. You may find it less predictable to use a fixed chance of a direction change for each tick (or a gradually increasing chance of a change of direction) - this should take out an element of predictability. -- Paul

Maybe i was slightly misleading with what i said. The value i have control over is the coefficient of Math.random() that selects the proportion of the maximum travel time to use (if that makes sense??). As far as i can work it out in my mind it shouldn't make any difference whether you implement this as a probability per tick or as a timeout. Seeing as the enemy shouldn't be able to work out when we are going to change direction. In fact change of flow mid sentence it will make a difference when you get towards the maximum travel time. Or will it?? i don't know. I'm gonna sit down with a piece of paper and decide. i wish i could decide things without a pencil... --Brainfade

The way i understand it is, Math.random() cannot return anything more than 1, so if you have been going in the same direction for coefficent*0.9 and still haven't turned, you must be going to turn very soon. If you had a check each tick (eg. if (Math.random()>0.8) {changeDirection();}) there is no maximum length, so the enemy has just as much chance of guessing right each tick, rather than the chance increasing each tick up to 100%. -- Tango

Yeah, both you(Tango) and Paul are right - I was getting it round my neck and trying to complicate the matter for no apparent reason. The problem i find with not have a set maximum move time (and therefore set maximum move distance), is that it invalidates my current wall avoidance method. I can think of a way around it, but i can also foresee problems with doing it that way. Anyway, i'm fairly happy with the improvement (10 or so places), and now know how to improve it. However i also reccon i can improve the travelTime segment of my gun. Hopefully i can sort it out out and serve up a new Kenneth version pretty soon... --Brainfade

That is true only if your inversion probability at the end of each run is 100%. Personally I find it easier to control with a max run distance. Also, it's not like your enemy is predicting your position in the next tick, that would be too easy, like laser weapons. ;) -- ABC

If you are using max run distances, then the inversion probability at the end of the run is obviously 100%, because you always turn at the end of the run. If the run in question is the full length of the max run distance, then the enemy can predict with perfect accruacy when you will turn. Oh, and BTW, try to avoid starting posts with "that" if it is not 100% clear to what you are refering. -- Tango

Sorry if it wasn't clear what I was talking about. You are assuming I always turn at the end of the run, maybe we have different definitions for a "run". I'm talking about a timeout until you make another decision. That decision can be to continue in the same direction for another "run", or invert and make a backwards "run". But even in your "100% inversion probability" case you only know for sure that the enemy is going to invert _in the next tick_ in very few cases, namely when the run time is the max run (3% of the time in a 30 ticks run, and that 30 ticks run only has a 3% probability of happening), and not what is going to happen in the next ticks. Maybe the enemy will make a small run backwards and then a big run forward. What I'm saying is that the increased predictability of a "max run time" type of movement is not significant, and depends a lot on what you do at the end of each "run". -- ABC

Going by your definition of run, all Paul and I are suggesting is making the run 1 tick long. I agree the significance is not all that great, but the slightest predictability is enough to lose you a few places in the league. -- Tango

Agreed. My point was that that kind of movement is much harder to "control". Let's say you have a 9% probability of inverting your movement at each tick when the bullet time is 30 ticks, how do you compute the probability of inversion for when the bullet time is 60 so that your movement profile stays the same at every distance? With a "max run" factored movement it's easy, just change that factor proportionally. -- ABC

The problem with that line of reasoning is, a perfectly flat profile is in fact predictable. You simply pick the lowest GuessFactor rather than the highest, because a curve flattener will go to the lowest GFs and avoid the highest, to try to level it out. -- Tango

That's a different discussion, but a very interesting one at that... :) I would say that an artificially flattened movement is in fact predictable to some extent, but a random one is not. -- ABC

You make it sound so easy to go to the lowest GF. It's not always physically possible, either. -- Kawigi

Yes, ABC, that's what i meant. I never said if it were easy or not, but it is the aim of "artificially flattened" bots. It may not be possible if there is a wall or a bot in the way, but other than that, it should be doable. -- Tango

True. The walls are the chaotic element of the "artificially flattened" movement, too. -- Kawigi

Artifical flattening is much more complicated than simply going to the lowest GB. Movement patterns are comprised of n spikes, where n is the bullet-distance (the number of bullets in the air between you and your enemy), and you have to flatten all of the spikes, not just one of them. Therefore, artificial flattening is only possible if you reduce the number of variables by staying at a whole-number bullet-distance (for 3-powered bullets, bullet-distance of 1 is 11 * 16 = 176), and possibly moving in multiples of bullet-time. I have some tormented scribbles in my Robocode notebook about this, but I don't think I'll ever try it because all of my other artificial flattening ideas have failed miserably. Except Spike, but that was a fluke. --nano


Rightyo, so having promised something special on another page i have to now backdown on that comment. I have recently been following the advice given above, and simplifying my movement and then doping lots of parameter tweaking and testing (I turned off my stat gun and used head on targetting). The majority of my testing was against DT 1.61 (Sentimental reasons - it was king when i first started robocoding), and after a period of changing and tweaking i managed to get it so i could beat DT 1.61. However then having tried this against a few other bots, i was getting absolutely spanked (aspid in particular). Then i optimised against aspid and i got beaten by anything with a stat gun. At the moment i have assembled a group of 6 bots and am testing against each of them and noting the percentage of the score i get. Is it best to simply add up all the percentages and use whichever parameter comes highest, or should i wait the scores by how many bots in the rumble have similar targetting, or should i just use the factor that beats cigaret (Actually i'm gonna test it and see if it beats DT 1.61, and Duelist. If it does i'll release it straight off - Damn my sentimental self...) --Brainfade

Taking the risk of feeding the enemies, take a look at Musashi's page about a KISS and efective movement. I think that it is what u search. -- Axe

I don't know if I've made a bot to this day that beats SandboxDT 1.61. I have made bots that could beat 1.91 about 1/3 of the time over long battles and 2.01 (I think) was the version that Sedan beat. Maybe Sedan was capable of beating some others, too. -- Kawigi


Robo Home | Kenneth | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited December 26, 2003 6:39 EST by Kawigi (diff)
Search: