# GamePhysics/Old

Robo Home | GamePhysics | Changes | Preferences | AllPages

Difference (from prior major revision) (no other diffs)

Changed: 1,2c1,79
 null grew liveness victimizer ones reticle shillings repellent conviction [online casinos ] Gutenberg climber posteriori imaginary [online casino ] informal extinct ballooned [casino ] .

### Robocode Processing Loop

The order that Robocode runs is as follows:
#All robots execute their code until taking action
#Time is updated (currentTime++)
#All bullets move and check for collisions
#All robots move (heading, accel, velocity, distance, in that order)
#All robots perform scans (and collect team messages)
#The battlefield draws

* Where do the events get processed? -- filmil
* When does firing occur?
** On the next tick. The difference between fire() and setFire() is that fire() also runs the next tick. However, it is fired from your current location.
** Just to check, this would be the order of events (each bullet is a different tick, events ordered through tick)
*** Enemy Fires a power 3
*** Bullet moves 11, I see change, I move, I call setFire 3
*** Bullet moves to 22, I move, My bullet moves to 11 from my current position
** or is the bullet fired from the position I move to the tick I called setFire?
** Here's how I believe it works:
*** Enemy Fires a power 3
*** Bullet is still at the location the enemy was last turn, you see the change, move, call setFire(3)
*** Bullet moves to 11, you move, your bullet is now fired at your old location.
*** Enemy bullet has moved 22, your bullet moved 11.

### Time and distance measurements in Robocode

Time (t) Robocode time is measured in "ticks", which are equivalent to frames displayed on the screen. Each robot gets one turn per tick. 1 tick = 1 turn = 1 frame.

* How much in fact is the robot allowed to think? A "Tick" does not correspond to real time, but there exists a realtime limit on how long one can 'contemplate'. What is this limit, and does it depend upon the system the Robocode simulator is running on? -- filmil
* The Robocode environment tries to measure the performance of the system when it is started. This in order to make it not dependent on this. How much you are allowed to think I don't know really. It's seldom a problem anyway. You'll tire of the bot being a really SlowBot before reaching this limit I think... -- PEZ
* Ok, I just tested this, and if it takes more than 5 seconds in a tick Robocode determines not to calculate score for the bot, and after 10 seconds the bot is stopped and is no longer processed. When it comes to skipped turns however, I am a bit confused. A bot in an infinite loop will not recieve skipped turn events, but other robots in the battle will still execute (although at a slower framerate) this leads me to believe that robocode does not run battles strictly sequentially. It appears that ticks still continue while the bot loops (a getTime within the loop shows anywhere from 7 to 20 ticks a second on my comp)for the first 5 seconds, and then for another 5 seconds Robocode solely runs that robot (no ticks pass) until it is disabled. -- Jokester
* IIRC your robot is warped to the next tick. Your robot continues running where it was, as if it is still in the previous tick (besides getting new data from getX() etc). You only receive events when you move to the next tick normally. -- Jonathan

Distance Measurement Robocode's units are basically measured in pixels, with two exceptions. First, all distances are measured with double precision, so you can actually move a fraction of a pixel. Second, Robocode automatically scales down battles to fit on the screen. In this case, the unit of distance is actually smaller than a pixel.

* With all due respect, equating pixels with robocode units is simply an error. Robocode units (runits) do not correspond to pixels since display can be scaled. As it is now, the explanation says: the units are pixels, except sometimes when they are not. It does not seem to clarify too much. Thanks for your patience in reading this. :) -- filmil
* It doesn't really matter. It's like with time ticks. Just units. -- PEZ
** That's why I said the above: introducing pixels serves no purpose. But I guess if it has become a custom, let they be pixels... -- filmil
*** It does serve a purpose, though. The distance will always be in pixels unless the user makes the window too small to display the battlefield, in which case Robocode will scale the whole battlefield down. But it certainly is pixels by default, and will never be any larger than pixels. -- Kawigi
** This is just like scaling down a large image to fit an average screen. It is still, say, 2048 pixels wide, even though it is 1024 on that screen. -- Jonathan

### Robot Movement Physics

Acceleration (a) Robots accelerate at the rate of 1 pixel/tick. Robots decelerate at the rate of 2 pixels/tick. Robocode determines acceleration for you, based on the distance you are trying to move.

* Note that this is different than real, 'live' tanks, i.e. with motors, where you can set the speed, and acceleration is of course dependent on the horsepower count of the motor. This difference also gets the system control people a surprise. -- filmil
** How different is this, aside from the fact that we can assume constant acceleration / deceleration? -- Kawigi
* Acceleration and deceleration does happen with full numbers, except for the last one reaching 0 or the intended speed. That last tick just fills the remaining part. Spinbot for example accelerates from 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 5.5 and if it would decelerate, it would go 5.5 -> 3.5 -> 1.5 -> 0 -- GrubbmGait
* Deceleration can also be greater than 2, which occurs during collisions.
* Even if you decelerate past 0 your max speed difference is 2. This means that if your speed is -0.5 it is possible to have 1.5 in the next tick, and vice versa.

Velocity Equation(v) v = at. Absolute velocity can never exceed 8. Note that technically, velocity is a vector, but in Robocode we simply assume the direction of the vector to be the robot's heading.

Distance Equation (d) d = vt.

### Robot, Gun, and Radar rotation

*Max rate of rotation of robot (10 - .75 * abs(velocity)) degrees / tick. The faster you're moving, the slower you turn.
** (pi/18) - (pi/240) * abs(speed) radians/tick
*Max rate of rotation of gun 20 degrees / tick. This is added to the current rate of rotation of the robot.
** pi/9 radians/tick
*Max rate of rotation of radar 45 degrees / tick. This is added to the current rate of rotation of the gun.
** pi/4 radians/tick

### Bullets

*Damage = 4 * firepower. If firepower > 1, it does an additional 2 * (power - 1).
*Velocity 20 - 3 * firepower;
*GunHeat generated 1 + firepower / 5. You cannot fire if gunHeat > 0. All guns are hot at the start of each round.
** How hot do the guns start?
** 3.0 IIRC
*Power returned on hit 3 * firepower.

### Collisions

With Another Robot Each robot takes .6 damage. If a robot is moving away from the collision, it will not be stopped.

With a Wall AdvancedRobots? take Math.abs(velocity) * .5 - 1; (Never < 0)

### Robocode Processing Loop

The order that Robocode runs is as follows:

1. All robots execute their code until taking action
2. Time is updated (currentTime++)
3. All bullets move and check for collisions
4. All robots move (heading, accel, velocity, distance, in that order)
5. All robots perform scans (and collect team messages)
6. The battlefield draws

• Where do the events get processed? -- filmil
• When does firing occur?
• On the next tick. The difference between fire() and setFire() is that fire() also runs the next tick. However, it is fired from your current location.
• Just to check, this would be the order of events (each bullet is a different tick, events ordered through tick)
• Enemy Fires a power 3
• Bullet moves 11, I see change, I move, I call setFire 3
• Bullet moves to 22, I move, My bullet moves to 11 from my current position
• or is the bullet fired from the position I move to the tick I called setFire?
• Here's how I believe it works:
• Enemy Fires a power 3
• Bullet is still at the location the enemy was last turn, you see the change, move, call setFire(3)
• Bullet moves to 11, you move, your bullet is now fired at your old location.
• Enemy bullet has moved 22, your bullet moved 11.

### Time and distance measurements in Robocode

Time (t) Robocode time is measured in "ticks", which are equivalent to frames displayed on the screen. Each robot gets one turn per tick. 1 tick = 1 turn = 1 frame.

• How much in fact is the robot allowed to think? A "Tick" does not correspond to real time, but there exists a realtime limit on how long one can 'contemplate'. What is this limit, and does it depend upon the system the Robocode simulator is running on? -- filmil
• The Robocode environment tries to measure the performance of the system when it is started. This in order to make it not dependent on this. How much you are allowed to think I don't know really. It's seldom a problem anyway. You'll tire of the bot being a really SlowBot before reaching this limit I think... -- PEZ
• Ok, I just tested this, and if it takes more than 5 seconds in a tick Robocode determines not to calculate score for the bot, and after 10 seconds the bot is stopped and is no longer processed. When it comes to skipped turns however, I am a bit confused. A bot in an infinite loop will not recieve skipped turn events, but other robots in the battle will still execute (although at a slower framerate) this leads me to believe that robocode does not run battles strictly sequentially. It appears that ticks still continue while the bot loops (a getTime within the loop shows anywhere from 7 to 20 ticks a second on my comp)for the first 5 seconds, and then for another 5 seconds Robocode solely runs that robot (no ticks pass) until it is disabled. -- Jokester
• IIRC your robot is warped to the next tick. Your robot continues running where it was, as if it is still in the previous tick (besides getting new data from getX() etc). You only receive events when you move to the next tick normally. -- Jonathan

Distance Measurement Robocode's units are basically measured in pixels, with two exceptions. First, all distances are measured with double precision, so you can actually move a fraction of a pixel. Second, Robocode automatically scales down battles to fit on the screen. In this case, the unit of distance is actually smaller than a pixel.

• With all due respect, equating pixels with robocode units is simply an error. Robocode units (runits) do not correspond to pixels since display can be scaled. As it is now, the explanation says: the units are pixels, except sometimes when they are not. It does not seem to clarify too much. Thanks for your patience in reading this. :) -- filmil
• It doesn't really matter. It's like with time ticks. Just units. -- PEZ
• That's why I said the above: introducing pixels serves no purpose. But I guess if it has become a custom, let they be pixels... -- filmil
• It does serve a purpose, though. The distance will always be in pixels unless the user makes the window too small to display the battlefield, in which case Robocode will scale the whole battlefield down. But it certainly is pixels by default, and will never be any larger than pixels. -- Kawigi
• This is just like scaling down a large image to fit an average screen. It is still, say, 2048 pixels wide, even though it is 1024 on that screen. -- Jonathan

### Robot Movement Physics

Acceleration (a) Robots accelerate at the rate of 1 pixel/tick. Robots decelerate at the rate of 2 pixels/tick. Robocode determines acceleration for you, based on the distance you are trying to move.

• Note that this is different than real, 'live' tanks, i.e. with motors, where you can set the speed, and acceleration is of course dependent on the horsepower count of the motor. This difference also gets the system control people a surprise. -- filmil
• How different is this, aside from the fact that we can assume constant acceleration / deceleration? -- Kawigi
• Acceleration and deceleration does happen with full numbers, except for the last one reaching 0 or the intended speed. That last tick just fills the remaining part. Spinbot for example accelerates from 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 5.5 and if it would decelerate, it would go 5.5 -> 3.5 -> 1.5 -> 0 -- GrubbmGait
• Deceleration can also be greater than 2, which occurs during collisions.
• Even if you decelerate past 0 your max speed difference is 2. This means that if your speed is -0.5 it is possible to have 1.5 in the next tick, and vice versa.

Velocity Equation(v) v = at. Absolute velocity can never exceed 8. Note that technically, velocity is a vector, but in Robocode we simply assume the direction of the vector to be the robot's heading.

Distance Equation (d) d = vt.

### Robot, Gun, and Radar rotation

• Max rate of rotation of robot (10 - .75 * abs(velocity)) degrees / tick. The faster you're moving, the slower you turn.
• (pi/18) - (pi/240) * abs(speed) radians/tick
• Max rate of rotation of gun 20 degrees / tick. This is added to the current rate of rotation of the robot.
• pi/9 radians/tick
• Max rate of rotation of radar 45 degrees / tick. This is added to the current rate of rotation of the gun.
• pi/4 radians/tick

### Bullets

• Damage = 4 * firepower. If firepower > 1, it does an additional 2 * (power - 1).
• Velocity 20 - 3 * firepower;
• GunHeat generated 1 + firepower / 5. You cannot fire if gunHeat > 0. All guns are hot at the start of each round.
• How hot do the guns start?
• 3.0 IIRC
• Power returned on hit 3 * firepower.

### Collisions

With Another Robot Each robot takes .6 damage. If a robot is moving away from the collision, it will not be stopped.

With a Wall AdvancedRobots? take Math.abs(velocity) * .5 - 1; (Never < 0)

Robo Home | GamePhysics | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited May 5, 2006 3:33 EST by Voidious (diff)
Search: