Difference between revisions of "User talk:BenHorner"
(anatomy of a turn...?) |
|||
Line 1: | Line 1: | ||
− | + | == anatomy of a turn == | |
− | + | Here is what I currently have for the seuqence of processing during a turn, the reference I got it from is no longer a valid web page, it was the help link from: http://robocode.sourceforge.net/ which now redirects to this wiki. =) | |
− | |||
− | : | + | * each turn these things happen in order: |
+ | ** time is incremented | ||
+ | ** bullets move and check for collisions | ||
+ | ** robots move | ||
+ | *** adjust heading | ||
+ | *** adjust acceleration | ||
+ | *** adjust velocity | ||
+ | *** adjust position | ||
+ | ** scans are made | ||
+ | ** robots execute their code until their thread is blocked (through action, or time out) | ||
− | + | Does anyone have anything to add to the above? Or change? I always thought that all the events would fire at once, and you would receive them in order of the priorities you set... I assumed they all fired where it says "scans are made" above. Also, if it is unintuitive, at what point a robot's energy is charged for firing. Thanks for any help on this one. --[[User:BenHorner|BenHorner]] 21:19, 25 May 2009 (UTC) | |
− | |||
− | ::: | + | == discrepancy between HitRobotEvent and ScannedRobotEvent? == |
+ | |||
+ | I was wondering if anyone else has noticed a discrepancy between the enemy energy reported by the HitRobotEvent, and the ScannedRobot event...? I have my bot which currently doesn't move, going up against Crazy in 35 round battles to test my radar and bookkeeping code. It seems like about twice per (35 round) battle I get a discrepancy of exactly 0.1 energy points. I believe the HitRobotEvent happens first, and reports lets say 54.60 for the enemy energy, and in the same round a ScannedRobotEvent happens reporting 54.50 for the enemy energy. This is a small difference, but I'm wondering if I should be accounting for fuzziness (something like sensor noise) in my bookkeeping code, rather than planning for exactness. Does this kind of thing happen many places? --[[User:BenHorner|BenHorner]] 17:11, 25 May 2009 (UTC) | ||
+ | |||
+ | : I haven't checked anything like that, but I only trust the onScannedEvent energy value, maybe something happens after the robots hit. --[[User:Zyx|zyx]] 19:04, 25 May 2009 (UTC) | ||
+ | |||
+ | : I have a theory about this that I believe is very compelling... Consider the following: 1) bullets moving is processed before bullets are fired, 2) scanning is processed after bullets are fired. If the enemy fired a 0.1 power bullet on the same tick as being hit, then of course there would be a discrepancy, due to the bullet hitting them being processed first. --[[User:Rednaxela|Rednaxela]] 20:05, 25 May 2009 (UTC) | ||
+ | |||
+ | :: I'm not sure I follow your scenario, but it sounds like you're proposing that the sequence of processing might account for the discrepancy? It was my impression that all the events fire without any state changing... That the calculations of state changes for the robots are made in a separate block of time than the events firing, is that not true? The only way this discrepancy could be legit is if some state of the robot (specifically it's energy value) is changed in between onHitRobot() being called and onScannedRobot() being called. (Or if those events are not reporting the then current state of the robot) --[[User:BenHorner|BenHorner]] 20:41, 25 May 2009 (UTC) | ||
+ | |||
== min/max/avg battle length (in turns/ticks)? == | == min/max/avg battle length (in turns/ticks)? == | ||
Line 26: | Line 42: | ||
:: I really don't think 1v1 battles ever last 1300 ticks per round... I just fired up some Dookious vs Dookious and Dookious vs Ascendant battles, and the longest round I saw was mid-700s. I'm not sure surfers have anything to do with battle length. Things that would make a battle long are firing low power bullets and/or the battle being close (so the longest-living bot gains back as much energy as possible before dying). --[[User:Voidious|Voidious]] 15:54, 25 May 2009 (UTC) | :: I really don't think 1v1 battles ever last 1300 ticks per round... I just fired up some Dookious vs Dookious and Dookious vs Ascendant battles, and the longest round I saw was mid-700s. I'm not sure surfers have anything to do with battle length. Things that would make a battle long are firing low power bullets and/or the battle being close (so the longest-living bot gains back as much energy as possible before dying). --[[User:Voidious|Voidious]] 15:54, 25 May 2009 (UTC) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 22:19, 25 May 2009
anatomy of a turn
Here is what I currently have for the seuqence of processing during a turn, the reference I got it from is no longer a valid web page, it was the help link from: http://robocode.sourceforge.net/ which now redirects to this wiki. =)
- each turn these things happen in order:
- time is incremented
- bullets move and check for collisions
- robots move
- adjust heading
- adjust acceleration
- adjust velocity
- adjust position
- scans are made
- robots execute their code until their thread is blocked (through action, or time out)
Does anyone have anything to add to the above? Or change? I always thought that all the events would fire at once, and you would receive them in order of the priorities you set... I assumed they all fired where it says "scans are made" above. Also, if it is unintuitive, at what point a robot's energy is charged for firing. Thanks for any help on this one. --BenHorner 21:19, 25 May 2009 (UTC)
discrepancy between HitRobotEvent and ScannedRobotEvent?
I was wondering if anyone else has noticed a discrepancy between the enemy energy reported by the HitRobotEvent, and the ScannedRobot event...? I have my bot which currently doesn't move, going up against Crazy in 35 round battles to test my radar and bookkeeping code. It seems like about twice per (35 round) battle I get a discrepancy of exactly 0.1 energy points. I believe the HitRobotEvent happens first, and reports lets say 54.60 for the enemy energy, and in the same round a ScannedRobotEvent happens reporting 54.50 for the enemy energy. This is a small difference, but I'm wondering if I should be accounting for fuzziness (something like sensor noise) in my bookkeeping code, rather than planning for exactness. Does this kind of thing happen many places? --BenHorner 17:11, 25 May 2009 (UTC)
- I haven't checked anything like that, but I only trust the onScannedEvent energy value, maybe something happens after the robots hit. --zyx 19:04, 25 May 2009 (UTC)
- I have a theory about this that I believe is very compelling... Consider the following: 1) bullets moving is processed before bullets are fired, 2) scanning is processed after bullets are fired. If the enemy fired a 0.1 power bullet on the same tick as being hit, then of course there would be a discrepancy, due to the bullet hitting them being processed first. --Rednaxela 20:05, 25 May 2009 (UTC)
- I'm not sure I follow your scenario, but it sounds like you're proposing that the sequence of processing might account for the discrepancy? It was my impression that all the events fire without any state changing... That the calculations of state changes for the robots are made in a separate block of time than the events firing, is that not true? The only way this discrepancy could be legit is if some state of the robot (specifically it's energy value) is changed in between onHitRobot() being called and onScannedRobot() being called. (Or if those events are not reporting the then current state of the robot) --BenHorner 20:41, 25 May 2009 (UTC)
min/max/avg battle length (in turns/ticks)?
Can anyone give me a feel for how long battles average? I want to use an array list to keep track of the ticks as they go by, for the random access, but I'd rather not make it reallocate itself unnecessarily often, especially when it's big. Thanks for any help. --BenHorner 23:48, 24 May 2009 (UTC)
Obviously it varies, but for 1v1, I usually ballpark it as 700-800 ticks per round. I think 25k in a 35 round battle is a good estimate. --Voidious 00:01, 25 May 2009 (UTC)
But for wave surfer battle, is usually over 1,000. I think it's around (for surfer) 1,300 - 1,500 ticks. » Nat | Talk » 11:53, 25 May 2009 (UTC)
So surfers get hit by bullets way less often? I'm really going to have to look into that sooner or later. --BenHorner 14:24, 25 May 2009 (UTC)
- Sorry, to make more clear, a battle with two wave surfers are over 1,000 ticks since the well-implements surfers usually almost dodge every enemy bullets, I have to said well-implements since some surfer, like BlackHole 0.1.11 cannot dodge even HOT (really, I had broke something in it and I don't wanna fix it). And even perfect AS gun can't make over 50% hit rate now. » Nat | Talk » 14:47, 25 May 2009 (UTC)
- Well, not just because of that. Also because most wave surfers favour huge distances compared to most other bots. About 400 is a typical wave surfer distance for instance, whereas many smaller bots prefer 200 to 300 distance from what I see. --Rednaxela 15:47, 25 May 2009 (UTC)
- I really don't think 1v1 battles ever last 1300 ticks per round... I just fired up some Dookious vs Dookious and Dookious vs Ascendant battles, and the longest round I saw was mid-700s. I'm not sure surfers have anything to do with battle length. Things that would make a battle long are firing low power bullets and/or the battle being close (so the longest-living bot gains back as much energy as possible before dying). --Voidious 15:54, 25 May 2009 (UTC)