http://robowiki.net/w/api.php?action=feedcontributions&user=Jab&feedformat=atomRobowiki - User contributions [en]2021-04-15T07:07:09ZUser contributionsMediaWiki 1.34.1http://robowiki.net/w/index.php?title=Enjambre/Evolution_History&diff=35874Enjambre/Evolution History2016-04-27T11:48:15Z<p>Jab: </p>
<hr />
<div>= Enjambre 3 =<br />
'''Released:''' 25 April 2016<br />
* Queen radar fix<br />
* Bees attack to close enemies in the way to their assigned enemy<br />
<br />
= Enjambre 2 =<br />
'''Released:''' 18 September 2009<br />
<br />
'''TeamRumble Ratings Date:''' 18 September 2009<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! APS<br />
! ELO<br />
! Battles<br />
|-<br />
| 26<br />
| 1448.9<br />
| 37.21<br />
| 34<br />
|}<br />
<br />
* Radar<br />
* General Module structure bugfixes<br />
* BlindFighting<br />
<br />
<br />
= Enjambre Beta (0.0.1) =<br />
'''Released:''' 28 January 2008<br />
<br />
'''TeamRumble Ratings Date:''' 18 September 2009<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! APS<br />
! ELO<br />
! Battles<br />
|-<br />
| 31<br />
| 1351.0<br />
| 30.89<br />
| 35<br />
|}<br />
<br />
* Sharing info<br />
* Anti-Gravity movements for the Queen and the Bees<br />
* Assignation algorithm based on minimum global distance<br />
<br />
[[Category:Bot Version Histories]]</div>Jabhttp://robowiki.net/w/index.php?title=RoboRumble/Participants/Teams&diff=35873RoboRumble/Participants/Teams2016-04-25T14:54:03Z<p>Jab: </p>
<hr />
<div>{{:RoboRumble/Navigation}}<br />
<br />
----<br />
Just add your team name ('''as appears in the Robocode selector after packaging, without 'Team:'''', so including version number) and the RobocodeRepository id number separated by "," (there must be no space after the comma).<br />
<br />
The list is in '''alphabetical''' order. Add your bot in the right slot.<br />
<br />
For your bot to be accepted by the RR@Home server, the following rules are mandatory:<br />
<br />
* The bot must have a package-name.<br />
* The bot must be packaged in a jar-file.<br />
* A <botname>.properties file must be present in the jar-file.<br />
* The naming of the bot must reflect the internal structure,see [http://home.versatel.nl/gheijenk/plaatjes/bot_naming.png]for sample.RamFire.<br />
<br />
The easiest way to do this is to package your bot with Robocode (Robot -> Package robot for upload).<br />
<br />
'''PLEASE MAKE SURE YOUR BOT IS NOT ALREADY ON THE LIST BEFORE YOU ADD IT.<br>IF YOU ARE ADDING A NEW VERSION OF YOUR BOT, PLEASE DELETE THE OLD ONE.'''<br />
<br />
----<br />
<pre><br />
abc.ShadowTeam 3.83,http://robocode.aclsi.pt/abc.ShadowTeam_3.83.jar<br />
ags.polylunar.Polylunar 1.6,http://robocode-archive.strangeautomata.com/robots/ags.polylunar.Polylunar_1.6.jar<br />
amz.TeamDeathTeam 1,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/amz.TeamDeathTeam_1.jar<br />
apvteam.MambaTeam 0.7.5,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/apvteam.MambaTeam_0.7.5.jar<br />
bugger.BuggerHive 1.0,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/bugger.BuggerHive_1.0.jar<br />
bvh.team.Valkiries 1.0,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/bvh.team.Valkiries_1.0.jar<br />
CharlieN.OmegaTeam.OmegaTeam 1.0,http://robocode-archive.strangeautomata.com/robots/CharlieN.OmegaTeam.OmegaTeam_1.0.jar<br />
cx.mini.DemoniacNimrods 0.50,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/cx.mini.DemoniacNimrods_0.50.jar<br />
davidalves.PhoenixTeam 0.54,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/davidalves.PhoenixTeam_0.54.jar<br />
dummy_team.BlindFighters 1.01,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/dummy_team.BlindFighters_1.01.jar<br />
ethdsy.MalackaTeam 1.2,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/ethdsy.MalackaTeam_1.2.jar<br />
florent.XSeries.Xmen 0.9,http://wesley3.free.fr/florent.XSeries.Xmen_0.9.jar<br />
gh.mini.GrubbmGroup 0.4,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/gh.mini.GrubbmGroup_0.4.jar<br />
gh.nano.GrofGroup 1.1,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/gh.nano.GrofGroup_1.1.jar<br />
gimp.GimpTeam 0.1,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/gimp.GimpTeam_0.1.jar<br />
jab.DiamondStealers 5,http://robocode-archive.strangeautomata.com/robots/jab.DiamondStealers_5.jar<br />
jab.Enjambre 3,https://github.com/jabiercoding/robocodeBots/raw/master/Enjambre/releases/jab.Enjambre_3.jar<br />
jeremyreeder.collective.FourProphetsAndADiscliple 5,http://thesafehouse.info/robocode/jeremyreeder.collective.FourProphetsAndADiscliple_5.jar<br />
kawigi.micro.ArmyOfShiz 1.1,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/kawigi.micro.ArmyOfShiz_1.1.jar<br />
kawigi.sbf.TidalWave 0.8,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/kawigi.sbf.TidalWave_0.8.jar<br />
kid.team.OmegaSquad .0.2,http://robocode-archive.strangeautomata.com/robots/kid.team.OmegaSquad_.0.2.jar<br />
Krabb.sliNk.SlartibartfassTeam 0.5,http://robocode-archive.strangeautomata.com/robots/Krabb.sliNk.SlartibartfassTeam_0.5.jar<br />
logiblocs.SittingDroidTeam 1.0,http://dl.dropbox.com/u/66369360/logiblocs.SittingDroidTeam_1.0.jar<br />
lxx.ConceptATeam 0.8,https://github.com/aleksey-zhidkov/ConceptA/raw/master/builds/lxx.ConceptATeam_0.8.jar<br />
mn.CombatTeam 3.23.1,http://dl.dropboxusercontent.com/s/qblhhwtes8mz3df/mn.CombatTeam_3.23.1.jar<br />
mn.nano.perceptual.ImpactTeam 1.3.0,http://dl.dropbox.com/s/1dft93slwo2llfl/mn.nano.perceptual.ImpactTeam_1.3.0.jar?dl=1<br />
mn.SuperSittingDuckTeam 1.0.2,http://dl.dropbox.com/s/4r3pwnua9el2z7k/mn.SuperSittingDuckTeam_1.0.2.jar?dl=1<br />
ms.AresHaikuTeam 0.3,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/ms.AresHaikuTeam_0.3.jar<br />
mskwik.BumblingIdiots 1.0,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/mskwik.BumblingIdiots_1.0.jar<br />
myl.micro.TroodonPack 1.10,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/myl.micro.TroodonPack_1.10.jar<br />
ntc.slippery.Slippery 1.0,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/ntc.slippery.Slippery_1.0.jar<br />
pedersen.ImWithDroidTeam 1.3,http://robocode-archive.strangeautomata.com/robots/pedersen.ImWithDroidTeam_1.3.jar<br />
pedersen.ImWithStupidTeam 1.3,http://robocode-archive.strangeautomata.com/robots/pedersen.ImWithStupidTeam_1.3.jar<br />
Polkwane.PTeam 1.0,https://dl.dropbox.com/s/wj0cqq7tpw4icft/Polkwane.PTeam_1.0.jar?token_hash=AAFDXqYv35LQmljQlq-I0Mwq7OrbvQ4-i-SVP_WRjBqRFQ&dl=1<br />
radnor.RadnorMedSchool 1.0,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/radnor.RadnorMedSchool_1.0.jar<br />
rz.AlephTeam 0.34,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/rz.AlephTeam_0.34.jar<br />
rz.GlowingHawks 0.2,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/rz.GlowingHawks_0.2.jar<br />
rz.HOFSwarm 1.1,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/rz.HOFSwarm_1.1.jar<br />
sampleteam.MyFirstTeam 1.0,http://robocode-archive.strangeautomata.com/robots/sampleteam.MyFirstTeam_1.0.jar<br />
sgp.DrunkenTeam 1.12,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/sgp.DrunkenTeam_1.12.jar<br />
sp.Minis.GeneBotUpgrade 1.1,https://sites.google.com/site/myrobocodedownloads/home/Geneticbot/sp.Minis.GeneBotUpgrade_1.1.jar?attredirects=0&d=1<br />
tmnr.TMNR 1.01,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/tmnr.TMNR_1.01.jar<br />
ustimaw.NightmareTeam 3.3,https://dl.dropbox.com/s/09x9h12npfreowf/ustimaw.NightmareTeam_3.3.jar<br />
vuen.Bakery 2.51,https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/vuen.Bakery_2.51.jar<br />
</pre><br />
----<br />
'''''No chatting on this page. Use the /ParticipantsChat page for that.'''''<br />
<br />
'''Removed due to broken Jar file:'''<br />
* tripphippy.wonderlandTeam 0.1,http://robocoderepository.com/BotFiles/3724/tripphippy.WonderlandTeam_0.1.jar<br />
<br />
----<br />
<br />
Removed due to WontFix issues in Robocode 1.7+:<br />
* GarmTeam: ([[http://sourceforge.net/tracker/?func=detail&aid=2845626&group_id=37202&atid=419486 SF #2845626]])<br />
: Krabb.sliNk.GarmTeam 0.9v,http://designnj.de/roboking/Krabb.sliNk.GarmTeam_0.9v.jar<br />
* DeltaSquad: ([[http://sourceforge.net/tracker/?func=detail&aid=2976258&group_id=37202&atid=419486 SF #297658]])<br />
: kid.DeltaSquad.DeltaSquad .1,http://www.citlink.net/~normanp/robocode/team/kid.DeltaSquad.DeltaSquad_.1.jar<br />
<br />
Removed due to crashing the client:<br />
kid.DeltaSquad.DeltaSquad .1,https://sites.google.com/site/robocodekid/deltasquadfiles/kid.DeltaSquad.DeltaSquad_.1.jar</div>Jabhttp://robowiki.net/w/index.php?title=User:Jab&diff=34010User:Jab2015-01-13T12:32:54Z<p>Jab: /* My Bots */</p>
<hr />
<div>== About Me ==<br />
<br />
e-mail: jabimail gmail com<br />
<br />
== My Bots ==<br />
* [[Sanguijuela]] Very competitive MicroRamBot<br />
* [[Enjambre]] Team: Just one queen and four blind ramming bees<br />
* [[DiamondStealer]] Versatile bot, 1vs1, melee and team.<br />
* [[ManuelGallegus]] 1vs1. Top-100 on 9th July 2008<br />
<br />
== Other stuff ==<br />
* [[Module]] bot structure<br />
<br />
[[Category:Bot Authors|Jab]]</div>Jabhttp://robowiki.net/w/index.php?title=User:Jab&diff=34009User:Jab2015-01-13T12:27:05Z<p>Jab: /* My Bots */</p>
<hr />
<div>== About Me ==<br />
<br />
e-mail: jabimail gmail com<br />
<br />
== My Bots ==<br />
* [[Sanguijuela]] MicroRamBot<br />
* [[Enjambre]] Team: One queen and four blind ramming bees<br />
* [[DiamondStealer]] 1vs1, melee and team<br />
* [[ManuelGallegus]] 1vs1<br />
<br />
== Other stuff ==<br />
* [[Module]] bot structure<br />
<br />
[[Category:Bot Authors|Jab]]</div>Jabhttp://robowiki.net/w/index.php?title=User:Jab&diff=34008User:Jab2015-01-13T12:25:17Z<p>Jab: /* My Bots */</p>
<hr />
<div>== About Me ==<br />
<br />
e-mail: jabimail gmail com<br />
<br />
== My Bots ==<br />
* [[Sanguijuela]]<br />
* [[Enjambre]]<br />
<br />
== Other stuff ==<br />
* [[Module]] bot structure<br />
<br />
[[Category:Bot Authors|Jab]]</div>Jabhttp://robowiki.net/w/index.php?title=Enjambre/Evolution_History&diff=12161Enjambre/Evolution History2009-09-17T21:37:22Z<p>Jab: jab.Enjambre 2. The swarm</p>
<hr />
<div>= Enjambre 2 =<br />
[http://www.freewebs.com/robocode/bots/Enjambre/jab.Enjambre_2.jar Download]<br />
<br />
'''Released:''' 18 September 2009<br />
<br />
'''TeamRumble Ratings Date:''' 18 September 2009<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! APS<br />
! ELO<br />
! Battles<br />
|-<br />
| 26<br />
| 1448.9<br />
| 37.21<br />
| 34<br />
|}<br />
<br />
* Radar<br />
* General Module structure bugfixes<br />
* BlindFighting<br />
<br />
<br />
= Enjambre Beta (0.0.1) =<br />
[http://www.freewebs.com/robocode/bots/Enjambre/jabteam.Enjambre_0.0.1.jar Download]<br />
<br />
'''Released:''' 28 January 2008<br />
<br />
'''TeamRumble Ratings Date:''' 18 September 2009<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! APS<br />
! ELO<br />
! Battles<br />
|-<br />
| 31<br />
| 1351.0<br />
| 30.89<br />
| 35<br />
|}<br />
<br />
* Sharing info<br />
* Anti-Gravity movements for the Queen and the Bees<br />
* Assignation algorithm based on minimum global distance<br />
<br />
[[Category:Bot Version Histories]]</div>Jabhttp://robowiki.net/w/index.php?title=Enjambre&diff=12160Enjambre2009-09-17T21:22:19Z<p>Jab: jab.Enjambre 2. The swarm</p>
<hr />
<div>; <nowiki>Sub-pages: </nowiki><br />
: '''[[/Evolution History]]'''<br />
<br />
{{Infobox Robot<br />
| bgcolour = #FFFFFE<br />
| image = Enjambre.jpg<br />
| caption = The Swarm<br />
| author = jab<br />
| extends = TeamRobot<br />
}}<br />
<br />
== Background Info ==<br />
; What's special about it?<br />
The Swarm consists on one Queen and four blind Bees.<br />
<br />
The Queen's role<br />
* Attack the other leader, but not aggresively because her life is important for the survival of the swarm.<br />
* Tell the bees the positions of the enemies and the other bees.<br />
* Assignate a bee for each enemy that is not the leader. This continuous assignation is based on the ''minimum global distance'' among bees and enemies.<br />
<br />
A Bee's role<br />
* Receive information and assignation from the Queen.<br />
* Ram the enemy.<br />
* Bite when close.<br />
* If there is no assignation (there are more bees than enemies), the bee will atack the enemies' leader or the closest enemy if the enemies' leader died.<br />
* If Queen dies, the Bees will start to fight as blind fighters.<br />
<br />
<br />
<br />
<br />
<br />
; How competitive is it?<br />
Not too much.<br />
<br />
== Additional Info ==<br />
; Where did you get the name?<br />
Enjambre means Swarm.<br />
<br />
[[Category:Bots|Enjambre]]<br />
[[Category:Teams|Enjambre]]</div>Jabhttp://robowiki.net/w/index.php?title=RoboRumble/Participants/Teams&diff=12149RoboRumble/Participants/Teams2009-09-17T06:49:58Z<p>Jab: jab.Enjambre 2. The swarm</p>
<hr />
<div>{{:RoboRumble/Navigation}}<br />
<br />
----<br />
Just add your team name ('''as appears in the Robocode selector after packaging, without 'Team:'''', so including version number) and the RobocodeRepository id number separated by "," (there must be no space after the comma). Please, make sure your bot is not in the list before adding it, and delete the old version if you are adding a new one.<br />
<br />
The list is in '''alphabetical''' order. Add your bot in the right slot.<br />
----<br />
<pre><br />
abc.ShadowTeam 3.83,http://robocode.aclsi.pt/abc.ShadowTeam_3.83.jar<br />
ags.polylunar.Polylunar 1.6,http://homepages.ucalgary.ca/~agschult/ags.polylunar.Polylunar_1.6.jar<br />
amz.TeamDeathTeam 1,2062<br />
apvteam.MambaTeam 0.7.5,1121<br />
bugger.BuggerHive 1.0,2831<br />
bvh.team.Valkiries 1.0,2775<br />
CharlieN.OmegaTeam.OmegaTeam 1.0,http://darkcanuck.net/rumble/robots/CharlieN.OmegaTeam.OmegaTeam_1.0.jar<br />
cx.mini.DemoniacNimrods 0.50,1277<br />
davidalves.PhoenixTeam 0.54, http://davidalves.net/robocode/robots/davidalves.Phoenix_0.54.jar<br />
dummy_team.BlindFighters 1.01,552<br />
ethdsy.MalackaTeam 1.2,1160<br />
florent.XSeries.Xmen 0.9,http://wesley3.free.fr/florent.XSeries.Xmen_0.9.jar<br />
gh.mini.GrubbmGroup 0.4,2483<br />
gh.nano.GrofGroup 1.1,2580<br />
gimp.GimpTeam 0.1,2435<br />
jab.DiamondStealers 5,http://www.freewebs.com/robocode/bots/DiamondStealers/jab.DiamondStealers_5.jar<br />
jab.Enjambre 2,http://www.freewebs.com/robocode/bots/Enjambre/jab.Enjambre_2.jar<br />
kawigi.micro.ArmyOfShiz 1.1,2522<br />
kawigi.sbf.TidalWave 0.8,1582<br />
kid.DeltaSquad.DeltaSquad .1,http://www.citlink.net/~normanp/robocode/team/kid.DeltaSquad.DeltaSquad_.1.jar<br />
kid.team.OmegaSquad .0.2,http://www.citlink.net/~normanp/robocode/team/kid.team.OmegaSquad_.0.2.jar<br />
Krabb.sliNk.GarmTeam 0.9v,http://designnj.de/roboking/Krabb.sliNk.GarmTeam_0.9v.jar<br />
Krabb.sliNk.SlartibartfassTeam 0.5,http://darkcanuck.net/rumble/robots/Krabb.sliNk.SlartibartfassTeam_0.5.jar<br />
mn.CombatTeam 1.0,2352<br />
ms.AresHaikuTeam 0.3,1750<br />
mskwik.BumblingIdiots 1.0,2704<br />
myl.micro.TroodonPack 1.10,1227<br />
ntc.slippery.Slippery 1.0,3271<br />
pedersen.ImWithDroidTeam 1.3,http://darkcanuck.net/rumble/robots/pedersen.ImWithDroidTeam_1.3.jar<br />
pedersen.ImWithStupidTeam 1.3,http://darkcanuck.net/rumble/robots/pedersen.ImWithStupidTeam_1.3.jar<br />
radnor.RadnorMedSchool 1.0,2149<br />
rz.AlephTeam 0.34,2013<br />
rz.GlowingHawks 0.2,1689<br />
rz.HOFSwarm 1.1,2494<br />
sgp.DrunkenTeam 1.12,284<br />
tripphippy.wonderlandTeam 0.1,http://robocoderepository.com/BotFiles/3724/tripphippy.WonderlandTeam_0.1.jar<br />
vuen.Bakery 2.51,453<br />
</pre><br />
----<br />
'''''No chatting on this page. Use the /ParticipantsChat page for that.'''''</div>Jabhttp://robowiki.net/w/index.php?title=User_talk:Voidious/Robocode_Version_Tests&diff=11929User talk:Voidious/Robocode Version Tests2009-09-11T13:27:53Z<p>Jab: Voting</p>
<hr />
<div>I don't think there are any differences between 1.6.1.4 and 1.7.1.1. The difference is quite big, 0.82%! But I think we are still using the fix, right? &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 15:51, 17 July 2009 (UTC)<br />
<br />
Yes, it's a pretty big difference (0.72% actually). 250 battles might not be enough, though, maybe I should run more for that pairing. If there is a 0.72% difference, I'd probably be against the change. But there's lots more to test first - I see my 1.6.1.4 CPU constant is ~20% higher than the 1.7* versions, that could even play a part. --[[User:Voidious|Voidious]] 20:36, 17 July 2009 (UTC)<br />
<br />
The Surfer-vs-Surfer battle seems to affect much more than Surfer-vs-Random battles. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 05:08, 18 July 2009 (UTC)<br />
<br />
: Not necessarially Nat. These results could just mean that Komarious and Ascendant are affected differently than Diamond and DrussGT. Komarious/Ascendant vs the random movers would be needed to tell that. Really this test would be more revealing if there was a full round-robin between involved bots. I'd also wonder: Do Komarious or Ascendant actually assume anything that's breaks in Alpha2? It's also worth noting that tests of score alone can't tell us if changes better match assumptions a bot is making, since a bot could just by fluke happen to operate in a way that is happy with conditions that the code didn't try to assume at all. --[[User:Rednaxela|Rednaxela]] 05:26, 18 July 2009 (UTC)<br />
<br />
: There's also just a much larger variance in those pairings, so maybe 500 battles isn't even enough. My initial goal was just to find out ''if'' there was a measurable difference among these versions, so I was going for diversity in the battles I used. Full round robin between all bots (in all versions) might help in deducing causes, but this testing is already taking a "metric ass-ton" of CPU cycles =), so I'd definitely reduce the # of bots if I were to try that. It would still be pretty speculative, though.<br />
: Assuming that we have enough battles, the Diamond vs Komarious result I believe shows there are other differences between 1.6.1.4 and 1.7.x that are contributing. I noticed the CPU constant is a little different, but I'm pretty sure nobody's skipping turns anyway. The Alpha2 updateMovement code shouldn't change anything for these two bots, I don't think.<br />
: The PrairieWolf result is bizarre. 2% is well above any margin of error on 500 battles, I think. I thought PrairieWolf would have decreased performance, if anything, when we changed the +1/-1 decel rules, but he does better in Alpha3.<br />
: --[[User:Voidious|Voidious]] 05:48, 18 July 2009 (UTC)<br />
<br />
:: ATWHEB (Assuming that we have enough battles), it seems that the surfer gains score from this changes, which seem weird... Since most surfers use old way, including the old decel-through-zero rules. I wonder what DrussGT vs. Diamond score will look like.<br />
:: I think PrairieWolf vibrate a bit shorter so DuelistMini missed him. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:07, 18 July 2009 (UTC)<br />
<br />
:: You might have to test DuelistMini against another opponent -- maybe it's the one that's doing worse, as opposed to PrairieWolf doing better? Thanks for running all these tests, btw. Hopefully they'll help pick the right version and not just confuse things further! =) --[[User:Darkcanuck|Darkcanuck]] 06:25, 18 July 2009 (UTC)<br />
<br />
:: No problem, though I will be taking some time to work on [[Diamond]] this weekend. =) Yeah, I don't think we can draw many conclusions just yet. I also just realized that ''both'' PW and DM do data saving... I'm actually not sure if that might throw off results or not (hopefully it does?), but maybe I'll try to find another vibrating test bot. I'm gonna run some stuff in 1.7.1.1 overnight here. --[[User:Voidious|Voidious]] 06:36, 18 July 2009 (UTC)<br />
<br />
Just want to know, where do you guys consider as 'unacceptable' (the red value)? Currently I use ±0.1 as 'margin of error' (green value), ±0.4 as 'acceptable' (black value), beyond that is all 'unacceptable'. I don't normally run a lot of battles so I don't know where it should be. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 07:30, 18 July 2009 (UTC)<br />
<br />
: Margin of error = ±0.1 when comparing results from 500 battles is probably about right, maybe even ±0.2. (That would mean margin of error on each 500-battle result is half that.) I'm unsure of my opinion on "acceptable". My first instinct is "any measurable change is unacceptable", but I need to think about it. I just really, really hate the idea of all our old Robocode bots slowly becoming (artificially) weaker and weaker, just because of changes to Robocode... --[[User:Voidious|Voidious]] 16:37, 18 July 2009 (UTC)<br />
<br />
: I too dislike the idea of changes progressively making old bots weaker and weaker, but I really don't think that these changes are something that makes old bots progressively weaker. I have a feeling that most of the score changes that could be seen would not be due to slightly breaking old assumptions, but instead are just flukes arising from things just plain being a little different. The tests show DrussGT vs Ascendant having stronger DrussGT scores than before, but I doubt that Ascendant assumes old behavior in a way that DrussGT doesn't. At very least, I think the number of bots that are not acting quite as intended due to old Robocode movement being unintuitive/weird, is greater than the number of bots that truly intentionally assume old behavior that differs from the Alpha2 mode of operation (Alpha3 being a slightly different story). --[[User:Rednaxela|Rednaxela]] 22:35, 18 July 2009 (UTC)<br />
<br />
:: I mostly agree, which is the reason I might be OK with some measurable score differences. However, I think that if there continue to be changes that have measurable impacts on scoring, older bots will gradually get weaker (or should I say, "weakerer", since they're bound to get relatively "weaker", anyway). Even if the code doesn't assume anything explicitly, it may implicitly -- it was tuned in a certain Robocode environment that is no longer reflective of how Robocode works. --[[User:Voidious|Voidious]] 22:59, 18 July 2009 (UTC)<br />
<br />
Let me throw in my 2 cents to the discussion. Although I am a rather conservative guy, I also like clear and simple behaviour. Therefor my vote undoubtly goes for the Alpha-2 variant. Differences in score between the old code and Alpha-2 I take for granted as the old code just seems flawed.<br>I think that the Alpha-3 is one step too far, as the vibrating movement was rather popular in the days before Wavesurfing, and is used in several bots from that time. As for solving 'bugs' in the old code, there have been more changes that did influence the score, and we accepted them because they were logical and better following the rules than before. Think about onBulletHitBullet, which happens 50% more often now than in 1.0.6, favouring the bots that take them into account. --[[User:GrubbmGait|GrubbmGait]] 00:08, 19 July 2009 (UTC)<br />
<br />
I took the weekend to work on Diamond, but I'm back to running lots more tests: [[DrussGT]] vs [[Diamond]], [[Raiko]] vs [[Toorkild]], Raiko vs [[Moebius]], and Toorkild vs Moebius. 1.7.1.4-Alpha3 should be done before I get home today, then I'll run Alpha2. --[[User:Voidious|Voidious]] 15:13, 21 July 2009 (UTC)<br />
<br />
I thought my original RoboResearch install dir used 1.7.1.1, but it was actually 1.5.4, so I've removed those scores for now. Doh! The rest are definitely right. :-P --[[User:Voidious|Voidious]] 22:13, 21 July 2009 (UTC)<br />
<br />
Hmm... Raiko vs Moebius has interesting score... So Raiko moving at integer velocity make the nano pm match better? &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 13:11, 22 July 2009 (UTC)<br />
<br />
I am back from vacation. It seems like most of you like Alpha 2 more than Alpha 3, and I bet that most people would want the old behaviour, even though it's buggy and hard to understand - at least harder than the new version. I don't intend to make more changes to Robocode for the movement ever after this change. So, is Alpha 2 the version we go for?<br />
Also notice, that bugs fixed in Robocode 1.7.1.x might have an impact on the scores (e.g. 'Bug [2793464]', 'Bug [2740708] - Fair Play!', and 'broken AdvancedRobot.setMaxTurnRate() that did not work since 1.5.4') --[[User:FlemmingLarsen|Fnl]] 12:15, 25 July 2009 (UTC)<br />
<br />
I personally don't have much preference between Alpha 2 and Alpha 3, but think that Alpha 2, with a limit to prevent acceleration from -0.1 to 1.9, would be preferable, so that it wouldn't be strangely advantageous for a bot to avoid hitting 0 speed ever. Even though some bots are known to have movement optimized for the case when you can accelerate from -1.0 to +1.0, I'm doubtful there are currently any that do things like hit -0.0001 speed instead of 0, in order to accelerate to 1.9999 --[[User:Rednaxela|Rednaxela]] 15:03, 25 July 2009 (UTC)<br />
<br />
: That's the only difference between Alpha2 and Alpha3. Alpha2 still allows decel-thru-zero (e.g. going from -0.1 to 1.9) whereas Alpha3 switches from decel to accel once zero is reached. --[[User:Darkcanuck|Darkcanuck]] 18:34, 25 July 2009 (UTC) <br />
<br />
I myself prefer the Alpha3 more since it is Mat himself suggest this, but I'm newer than everybody else here except Positive. And because the Alpha2 would bring a strange behavior that allow robot able to accl from -0.000000000000000001 to 1.999999999999999999, which is not fair. Rednaxela, I don't think there are any robots do that, but it may have impact on score. If we do that, we must have Alpha4 with that to make Voidious happy ;) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 15:23, 25 July 2009 (UTC)<br />
<br />
: Well, I was thiknking that an Alpha4 might not be a bad idea :P --[[User:Rednaxela|Rednaxela]] 15:28, 25 July 2009 (UTC)<br />
<br />
I'm still firmly in the Alpha3 camp. As Voidious pointed out, there's no reason to introduce a change in behaviour that only fixes things halfway. Either the decel-thru zero quirk gets fixed (Alpha3) or the old behaviour should stay (Alpha2). In either case, all bots benefit from an improved Robocode movement algorithm. --[[User:Darkcanuck|Darkcanuck]] 18:34, 25 July 2009 (UTC)<br />
<br />
We should have poll somewhere... &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 18:50, 25 July 2009 (UTC)<br />
<br />
I'm torn at this point. In general, I'm against changing Robocode rules more than we need to, and I don't see the -0.1 to 1.9 quirk as that big a deal. (We've known about it for a long time, but who even cares to do it? It's very little gain for really uglying up your movement code.) I also greatly respect GrubbmGait's opinion, and while I don't speak for them, I believe ABC and David Alves are usually against changing Robocode physics rules, too.<br />
<br />
On the other hand, the Alpha3 solution is very elegant; there are noticeable score differences, but nothing major or seeming to favor specific bots; and the "vibrating" movement is still possible, just between ±0.7 instead of ±1.0. I also respect all of your opinions =), and Darkcanuck has seemed very conservative about Robocode versions in the rumble, and he says Alpha3... Sorry for such a long post to basically say "I don't know", but just felt I should post my thoughts.<br />
<br />
--[[User:Voidious|Voidious]] 20:17, 25 July 2009 (UTC)<br />
<br />
We could do an Alpha 4 - no problem. It might turn out to be better. Could you do a Hijack 3 with the code needed? Then I will make a new Alpha 4 for it, and everybody will be able to see the code for it. :-) --[[User:FlemmingLarsen|Fnl]] 20:59, 25 July 2009 (UTC)<br />
<br />
I believe the needed getNewVelocity() is already done here: [[Positive/Optimal Velocity]]. I haven't tested it, but it looks right to me. --[[User:Rednaxela|Rednaxela]] 21:48, 25 July 2009 (UTC)<br />
<br />
The version [[User talk:Positive/Optimal Velocity|on the bottom of this page]] is the most recent. <br />
<br />
If you're interested in my opinion, I think keeping alpha-2 is probably the cleanest solution as well. It provides most backward and forward compability. If you want to design very precise robots now, you will need to do so for 1.6.1.4 anyway, so it's nice if you know you won't eventually have to adjust again. <br />
<br />
The only reason to change it, would be to make it easier on the life of future perfectionist coders. You won't bother them with having to code special -0.1 > 1.9 codes to use the full available potential. Alpha-3 would solve that mathematically elegant, but would force them to deal with fractional velocities instead. Alpha-4 solves it a little less elegant, but I believe it solves the problem just as "correct" (going from -2>-1>1 isn't really better than -2>0>1, because it gives different displacement and turn rates), but with more backward compatibility and no fractional velocities. So I think that would be best. :) --[[User:Positive|Positive]] 23:13, 25 July 2009 (UTC)<br />
<br />
Okay, I have now assembled the [http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-4-setup.jar Alpha 4 for download] based on the version [[User talk:Positive/Optimal Velocity|on the bottom of this page]]. Perhaps we should run the tests for this version also, so we can compare it against the results for the Alpha 2 and 3? --[[User:FlemmingLarsen|Fnl]] 21:47, 26 July 2009 (UTC)<br />
<br />
I'll kick off some tests today, starting with the most varied ones among the current results. I think it will take a couple of days to run through them all (assuming I can resist tweaking Diamond for that long =)). --[[User:Voidious|Voidious]] 18:47, 27 July 2009 (UTC)<br />
<br />
I've not yet seen any strange behaviour resulting from the changes in Alpha-4 so far, having run and watched about 100 rounds of 10-round batles. So I'd say it's implemented correctly. I don't know if it differs on score, though. --[[User:Positive|Positive]] 16:01, 28 July 2009 (UTC)<br />
<br />
Hmm, the way that the new version are always getting notably higher in "Raiko vs Moebius", seems to say to me that either '''1)''' something else that happened in 1.7.x is affecting either Raiko or Moebius, or '''2)''' the 1.6 battle just happened to be lucky for Moebius and more seasons are needed. --[[User:Rednaxela|Rednaxela]] 14:36, 29 July 2009 (UTC)<br />
<br />
: Sure, I will run some more battles, but I do suspect it's something else in 1.7.x causing the big difference compared to 1.6.1.4. --[[User:Voidious|Voidious]] 15:43, 29 July 2009 (UTC)<br />
<br />
: Not sure if this effect? http://sourceforge.net/tracker/?func=detail&aid=2828479&group_id=37202&atid=419486 &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 10:40, 30 July 2009 (UTC)<br />
<br />
: Nat, I don't think so. I've only seen it happen in melee fights. And I don't believe many 1v1 bots check the onRobotDeath event (they usually use the onDeath and onWin events) --[[User:Positive|Positive]] 14:36, 2 August 2009 (UTC)<br />
<br />
By the way, perhaps this would be an opportunity to fix that bug where robots sometimes get to a location of x=17.99998 and other outside-of-arena locations? --[[User:Positive|Positive]] 14:36, 2 August 2009 (UTC)<br />
<br />
: Is there really? Could you please explain the situation some more? &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 15:41, 2 August 2009 (UTC)<br />
: Perhaps you could create a robot that can reproduce the issue, and attach it to a new bug report at SourceForge for Robocode? This way we can fix this issue faster. :-) --[[User:FlemmingLarsen|Fnl]] 19:33, 2 August 2009 (UTC)<br />
: I just finished testing it, and it seems I was wrong. Whenever I try, getX() and getY() return the correct values. Sometimes when my robot scans opponents it does get values like Y=582.0000000000002, but I just realized those must be rounding errors. Well sorry... and that's one less bug to fix. :) --[[User:Positive|Positive]] 21:55, 2 August 2009 (UTC)<br />
: Okay, no harm done. =) --[[User:FlemmingLarsen|Fnl]] 19:49, 3 August 2009 (UTC)<br />
<br />
Guys, I finally managed to fix the [https://sourceforge.net/tracker/?func=detail&aid=2828479&group_id=37202&atid=419486 Missed onRobotDeath events] issue. :-) Hence, it might make sense to make an Alpha-5 (or real Beta) to see what difference this bugfix makes compared to the other alphas. However, I do not know which getNextVelocity() method I should base it on. That is, which alpha version should I base the new alpha on? Alpha-2, Alpha-3, or Alpha-4? Which alpha do you prefer. Did we ever get to a conclusion about which alpha version that is the better one? I know there are different oppinions here. In addition, I should like to release a real Beta soon in order to get rid of other bugs as well. So I really need to make a decision on which getNextVelocity() method to use. --[[User:FlemmingLarsen|Fnl]] 20:08, 4 August 2009 (UTC)<br />
<br />
In the end, I consider it your decision, Fnl. But if you'd like, we could set up a poll on this page? I'm actually still torn on the issue, but in that case, I have to err on the side of caution towards legacy bots... No hard feelings if/when Alpha3 wins out, though. =) (And maybe you should be able to vote for as many choices as you like.) --[[User:Voidious|Voidious]] 20:35, 4 August 2009 (UTC)<br />
<br />
{| border="1" cellpadding="3" style="border-collapse: collapse; color: black; text-align:center"<br />
| Name || Alpha2 (old rules) || Alpha3 (new rules) || Alpha4 (cap at v=1) || Comment<br />
|-<br />
|style='text-align:left'| [[User:Voidious|Voidious]] || X || || ||<br />
|-<br />
|style='text-align:left'| [[User:Positive|Positive]] || X || || X ||<br />
|-<br />
|style='text-align:left'| [[User:Rednaxela|Rednaxela]] || || X || X ||<br />
|-<br />
|style='text-align:left'| [[User:Darkcanuck|Darkcanuck]] || || X || ||<br />
|-<br />
|style='text-align:left'| [[User:Nat|Nat]] || || X || ||<br />
|-<br />
|style='text-align:left'| [[User:FlemmingLarsen|Fnl]] || X || X || ||<br />
|-<br />
|style='text-align:left'| [[User:GrubbmGait|GrubbmGait]] || X || || X ||<br />
|-<br />
|style='text-align:left'| [[User:Skilgannon|Skilgannon]] || || X || ||<br />
|-<br />
|style='text-align:left'| [[User:Jab|Jab]] || X || X || || "Vibrating" could be allowed, but it should appear at least in the official game physics page!<br />
|}<br />
<br />
Hi guys. I am very sorry, but I discoved a bug in the updateMovement() compared to 1.6.1.4, which is described in the [[User:Positive/Optimal_Velocity|Optimal_Velocity]] page. The problem is that the getDistanceRemaining() will return invalid value when the robot we setAhead(0) or setBack(0), but the robot needs to brake. AFAIK, this must have an impact on the scores and hence the results for all the alphas! :-(<br />
<br />
I intend to make at least an Alpha-5 with all bugfixes since 1.7.1.3. Perhaps I should make 3 new alphas to replace Alpha-2, Alpha-3, and Alpha-4 so we can retest with these? Suggestions are very welcome. We could also just make a decision of which rules to use, and only make an Alpha-5, e.g. stick to the old rules (like Alpha-2)? --[[User:FlemmingLarsen|Fnl]] 22:13, 7 August 2009 (UTC)<br />
<br />
== New Alphas ==<br />
<br />
I have now created 3 new alphas (5, 6, 7) to replace the old alphas (2, 3, 4):<br />
* [[http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-5-setup.jar Alpha-5]]: Old rules (Hijack - code changes are [[Talk:Positive/Optimal Velocity#Hijack =)|here (getNewVelocity)]] and [[User:Positive/Optimal_Velocity#Corrected_updateMovement_code|here (updateMovement)]]) - replaces Alpha-2<br />
* [[http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-6-setup.jar Alpha-6]]: New rules (Hijack 2 - code changes are [[User:Voidious/Optimal Velocity#Hijack 2|here (getNewVelocity)]] and [[User:Positive/Optimal_Velocity#Corrected_updateMovement_code|here (updateMovement)]]) - replaces Alpha-3<br />
* [[http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-7-setup.jar Alpha-7]]: Cap at v=1 (code changes are one the middle of [[User_talk:Positive/Optimal_Velocity|this page (getNewVelocity)]] and [[User:Positive/Optimal_Velocity#Corrected_updateMovement_code|here (updateMovement)]]) - replaces Alpha-4<br />
<br />
I propose that we make a new table and compare each new alpha against only version 1.6.1.4. --[[User:FlemmingLarsen|Fnl]] 22:47, 7 August 2009 (UTC)<br />
<br />
Note that the new alphas contains a bugfix for the missing RobotDeathEvents too. =) --[[User:FlemmingLarsen|Fnl]] 22:53, 7 August 2009 (UTC)<br />
<br />
Is the code for the new alphas available in SVN? I'd like to test some of the routines. I'm still studying the new code at [[User:Positive/Optimal Velocity]] and I'm a little confused now as to what was used in each alpha... --[[User:Darkcanuck|Darkcanuck]] 04:55, 8 August 2009 (UTC)<br />
<br />
: No, current code is on Fnl's machine. It isn't available in SVN yet, though I want it too (maybe movement-1/2/3-workspace branches?) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:02, 8 August 2009 (UTC)<br />
<br />
: Nat is right. I don't commit the code for alphas as the intension of an alpha for Robocode is to detirmine if the code should be commit to SVN. An alpha is considered as a prototype/experiment, and are never "official" (hence not in the SVN). However, I have updated the links on the listed alphas so you are able to find the code. --[[User:FlemmingLarsen|Fnl]] 06:13, 8 August 2009 (UTC)<br />
<br />
If you want to study the code, all you need to do is to read out the source code from the SVN trunk/head, and replace the getNextVelocity() depending on which alpha you need to examine (from the links above). In addition, you need to replace the buggy updateMovement() method with the one I added on the buttom on [[User:Positive/Optimal_Velocity#Corrected_updateMovement_code|here]] yesterday. That's it. =) --[[User:FlemmingLarsen|Fnl]] 06:16, 8 August 2009 (UTC)<br />
<br />
----<br />
Okay guys, I decided to add the last two alphas before the Beta:<br />
<br />
* [[http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-8-setup.jar Alpha-8]]: Old rules, [[Talk:Positive/Optimal Velocity#Hijack =)|Skilgammon's getNewVelocity]] and [[User:Positive/Optimal_Velocity#Nat.27s_updateMovement|Nat's updateMovement]] (behaves like 1.6.1.4). Replaces Alpha-2<br />
* [[http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-9-setup.jar Alpha-9]]: New rules, [[User:Voidious/Optimal Velocity#Hijack 2|Voidious's getNewVelocity]] and [[User:Positive/Optimal_Velocity#Nat.27s_updateMovement|Nat's updateMovement]] (behaves like 1.6.1.4). Replaces Alpha-3<br />
<br />
Now we could retest again, and if you have not put your vote yet in the vote table above, please add your vote. :-) --[[User:FlemmingLarsen|Fnl]] 20:12, 9 August 2009 (UTC)<br />
<br />
Great - I'll start running tests this evening / tomorrow morning, should have a lot of results posted in the next couple of days. --[[User:Voidious|Voidious]] 20:53, 9 August 2009 (UTC)<br />
<br />
: Super! I can't wait to see the results. I hope that the new version of updateMovement (by Nat) and also the bugfix for the missing RobotDeathEvents compared to the old alphas will give lesser differences in the scores compared to version 1.6.1.4. We might even see a smaller difference between the old vs new rules after all when the old aplhas are buggy. =) --[[User:FlemmingLarsen|Fnl]] 22:25, 9 August 2009 (UTC)<br />
<br />
I've come around to the idea of the split-tick decel rules, despite the fact that they make DrussGT's movement simulator wrong. The discontinuity that [[User:Rednaxela|Rednaxela]] pointed out was the swaying argument. --[[User:Skilgannon|Skilgannon]] 21:57, 9 August 2009 (UTC)<br />
<br />
: Heh. I was convinced that you would vote for Alpha-2. Great that you added your vote. =) --[[User:FlemmingLarsen|Fnl]] 22:17, 9 August 2009 (UTC)<br />
<br />
: No tie-break now. But we need to see new result before vote again. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 09:05, 10 August 2009 (UTC)<br />
<br />
Hmm.. looks like the difference between Alpha8 and Alpha2, largely fixes the "Raiko vs Moebius" discrepency. I wonder how Alpha9 will turn out now :) --[[User:Rednaxela|Rednaxela]] 04:06, 11 August 2009 (UTC)<br />
: Oh, and I just noticed you said "eg -1 to 0.4" Voidious. Shouldn't that be 0.5, not 0.4? -1 to 0 is half the decel that can occur in a tick, and 0 to 0.5 would be half the accel of a tick. --[[User:Rednaxela|Rednaxela]] 04:11, 11 August 2009 (UTC)<br />
: Yep, just a typo. =) Good catch - thanks! --[[User:Voidious|Voidious]] 04:23, 11 August 2009 (UTC)<br />
<br />
IIRC Raiko also saves data, so having 1000 battles in 1.6.1.4 vs. only 500 in Alpha9 would naturally favor the 1.6.4 results. --[[User:Skilgannon|Skilgannon]] 10:57, 11 August 2009 (UTC)<br />
<br />
: Wow, I had no idea [[Raiko]] saved data. Looks like he's not saving it against [[Moebius]] because he only saves if he wins < 70% of rounds, but is saving against [[Toorkild]]. How crazy to use up so much space with file saving, restoring, and logic behind it in a [[MiniBot]]! --[[User:Voidious|Voidious]] 12:36, 11 August 2009 (UTC)<br />
<br />
I think I will run another 500 battles for Raiko vs Moebius in the new alphas. Very strange that the difference is the opposite of the Alpha2 vs Alpha3 difference... --[[User:Voidious|Voidious]] 23:37, 11 August 2009 (UTC)<br />
<br />
I wonder, is my updateMovement() has some bugs? It should be all green... Look at all scores & diffs again, there are a lot of 'weird' result. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 00:04, 12 August 2009 (UTC)<br />
<br />
: Hmm.. I wonder if it is due to the other bugfixes in the two recent alphas (8 & 9)? At least the differences in scores compared to Alpha-2, 3, and 4 seems to be lesser than with the new Alphas. --[[User:FlemmingLarsen|Fnl]] 21:16, 16 August 2009 (UTC)<br />
<br />
Should we update the pool now when the new results from [[User:Voidious|Voidious]] are ready? I need to know what version to include in the comming Beta. ;-) --[[User:FlemmingLarsen|Fnl]] 21:16, 16 August 2009 (UTC)<br />
<br />
Hey guys, conclusion please? I think jab has had change his vote to Alpha-2 so I think it's a tie now. I think you can choose what you want, Fnl, we all respect your decision, don't we? =) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 13:11, 17 August 2009 (UTC)<br />
<br />
I don't have any more tests running at the moment. What else do you guys think I should run? Or is this enough to draw a conclusion? I think I'm sticking with my alpha 2 vote, though I'm still torn, and I should probably investigate the two problem pairings further. I'm not sure jab really decided on one. It looks to me like the new rules will win the vote. --[[User:Voidious|Voidious]] 14:28, 17 August 2009 (UTC)<br />
<br />
Well... I'd say it would be worth investigating ''"Raiko vs Moebius"'' if anyone has any ideas about what may be going wrong. ''"PrairieWolf vs DuelistMini"'' may be worth investigating before the final release, but I don't think would affect the choice between Alpha8 and Alpha9 as it scores similarly high either way. I'm not sure though, what the issue could be. I've looked at both the Mobius and Raiko code and didn't see anything that I'd expect to be significantly affected by the rule fix. Until further notice though, my vote sticks with Alpha9 style. --[[User:Rednaxela|Rednaxela]] 14:41, 17 August 2009 (UTC)<br />
<br />
It is about time to release Robocode 1.7.1.4 Beta. After having seen the results from [[User:Voidious|Voidious]] and the votes on this page, I will include the new rules from the Alpha-9 in the beta. I intend to assemble this today. :-) --[[User:FlemmingLarsen|Fnl]] 18:38, 21 August 2009 (UTC)<br />
<br />
I have finally released 1.7.1.4 Beta with some additional bugfixes compared to the Alpha-9. Please test this Beta with RoboRumble so we can fix such issues before the final release of 1.7.1.4. :-) --[[User:FlemmingLarsen|Fnl]] 22:19, 26 August 2009 (UTC)</div>Jabhttp://robowiki.net/w/index.php?title=Talk:Robocode/Game_Physics&diff=10457Talk:Robocode/Game Physics2009-08-14T08:59:29Z<p>Jab: /* Accel/decel rules */</p>
<hr />
<div>__TOC__<br />
== Robot hitbox ==<br />
I need to know percisely, which might involve rotating a rectangle, I don't know, if a point intersects my bot, given its X and Y location. Remeber that in Robocode, Y is reversed. While I'm at it, I might just ask: What your opinion is on whether I should do surfing or anti-gravity movement to dodge predicted bullets my robot simulates?<br />
--[[User:Awesomeness|Awesomeness]] 21:52, 3 May 2009 (UTC)<br />
<br />
The 'hitbox' of a robot is always a non-rotated square at the bot's location, so the former check is very very simple. As for your second question: It depends. Surfing is going to be stronger almost surely, however anti-gravity movement is considerably simpler. My suggestion would be to do anti-gravity for now, and at a later date try surfing once you feel comfortable with exactly how it works. --[[User:Rednaxela|Rednaxela]] 22:01, 3 May 2009 (UTC)<br />
<br />
Oh, is it a 40 pixel long sqare? that's what it looks like. --[[User:Awesomeness|Awesomeness]] 22:43, 3 May 2009 (UTC)<br />
<br />
No, it is 36px non-rotating square. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 23:42, 3 May 2009 (UTC)<br />
<br />
== Gun turn and fire execution order ==<br />
<br />
When, in the execution order, are bullets fired, and when is the gun turned? Thanks! --[[User:Mageek|Mageek]] 02:44, 28 May 2009 (UTC)<br />
<br />
I believe that's part of #2 in the "Robocode Processing Loop" section. I can tell you for sure, though, that if you do setFire and setTurnGunRight in the same turn, the bullet will fire at the bearing of your gun ''before'' that gun turn happens. Both of them happen on the next tick, but the bullet is fired as if it were fired on the same tick as setFire (the location is from that tick, and it has advanced by its velocity once). Does that answer your question? --[[User:Voidious|Voidious]] 02:53, 28 May 2009 (UTC)<br />
<br />
Thank-you, that is exactly what I was trying to figure out. --[[User:Mageek|Mageek]] 03:39, 28 May 2009 (UTC)<br />
<br />
== Accel/decel rules ==<br />
<br />
(Conversation began on [[Talk:Darkcanuck/RRServer]]...)<br />
<br />
I've almost finished my first robot to enter to the melee rumble :), but I'm wondering: does the (melee)server use the old accel/decel rules (where you can go from -1 to 1) or the new (where you can't)? --[[User:Positive|Positive]] 23:22, 11 Jul 2009<br />
<br />
The RoboRumble currently only allows clients using versions 1.5.4, 1.6.0, and 1.6.1.4, so it should only be the old rule (where you can). I actually didn't realize that was changed -- I really don't like that. =( Lots of legacy bots are programmed to believe you can. --[[User:Voidious|Voidious]] 21:24, 11 July 2009 (UTC)<br />
<br />
Woah, what a quick response! Thanks for the info. :) I don't really like the change either (I have a cool -1, +1 strategy and a nice move simulator), but alas. --[[User:Positive|Positive]] 23:36, 11 Jul 2009<br />
<br />
Are you sure the rules have changed? I thought the only changes to movement in later versions of Robocode (still unsupported in the rumble, btw) were to fix the movement quirks that Simonton had found. I don't remember decelerating through 0 being one of them. --[[User:Darkcanuck|Darkcanuck]] 22:26, 11 July 2009 (UTC)<br />
<br />
Here is the [http://sourceforge.net/tracker/?func=detail&aid=2793464&group_id=37202&atid=419486 discussion at the bug tracker]. Fnl explains that if for example your robot is at -1.0 velocity, it can only reach 0.75 velocity the next turn (as of version 1.7.1.2). --[[User:Positive|Positive]] 02:45, 12 Jul 2009<br />
<br />
Errr.... 0.75 is not 'accurate'... It's what robocode as of 1.7.1.2 does, but it's just as incorrect as before the change... Fnl says it uses a formula of <code>(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION *<br />
accelTime * accelTime)</code>, when the correct formula should be <code>(Rules.DECELERATION * decelTime + Rules.ACCELERATION * accelTime)</code>. Change in velocity, is always equal to acceleration multiplied by time, not time squared... It looks like Fnl got his physics mixed up and looked at a formula to get distance from acceleration (<code>d = a*t*t</code>) instead of getting velocity change from acceleration (<code>v = a*t</code>) :-( --[[User:Rednaxela|Rednaxela]] 01:47, 12 July 2009 (UTC)<br />
<br />
: Ooh, I see this now... Do some tests and file a bug for [[Fnl]]? --[[User:Darkcanuck|Darkcanuck]] 02:48, 12 July 2009 (UTC)<br />
<br />
:: Robocode Developer Google Groups, I think. So Flemming can re-open that tracker instead of creating new one. I always wonder why it go from 1 to -0.75, not 0.5 since it have only half turns left, I always think that I don't have enough physics knowledge. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 02:59, 12 July 2009 (UTC)<br />
<br />
Voidious, do you subscribe to [http://groups.google.com/group/robocode-developers Robocode Developer Google Groups]? I think we have reached the conclusion that we worth this change, unless there are too many effects. After we changed it, Flemming and I did run a lot of test (well, mostly Flemming run, I'd run only one test). I've test [[Dookious]] with [[DrussGT]], on both 1.6.1.4 and 1.7.1.x with new updateMovement(), and the difference is around 1-2%, which is acceptable in margin of error. I chose Dookious and DrussGT because I know that Dookious use FuturePosition library, which is the internal copy of old movement engine. And DrussGT use Skilgannon's special movement predictor which I believe should be the loosely implementation of the 'correct' movement engine.<br />
<br />
Positive, I believe that if you create a good movement under 1.6.1.4, it will be good in 1.7.1.x version too. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:20, 12 July 2009 (UTC)<br />
<br />
- - -<br />
<br />
Hi guys, to you mind I join the discussion? I did the change in "update movement" for many reasons. The issue(s) were raised a long time ago on the old RoboWiki (the 3 caveats raised by Simonton - http://old.robowiki.net/cgi-bin/robowiki?GamePhysics/BotSpeed), and later discussed within the Robocode Developer Group (even Mathew Nelson joined the discussion). That is, if we would make the change or not. Especially with you guys in mind. The conclusion in the groups was to fix the bugs so Robocode would follow its own rules, and because lot's of robots out there counts on the rules as explained, not to the way Robocode was actually behaving. Not everybody replicates the internal code of Robocode to get the formulas correct.<br />
<br />
The old closed bug tracker on SF created is available here: https://sourceforge.net/tracker/?func=detail&atid=419486&aid=2077512&group_id=37202<br />
<br />
Another goal with the change was to make the internal code easier less messy and easier to understand. Regarding the impact of the change, the results are not very different (unless you can prove me wrong here). I ran lots of lots of test with RoboRumble (also Melee and TeamRumble) on my local machines (different single-code, quad-core, Linux, Windows, 32 and 64 bit etc.), and I couldn't tell the difference in rankings or score with or without the change. There was a difference, but it was in average less than 1 percent. Is it really that much of a problem? Really?<br />
<br />
I would really love if people could try out the Betas on RoboRumble and put issues on SF as soon as they are discovered. Then the issues can be fixed or discussed before we do the real release. This way, we could avoid such issues as this one long time after the change was made and released.<br />
<br />
Btw. I am very familiar with physics, even tough the physics in Robocode does not really follow the real physics laws. I might not have explained the details about the fix well enough. <br />
<br />
Instead of shifting between old and new code (like you propose?), I should like you guys to tell me where the problem is in the code instead, since you are obviously the experts. The code is Open Source, so everybody is free to come with suggestions to what and where to correct things.<br />
<br />
Here we go:<br />
<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (dx != 0 || dy != 0) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
// If the distance is negative, then change it to be positive and change the sign of the input velocity and the result<br />
if (distance < 0) {<br />
return -getNewVelocity(-velocity, -distance);<br />
}<br />
<br />
double newVelocity;<br />
<br />
// Get the speed, which is always positive (because it is a scalar)<br />
final double speed = Math.abs(velocity); <br />
<br />
// Check if we are decelerating, i.e. if the velocity is negative.<br />
// Note that if the speed is too high due to a new max. velocity, we must also decelerate.<br />
if (velocity < 0 || speed > currentCommands.getMaxVelocity()) {<br />
// If the velocity is negative, we are decelerating<br />
newVelocity = speed - Rules.DECELERATION;<br />
<br />
// Check if we are going from deceleration into acceleration<br />
if (newVelocity < 0) {<br />
// If we have decelerated to velocity = 0, then the remaining time must be used for acceleration<br />
double decelTime = speed / Rules.DECELERATION;<br />
double accelTime = (1 - decelTime);<br />
<br />
// New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d<br />
// However, the new velocity must be limited by the max. velocity<br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,<br />
distance));<br />
<br />
// Note: We change the sign here due to the sign check later when returning the result<br />
velocity *= -1;<br />
}<br />
} else {<br />
// Else, we are not decelerating, but might need to start doing so due to the remaining distance<br />
<br />
// Deceleration time (t) is calculated by: v = a * t => t = v / a<br />
final double decelTime = speed / Rules.DECELERATION;<br />
<br />
// Deceleration time (d) is calculated by: d = 1/2 a * t^2 + v0 * t + t<br />
// Adding the extra 't' (in the end) is special for Robocode, and v0 is the starting velocity = 0<br />
final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;<br />
<br />
// Check if we should start decelerating<br />
if (distance <= decelDist) {<br />
// If the distance < max. deceleration distance, we must decelerate so we hit a distance = 0<br />
<br />
// Calculate time left for deceleration to distance = 0<br />
double time = distance / (decelTime + 1); // 1 is added here due to the extra 't' for Robocode<br />
<br />
// New velocity (v) = a * t, i.e. deceleration * time, but not greater than the current speed<br />
<br />
if (time <= 1) {<br />
// When there is only one turn left (t <= 1), we set the speed to match the remaining distance<br />
newVelocity = Math.max(speed - Rules.DECELERATION, distance);<br />
} else {<br />
// New velocity (v) = a * t, i.e. deceleration * time<br />
newVelocity = time * Rules.DECELERATION;<br />
<br />
if (speed < newVelocity) {<br />
// If the speed is less that the new velocity we just calculated, then use the old speed instead<br />
newVelocity = speed;<br />
} else if (speed - newVelocity > Rules.DECELERATION) {<br />
// The deceleration must not exceed the max. deceleration.<br />
// Hence, we limit the velocity to the speed minus the max. deceleration.<br />
newVelocity = speed - Rules.DECELERATION;<br />
}<br />
}<br />
} else {<br />
// Else, we need to accelerate, but only to max. velocity<br />
newVelocity = Math.min(speed + Rules.ACCELERATION, currentCommands.getMaxVelocity());<br />
}<br />
}<br />
<br />
// Return the new velocity with the correct sign. We have been working with the speed, which is always positive<br />
return (velocity < 0) ? -newVelocity : newVelocity;<br />
}<br />
</pre><br />
<br />
What must be corrected in order to make everybody happy, following the "physic laws" and rules of Robocode? --[[User:FlemmingLarsen|Fnl]] 22:59, 12 July 2009 (UTC)<br />
<br />
Fnl, it will take me some time to look over the code and discussions before I can give more constructive feedback. But some things I can comment on for now:<br />
* Fixing the issues Simonton brought up seems very reasonable to me. One is a bug that I doubt anyone depends on (the setMaxVelocity / decel). For the others, I'd guess [[DrussGT]] and [[SilverSurfer]] are the only bots that might simulate the quirks (being Go-To surfers). Some [[Wave Surfing Challenge]] tests with SS (I will run some) and feedback from Skilgannon could shed some light on potential impact.<br />
* I'm not clear on what has happened with this, but I believe changing the ability to go from velocity 1 to -1 could adversely impact a lot of bots. Even a bot as old as [[PrairieWolf]] (2002) has a movement mode that depends on it ("buzzing" between 1 and -1), and I'd guess nearly every modern wave surfer also simulates this aspect of the physics.<br />
* One percent ''is'' a lot -- see the "huge" 1% APS gap between DrussGT and Dookious =). That said, it takes hundreds or thousands of battles to get a result accurate enough to see that 1% difference.<br />
* I do not envy your position in these types of matters, and as always, I appreciate the effort you put into developing Robocode. Robocode's impact goes far beyond the "hardcore" Robocoders on this wiki, and I fully understand that you want to polish Robocode as best as you can for the benefit of everyone that uses it. Cheers,<br />
--[[User:Voidious|Voidious]] 00:01, 13 July 2009 (UTC)<br />
<br />
: 1 percent is ''not'' a lot with this major change in physics, especially when it makes the game follows its own rule better. 1% is 'huge' in APS, I agree. But if you look at each battle closely, the results can swing up to 10% &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
<br />
:: 1% is 1% and it ''is'' a lot. You're right that individual battles have a large variance, that's why you need to run hundreds of battles to get a meaningful result. If you run enough battles to get a statistically accurate result, 1% is a lot. If you don't run enough battles, you can't draw any real conclusion from the results. <br />
:: I'm not claiming there is a 1% difference in results. I'm only saying that if tests only narrowed it down to "1% or less", that's not really enough to satisfy my need for accuracy and consistency. No ill will here, I should get involved and run some tests if I care so much. And I do. And I will. =)<br />
:: --[[User:Voidious|Voidious]] 17:40, 13 July 2009 (UTC)<br />
<br />
::: While I wat to argue that 1% is ''not'' a lot for this major physics change, I don't think that is an issue anymore. I think you already accept the changes now =) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:37, 14 July 2009 (UTC)<br />
<br />
I've read the mailing list and bug report concerning the issue. Does the -1, +1 thing really need to be changed to fix the bugs? This is how I would code it, and I believe it should fix the bugs. I haven't actually compiled it into robocode, but the velocity routines themselves have been tested and are working. And excuse me, I'm a bad commenter :):<br />
<br />
<pre><br />
<br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
// small tweak from original version<br />
if(velocity!=0)<br />
{<br />
x+=velocity * sin(bodyHeading);<br />
y+=velocity * cos(bodyHeading);<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
static double getNewVelocity(double velocityArg, double distanceArg) <br />
{ <br />
double velocity;<br />
double distance;<br />
<br />
// Make sure the remaining distance is always positive or zero<br />
// (we switch this back later)<br />
if(distanceArg<0)<br />
{<br />
velocity=-velocityArg;<br />
distance=-distanceArg;<br />
}<br />
else<br />
{<br />
velocity=velocityArg;<br />
distance=distanceArg;<br />
}<br />
<br />
// Get the next most positive velocity the robot can reach for next turn<br />
double mostPositiveReachableVelocity = VelocityToMostPositiveVelocity(velocity);<br />
// Get the next most negative velocity the robot can reach for next turn<br />
double mostNegativeReachableVelocity = VelocityToMostNegativeVelocity(velocity);<br />
<br />
<br />
double highestWantedVelocity = Math.min(currentCommands.getMaxVelocity(), maxSpeedToStopInDisp(distance));<br />
<br />
// The real next velocity is limited by what is actually reachable<br />
double nextVelocity = Math.min(mostPositiveReachableVelocity,Math.max(mostNegativeReachableVelocity,highestWantedVelocity ));<br />
<br />
// Switch return value back if needed<br />
if(distanceArg<0)<br />
nextVelocity = -nextVelocity;<br />
<br />
return nextVelocity;<br />
}<br />
<br />
<br />
static public double VelocityToMostPositiveVelocity(double velocity)<br />
{<br />
// Returns the most positive reachable velocity from the<br />
// specified velocity in one turn<br />
if(velocity>0)<br />
{<br />
double returnVelocity = velocity+Rules.ACCELERATION;<br />
if(returnVelocity>Rules.MAX_VELOCITY)<br />
return Rules.MAX_VELOCITY;<br />
else<br />
return returnVelocity;<br />
}<br />
else<br />
{<br />
double returnVelocity = velocity+Rules.DECELERATION;<br />
if(returnVelocity>Rules.ACCELERATION)<br />
return Rules.ACCELERATION;<br />
else<br />
return returnVelocity;<br />
}<br />
}<br />
static public double VelocityToMostNegativeVelocity(double velocity)<br />
{<br />
// Returns the most negative reachable velocity from the<br />
// specified velocity in one turn<br />
if(velocity<0)<br />
{<br />
double returnVelocity = velocity-Rules.ACCELERATION;<br />
if(returnVelocity<-Rules.MAX_VELOCITY)<br />
return -Rules.MAX_VELOCITY;<br />
else<br />
return returnVelocity;<br />
}<br />
else<br />
{<br />
double returnVelocity = velocity-Rules.DECELERATION;<br />
if(returnVelocity<-Rules.ACCELERATION)<br />
return -Rules.ACCELERATION;<br />
else<br />
return returnVelocity;<br />
}<br />
}<br />
<br />
static private final double[] dispStopArray = <br />
{0.0000,1.0000,2.0000,2.5000,3.0000,<br />
3.5000,4.0000,4.3333,4.6666,5.0000,<br />
5.3333,5.6666,6.0000,6.2500,6.5000,<br />
6.7500,7.0000,7.2500,7.5000,7.7500};<br />
static public double maxSpeedToStopInDisp(double displacement)<br />
{<br />
// Returns the biggest velocity the robot could go to this turn,<br />
// still being able to stop without overshooting. (Or if <br />
// remaining displacement is less than 2, returns that)<br />
// This routine could be improved to match up with robocode's<br />
// older velocity selecting rules.<br />
if(displacement>=0)<br />
{<br />
if(displacement>=20)<br />
return 8.0;<br />
else if(displacement<=2)<br />
return displacement;<br />
else<br />
return dispStopArray[(int)Math.floor(displacement)];<br />
}<br />
else<br />
{<br />
return 0;<br />
}<br />
}<br />
</pre><br />
I also appreciate your effort, Fnl. :) --[[User:Positive|Positive]] 01:48, 13 July 2009 (UTC)<br />
<br />
Ok, I'm up to speed with the discussions and the code. I think, for how it was decided, this line:<br />
<pre><br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,<br />
distance));<br />
</pre><br />
...should be changed to:<br />
<pre><br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.ACCELERATION * accelTime, distance));<br />
</pre><br />
* The deceleration already takes you to zero, so we just need to use the remaining time for acceleration, right?<br />
* Don't need to square the accelTime (v = at).<br />
<br />
So, as I understand it, your velocities should be, for example: -1, +0.5, -0.75, +0.625? "Legacy" issues aside, I like this solution a lot. It makes sense. I've been considering this issue a bit now, and here's how I'd lay out the impact to affected bots:<br />
* A bot like [[PrairieWolf]] that oscillates between 1 and -1 will now oscillate between roughly 0.7 and -0.7. I'm ''guessing'' this has very minimal impact on performance (though I am curious to test / confirm).<br />
* When Wave Surfers predict a change of direction, their predictions could be off. I believe most surfers are dealing with whole number velocities the great majority of the time. Changing direction from even velocities will not be impacted. Changing direction from odd velocities, their predictions could be off by as much as 4 pixels -- predicting a velocity 0.5 too high for 8 ticks (until they reach max velocity). Some might disagree, and of course I advocate ultimate precision in surfing, but I believe the impact here is negligible. (How many of us even do precise bot width? And I never found much to be gained there, anyway.)<br />
* I'm still not crazy about changing Robocode's physics, and I might've opposed it if put to a vote, but I think the impact is negligible and the new solution is a good one. <br />
<br />
Also, I've started running those [[SilverSurfer]] WSC tests on 1.6.1.4 and 1.7.3 to compare. I'll have the results today or tomorrow.<br />
<br />
--[[User:Voidious|Voidious]] 15:31, 13 July 2009 (UTC)<br />
<br />
: The information in Robocode (mostly the floating point value) isn't digital, means that only 0.5 change isn't impact ''much''. If you can dodge bullets well, the missed 2 ticks with the most of 2 pixels won't make the bullet hit you. If you can't dodge it, the slippage of 2 pixels ''may'' make you dodged it, but only by luck. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
<br />
<Edit conflict> Thanks for taking a look Fnl. I personally think that the current code is more complicated than necessary, and as such, harder to understand. Here's a few things that should be addressed:<br />
* The decelDist. Because robocode follows a discrete time base, it cannot be approximated with calculus. For example, say your speed is 3, your formula gives 3.75 as decelDist. However, 3 + 1 + 0 = 4, so your code would not want to decelerate in the right places. This would be the correct implementation:<br />
<pre><br />
private static final double decelDistance(double velocity){<br />
double distance = 0;<br />
while(velocity > 0){<br />
distance += velocity;<br />
velocity = Math.max(0,velocity - Rules.DECELERATION);<br />
}<br />
return distance;<br />
}<br />
</pre><br />
* One of the ideas of robocode is that your bot has a continuous acceleration/deceleration over a single tick. I see what you have done is, when a bot is decelerating over 0 velocity, it takes 1/2 of the tick to decelerate and then 1/2 of the tick is left to accelerate in the other direction (the split may depend on the amount of time taken to decelerate to 0 first). But many older bots rely on being able to decelerate over the entire tick, using the 2 deceleration value instead of the 1 acceleration value, so that they can 'vibrate' from 1 to -1 back to 1 etc. While I agree that it is not correct, these are the physics of robocode, not real life =) Because of this, you can essentially remove the majority of the inside of that 'if' block, just leaving <code>velocity *= -1;</code>.<br />
* I have re-written this method, and if people want I'll post it, but it seems that with a few quick fixes this one should be up to scratch =), so I don't really think that's necessary.<br />
<br />
As an answer to [[Voidious]], I haven't taken any of the 'quirks' into account while writing DrussGT. It is coded with the rules, as they are described on the [[Robocode/Game_Physics]] page, in mind. --[[User:Skilgannon|Skilgannon]] 16:00, 13 July 2009 (UTC)<br />
<br />
: (edit conflict) In my tests, DrussGT usually performs worse. But just around 0.2% or somethings. I'm not sure since I ran only 3 35-rounds tests.<br />
: While I agree with you that this isn't real life, it still isn't correct under its own Rules. The major reason we have this fix is that we want Robocode to follows its own rule batter. Otherwise we should have the bullet velocity affected by robot velocity, the curved bullet, better bullet-bullet collision checking etc. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
:: Sorry, but 3 battles simply cannot produce a result within 0.2% accuracy. In my experience, you'd need 100 or more before the overall result stays within 0.2%. --[[User:Voidious|Voidious]] 17:40, 13 July 2009 (UTC)<br />
<br />
Hi guys. Thank you for the constructive feedback. I appreciate that. I see many of you have some really good pointer of what to change, and where to make the changes. Currently, I have my house full of guests and is just checking what is going on in this forum. Tomorrow evening, I will take a closer look at all the comments, and I agree that the new implementation for "update movevement" is buggy too. I intend to create some variants that you can download and test for yourselves. Afterwards, you can choose which one is the better one for the next version of Robocode.<br />
Compared to 1.6.x.x, the code has become much simpler than it was before. I am not sure that the code could be any simpler than it is now as we will brake something else (because something is missing) - even though I hope it is possible.<br />
So, tomorrow I will review all comment on this page and take action. =) --[[User:FlemmingLarsen|Fnl]] 17:43, 13 July 2009 (UTC)<br />
<br />
I really agree that the code is a lot more simple and adaptable than 1.6 and before. When I was adapting the internal Robocode's movement engine for my movement predictor, I can't adapt the <1.6 code. I get my head mess when I'm trying to understand it. However, I can adapt the current code really easy (in fact, I did copy almost whole getNewVelocity() method) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:37, 14 July 2009 (UTC)<br />
<br />
I have examined all the comments here, and is trying to figure out how to modify the existing code for getNewVelocity(). I think you are on the right track [[Voidious]], and hence I want to implement your modifications so we could all try them out. However, I have a hard time figuring out how the modified version of getNewVelocity() will look like. If a change the part for the newVelocity, it must be in the two places in the code, where it is assigned. You have only written how you want the first one. [[Voidious]], could you give the full version of your version of getNewVelocity() as you think it should be? This way we all will be able to follow (and discuss) the changes/ideas, and I will be able to implement it straight away. :-) --[[User:FlemmingLarsen|Fnl]] 22:28, 14 July 2009 (UTC)<br />
<br />
Sorry, I was only closely examining the decelerating through zero issue before. I agree with Skilgannon's assessment that decelDist doesn't seem right, though I'm not sure I'm understanding this fully. Skilgannon, you say that decelDist(3) should be 4, but shouldn't it be 1, since we can update the speed before we move? In either case, I don't understand why it would be 3.75, but I'm curious if there is some voodoo at work in this code that I'm not getting yet. I'll study some more and try to figure it out. =) <br />
<br />
And Skilgannon, no harm in posting your rewritten version, I wouldn't mind seeing it. I'll also check out Positive's version. And I'll have some 1.6.1.4 vs 1.7.1.3 [[Wave Surfing Challenge 2K6|WSC2K6]] scores ready to examine tomorrow. Only about 180 more seasons to run. =)<br />
<br />
--[[User:Voidious|Voidious]] 00:23, 15 July 2009 (UTC)<br />
* My understanding (and subsequently, DrussGT's movement simulator, which uses a decelDistance based method of deciding when to decelerate) is if we go with the velocity of 3 this tick, how far will we travel in total if we decide it's necessary to decelerate next tick. ''Basically, do we have freedom with to do as we please with our velocity this tick, and still be able to decelerate sufficiently in the future''. If the answer is "no", then we need to decelerate ''or'' maintain velocity this tick. My statements about 4 and 3.75 assumed the DECELERATION is 2. Fnl gets 3.75 from this little bit of code:<br />
<pre><br />
final double decelTime = speed / Rules.DECELERATION;<br />
final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;<br />
</pre><br />
: ie. <code>3/2 = 1.5 --> 0.5*2*1.5*1.5 + 1.5 = 3.75</code> whereas it should be <code>3 + (3-2) = 4</code>. I'll be very interested to see what the scores look like =) --[[User:Skilgannon|Skilgannon]] 08:59, 15 July 2009 (UTC) <br />
<br />
Wow, this problem really is not trivial. Here's what I came up with, I think it works and is pretty minimal:<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (dx != 0 || dy != 0) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
// If the distance is negative, then change it to be positive and change the sign of the input velocity and the result<br />
if (distance < 0) {<br />
return -getNewVelocity(-velocity, -distance);<br />
}<br />
<br />
double newVelocity;<br />
<br />
// Get the speed, which is always positive (because it is a scalar)<br />
final double speed = Math.abs(velocity); <br />
<br />
if (velocity < 0) {<br />
// Check if we are decelerating, i.e. if the velocity is negative.<br />
newVelocity = speed - Rules.DECELERATION;<br />
<br />
// Check if we are going from deceleration into acceleration<br />
if (newVelocity < 0) {<br />
// If we have decelerated to velocity = 0, then the remaining time must be used for acceleration<br />
double decelTime = speed / Rules.DECELERATION;<br />
double accelTime = (1 - decelTime);<br />
<br />
// New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d<br />
// However, the new velocity must be limited by the max. velocity<br />
newVelocity = Math.min(Rules.ACCELERATION * accelTime, distance));<br />
<br />
// Note: We change the sign here due to the sign check later when returning the result<br />
velocity *= -1;<br />
}<br />
} else {<br />
// Deceleration distance (d) is calculated iteratively due to Robocode's<br />
// discrete time system.<br />
final double decelDist = decelDistance(speed);<br />
<br />
// Deceleration ticks is the number of ticks it will take to get to<br />
// zero velocity. <br />
final long decelTime = Math.round( // VOIDIOUS: for rounding errors? maybe unnecessary<br />
Math.ceil((speed - Rules.DECELERATION) / Rules.DECELERATION));<br />
<br />
// The maximum distance coverable with an equivalent decelTime<br />
final double decelTimeMaxDist = ((decelTime + 1) / 2.0) * decelTime // sum of 1..decelTime<br />
* Rules.DECELERATION;<br />
<br />
if (distance <= Rules.DECELERATION) {<br />
// If we can cover remaining distance and then completely stop,<br />
// set speed = distance<br />
newVelocity = Math.max(speed - Rules.DECELERATION, distance);<br />
} else if (distance <= decelTimeMaxDist) {<br />
// If we can cover distance in decelTime, split any extra<br />
// distance (between decelDist and distance) over decelTime<br />
// ticks<br />
newVelocity = speed - Rules.DECELERATION + <br />
((distance - decelDist) / decelTime);<br />
} else {<br />
// If we need more than decelTime ticks, try to spread the<br />
// extra distance over (decelTime + 1) ticks. This will just max <br />
// the acceleration if it needs to (ie, if we need more ticks).<br />
// VOIDIOUS: I think this part would break if Rules.ACCELERATION<br />
// were set above Rules.DECELERATION; we might need an <br />
// extra case or something. Doh. =(<br />
newVelocity = Math.min(speed + Rules.ACCELERATION,<br />
(decelTime * Rules.DECELERATION) +<br />
((distance - decelTimeMaxDist) / (decelTime + 1)));<br />
}<br />
}<br />
<br />
// VOIDIOUS: I think it makes more sense to do this here; no need to decelerate maximally<br />
// if you don't need to to accomodate a new setMaxVelocity.<br />
newVelocity = Math.max(speed - Rules.DECELERATION, <br />
Math.min(newVelocity, currentCommands.getMaxVelocity()));<br />
<br />
// Return the new velocity with the correct sign. We have been working with the speed, which is always positive<br />
return (velocity < 0) ? -newVelocity : newVelocity;<br />
}<br />
<br />
private static final double decelDistance(double speed){<br />
double distance = 0;<br />
while(speed > 0){<br />
speed = Math.max(0,speed - Rules.DECELERATION);<br />
distance += speed;<br />
}<br />
return distance;<br />
}<br />
</pre><br />
Velocity is updated before the bot moves, right? =) This is a serious brain teaser! Wanted to post what I had before bed, but I'm still not satisfied with the part that would break with different accel/decel values. --[[User:Voidious|Voidious]] 05:06, 15 July 2009 (UTC)<br />
<br />
(maybe we should move this lengthy discussion to another page?)<br />
I've been going through the new velocity formula and have similar concerns as [[Skilgannon]]. Just running some test cases using my [[Darkcanuck/VelocityTest | VelocityTest]] class and have found cases where the bot overshoots the requested distance (e.g. try starting velocity 0, distance 6 -- the bot ramps up to velocity 3 and will thus overshoot badly). I'll put together some tests and then maybe make a fixed version of the routine.<br />
<br />
Regarding deceleration through 0, I have to sympathize with Fnl et al. There's nothing in the rules that says a bot can decelerate through 0 and gain some free acceleration. Deceleration takes you towards 0, acceleration takes you away from it. It's a quirk -- often called a "bug" -- that was perhaps first publicized [http://oldtestwiki.roborumble.org/cgi-bin/robowiki?GamePhysics here] (near bottom) and has been exploited since. Its not a huge quirk, the advantage is minimal so fixing it should also be minimal but only tests can really confirm this.<br />
<br />
--[[User:Darkcanuck|Darkcanuck]] 05:09, 15 July 2009 (UTC)<br />
<br />
Hey Fellas. Great you're doing more research into this! I think the -1, +1 thing is not a major issue, but if the incorrect movement handling bugs can be fixed in a way that the -1, +1 thing stays valid, is there any harm? I think the version I posted is simpler to understand, and it should work effectively. The only thing that you might not agree with is the working of the maxSpeedToStopInDisp function, but that should at least centralize the problem. :) --[[User:Positive|Positive]] 05:53, 15 July 2009 (UTC)<br />
<br />
: I'm sorry I haven't examined yours more. There are two reasons, really:<br />
:* It does look like you're solving the problem efficiently (and I assume correctly), but I think it depends on fixing one or all of Rules.DECELERATION, Rules.ACCELERATION, and maximum velocity=8. I think we want a solution independent of those values.<br />
:* I find this quite an enjoyable brain teaser, and just wanted to figure out an answer myself. =)<br />
:--[[User:Voidious|Voidious]] 13:26, 15 July 2009 (UTC)<br />
<br />
: I did test your solution and it passes all the same tests that Voidious' version 2 does. But as he pointed out, the hardcoded values are problematic. --[[User:Darkcanuck|Darkcanuck]] 17:48, 15 July 2009 (UTC)<br />
<br />
The reason I don't like breaking the +-1 thing is because it makes the precise prediction significantly more complicated, and what's more it assumes that the acceleration has more than one value between 2 ticks, which to me seems to break the whole concept of a discrete time interval. For interests sake, here's the one I wrote:<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (velocity != 0 ) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
<br />
if (distance < 0) <br />
return -getNewVelocity(-velocity, -distance);<br />
// If the distance is negative, then change it to be positive<br />
// and change the sign of the input velocity and the result<br />
<br />
double maxVel = currentCommands.getMaxVelocity();<br />
if (velocity < 0)<br />
return Math.min(velocity + Rules.DECELERATION, maxVel);<br />
//we want to go in the opposite direction, so decelerate <br />
<br />
else{ <br />
//we are going in the direction we want, test what happens if we accelerate<br />
<br />
double accel = Math.min(Rules.ACCELERATION, maxVel - velocity);<br />
//speed up, but not more than max velocity. decel if maxVel is less than velocity.<br />
<br />
accel = Math.max(accel, -Rules.DECELERATION);<br />
//prevent excess deceleration due to bot lowering the maxVel while velocity is high<br />
<br />
if (distance > decelDistance(velocity + accel))<br />
return velocity + accel;<br />
else if(accel != 0 && distance > decelDistance(velocity))<br />
return velocity;<br />
else{<br />
if(distance < Rules.DECELERATION <br />
//we'll be able to cover remaining distance in 1 tick and then decel to stop<br />
<br />
&& velocity - distance <= Rules.DECELERATION <br />
//and our velocity is low enough for us to get to that required velocity<br />
)<br />
return Math.min(distance, maxVel);<br />
//choose the velocity to cover all remaining distance <br />
<br />
return Math.max(-maxVel, velocity - Rules.DECELERATION);<br />
//velocity > 0 and we are close enough, so decelerate. <br />
}<br />
<br />
}<br />
<br />
}<br />
/**<br />
* Returns the linear distance it would take to decelerate from a given positive velocity<br />
*<br />
* @param velocity the positive velocity from which to test<br />
* @return the linear distance required to decelerate to a standstill<br />
*/<br />
private static final double decelDistance(double velocity){<br />
double distance = 0;<br />
while(velocity > 0){<br />
distance += velocity;<br />
velocity = Math.max(0,velocity - Rules.DECELERATION);<br />
}<br />
return distance;<br />
} <br />
</pre><br />
I'm fairly sure this fixes the 0,6 test Darkcanuck is doing. Voidious, one of the problems with your decelDistance() implementation is that your decel distance assumes you decelerate before adding the distance, whereas mine checks if we can still accelerate this tick and be able to decelerate sufficiently in the future. Also, mine considers the case of continuing at the current velocity, which may be a better option, as in the 0,6 test. --[[User:Skilgannon|Skilgannon]] 08:27, 15 July 2009 (UTC)<br />
<br />
: I agree that the new formulas do break the simplicity of the discrete time period. One simple solution would be simply to apply deceleration until 0 velocity is reached -- the extra time for acceleration would be lost. That would both follow the rules and keep the accel/decel values simple. But Fnl's solution does compromise by giving back the extra time for some acceleration, which should help bots that rely on this quirk. --[[User:Darkcanuck|Darkcanuck]] 16:29, 15 July 2009 (UTC)<br />
<br />
(I agree about moving this to a different or its own page. Anyone can feel free, or I'll do it in a bit.) Ah, I'm just imagining a different significance to decelDist: I imagine it as the minimum distance we would cover if we slam on the brakes. The problem with the (0, 6) case (more specifically the (2, 3) case) in mine is similar to the problem I theorize about when Rules.accel is greater than Rules.decel: I assume that if you can't cover ''distance'' in decelTime ticks, you can split the extra distance over (decelTime + 1) ticks, which of course is 1 tick and you go to speed 3. Maybe I should force decelTime to a min of 1, since if it's 0 and distance <= Rules.decel, we hit the first case and don't use it, otherwise we hit the 3rd case and need 2 ticks.<br />
<br />
Mine would also remain at constant velocity if needed, or even speed up a bit, despite lack of a special case. I'll have to investigate that 0 to -2 acceleration... hopefully that's a simple fix. <br />
<br />
I forgot that you'd already be familiar with this kinda stuff, since you are the Lord of Go-To. =) But I still see a problem with yours in that you restrict your decisions to max accel, constant, or max decel. Take the v=6.1, d=15 case: you want to do it in 4 ticks, and mine will (I think =)) go 6.75, 4.75, 2.75, 0.75. I think yours would go 6.1, 4.1, then be presented with (4.1, 4.8) and fail to do it in 4 ticks.<br />
<br />
I swear there must be a known Dynamic Programming problem that reduces to this. Maybe my effort would be better spent finding it and copying the established solution. =) To be clear, we are trying to do this in the optimal number of ticks, right?<br />
<br />
--[[User:Voidious|Voidious]] 13:26, 15 July 2009 (UTC)<br />
<br />
* Yep, what we are attempting to do is minimize number of ticks until velocity and distance are 0. The implementation I have in DrussGT is a highly simplified version of what I posted, and probably runs about 10 times faster =) --[[User:Skilgannon|Skilgannon]] 7:57, 16 July 2009 (UTC)<br />
<br />
I updated my method and posted it to [[User:Voidious/Optimal Velocity]]. I think this fixes both the (2, 3) case and the (0, 2) case, though I feel like the (2, 3) case should go 2/1 instead of 1.5/1.5. Can we agree that Rules.DECELERATION will never be less than Rules.ACCELERATION? Or just accept that caveat in our solutions? I believe changing that would seriously complicate things. --[[User:Voidious|Voidious]] 14:28, 15 July 2009 (UTC)<br />
<br />
Ok, I really need to stop thinking about this and get some work done =), but I found some topics maybe worth checking out: <br />
* [http://en.wikipedia.org/wiki/Bellman_equation Wikipedia: Bellman equation]<br />
* [http://en.wikipedia.org/wiki/Backward_induction Wikipedia: Backward induction] (found linked [http://en.wikipedia.org/wiki/Dynamic_programming#Algorithms_that_use_dynamic_programming here])<br />
--[[User:Voidious|Voidious]] 14:43, 15 July 2009 (UTC)<br />
<br />
I understand your point Voidious. But I think in any case, the whole concept is complex in such a way, it's good to break it up into different functions (like Darkcanuck has already done partially). How about you guys make the following functions for your versions: <br />
<pre><br />
double getMaxVelocity(double distance)<br />
{<br />
// returns the largest possible velocity for the robot to be set to,<br />
// that, if next turn it had to start decelerating, it would still be<br />
// able to stop without overshooting<br />
}<br />
</pre><br />
<br />
Basically, that would refine the problem. Because in that function you don't have to care about the current velocity. :) After this function returns, you only need to check if the returned velocity "wantedVelocity" is actually reachable from the current velocity by the accelerating/deceleration laws of robocode. And if not try to get closest to it (that won't cause any problems, because any speed returned lower than the max velocity won't overshoot either) :) <br />
<br />
So basically, the other function needed is:<br />
<pre><br />
double getClosestReachableVelocityToVelocity(double currentVelocity,double wantedVelocity)<br />
{<br />
// with this function you can basically assume setAhead(Infinity) or setAhead(-Infinity)<br />
// was called, and you determine the next velocity based on the max velocity<br />
// set by the robot. For example, if the current velocity is 0 and the max velocity<br />
// set was 4.0, it would return 1.0. If the current velocity was 8.0, it would return 6.0.<br />
} <br />
</pre><br />
Finally, the getNewVelocities final version would be (independant of the workings of the other functions):<br />
<pre><br />
double getNewVelocity(double velocity, double distance) <br />
{<br />
if(distance<0)<br />
return -getNewVelocity(-velocity,-distance);<br />
double highestVelocity = getMaxVelocity(distance); // highest velocity without overshooting<br />
double wantedVelocity = Math.min(highestVelocity,currentCommands.getMaxVelocity());<br />
// the actually wanted velocity by the robot is the highest possible,<br />
// limited by what the robot set by the setMaxVelocity command<br />
return getClosestReachableVelocityToVelocity(velocity, wantedVelocity);<br />
// return whatever is closest to that velocity<br />
}<br />
</pre><br />
--[[User:Positive|Positive]] 16:50, 15 July 2009 (UTC)<br />
<br />
: I didn't break anything up, just plugged the getNewVelocity functions into a simple (well, the latest version is no longer so simple) testing framework. The best solution is the one that gets the job done in the least code, while still remaining understandable. =) --[[User:Darkcanuck|Darkcanuck]] 17:48, 15 July 2009 (UTC)<br />
<br />
: I really like how you frame the problem here. I think I have a solution to getMaxVelocity at [[User:Voidious/Optimal Velocity]]. This seems like a much cooler and cleaner way to deal with this. --[[User:Voidious|Voidious]] 18:14, 15 July 2009 (UTC)<br />
<br />
:: Okay Darkcanuck, I understand. I just finished creating an implementation of the getClosestReachableVelocityToVelocity here: [[Positive/Optimal Velocity]]. I'll try to combine Voidious's getMaxVelocity routine with it and the code above, and post the results. --[[User:Positive|Positive]] 19:11, 15 July 2009 (UTC)<br />
<br />
It seems like it's working. I posted the results here [[Positive/Optimal Velocity]]. Great job Voidious with your getMaxVelocity function! --[[User:Positive|Positive]] 19:37, 15 July 2009 (UTC)<br />
<br />
You guys are truely amazing. Good job! I knew the "update movement" was non-trivial and could be complex when I tried to simplify things and get rid of the "bugs". But now it seems even much more complex. The rules are simple, but the code behind it complex?! I will put take all the code from the [[Positive/Optimal Velocity]] page and put into Robocode. Then I will make a new Alpha version, which everybody could try out to see if this is what we want in the next version of Robococe (1.7.1.4). And yes [[User:Positive|Positive]], your version of updateMovement is better. --[[User:FlemmingLarsen|Fnl]] 21:41, 15 July 2009 (UTC)<br />
<br />
: Yes, great team-work. And.. it's great to feel appreciated. :) Fnl, please include the temporary fix in the getMaxVelocity that was just added (to speed up robots that use setAhead(huge number)). --[[User:Positive|Positive]] 21:50, 15 July 2009 (UTC)<br />
<br />
: Cool! =) --[[User:Voidious|Voidious]] 22:25, 15 July 2009 (UTC)<br />
<br />
Okay, I will make sure the include the temporary fix. If we find a better solution later, I will of course update the code as well.<br />
<br />
'''Notice:''' If you are not a member of the [http://groups.google.com/group/robocode-developers Robocode Developers Discussion Group] then please do not hesitate with joining this group soon. The way you/we won't miss important aspects in our discussions about changes (and new features) in Robocode. --[[User:FlemmingLarsen|Fnl]] 22:07, 15 July 2009 (UTC)<br />
<br />
Ok, so I ran some tests. With both [[Diamond]] and [[SilverSurfer]], in both 1.6.1.4 and 1.7.1.3, I ran 100 seasons of 500-round [[Wave Surfing Challenge 2K6]]. We've banged on the 1.7.1.3 updateMovement code quite a bit now, and clearly it has changes that could affect both True Surfing (decel through 0) and Go-To (velocity selection). However, the results are extremely close (and surprisingly, 5 out of 6 of the scores are higher in 1.7.1.3.)<br />
<br />
{| border="1" style="border-collapse: collapse; font-size: 85%; color: black"<br />
| '''Bot'''<br />
| '''Bot A'''<br />
| '''Bot B'''<br />
| '''Bot C'''<br />
| '''Total'''<br />
|-<br />
| SilverSurfer 2.53.33<br />
| 99.84/99.85<br />
| 91.15/91.04<br />
| 85.77/85.81<br />
| '''92.25'''/'''92.23'''<br />
|-<br />
| Diamond 1.197<br />
| 99.92/99.93<br />
| 98.46/98.48<br />
| 96.94/96.98<br />
| '''98.44'''/'''98.47'''<br />
|}<br />
<br />
I'll be sure to run some more and different tests with the new Alpha, as well.<br />
<br />
--[[User:Voidious|Voidious]] 22:25, 15 July 2009 (UTC)<br />
<br />
Here is the new Alpha-1: http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-1-setup.jar --[[User:FlemmingLarsen|Fnl]] 22:39, 15 July 2009 (UTC)<br />
<br />
Hey Fnl, that last change Positive made at [[Positive/Optimal Velocity]] is an important one. Without it, setMaxVelocity actually doesn't work at all in this Alpha-1. (Tested with [[Jen]], who starts in a stop and go mode, but just moves full speed in the alpha.) <code>Math.min(highestVelocity,8.0)</code> should have <code>currentCommands.getMaxVelocity()</code> instead of 8.0. --[[User:Voidious|Voidious]] 00:04, 16 July 2009 (UTC)<br />
<br />
I just tested it too, and had the same results. --[[User:Positive|Positive]] 00:08, 16 July 2009 (UTC)<br />
<br />
I like this =) Although there still seems to me to be some clean solution that we've all missed, which doesn't involve different cases. Although it may be the tick-based environment that prevents that. However, Murphy be blamed, now that it's too late, I've finally come up with a decelDistance() function that doesn't have a loop:<br />
<pre><br />
private static final double decelDistance(double speed){<br />
double t = speed / Rules.DECELERATION;<br />
double floor_t = Math.floor(t);<br />
return 0.5*floor_t*(floor_t+1)*Rules.DECELERATION + (speed%Rules.DECELERATION)*Math.ceil(t);//used by Skilgannon's solution<br />
//return 0.5*floor_t*(floor_t-1)*Rules.DECELERATION + (speed%Rules.DECELERATION)*Math.ceil(t);//used by Voidious's solution<br />
}<br />
</pre><br />
--[[User:Skilgannon|Skilgannon]] 07:57, 16 July 2009 (UTC)<br />
<br />
Fnl, to save you from looking all over the place, I think the final evolution of the code is at:<br />
* [[Talk:Positive/Optimal Velocity#Hijack =)]] - old decel-through-zero rules<br />
* [[User:Voidious/Optimal Velocity#Hijack 2]] - new decel-through-zero rules<br />
As of now, Darkcanuck has tested the former but not the latter. You can take a look yourself and decide which you want to try in the next Alpha.<br />
<br />
--[[User:Voidious|Voidious]] 16:00, 16 July 2009 (UTC)<br />
<br />
Results for both can be found here: [[Talk:Darkcanuck/VelocityTest]]. I have yet to break either version, but I'll try... --[[User:Darkcanuck|Darkcanuck]] 16:04, 16 July 2009 (UTC)<br />
<br />
The section itself is 48KB now, longer than most pages =) Did we reach the conclusion on old decel-through-zero or new decel-through-zero rules yet? &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:51, 16 July 2009 (UTC)<br />
<br />
Well, that decision really is Fnl's. I don't think we debated it until there was a consensus among the rest of us. Personally, I believe that the effect on current bots will be immeasurably small. I will run some extensive tests to compare the versions, and hopefully the results will support this. (I've got some more of the 1.6.1.4 test runs going already.) --[[User:Voidious|Voidious]] 17:54, 16 July 2009 (UTC)<br />
<br />
Oh, I think he'll choose the new rules. The older conclusion is to makes Robocode follow its own rules better. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 18:09, 16 July 2009 (UTC)<br />
<br />
<br />
Sorry for the bad Alpha-1. The compiler did not see the update (?) I made on the source for the temporary fix. Nevermind, I have made two new alphas to try out:<br />
* [[Talk:Positive/Optimal Velocity#Hijack =)]] - old decel-through-zero rules - [http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-2-setup.jar Download Alpha 2]<br />
* [[User:Voidious/Optimal Velocity#Hijack 2]] - new decel-through-zero rules- [http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-3-setup.jar Download Alpha 3]<br />
<br />
Actually, I am not sure which version I prefer after this long discussion, but it seems to me that the new decel-through-zero rules is more correct. Actually, it was Mathew Nelson who mentioned that it ought to be fixed too, so that was my motivation for adding it. But I will let it up to you guys to decide.<br />
<br />
Btw. Nice job with making the source code smaller with the two Hijack versions.<br />
<br />
--[[User:FlemmingLarsen|Fnl]] 22:54, 16 July 2009 (UTC)<br />
<br />
Thanks, Fnl. I'm going to run quite a few tests with these two and 1.6.1.4 and post results. So far, [[Diamond]] 1.191 vs [[Barracuda]] over 500 battles (35 rounds) is 99.51 in 1.6.1.4 and 99.52 in 1.7.1.4-Alpha 3 -- not a bad start. =)<br />
<br />
I'm planning to test with [[Diamond]], [[Phoenix]], [[DrussGT]], and [[PrairieWolf]] (vs a few other bots). The first 3 because they are likely among the most precise bots out there, Diamond over Dookious because it's the same precision and surfing but twice as fast, and PrairieWolf because I know he has a +1/-1 movement mode. Maybe I should add [[Wintermute]]? If anyone has suggestions on who else I should test with (and maybe why), let me know. I will definitely do some tests with non-surfers, but surfers do seem the most precise and thus the most likely to be affected.<br />
<br />
--[[User:Voidious|Voidious]] 01:19, 17 July 2009 (UTC)<br />
<br />
FYI: From tomorrow and one week forward (week 30) I will be on a summer vacation in a rented summer cottage together with my family. If I am lucky, I will be able to access the Internet from there. But the connection might be slow. I will check out these pages while I am off, but I cannot promise that I will be able to compile everything into a new version, and I need to fix some other issues before I can release a 1.7.1.4 Beta. Until then, have fun with the alphas here. If other issues needs to be addressed as well, then please create a bug report on SourceForge so we can keep track of all issues. :-) --[[User:FlemmingLarsen|Fnl]] 21:56, 17 July 2009 (UTC)<br />
<br />
[[Sanguijuela]] v0.8 is a micro rambot using the Accel/decel trick. Please, let me know if I'm wrong, but as far as I understand, this trick will be inevitable useless in the future at the RoboRumble, right? If this is correct I will remove the trick and upload a new version (with 50 less of codesize :P ) and we will see the impact. Thanks! --[[User:Jab|jab]] 16:02, 13 August 2009 (UTC)<br />
<br />
Well, it depends on the result of the vote. You can vote against removing it, to tie the vote. --[[User:Positive|Positive]] 18:44, 13 August 2009 (UTC)<br />
<br />
Vote? Ok, it could be against my interests but I vote in favor of removing it. :D I read this discussion by chance while I was checking my bots ranking after more than a year and a half so I see the problem: There are many bots out there using the trick and thinking that others are using it. Many bots are not going to be updated... But it is a trick, we took advantage of a robocode bug. I read once about the Teleport bug at the old wiki, it is not similar somehow? but the accel/decel bug seems to be accepted for a long time. Solutions? I think that there are two solutions: Removing the bug (I didn't check if it is already resolved in new versions) and reset the roborumble server and only allows newer versions as roborumble clients, or making this Accel/decel phenomenon part of the official [[Robocode/Game Physics]]. That could be another solution. What do you think? --[[User:Jab|jab]] 21:58, 13 August 2009 (UTC)<br />
<br />
Hey jab, welcome back. =) Always good to have more input on this. No, it's not resolved yet, and there is some testing [[User:Voidious/Robocode Version Tests|here]] and more discussion on that page's [[User talk:Voidious/Robocode Version Tests|talk page]]. It is certainly a grey area and I can see both sides. If I thought the impact on scores would be great, I would be strongly against allowing this change, "bug" or not, but really I don't think that will be the case. You could still "vibrate", just not between 1 and -1 (would end up around -0.7/0.7), and precise prediction would only end up off by a few pixels, at most. --[[User:Voidious|Voidious]] 22:26, 13 August 2009 (UTC)<br />
<br />
It could be as easy as putting it in the official rules. "Vibrating" could be allowed, but it should appear at least in the game physics page. With this condition I could change my vote for keeping the old rules and the code that could be the reason why Sanguijuela is currently the best rambot in the rumble ;-)<br />
<pre><br />
if (changingDirection && Math.abs(getVelocity()) >= 2) {<br />
//Acceleration Trick<br />
setMaxVelocity(0.00001);<br />
} else<br />
</pre><br />
<br />
I think that this option of making it official should be firmly accepted or rejected before trying to find a correct implementation of preventing it.<br />
--[[User:Jab|jab]] 08:59, 14 August 2009 (UTC)</div>Jabhttp://robowiki.net/w/index.php?title=Talk:Robocode/Game_Physics&diff=10416Talk:Robocode/Game Physics2009-08-13T22:02:19Z<p>Jab: /* Accel/decel rules */</p>
<hr />
<div>__TOC__<br />
== Robot hitbox ==<br />
I need to know percisely, which might involve rotating a rectangle, I don't know, if a point intersects my bot, given its X and Y location. Remeber that in Robocode, Y is reversed. While I'm at it, I might just ask: What your opinion is on whether I should do surfing or anti-gravity movement to dodge predicted bullets my robot simulates?<br />
--[[User:Awesomeness|Awesomeness]] 21:52, 3 May 2009 (UTC)<br />
<br />
The 'hitbox' of a robot is always a non-rotated square at the bot's location, so the former check is very very simple. As for your second question: It depends. Surfing is going to be stronger almost surely, however anti-gravity movement is considerably simpler. My suggestion would be to do anti-gravity for now, and at a later date try surfing once you feel comfortable with exactly how it works. --[[User:Rednaxela|Rednaxela]] 22:01, 3 May 2009 (UTC)<br />
<br />
Oh, is it a 40 pixel long sqare? that's what it looks like. --[[User:Awesomeness|Awesomeness]] 22:43, 3 May 2009 (UTC)<br />
<br />
No, it is 36px non-rotating square. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 23:42, 3 May 2009 (UTC)<br />
<br />
== Gun turn and fire execution order ==<br />
<br />
When, in the execution order, are bullets fired, and when is the gun turned? Thanks! --[[User:Mageek|Mageek]] 02:44, 28 May 2009 (UTC)<br />
<br />
I believe that's part of #2 in the "Robocode Processing Loop" section. I can tell you for sure, though, that if you do setFire and setTurnGunRight in the same turn, the bullet will fire at the bearing of your gun ''before'' that gun turn happens. Both of them happen on the next tick, but the bullet is fired as if it were fired on the same tick as setFire (the location is from that tick, and it has advanced by its velocity once). Does that answer your question? --[[User:Voidious|Voidious]] 02:53, 28 May 2009 (UTC)<br />
<br />
Thank-you, that is exactly what I was trying to figure out. --[[User:Mageek|Mageek]] 03:39, 28 May 2009 (UTC)<br />
<br />
== Accel/decel rules ==<br />
<br />
(Conversation began on [[Talk:Darkcanuck/RRServer]]...)<br />
<br />
I've almost finished my first robot to enter to the melee rumble :), but I'm wondering: does the (melee)server use the old accel/decel rules (where you can go from -1 to 1) or the new (where you can't)? --[[User:Positive|Positive]] 23:22, 11 Jul 2009<br />
<br />
The RoboRumble currently only allows clients using versions 1.5.4, 1.6.0, and 1.6.1.4, so it should only be the old rule (where you can). I actually didn't realize that was changed -- I really don't like that. =( Lots of legacy bots are programmed to believe you can. --[[User:Voidious|Voidious]] 21:24, 11 July 2009 (UTC)<br />
<br />
Woah, what a quick response! Thanks for the info. :) I don't really like the change either (I have a cool -1, +1 strategy and a nice move simulator), but alas. --[[User:Positive|Positive]] 23:36, 11 Jul 2009<br />
<br />
Are you sure the rules have changed? I thought the only changes to movement in later versions of Robocode (still unsupported in the rumble, btw) were to fix the movement quirks that Simonton had found. I don't remember decelerating through 0 being one of them. --[[User:Darkcanuck|Darkcanuck]] 22:26, 11 July 2009 (UTC)<br />
<br />
Here is the [http://sourceforge.net/tracker/?func=detail&aid=2793464&group_id=37202&atid=419486 discussion at the bug tracker]. Fnl explains that if for example your robot is at -1.0 velocity, it can only reach 0.75 velocity the next turn (as of version 1.7.1.2). --[[User:Positive|Positive]] 02:45, 12 Jul 2009<br />
<br />
Errr.... 0.75 is not 'accurate'... It's what robocode as of 1.7.1.2 does, but it's just as incorrect as before the change... Fnl says it uses a formula of <code>(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION *<br />
accelTime * accelTime)</code>, when the correct formula should be <code>(Rules.DECELERATION * decelTime + Rules.ACCELERATION * accelTime)</code>. Change in velocity, is always equal to acceleration multiplied by time, not time squared... It looks like Fnl got his physics mixed up and looked at a formula to get distance from acceleration (<code>d = a*t*t</code>) instead of getting velocity change from acceleration (<code>v = a*t</code>) :-( --[[User:Rednaxela|Rednaxela]] 01:47, 12 July 2009 (UTC)<br />
<br />
: Ooh, I see this now... Do some tests and file a bug for [[Fnl]]? --[[User:Darkcanuck|Darkcanuck]] 02:48, 12 July 2009 (UTC)<br />
<br />
:: Robocode Developer Google Groups, I think. So Flemming can re-open that tracker instead of creating new one. I always wonder why it go from 1 to -0.75, not 0.5 since it have only half turns left, I always think that I don't have enough physics knowledge. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 02:59, 12 July 2009 (UTC)<br />
<br />
Voidious, do you subscribe to [http://groups.google.com/group/robocode-developers Robocode Developer Google Groups]? I think we have reached the conclusion that we worth this change, unless there are too many effects. After we changed it, Flemming and I did run a lot of test (well, mostly Flemming run, I'd run only one test). I've test [[Dookious]] with [[DrussGT]], on both 1.6.1.4 and 1.7.1.x with new updateMovement(), and the difference is around 1-2%, which is acceptable in margin of error. I chose Dookious and DrussGT because I know that Dookious use FuturePosition library, which is the internal copy of old movement engine. And DrussGT use Skilgannon's special movement predictor which I believe should be the loosely implementation of the 'correct' movement engine.<br />
<br />
Positive, I believe that if you create a good movement under 1.6.1.4, it will be good in 1.7.1.x version too. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:20, 12 July 2009 (UTC)<br />
<br />
- - -<br />
<br />
Hi guys, to you mind I join the discussion? I did the change in "update movement" for many reasons. The issue(s) were raised a long time ago on the old RoboWiki (the 3 caveats raised by Simonton - http://old.robowiki.net/cgi-bin/robowiki?GamePhysics/BotSpeed), and later discussed within the Robocode Developer Group (even Mathew Nelson joined the discussion). That is, if we would make the change or not. Especially with you guys in mind. The conclusion in the groups was to fix the bugs so Robocode would follow its own rules, and because lot's of robots out there counts on the rules as explained, not to the way Robocode was actually behaving. Not everybody replicates the internal code of Robocode to get the formulas correct.<br />
<br />
The old closed bug tracker on SF created is available here: https://sourceforge.net/tracker/?func=detail&atid=419486&aid=2077512&group_id=37202<br />
<br />
Another goal with the change was to make the internal code easier less messy and easier to understand. Regarding the impact of the change, the results are not very different (unless you can prove me wrong here). I ran lots of lots of test with RoboRumble (also Melee and TeamRumble) on my local machines (different single-code, quad-core, Linux, Windows, 32 and 64 bit etc.), and I couldn't tell the difference in rankings or score with or without the change. There was a difference, but it was in average less than 1 percent. Is it really that much of a problem? Really?<br />
<br />
I would really love if people could try out the Betas on RoboRumble and put issues on SF as soon as they are discovered. Then the issues can be fixed or discussed before we do the real release. This way, we could avoid such issues as this one long time after the change was made and released.<br />
<br />
Btw. I am very familiar with physics, even tough the physics in Robocode does not really follow the real physics laws. I might not have explained the details about the fix well enough. <br />
<br />
Instead of shifting between old and new code (like you propose?), I should like you guys to tell me where the problem is in the code instead, since you are obviously the experts. The code is Open Source, so everybody is free to come with suggestions to what and where to correct things.<br />
<br />
Here we go:<br />
<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (dx != 0 || dy != 0) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
// If the distance is negative, then change it to be positive and change the sign of the input velocity and the result<br />
if (distance < 0) {<br />
return -getNewVelocity(-velocity, -distance);<br />
}<br />
<br />
double newVelocity;<br />
<br />
// Get the speed, which is always positive (because it is a scalar)<br />
final double speed = Math.abs(velocity); <br />
<br />
// Check if we are decelerating, i.e. if the velocity is negative.<br />
// Note that if the speed is too high due to a new max. velocity, we must also decelerate.<br />
if (velocity < 0 || speed > currentCommands.getMaxVelocity()) {<br />
// If the velocity is negative, we are decelerating<br />
newVelocity = speed - Rules.DECELERATION;<br />
<br />
// Check if we are going from deceleration into acceleration<br />
if (newVelocity < 0) {<br />
// If we have decelerated to velocity = 0, then the remaining time must be used for acceleration<br />
double decelTime = speed / Rules.DECELERATION;<br />
double accelTime = (1 - decelTime);<br />
<br />
// New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d<br />
// However, the new velocity must be limited by the max. velocity<br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,<br />
distance));<br />
<br />
// Note: We change the sign here due to the sign check later when returning the result<br />
velocity *= -1;<br />
}<br />
} else {<br />
// Else, we are not decelerating, but might need to start doing so due to the remaining distance<br />
<br />
// Deceleration time (t) is calculated by: v = a * t => t = v / a<br />
final double decelTime = speed / Rules.DECELERATION;<br />
<br />
// Deceleration time (d) is calculated by: d = 1/2 a * t^2 + v0 * t + t<br />
// Adding the extra 't' (in the end) is special for Robocode, and v0 is the starting velocity = 0<br />
final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;<br />
<br />
// Check if we should start decelerating<br />
if (distance <= decelDist) {<br />
// If the distance < max. deceleration distance, we must decelerate so we hit a distance = 0<br />
<br />
// Calculate time left for deceleration to distance = 0<br />
double time = distance / (decelTime + 1); // 1 is added here due to the extra 't' for Robocode<br />
<br />
// New velocity (v) = a * t, i.e. deceleration * time, but not greater than the current speed<br />
<br />
if (time <= 1) {<br />
// When there is only one turn left (t <= 1), we set the speed to match the remaining distance<br />
newVelocity = Math.max(speed - Rules.DECELERATION, distance);<br />
} else {<br />
// New velocity (v) = a * t, i.e. deceleration * time<br />
newVelocity = time * Rules.DECELERATION;<br />
<br />
if (speed < newVelocity) {<br />
// If the speed is less that the new velocity we just calculated, then use the old speed instead<br />
newVelocity = speed;<br />
} else if (speed - newVelocity > Rules.DECELERATION) {<br />
// The deceleration must not exceed the max. deceleration.<br />
// Hence, we limit the velocity to the speed minus the max. deceleration.<br />
newVelocity = speed - Rules.DECELERATION;<br />
}<br />
}<br />
} else {<br />
// Else, we need to accelerate, but only to max. velocity<br />
newVelocity = Math.min(speed + Rules.ACCELERATION, currentCommands.getMaxVelocity());<br />
}<br />
}<br />
<br />
// Return the new velocity with the correct sign. We have been working with the speed, which is always positive<br />
return (velocity < 0) ? -newVelocity : newVelocity;<br />
}<br />
</pre><br />
<br />
What must be corrected in order to make everybody happy, following the "physic laws" and rules of Robocode? --[[User:FlemmingLarsen|Fnl]] 22:59, 12 July 2009 (UTC)<br />
<br />
Fnl, it will take me some time to look over the code and discussions before I can give more constructive feedback. But some things I can comment on for now:<br />
* Fixing the issues Simonton brought up seems very reasonable to me. One is a bug that I doubt anyone depends on (the setMaxVelocity / decel). For the others, I'd guess [[DrussGT]] and [[SilverSurfer]] are the only bots that might simulate the quirks (being Go-To surfers). Some [[Wave Surfing Challenge]] tests with SS (I will run some) and feedback from Skilgannon could shed some light on potential impact.<br />
* I'm not clear on what has happened with this, but I believe changing the ability to go from velocity 1 to -1 could adversely impact a lot of bots. Even a bot as old as [[PrairieWolf]] (2002) has a movement mode that depends on it ("buzzing" between 1 and -1), and I'd guess nearly every modern wave surfer also simulates this aspect of the physics.<br />
* One percent ''is'' a lot -- see the "huge" 1% APS gap between DrussGT and Dookious =). That said, it takes hundreds or thousands of battles to get a result accurate enough to see that 1% difference.<br />
* I do not envy your position in these types of matters, and as always, I appreciate the effort you put into developing Robocode. Robocode's impact goes far beyond the "hardcore" Robocoders on this wiki, and I fully understand that you want to polish Robocode as best as you can for the benefit of everyone that uses it. Cheers,<br />
--[[User:Voidious|Voidious]] 00:01, 13 July 2009 (UTC)<br />
<br />
: 1 percent is ''not'' a lot with this major change in physics, especially when it makes the game follows its own rule better. 1% is 'huge' in APS, I agree. But if you look at each battle closely, the results can swing up to 10% &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
<br />
:: 1% is 1% and it ''is'' a lot. You're right that individual battles have a large variance, that's why you need to run hundreds of battles to get a meaningful result. If you run enough battles to get a statistically accurate result, 1% is a lot. If you don't run enough battles, you can't draw any real conclusion from the results. <br />
:: I'm not claiming there is a 1% difference in results. I'm only saying that if tests only narrowed it down to "1% or less", that's not really enough to satisfy my need for accuracy and consistency. No ill will here, I should get involved and run some tests if I care so much. And I do. And I will. =)<br />
:: --[[User:Voidious|Voidious]] 17:40, 13 July 2009 (UTC)<br />
<br />
::: While I wat to argue that 1% is ''not'' a lot for this major physics change, I don't think that is an issue anymore. I think you already accept the changes now =) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:37, 14 July 2009 (UTC)<br />
<br />
I've read the mailing list and bug report concerning the issue. Does the -1, +1 thing really need to be changed to fix the bugs? This is how I would code it, and I believe it should fix the bugs. I haven't actually compiled it into robocode, but the velocity routines themselves have been tested and are working. And excuse me, I'm a bad commenter :):<br />
<br />
<pre><br />
<br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
// small tweak from original version<br />
if(velocity!=0)<br />
{<br />
x+=velocity * sin(bodyHeading);<br />
y+=velocity * cos(bodyHeading);<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
static double getNewVelocity(double velocityArg, double distanceArg) <br />
{ <br />
double velocity;<br />
double distance;<br />
<br />
// Make sure the remaining distance is always positive or zero<br />
// (we switch this back later)<br />
if(distanceArg<0)<br />
{<br />
velocity=-velocityArg;<br />
distance=-distanceArg;<br />
}<br />
else<br />
{<br />
velocity=velocityArg;<br />
distance=distanceArg;<br />
}<br />
<br />
// Get the next most positive velocity the robot can reach for next turn<br />
double mostPositiveReachableVelocity = VelocityToMostPositiveVelocity(velocity);<br />
// Get the next most negative velocity the robot can reach for next turn<br />
double mostNegativeReachableVelocity = VelocityToMostNegativeVelocity(velocity);<br />
<br />
<br />
double highestWantedVelocity = Math.min(currentCommands.getMaxVelocity(), maxSpeedToStopInDisp(distance));<br />
<br />
// The real next velocity is limited by what is actually reachable<br />
double nextVelocity = Math.min(mostPositiveReachableVelocity,Math.max(mostNegativeReachableVelocity,highestWantedVelocity ));<br />
<br />
// Switch return value back if needed<br />
if(distanceArg<0)<br />
nextVelocity = -nextVelocity;<br />
<br />
return nextVelocity;<br />
}<br />
<br />
<br />
static public double VelocityToMostPositiveVelocity(double velocity)<br />
{<br />
// Returns the most positive reachable velocity from the<br />
// specified velocity in one turn<br />
if(velocity>0)<br />
{<br />
double returnVelocity = velocity+Rules.ACCELERATION;<br />
if(returnVelocity>Rules.MAX_VELOCITY)<br />
return Rules.MAX_VELOCITY;<br />
else<br />
return returnVelocity;<br />
}<br />
else<br />
{<br />
double returnVelocity = velocity+Rules.DECELERATION;<br />
if(returnVelocity>Rules.ACCELERATION)<br />
return Rules.ACCELERATION;<br />
else<br />
return returnVelocity;<br />
}<br />
}<br />
static public double VelocityToMostNegativeVelocity(double velocity)<br />
{<br />
// Returns the most negative reachable velocity from the<br />
// specified velocity in one turn<br />
if(velocity<0)<br />
{<br />
double returnVelocity = velocity-Rules.ACCELERATION;<br />
if(returnVelocity<-Rules.MAX_VELOCITY)<br />
return -Rules.MAX_VELOCITY;<br />
else<br />
return returnVelocity;<br />
}<br />
else<br />
{<br />
double returnVelocity = velocity-Rules.DECELERATION;<br />
if(returnVelocity<-Rules.ACCELERATION)<br />
return -Rules.ACCELERATION;<br />
else<br />
return returnVelocity;<br />
}<br />
}<br />
<br />
static private final double[] dispStopArray = <br />
{0.0000,1.0000,2.0000,2.5000,3.0000,<br />
3.5000,4.0000,4.3333,4.6666,5.0000,<br />
5.3333,5.6666,6.0000,6.2500,6.5000,<br />
6.7500,7.0000,7.2500,7.5000,7.7500};<br />
static public double maxSpeedToStopInDisp(double displacement)<br />
{<br />
// Returns the biggest velocity the robot could go to this turn,<br />
// still being able to stop without overshooting. (Or if <br />
// remaining displacement is less than 2, returns that)<br />
// This routine could be improved to match up with robocode's<br />
// older velocity selecting rules.<br />
if(displacement>=0)<br />
{<br />
if(displacement>=20)<br />
return 8.0;<br />
else if(displacement<=2)<br />
return displacement;<br />
else<br />
return dispStopArray[(int)Math.floor(displacement)];<br />
}<br />
else<br />
{<br />
return 0;<br />
}<br />
}<br />
</pre><br />
I also appreciate your effort, Fnl. :) --[[User:Positive|Positive]] 01:48, 13 July 2009 (UTC)<br />
<br />
Ok, I'm up to speed with the discussions and the code. I think, for how it was decided, this line:<br />
<pre><br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,<br />
distance));<br />
</pre><br />
...should be changed to:<br />
<pre><br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.ACCELERATION * accelTime, distance));<br />
</pre><br />
* The deceleration already takes you to zero, so we just need to use the remaining time for acceleration, right?<br />
* Don't need to square the accelTime (v = at).<br />
<br />
So, as I understand it, your velocities should be, for example: -1, +0.5, -0.75, +0.625? "Legacy" issues aside, I like this solution a lot. It makes sense. I've been considering this issue a bit now, and here's how I'd lay out the impact to affected bots:<br />
* A bot like [[PrairieWolf]] that oscillates between 1 and -1 will now oscillate between roughly 0.7 and -0.7. I'm ''guessing'' this has very minimal impact on performance (though I am curious to test / confirm).<br />
* When Wave Surfers predict a change of direction, their predictions could be off. I believe most surfers are dealing with whole number velocities the great majority of the time. Changing direction from even velocities will not be impacted. Changing direction from odd velocities, their predictions could be off by as much as 4 pixels -- predicting a velocity 0.5 too high for 8 ticks (until they reach max velocity). Some might disagree, and of course I advocate ultimate precision in surfing, but I believe the impact here is negligible. (How many of us even do precise bot width? And I never found much to be gained there, anyway.)<br />
* I'm still not crazy about changing Robocode's physics, and I might've opposed it if put to a vote, but I think the impact is negligible and the new solution is a good one. <br />
<br />
Also, I've started running those [[SilverSurfer]] WSC tests on 1.6.1.4 and 1.7.3 to compare. I'll have the results today or tomorrow.<br />
<br />
--[[User:Voidious|Voidious]] 15:31, 13 July 2009 (UTC)<br />
<br />
: The information in Robocode (mostly the floating point value) isn't digital, means that only 0.5 change isn't impact ''much''. If you can dodge bullets well, the missed 2 ticks with the most of 2 pixels won't make the bullet hit you. If you can't dodge it, the slippage of 2 pixels ''may'' make you dodged it, but only by luck. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
<br />
<Edit conflict> Thanks for taking a look Fnl. I personally think that the current code is more complicated than necessary, and as such, harder to understand. Here's a few things that should be addressed:<br />
* The decelDist. Because robocode follows a discrete time base, it cannot be approximated with calculus. For example, say your speed is 3, your formula gives 3.75 as decelDist. However, 3 + 1 + 0 = 4, so your code would not want to decelerate in the right places. This would be the correct implementation:<br />
<pre><br />
private static final double decelDistance(double velocity){<br />
double distance = 0;<br />
while(velocity > 0){<br />
distance += velocity;<br />
velocity = Math.max(0,velocity - Rules.DECELERATION);<br />
}<br />
return distance;<br />
}<br />
</pre><br />
* One of the ideas of robocode is that your bot has a continuous acceleration/deceleration over a single tick. I see what you have done is, when a bot is decelerating over 0 velocity, it takes 1/2 of the tick to decelerate and then 1/2 of the tick is left to accelerate in the other direction (the split may depend on the amount of time taken to decelerate to 0 first). But many older bots rely on being able to decelerate over the entire tick, using the 2 deceleration value instead of the 1 acceleration value, so that they can 'vibrate' from 1 to -1 back to 1 etc. While I agree that it is not correct, these are the physics of robocode, not real life =) Because of this, you can essentially remove the majority of the inside of that 'if' block, just leaving <code>velocity *= -1;</code>.<br />
* I have re-written this method, and if people want I'll post it, but it seems that with a few quick fixes this one should be up to scratch =), so I don't really think that's necessary.<br />
<br />
As an answer to [[Voidious]], I haven't taken any of the 'quirks' into account while writing DrussGT. It is coded with the rules, as they are described on the [[Robocode/Game_Physics]] page, in mind. --[[User:Skilgannon|Skilgannon]] 16:00, 13 July 2009 (UTC)<br />
<br />
: (edit conflict) In my tests, DrussGT usually performs worse. But just around 0.2% or somethings. I'm not sure since I ran only 3 35-rounds tests.<br />
: While I agree with you that this isn't real life, it still isn't correct under its own Rules. The major reason we have this fix is that we want Robocode to follows its own rule batter. Otherwise we should have the bullet velocity affected by robot velocity, the curved bullet, better bullet-bullet collision checking etc. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
:: Sorry, but 3 battles simply cannot produce a result within 0.2% accuracy. In my experience, you'd need 100 or more before the overall result stays within 0.2%. --[[User:Voidious|Voidious]] 17:40, 13 July 2009 (UTC)<br />
<br />
Hi guys. Thank you for the constructive feedback. I appreciate that. I see many of you have some really good pointer of what to change, and where to make the changes. Currently, I have my house full of guests and is just checking what is going on in this forum. Tomorrow evening, I will take a closer look at all the comments, and I agree that the new implementation for "update movevement" is buggy too. I intend to create some variants that you can download and test for yourselves. Afterwards, you can choose which one is the better one for the next version of Robocode.<br />
Compared to 1.6.x.x, the code has become much simpler than it was before. I am not sure that the code could be any simpler than it is now as we will brake something else (because something is missing) - even though I hope it is possible.<br />
So, tomorrow I will review all comment on this page and take action. =) --[[User:FlemmingLarsen|Fnl]] 17:43, 13 July 2009 (UTC)<br />
<br />
I really agree that the code is a lot more simple and adaptable than 1.6 and before. When I was adapting the internal Robocode's movement engine for my movement predictor, I can't adapt the <1.6 code. I get my head mess when I'm trying to understand it. However, I can adapt the current code really easy (in fact, I did copy almost whole getNewVelocity() method) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:37, 14 July 2009 (UTC)<br />
<br />
I have examined all the comments here, and is trying to figure out how to modify the existing code for getNewVelocity(). I think you are on the right track [[Voidious]], and hence I want to implement your modifications so we could all try them out. However, I have a hard time figuring out how the modified version of getNewVelocity() will look like. If a change the part for the newVelocity, it must be in the two places in the code, where it is assigned. You have only written how you want the first one. [[Voidious]], could you give the full version of your version of getNewVelocity() as you think it should be? This way we all will be able to follow (and discuss) the changes/ideas, and I will be able to implement it straight away. :-) --[[User:FlemmingLarsen|Fnl]] 22:28, 14 July 2009 (UTC)<br />
<br />
Sorry, I was only closely examining the decelerating through zero issue before. I agree with Skilgannon's assessment that decelDist doesn't seem right, though I'm not sure I'm understanding this fully. Skilgannon, you say that decelDist(3) should be 4, but shouldn't it be 1, since we can update the speed before we move? In either case, I don't understand why it would be 3.75, but I'm curious if there is some voodoo at work in this code that I'm not getting yet. I'll study some more and try to figure it out. =) <br />
<br />
And Skilgannon, no harm in posting your rewritten version, I wouldn't mind seeing it. I'll also check out Positive's version. And I'll have some 1.6.1.4 vs 1.7.1.3 [[Wave Surfing Challenge 2K6|WSC2K6]] scores ready to examine tomorrow. Only about 180 more seasons to run. =)<br />
<br />
--[[User:Voidious|Voidious]] 00:23, 15 July 2009 (UTC)<br />
* My understanding (and subsequently, DrussGT's movement simulator, which uses a decelDistance based method of deciding when to decelerate) is if we go with the velocity of 3 this tick, how far will we travel in total if we decide it's necessary to decelerate next tick. ''Basically, do we have freedom with to do as we please with our velocity this tick, and still be able to decelerate sufficiently in the future''. If the answer is "no", then we need to decelerate ''or'' maintain velocity this tick. My statements about 4 and 3.75 assumed the DECELERATION is 2. Fnl gets 3.75 from this little bit of code:<br />
<pre><br />
final double decelTime = speed / Rules.DECELERATION;<br />
final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;<br />
</pre><br />
: ie. <code>3/2 = 1.5 --> 0.5*2*1.5*1.5 + 1.5 = 3.75</code> whereas it should be <code>3 + (3-2) = 4</code>. I'll be very interested to see what the scores look like =) --[[User:Skilgannon|Skilgannon]] 08:59, 15 July 2009 (UTC) <br />
<br />
Wow, this problem really is not trivial. Here's what I came up with, I think it works and is pretty minimal:<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (dx != 0 || dy != 0) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
// If the distance is negative, then change it to be positive and change the sign of the input velocity and the result<br />
if (distance < 0) {<br />
return -getNewVelocity(-velocity, -distance);<br />
}<br />
<br />
double newVelocity;<br />
<br />
// Get the speed, which is always positive (because it is a scalar)<br />
final double speed = Math.abs(velocity); <br />
<br />
if (velocity < 0) {<br />
// Check if we are decelerating, i.e. if the velocity is negative.<br />
newVelocity = speed - Rules.DECELERATION;<br />
<br />
// Check if we are going from deceleration into acceleration<br />
if (newVelocity < 0) {<br />
// If we have decelerated to velocity = 0, then the remaining time must be used for acceleration<br />
double decelTime = speed / Rules.DECELERATION;<br />
double accelTime = (1 - decelTime);<br />
<br />
// New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d<br />
// However, the new velocity must be limited by the max. velocity<br />
newVelocity = Math.min(Rules.ACCELERATION * accelTime, distance));<br />
<br />
// Note: We change the sign here due to the sign check later when returning the result<br />
velocity *= -1;<br />
}<br />
} else {<br />
// Deceleration distance (d) is calculated iteratively due to Robocode's<br />
// discrete time system.<br />
final double decelDist = decelDistance(speed);<br />
<br />
// Deceleration ticks is the number of ticks it will take to get to<br />
// zero velocity. <br />
final long decelTime = Math.round( // VOIDIOUS: for rounding errors? maybe unnecessary<br />
Math.ceil((speed - Rules.DECELERATION) / Rules.DECELERATION));<br />
<br />
// The maximum distance coverable with an equivalent decelTime<br />
final double decelTimeMaxDist = ((decelTime + 1) / 2.0) * decelTime // sum of 1..decelTime<br />
* Rules.DECELERATION;<br />
<br />
if (distance <= Rules.DECELERATION) {<br />
// If we can cover remaining distance and then completely stop,<br />
// set speed = distance<br />
newVelocity = Math.max(speed - Rules.DECELERATION, distance);<br />
} else if (distance <= decelTimeMaxDist) {<br />
// If we can cover distance in decelTime, split any extra<br />
// distance (between decelDist and distance) over decelTime<br />
// ticks<br />
newVelocity = speed - Rules.DECELERATION + <br />
((distance - decelDist) / decelTime);<br />
} else {<br />
// If we need more than decelTime ticks, try to spread the<br />
// extra distance over (decelTime + 1) ticks. This will just max <br />
// the acceleration if it needs to (ie, if we need more ticks).<br />
// VOIDIOUS: I think this part would break if Rules.ACCELERATION<br />
// were set above Rules.DECELERATION; we might need an <br />
// extra case or something. Doh. =(<br />
newVelocity = Math.min(speed + Rules.ACCELERATION,<br />
(decelTime * Rules.DECELERATION) +<br />
((distance - decelTimeMaxDist) / (decelTime + 1)));<br />
}<br />
}<br />
<br />
// VOIDIOUS: I think it makes more sense to do this here; no need to decelerate maximally<br />
// if you don't need to to accomodate a new setMaxVelocity.<br />
newVelocity = Math.max(speed - Rules.DECELERATION, <br />
Math.min(newVelocity, currentCommands.getMaxVelocity()));<br />
<br />
// Return the new velocity with the correct sign. We have been working with the speed, which is always positive<br />
return (velocity < 0) ? -newVelocity : newVelocity;<br />
}<br />
<br />
private static final double decelDistance(double speed){<br />
double distance = 0;<br />
while(speed > 0){<br />
speed = Math.max(0,speed - Rules.DECELERATION);<br />
distance += speed;<br />
}<br />
return distance;<br />
}<br />
</pre><br />
Velocity is updated before the bot moves, right? =) This is a serious brain teaser! Wanted to post what I had before bed, but I'm still not satisfied with the part that would break with different accel/decel values. --[[User:Voidious|Voidious]] 05:06, 15 July 2009 (UTC)<br />
<br />
(maybe we should move this lengthy discussion to another page?)<br />
I've been going through the new velocity formula and have similar concerns as [[Skilgannon]]. Just running some test cases using my [[Darkcanuck/VelocityTest | VelocityTest]] class and have found cases where the bot overshoots the requested distance (e.g. try starting velocity 0, distance 6 -- the bot ramps up to velocity 3 and will thus overshoot badly). I'll put together some tests and then maybe make a fixed version of the routine.<br />
<br />
Regarding deceleration through 0, I have to sympathize with Fnl et al. There's nothing in the rules that says a bot can decelerate through 0 and gain some free acceleration. Deceleration takes you towards 0, acceleration takes you away from it. It's a quirk -- often called a "bug" -- that was perhaps first publicized [http://oldtestwiki.roborumble.org/cgi-bin/robowiki?GamePhysics here] (near bottom) and has been exploited since. Its not a huge quirk, the advantage is minimal so fixing it should also be minimal but only tests can really confirm this.<br />
<br />
--[[User:Darkcanuck|Darkcanuck]] 05:09, 15 July 2009 (UTC)<br />
<br />
Hey Fellas. Great you're doing more research into this! I think the -1, +1 thing is not a major issue, but if the incorrect movement handling bugs can be fixed in a way that the -1, +1 thing stays valid, is there any harm? I think the version I posted is simpler to understand, and it should work effectively. The only thing that you might not agree with is the working of the maxSpeedToStopInDisp function, but that should at least centralize the problem. :) --[[User:Positive|Positive]] 05:53, 15 July 2009 (UTC)<br />
<br />
: I'm sorry I haven't examined yours more. There are two reasons, really:<br />
:* It does look like you're solving the problem efficiently (and I assume correctly), but I think it depends on fixing one or all of Rules.DECELERATION, Rules.ACCELERATION, and maximum velocity=8. I think we want a solution independent of those values.<br />
:* I find this quite an enjoyable brain teaser, and just wanted to figure out an answer myself. =)<br />
:--[[User:Voidious|Voidious]] 13:26, 15 July 2009 (UTC)<br />
<br />
: I did test your solution and it passes all the same tests that Voidious' version 2 does. But as he pointed out, the hardcoded values are problematic. --[[User:Darkcanuck|Darkcanuck]] 17:48, 15 July 2009 (UTC)<br />
<br />
The reason I don't like breaking the +-1 thing is because it makes the precise prediction significantly more complicated, and what's more it assumes that the acceleration has more than one value between 2 ticks, which to me seems to break the whole concept of a discrete time interval. For interests sake, here's the one I wrote:<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (velocity != 0 ) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
<br />
if (distance < 0) <br />
return -getNewVelocity(-velocity, -distance);<br />
// If the distance is negative, then change it to be positive<br />
// and change the sign of the input velocity and the result<br />
<br />
double maxVel = currentCommands.getMaxVelocity();<br />
if (velocity < 0)<br />
return Math.min(velocity + Rules.DECELERATION, maxVel);<br />
//we want to go in the opposite direction, so decelerate <br />
<br />
else{ <br />
//we are going in the direction we want, test what happens if we accelerate<br />
<br />
double accel = Math.min(Rules.ACCELERATION, maxVel - velocity);<br />
//speed up, but not more than max velocity. decel if maxVel is less than velocity.<br />
<br />
accel = Math.max(accel, -Rules.DECELERATION);<br />
//prevent excess deceleration due to bot lowering the maxVel while velocity is high<br />
<br />
if (distance > decelDistance(velocity + accel))<br />
return velocity + accel;<br />
else if(accel != 0 && distance > decelDistance(velocity))<br />
return velocity;<br />
else{<br />
if(distance < Rules.DECELERATION <br />
//we'll be able to cover remaining distance in 1 tick and then decel to stop<br />
<br />
&& velocity - distance <= Rules.DECELERATION <br />
//and our velocity is low enough for us to get to that required velocity<br />
)<br />
return Math.min(distance, maxVel);<br />
//choose the velocity to cover all remaining distance <br />
<br />
return Math.max(-maxVel, velocity - Rules.DECELERATION);<br />
//velocity > 0 and we are close enough, so decelerate. <br />
}<br />
<br />
}<br />
<br />
}<br />
/**<br />
* Returns the linear distance it would take to decelerate from a given positive velocity<br />
*<br />
* @param velocity the positive velocity from which to test<br />
* @return the linear distance required to decelerate to a standstill<br />
*/<br />
private static final double decelDistance(double velocity){<br />
double distance = 0;<br />
while(velocity > 0){<br />
distance += velocity;<br />
velocity = Math.max(0,velocity - Rules.DECELERATION);<br />
}<br />
return distance;<br />
} <br />
</pre><br />
I'm fairly sure this fixes the 0,6 test Darkcanuck is doing. Voidious, one of the problems with your decelDistance() implementation is that your decel distance assumes you decelerate before adding the distance, whereas mine checks if we can still accelerate this tick and be able to decelerate sufficiently in the future. Also, mine considers the case of continuing at the current velocity, which may be a better option, as in the 0,6 test. --[[User:Skilgannon|Skilgannon]] 08:27, 15 July 2009 (UTC)<br />
<br />
: I agree that the new formulas do break the simplicity of the discrete time period. One simple solution would be simply to apply deceleration until 0 velocity is reached -- the extra time for acceleration would be lost. That would both follow the rules and keep the accel/decel values simple. But Fnl's solution does compromise by giving back the extra time for some acceleration, which should help bots that rely on this quirk. --[[User:Darkcanuck|Darkcanuck]] 16:29, 15 July 2009 (UTC)<br />
<br />
(I agree about moving this to a different or its own page. Anyone can feel free, or I'll do it in a bit.) Ah, I'm just imagining a different significance to decelDist: I imagine it as the minimum distance we would cover if we slam on the brakes. The problem with the (0, 6) case (more specifically the (2, 3) case) in mine is similar to the problem I theorize about when Rules.accel is greater than Rules.decel: I assume that if you can't cover ''distance'' in decelTime ticks, you can split the extra distance over (decelTime + 1) ticks, which of course is 1 tick and you go to speed 3. Maybe I should force decelTime to a min of 1, since if it's 0 and distance <= Rules.decel, we hit the first case and don't use it, otherwise we hit the 3rd case and need 2 ticks.<br />
<br />
Mine would also remain at constant velocity if needed, or even speed up a bit, despite lack of a special case. I'll have to investigate that 0 to -2 acceleration... hopefully that's a simple fix. <br />
<br />
I forgot that you'd already be familiar with this kinda stuff, since you are the Lord of Go-To. =) But I still see a problem with yours in that you restrict your decisions to max accel, constant, or max decel. Take the v=6.1, d=15 case: you want to do it in 4 ticks, and mine will (I think =)) go 6.75, 4.75, 2.75, 0.75. I think yours would go 6.1, 4.1, then be presented with (4.1, 4.8) and fail to do it in 4 ticks.<br />
<br />
I swear there must be a known Dynamic Programming problem that reduces to this. Maybe my effort would be better spent finding it and copying the established solution. =) To be clear, we are trying to do this in the optimal number of ticks, right?<br />
<br />
--[[User:Voidious|Voidious]] 13:26, 15 July 2009 (UTC)<br />
<br />
* Yep, what we are attempting to do is minimize number of ticks until velocity and distance are 0. The implementation I have in DrussGT is a highly simplified version of what I posted, and probably runs about 10 times faster =) --[[User:Skilgannon|Skilgannon]] 7:57, 16 July 2009 (UTC)<br />
<br />
I updated my method and posted it to [[User:Voidious/Optimal Velocity]]. I think this fixes both the (2, 3) case and the (0, 2) case, though I feel like the (2, 3) case should go 2/1 instead of 1.5/1.5. Can we agree that Rules.DECELERATION will never be less than Rules.ACCELERATION? Or just accept that caveat in our solutions? I believe changing that would seriously complicate things. --[[User:Voidious|Voidious]] 14:28, 15 July 2009 (UTC)<br />
<br />
Ok, I really need to stop thinking about this and get some work done =), but I found some topics maybe worth checking out: <br />
* [http://en.wikipedia.org/wiki/Bellman_equation Wikipedia: Bellman equation]<br />
* [http://en.wikipedia.org/wiki/Backward_induction Wikipedia: Backward induction] (found linked [http://en.wikipedia.org/wiki/Dynamic_programming#Algorithms_that_use_dynamic_programming here])<br />
--[[User:Voidious|Voidious]] 14:43, 15 July 2009 (UTC)<br />
<br />
I understand your point Voidious. But I think in any case, the whole concept is complex in such a way, it's good to break it up into different functions (like Darkcanuck has already done partially). How about you guys make the following functions for your versions: <br />
<pre><br />
double getMaxVelocity(double distance)<br />
{<br />
// returns the largest possible velocity for the robot to be set to,<br />
// that, if next turn it had to start decelerating, it would still be<br />
// able to stop without overshooting<br />
}<br />
</pre><br />
<br />
Basically, that would refine the problem. Because in that function you don't have to care about the current velocity. :) After this function returns, you only need to check if the returned velocity "wantedVelocity" is actually reachable from the current velocity by the accelerating/deceleration laws of robocode. And if not try to get closest to it (that won't cause any problems, because any speed returned lower than the max velocity won't overshoot either) :) <br />
<br />
So basically, the other function needed is:<br />
<pre><br />
double getClosestReachableVelocityToVelocity(double currentVelocity,double wantedVelocity)<br />
{<br />
// with this function you can basically assume setAhead(Infinity) or setAhead(-Infinity)<br />
// was called, and you determine the next velocity based on the max velocity<br />
// set by the robot. For example, if the current velocity is 0 and the max velocity<br />
// set was 4.0, it would return 1.0. If the current velocity was 8.0, it would return 6.0.<br />
} <br />
</pre><br />
Finally, the getNewVelocities final version would be (independant of the workings of the other functions):<br />
<pre><br />
double getNewVelocity(double velocity, double distance) <br />
{<br />
if(distance<0)<br />
return -getNewVelocity(-velocity,-distance);<br />
double highestVelocity = getMaxVelocity(distance); // highest velocity without overshooting<br />
double wantedVelocity = Math.min(highestVelocity,currentCommands.getMaxVelocity());<br />
// the actually wanted velocity by the robot is the highest possible,<br />
// limited by what the robot set by the setMaxVelocity command<br />
return getClosestReachableVelocityToVelocity(velocity, wantedVelocity);<br />
// return whatever is closest to that velocity<br />
}<br />
</pre><br />
--[[User:Positive|Positive]] 16:50, 15 July 2009 (UTC)<br />
<br />
: I didn't break anything up, just plugged the getNewVelocity functions into a simple (well, the latest version is no longer so simple) testing framework. The best solution is the one that gets the job done in the least code, while still remaining understandable. =) --[[User:Darkcanuck|Darkcanuck]] 17:48, 15 July 2009 (UTC)<br />
<br />
: I really like how you frame the problem here. I think I have a solution to getMaxVelocity at [[User:Voidious/Optimal Velocity]]. This seems like a much cooler and cleaner way to deal with this. --[[User:Voidious|Voidious]] 18:14, 15 July 2009 (UTC)<br />
<br />
:: Okay Darkcanuck, I understand. I just finished creating an implementation of the getClosestReachableVelocityToVelocity here: [[Positive/Optimal Velocity]]. I'll try to combine Voidious's getMaxVelocity routine with it and the code above, and post the results. --[[User:Positive|Positive]] 19:11, 15 July 2009 (UTC)<br />
<br />
It seems like it's working. I posted the results here [[Positive/Optimal Velocity]]. Great job Voidious with your getMaxVelocity function! --[[User:Positive|Positive]] 19:37, 15 July 2009 (UTC)<br />
<br />
You guys are truely amazing. Good job! I knew the "update movement" was non-trivial and could be complex when I tried to simplify things and get rid of the "bugs". But now it seems even much more complex. The rules are simple, but the code behind it complex?! I will put take all the code from the [[Positive/Optimal Velocity]] page and put into Robocode. Then I will make a new Alpha version, which everybody could try out to see if this is what we want in the next version of Robococe (1.7.1.4). And yes [[User:Positive|Positive]], your version of updateMovement is better. --[[User:FlemmingLarsen|Fnl]] 21:41, 15 July 2009 (UTC)<br />
<br />
: Yes, great team-work. And.. it's great to feel appreciated. :) Fnl, please include the temporary fix in the getMaxVelocity that was just added (to speed up robots that use setAhead(huge number)). --[[User:Positive|Positive]] 21:50, 15 July 2009 (UTC)<br />
<br />
: Cool! =) --[[User:Voidious|Voidious]] 22:25, 15 July 2009 (UTC)<br />
<br />
Okay, I will make sure the include the temporary fix. If we find a better solution later, I will of course update the code as well.<br />
<br />
'''Notice:''' If you are not a member of the [http://groups.google.com/group/robocode-developers Robocode Developers Discussion Group] then please do not hesitate with joining this group soon. The way you/we won't miss important aspects in our discussions about changes (and new features) in Robocode. --[[User:FlemmingLarsen|Fnl]] 22:07, 15 July 2009 (UTC)<br />
<br />
Ok, so I ran some tests. With both [[Diamond]] and [[SilverSurfer]], in both 1.6.1.4 and 1.7.1.3, I ran 100 seasons of 500-round [[Wave Surfing Challenge 2K6]]. We've banged on the 1.7.1.3 updateMovement code quite a bit now, and clearly it has changes that could affect both True Surfing (decel through 0) and Go-To (velocity selection). However, the results are extremely close (and surprisingly, 5 out of 6 of the scores are higher in 1.7.1.3.)<br />
<br />
{| border="1" style="border-collapse: collapse; font-size: 85%; color: black"<br />
| '''Bot'''<br />
| '''Bot A'''<br />
| '''Bot B'''<br />
| '''Bot C'''<br />
| '''Total'''<br />
|-<br />
| SilverSurfer 2.53.33<br />
| 99.84/99.85<br />
| 91.15/91.04<br />
| 85.77/85.81<br />
| '''92.25'''/'''92.23'''<br />
|-<br />
| Diamond 1.197<br />
| 99.92/99.93<br />
| 98.46/98.48<br />
| 96.94/96.98<br />
| '''98.44'''/'''98.47'''<br />
|}<br />
<br />
I'll be sure to run some more and different tests with the new Alpha, as well.<br />
<br />
--[[User:Voidious|Voidious]] 22:25, 15 July 2009 (UTC)<br />
<br />
Here is the new Alpha-1: http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-1-setup.jar --[[User:FlemmingLarsen|Fnl]] 22:39, 15 July 2009 (UTC)<br />
<br />
Hey Fnl, that last change Positive made at [[Positive/Optimal Velocity]] is an important one. Without it, setMaxVelocity actually doesn't work at all in this Alpha-1. (Tested with [[Jen]], who starts in a stop and go mode, but just moves full speed in the alpha.) <code>Math.min(highestVelocity,8.0)</code> should have <code>currentCommands.getMaxVelocity()</code> instead of 8.0. --[[User:Voidious|Voidious]] 00:04, 16 July 2009 (UTC)<br />
<br />
I just tested it too, and had the same results. --[[User:Positive|Positive]] 00:08, 16 July 2009 (UTC)<br />
<br />
I like this =) Although there still seems to me to be some clean solution that we've all missed, which doesn't involve different cases. Although it may be the tick-based environment that prevents that. However, Murphy be blamed, now that it's too late, I've finally come up with a decelDistance() function that doesn't have a loop:<br />
<pre><br />
private static final double decelDistance(double speed){<br />
double t = speed / Rules.DECELERATION;<br />
double floor_t = Math.floor(t);<br />
return 0.5*floor_t*(floor_t+1)*Rules.DECELERATION + (speed%Rules.DECELERATION)*Math.ceil(t);//used by Skilgannon's solution<br />
//return 0.5*floor_t*(floor_t-1)*Rules.DECELERATION + (speed%Rules.DECELERATION)*Math.ceil(t);//used by Voidious's solution<br />
}<br />
</pre><br />
--[[User:Skilgannon|Skilgannon]] 07:57, 16 July 2009 (UTC)<br />
<br />
Fnl, to save you from looking all over the place, I think the final evolution of the code is at:<br />
* [[Talk:Positive/Optimal Velocity#Hijack =)]] - old decel-through-zero rules<br />
* [[User:Voidious/Optimal Velocity#Hijack 2]] - new decel-through-zero rules<br />
As of now, Darkcanuck has tested the former but not the latter. You can take a look yourself and decide which you want to try in the next Alpha.<br />
<br />
--[[User:Voidious|Voidious]] 16:00, 16 July 2009 (UTC)<br />
<br />
Results for both can be found here: [[Talk:Darkcanuck/VelocityTest]]. I have yet to break either version, but I'll try... --[[User:Darkcanuck|Darkcanuck]] 16:04, 16 July 2009 (UTC)<br />
<br />
The section itself is 48KB now, longer than most pages =) Did we reach the conclusion on old decel-through-zero or new decel-through-zero rules yet? &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:51, 16 July 2009 (UTC)<br />
<br />
Well, that decision really is Fnl's. I don't think we debated it until there was a consensus among the rest of us. Personally, I believe that the effect on current bots will be immeasurably small. I will run some extensive tests to compare the versions, and hopefully the results will support this. (I've got some more of the 1.6.1.4 test runs going already.) --[[User:Voidious|Voidious]] 17:54, 16 July 2009 (UTC)<br />
<br />
Oh, I think he'll choose the new rules. The older conclusion is to makes Robocode follow its own rules better. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 18:09, 16 July 2009 (UTC)<br />
<br />
<br />
Sorry for the bad Alpha-1. The compiler did not see the update (?) I made on the source for the temporary fix. Nevermind, I have made two new alphas to try out:<br />
* [[Talk:Positive/Optimal Velocity#Hijack =)]] - old decel-through-zero rules - [http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-2-setup.jar Download Alpha 2]<br />
* [[User:Voidious/Optimal Velocity#Hijack 2]] - new decel-through-zero rules- [http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-3-setup.jar Download Alpha 3]<br />
<br />
Actually, I am not sure which version I prefer after this long discussion, but it seems to me that the new decel-through-zero rules is more correct. Actually, it was Mathew Nelson who mentioned that it ought to be fixed too, so that was my motivation for adding it. But I will let it up to you guys to decide.<br />
<br />
Btw. Nice job with making the source code smaller with the two Hijack versions.<br />
<br />
--[[User:FlemmingLarsen|Fnl]] 22:54, 16 July 2009 (UTC)<br />
<br />
Thanks, Fnl. I'm going to run quite a few tests with these two and 1.6.1.4 and post results. So far, [[Diamond]] 1.191 vs [[Barracuda]] over 500 battles (35 rounds) is 99.51 in 1.6.1.4 and 99.52 in 1.7.1.4-Alpha 3 -- not a bad start. =)<br />
<br />
I'm planning to test with [[Diamond]], [[Phoenix]], [[DrussGT]], and [[PrairieWolf]] (vs a few other bots). The first 3 because they are likely among the most precise bots out there, Diamond over Dookious because it's the same precision and surfing but twice as fast, and PrairieWolf because I know he has a +1/-1 movement mode. Maybe I should add [[Wintermute]]? If anyone has suggestions on who else I should test with (and maybe why), let me know. I will definitely do some tests with non-surfers, but surfers do seem the most precise and thus the most likely to be affected.<br />
<br />
--[[User:Voidious|Voidious]] 01:19, 17 July 2009 (UTC)<br />
<br />
FYI: From tomorrow and one week forward (week 30) I will be on a summer vacation in a rented summer cottage together with my family. If I am lucky, I will be able to access the Internet from there. But the connection might be slow. I will check out these pages while I am off, but I cannot promise that I will be able to compile everything into a new version, and I need to fix some other issues before I can release a 1.7.1.4 Beta. Until then, have fun with the alphas here. If other issues needs to be addressed as well, then please create a bug report on SourceForge so we can keep track of all issues. :-) --[[User:FlemmingLarsen|Fnl]] 21:56, 17 July 2009 (UTC)<br />
<br />
[[Sanguijuela]] v0.8 is a micro rambot using the Accel/decel trick. Please, let me know if I'm wrong, but as far as I understand, this trick will be inevitable useless in the future at the RoboRumble, right? If this is correct I will remove the trick and upload a new version (with 50 less of codesize :P ) and we will see the impact. Thanks! --[[User:Jab|jab]] 16:02, 13 August 2009 (UTC)<br />
<br />
Well, it depends on the result of the vote. You can vote against removing it, to tie the vote. --[[User:Positive|Positive]] 18:44, 13 August 2009 (UTC)<br />
<br />
Vote? Ok, it could be against my interests but I vote in favor of removing it. :D I read this discussion by chance while I was checking my bots ranking after more than a year and a half so I see the problem: There are many bots out there using the trick and thinking that others are using it. Many bots are not going to be updated... But it is a trick, we took advantage of a robocode bug. I read once about the Teleport bug at the old wiki, it is not similar somehow? but the accel/decel bug seems to be accepted for a long time. Solutions? I think that there are two solutions: Removing the bug (I didn't check if it is already resolved in new versions) and reset the roborumble server and only allows newer versions as roborumble clients, or making this Accel/decel phenomenon part of the official [[Robocode/Game Physics]]. That could be another solution. What do you think? --[[User:Jab|jab]] 21:58, 13 August 2009 (UTC)</div>Jabhttp://robowiki.net/w/index.php?title=Talk:Robocode/Game_Physics&diff=10413Talk:Robocode/Game Physics2009-08-13T21:58:59Z<p>Jab: /* Accel/decel rules */</p>
<hr />
<div>__TOC__<br />
== Robot hitbox ==<br />
I need to know percisely, which might involve rotating a rectangle, I don't know, if a point intersects my bot, given its X and Y location. Remeber that in Robocode, Y is reversed. While I'm at it, I might just ask: What your opinion is on whether I should do surfing or anti-gravity movement to dodge predicted bullets my robot simulates?<br />
--[[User:Awesomeness|Awesomeness]] 21:52, 3 May 2009 (UTC)<br />
<br />
The 'hitbox' of a robot is always a non-rotated square at the bot's location, so the former check is very very simple. As for your second question: It depends. Surfing is going to be stronger almost surely, however anti-gravity movement is considerably simpler. My suggestion would be to do anti-gravity for now, and at a later date try surfing once you feel comfortable with exactly how it works. --[[User:Rednaxela|Rednaxela]] 22:01, 3 May 2009 (UTC)<br />
<br />
Oh, is it a 40 pixel long sqare? that's what it looks like. --[[User:Awesomeness|Awesomeness]] 22:43, 3 May 2009 (UTC)<br />
<br />
No, it is 36px non-rotating square. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 23:42, 3 May 2009 (UTC)<br />
<br />
== Gun turn and fire execution order ==<br />
<br />
When, in the execution order, are bullets fired, and when is the gun turned? Thanks! --[[User:Mageek|Mageek]] 02:44, 28 May 2009 (UTC)<br />
<br />
I believe that's part of #2 in the "Robocode Processing Loop" section. I can tell you for sure, though, that if you do setFire and setTurnGunRight in the same turn, the bullet will fire at the bearing of your gun ''before'' that gun turn happens. Both of them happen on the next tick, but the bullet is fired as if it were fired on the same tick as setFire (the location is from that tick, and it has advanced by its velocity once). Does that answer your question? --[[User:Voidious|Voidious]] 02:53, 28 May 2009 (UTC)<br />
<br />
Thank-you, that is exactly what I was trying to figure out. --[[User:Mageek|Mageek]] 03:39, 28 May 2009 (UTC)<br />
<br />
== Accel/decel rules ==<br />
<br />
(Conversation began on [[Talk:Darkcanuck/RRServer]]...)<br />
<br />
I've almost finished my first robot to enter to the melee rumble :), but I'm wondering: does the (melee)server use the old accel/decel rules (where you can go from -1 to 1) or the new (where you can't)? --[[User:Positive|Positive]] 23:22, 11 Jul 2009<br />
<br />
The RoboRumble currently only allows clients using versions 1.5.4, 1.6.0, and 1.6.1.4, so it should only be the old rule (where you can). I actually didn't realize that was changed -- I really don't like that. =( Lots of legacy bots are programmed to believe you can. --[[User:Voidious|Voidious]] 21:24, 11 July 2009 (UTC)<br />
<br />
Woah, what a quick response! Thanks for the info. :) I don't really like the change either (I have a cool -1, +1 strategy and a nice move simulator), but alas. --[[User:Positive|Positive]] 23:36, 11 Jul 2009<br />
<br />
Are you sure the rules have changed? I thought the only changes to movement in later versions of Robocode (still unsupported in the rumble, btw) were to fix the movement quirks that Simonton had found. I don't remember decelerating through 0 being one of them. --[[User:Darkcanuck|Darkcanuck]] 22:26, 11 July 2009 (UTC)<br />
<br />
Here is the [http://sourceforge.net/tracker/?func=detail&aid=2793464&group_id=37202&atid=419486 discussion at the bug tracker]. Fnl explains that if for example your robot is at -1.0 velocity, it can only reach 0.75 velocity the next turn (as of version 1.7.1.2). --[[User:Positive|Positive]] 02:45, 12 Jul 2009<br />
<br />
Errr.... 0.75 is not 'accurate'... It's what robocode as of 1.7.1.2 does, but it's just as incorrect as before the change... Fnl says it uses a formula of <code>(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION *<br />
accelTime * accelTime)</code>, when the correct formula should be <code>(Rules.DECELERATION * decelTime + Rules.ACCELERATION * accelTime)</code>. Change in velocity, is always equal to acceleration multiplied by time, not time squared... It looks like Fnl got his physics mixed up and looked at a formula to get distance from acceleration (<code>d = a*t*t</code>) instead of getting velocity change from acceleration (<code>v = a*t</code>) :-( --[[User:Rednaxela|Rednaxela]] 01:47, 12 July 2009 (UTC)<br />
<br />
: Ooh, I see this now... Do some tests and file a bug for [[Fnl]]? --[[User:Darkcanuck|Darkcanuck]] 02:48, 12 July 2009 (UTC)<br />
<br />
:: Robocode Developer Google Groups, I think. So Flemming can re-open that tracker instead of creating new one. I always wonder why it go from 1 to -0.75, not 0.5 since it have only half turns left, I always think that I don't have enough physics knowledge. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 02:59, 12 July 2009 (UTC)<br />
<br />
Voidious, do you subscribe to [http://groups.google.com/group/robocode-developers Robocode Developer Google Groups]? I think we have reached the conclusion that we worth this change, unless there are too many effects. After we changed it, Flemming and I did run a lot of test (well, mostly Flemming run, I'd run only one test). I've test [[Dookious]] with [[DrussGT]], on both 1.6.1.4 and 1.7.1.x with new updateMovement(), and the difference is around 1-2%, which is acceptable in margin of error. I chose Dookious and DrussGT because I know that Dookious use FuturePosition library, which is the internal copy of old movement engine. And DrussGT use Skilgannon's special movement predictor which I believe should be the loosely implementation of the 'correct' movement engine.<br />
<br />
Positive, I believe that if you create a good movement under 1.6.1.4, it will be good in 1.7.1.x version too. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:20, 12 July 2009 (UTC)<br />
<br />
- - -<br />
<br />
Hi guys, to you mind I join the discussion? I did the change in "update movement" for many reasons. The issue(s) were raised a long time ago on the old RoboWiki (the 3 caveats raised by Simonton - http://old.robowiki.net/cgi-bin/robowiki?GamePhysics/BotSpeed), and later discussed within the Robocode Developer Group (even Mathew Nelson joined the discussion). That is, if we would make the change or not. Especially with you guys in mind. The conclusion in the groups was to fix the bugs so Robocode would follow its own rules, and because lot's of robots out there counts on the rules as explained, not to the way Robocode was actually behaving. Not everybody replicates the internal code of Robocode to get the formulas correct.<br />
<br />
The old closed bug tracker on SF created is available here: https://sourceforge.net/tracker/?func=detail&atid=419486&aid=2077512&group_id=37202<br />
<br />
Another goal with the change was to make the internal code easier less messy and easier to understand. Regarding the impact of the change, the results are not very different (unless you can prove me wrong here). I ran lots of lots of test with RoboRumble (also Melee and TeamRumble) on my local machines (different single-code, quad-core, Linux, Windows, 32 and 64 bit etc.), and I couldn't tell the difference in rankings or score with or without the change. There was a difference, but it was in average less than 1 percent. Is it really that much of a problem? Really?<br />
<br />
I would really love if people could try out the Betas on RoboRumble and put issues on SF as soon as they are discovered. Then the issues can be fixed or discussed before we do the real release. This way, we could avoid such issues as this one long time after the change was made and released.<br />
<br />
Btw. I am very familiar with physics, even tough the physics in Robocode does not really follow the real physics laws. I might not have explained the details about the fix well enough. <br />
<br />
Instead of shifting between old and new code (like you propose?), I should like you guys to tell me where the problem is in the code instead, since you are obviously the experts. The code is Open Source, so everybody is free to come with suggestions to what and where to correct things.<br />
<br />
Here we go:<br />
<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (dx != 0 || dy != 0) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
// If the distance is negative, then change it to be positive and change the sign of the input velocity and the result<br />
if (distance < 0) {<br />
return -getNewVelocity(-velocity, -distance);<br />
}<br />
<br />
double newVelocity;<br />
<br />
// Get the speed, which is always positive (because it is a scalar)<br />
final double speed = Math.abs(velocity); <br />
<br />
// Check if we are decelerating, i.e. if the velocity is negative.<br />
// Note that if the speed is too high due to a new max. velocity, we must also decelerate.<br />
if (velocity < 0 || speed > currentCommands.getMaxVelocity()) {<br />
// If the velocity is negative, we are decelerating<br />
newVelocity = speed - Rules.DECELERATION;<br />
<br />
// Check if we are going from deceleration into acceleration<br />
if (newVelocity < 0) {<br />
// If we have decelerated to velocity = 0, then the remaining time must be used for acceleration<br />
double decelTime = speed / Rules.DECELERATION;<br />
double accelTime = (1 - decelTime);<br />
<br />
// New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d<br />
// However, the new velocity must be limited by the max. velocity<br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,<br />
distance));<br />
<br />
// Note: We change the sign here due to the sign check later when returning the result<br />
velocity *= -1;<br />
}<br />
} else {<br />
// Else, we are not decelerating, but might need to start doing so due to the remaining distance<br />
<br />
// Deceleration time (t) is calculated by: v = a * t => t = v / a<br />
final double decelTime = speed / Rules.DECELERATION;<br />
<br />
// Deceleration time (d) is calculated by: d = 1/2 a * t^2 + v0 * t + t<br />
// Adding the extra 't' (in the end) is special for Robocode, and v0 is the starting velocity = 0<br />
final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;<br />
<br />
// Check if we should start decelerating<br />
if (distance <= decelDist) {<br />
// If the distance < max. deceleration distance, we must decelerate so we hit a distance = 0<br />
<br />
// Calculate time left for deceleration to distance = 0<br />
double time = distance / (decelTime + 1); // 1 is added here due to the extra 't' for Robocode<br />
<br />
// New velocity (v) = a * t, i.e. deceleration * time, but not greater than the current speed<br />
<br />
if (time <= 1) {<br />
// When there is only one turn left (t <= 1), we set the speed to match the remaining distance<br />
newVelocity = Math.max(speed - Rules.DECELERATION, distance);<br />
} else {<br />
// New velocity (v) = a * t, i.e. deceleration * time<br />
newVelocity = time * Rules.DECELERATION;<br />
<br />
if (speed < newVelocity) {<br />
// If the speed is less that the new velocity we just calculated, then use the old speed instead<br />
newVelocity = speed;<br />
} else if (speed - newVelocity > Rules.DECELERATION) {<br />
// The deceleration must not exceed the max. deceleration.<br />
// Hence, we limit the velocity to the speed minus the max. deceleration.<br />
newVelocity = speed - Rules.DECELERATION;<br />
}<br />
}<br />
} else {<br />
// Else, we need to accelerate, but only to max. velocity<br />
newVelocity = Math.min(speed + Rules.ACCELERATION, currentCommands.getMaxVelocity());<br />
}<br />
}<br />
<br />
// Return the new velocity with the correct sign. We have been working with the speed, which is always positive<br />
return (velocity < 0) ? -newVelocity : newVelocity;<br />
}<br />
</pre><br />
<br />
What must be corrected in order to make everybody happy, following the "physic laws" and rules of Robocode? --[[User:FlemmingLarsen|Fnl]] 22:59, 12 July 2009 (UTC)<br />
<br />
Fnl, it will take me some time to look over the code and discussions before I can give more constructive feedback. But some things I can comment on for now:<br />
* Fixing the issues Simonton brought up seems very reasonable to me. One is a bug that I doubt anyone depends on (the setMaxVelocity / decel). For the others, I'd guess [[DrussGT]] and [[SilverSurfer]] are the only bots that might simulate the quirks (being Go-To surfers). Some [[Wave Surfing Challenge]] tests with SS (I will run some) and feedback from Skilgannon could shed some light on potential impact.<br />
* I'm not clear on what has happened with this, but I believe changing the ability to go from velocity 1 to -1 could adversely impact a lot of bots. Even a bot as old as [[PrairieWolf]] (2002) has a movement mode that depends on it ("buzzing" between 1 and -1), and I'd guess nearly every modern wave surfer also simulates this aspect of the physics.<br />
* One percent ''is'' a lot -- see the "huge" 1% APS gap between DrussGT and Dookious =). That said, it takes hundreds or thousands of battles to get a result accurate enough to see that 1% difference.<br />
* I do not envy your position in these types of matters, and as always, I appreciate the effort you put into developing Robocode. Robocode's impact goes far beyond the "hardcore" Robocoders on this wiki, and I fully understand that you want to polish Robocode as best as you can for the benefit of everyone that uses it. Cheers,<br />
--[[User:Voidious|Voidious]] 00:01, 13 July 2009 (UTC)<br />
<br />
: 1 percent is ''not'' a lot with this major change in physics, especially when it makes the game follows its own rule better. 1% is 'huge' in APS, I agree. But if you look at each battle closely, the results can swing up to 10% &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
<br />
:: 1% is 1% and it ''is'' a lot. You're right that individual battles have a large variance, that's why you need to run hundreds of battles to get a meaningful result. If you run enough battles to get a statistically accurate result, 1% is a lot. If you don't run enough battles, you can't draw any real conclusion from the results. <br />
:: I'm not claiming there is a 1% difference in results. I'm only saying that if tests only narrowed it down to "1% or less", that's not really enough to satisfy my need for accuracy and consistency. No ill will here, I should get involved and run some tests if I care so much. And I do. And I will. =)<br />
:: --[[User:Voidious|Voidious]] 17:40, 13 July 2009 (UTC)<br />
<br />
::: While I wat to argue that 1% is ''not'' a lot for this major physics change, I don't think that is an issue anymore. I think you already accept the changes now =) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:37, 14 July 2009 (UTC)<br />
<br />
I've read the mailing list and bug report concerning the issue. Does the -1, +1 thing really need to be changed to fix the bugs? This is how I would code it, and I believe it should fix the bugs. I haven't actually compiled it into robocode, but the velocity routines themselves have been tested and are working. And excuse me, I'm a bad commenter :):<br />
<br />
<pre><br />
<br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
// small tweak from original version<br />
if(velocity!=0)<br />
{<br />
x+=velocity * sin(bodyHeading);<br />
y+=velocity * cos(bodyHeading);<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
static double getNewVelocity(double velocityArg, double distanceArg) <br />
{ <br />
double velocity;<br />
double distance;<br />
<br />
// Make sure the remaining distance is always positive or zero<br />
// (we switch this back later)<br />
if(distanceArg<0)<br />
{<br />
velocity=-velocityArg;<br />
distance=-distanceArg;<br />
}<br />
else<br />
{<br />
velocity=velocityArg;<br />
distance=distanceArg;<br />
}<br />
<br />
// Get the next most positive velocity the robot can reach for next turn<br />
double mostPositiveReachableVelocity = VelocityToMostPositiveVelocity(velocity);<br />
// Get the next most negative velocity the robot can reach for next turn<br />
double mostNegativeReachableVelocity = VelocityToMostNegativeVelocity(velocity);<br />
<br />
<br />
double highestWantedVelocity = Math.min(currentCommands.getMaxVelocity(), maxSpeedToStopInDisp(distance));<br />
<br />
// The real next velocity is limited by what is actually reachable<br />
double nextVelocity = Math.min(mostPositiveReachableVelocity,Math.max(mostNegativeReachableVelocity,highestWantedVelocity ));<br />
<br />
// Switch return value back if needed<br />
if(distanceArg<0)<br />
nextVelocity = -nextVelocity;<br />
<br />
return nextVelocity;<br />
}<br />
<br />
<br />
static public double VelocityToMostPositiveVelocity(double velocity)<br />
{<br />
// Returns the most positive reachable velocity from the<br />
// specified velocity in one turn<br />
if(velocity>0)<br />
{<br />
double returnVelocity = velocity+Rules.ACCELERATION;<br />
if(returnVelocity>Rules.MAX_VELOCITY)<br />
return Rules.MAX_VELOCITY;<br />
else<br />
return returnVelocity;<br />
}<br />
else<br />
{<br />
double returnVelocity = velocity+Rules.DECELERATION;<br />
if(returnVelocity>Rules.ACCELERATION)<br />
return Rules.ACCELERATION;<br />
else<br />
return returnVelocity;<br />
}<br />
}<br />
static public double VelocityToMostNegativeVelocity(double velocity)<br />
{<br />
// Returns the most negative reachable velocity from the<br />
// specified velocity in one turn<br />
if(velocity<0)<br />
{<br />
double returnVelocity = velocity-Rules.ACCELERATION;<br />
if(returnVelocity<-Rules.MAX_VELOCITY)<br />
return -Rules.MAX_VELOCITY;<br />
else<br />
return returnVelocity;<br />
}<br />
else<br />
{<br />
double returnVelocity = velocity-Rules.DECELERATION;<br />
if(returnVelocity<-Rules.ACCELERATION)<br />
return -Rules.ACCELERATION;<br />
else<br />
return returnVelocity;<br />
}<br />
}<br />
<br />
static private final double[] dispStopArray = <br />
{0.0000,1.0000,2.0000,2.5000,3.0000,<br />
3.5000,4.0000,4.3333,4.6666,5.0000,<br />
5.3333,5.6666,6.0000,6.2500,6.5000,<br />
6.7500,7.0000,7.2500,7.5000,7.7500};<br />
static public double maxSpeedToStopInDisp(double displacement)<br />
{<br />
// Returns the biggest velocity the robot could go to this turn,<br />
// still being able to stop without overshooting. (Or if <br />
// remaining displacement is less than 2, returns that)<br />
// This routine could be improved to match up with robocode's<br />
// older velocity selecting rules.<br />
if(displacement>=0)<br />
{<br />
if(displacement>=20)<br />
return 8.0;<br />
else if(displacement<=2)<br />
return displacement;<br />
else<br />
return dispStopArray[(int)Math.floor(displacement)];<br />
}<br />
else<br />
{<br />
return 0;<br />
}<br />
}<br />
</pre><br />
I also appreciate your effort, Fnl. :) --[[User:Positive|Positive]] 01:48, 13 July 2009 (UTC)<br />
<br />
Ok, I'm up to speed with the discussions and the code. I think, for how it was decided, this line:<br />
<pre><br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,<br />
distance));<br />
</pre><br />
...should be changed to:<br />
<pre><br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.ACCELERATION * accelTime, distance));<br />
</pre><br />
* The deceleration already takes you to zero, so we just need to use the remaining time for acceleration, right?<br />
* Don't need to square the accelTime (v = at).<br />
<br />
So, as I understand it, your velocities should be, for example: -1, +0.5, -0.75, +0.625? "Legacy" issues aside, I like this solution a lot. It makes sense. I've been considering this issue a bit now, and here's how I'd lay out the impact to affected bots:<br />
* A bot like [[PrairieWolf]] that oscillates between 1 and -1 will now oscillate between roughly 0.7 and -0.7. I'm ''guessing'' this has very minimal impact on performance (though I am curious to test / confirm).<br />
* When Wave Surfers predict a change of direction, their predictions could be off. I believe most surfers are dealing with whole number velocities the great majority of the time. Changing direction from even velocities will not be impacted. Changing direction from odd velocities, their predictions could be off by as much as 4 pixels -- predicting a velocity 0.5 too high for 8 ticks (until they reach max velocity). Some might disagree, and of course I advocate ultimate precision in surfing, but I believe the impact here is negligible. (How many of us even do precise bot width? And I never found much to be gained there, anyway.)<br />
* I'm still not crazy about changing Robocode's physics, and I might've opposed it if put to a vote, but I think the impact is negligible and the new solution is a good one. <br />
<br />
Also, I've started running those [[SilverSurfer]] WSC tests on 1.6.1.4 and 1.7.3 to compare. I'll have the results today or tomorrow.<br />
<br />
--[[User:Voidious|Voidious]] 15:31, 13 July 2009 (UTC)<br />
<br />
: The information in Robocode (mostly the floating point value) isn't digital, means that only 0.5 change isn't impact ''much''. If you can dodge bullets well, the missed 2 ticks with the most of 2 pixels won't make the bullet hit you. If you can't dodge it, the slippage of 2 pixels ''may'' make you dodged it, but only by luck. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
<br />
<Edit conflict> Thanks for taking a look Fnl. I personally think that the current code is more complicated than necessary, and as such, harder to understand. Here's a few things that should be addressed:<br />
* The decelDist. Because robocode follows a discrete time base, it cannot be approximated with calculus. For example, say your speed is 3, your formula gives 3.75 as decelDist. However, 3 + 1 + 0 = 4, so your code would not want to decelerate in the right places. This would be the correct implementation:<br />
<pre><br />
private static final double decelDistance(double velocity){<br />
double distance = 0;<br />
while(velocity > 0){<br />
distance += velocity;<br />
velocity = Math.max(0,velocity - Rules.DECELERATION);<br />
}<br />
return distance;<br />
}<br />
</pre><br />
* One of the ideas of robocode is that your bot has a continuous acceleration/deceleration over a single tick. I see what you have done is, when a bot is decelerating over 0 velocity, it takes 1/2 of the tick to decelerate and then 1/2 of the tick is left to accelerate in the other direction (the split may depend on the amount of time taken to decelerate to 0 first). But many older bots rely on being able to decelerate over the entire tick, using the 2 deceleration value instead of the 1 acceleration value, so that they can 'vibrate' from 1 to -1 back to 1 etc. While I agree that it is not correct, these are the physics of robocode, not real life =) Because of this, you can essentially remove the majority of the inside of that 'if' block, just leaving <code>velocity *= -1;</code>.<br />
* I have re-written this method, and if people want I'll post it, but it seems that with a few quick fixes this one should be up to scratch =), so I don't really think that's necessary.<br />
<br />
As an answer to [[Voidious]], I haven't taken any of the 'quirks' into account while writing DrussGT. It is coded with the rules, as they are described on the [[Robocode/Game_Physics]] page, in mind. --[[User:Skilgannon|Skilgannon]] 16:00, 13 July 2009 (UTC)<br />
<br />
: (edit conflict) In my tests, DrussGT usually performs worse. But just around 0.2% or somethings. I'm not sure since I ran only 3 35-rounds tests.<br />
: While I agree with you that this isn't real life, it still isn't correct under its own Rules. The major reason we have this fix is that we want Robocode to follows its own rule batter. Otherwise we should have the bullet velocity affected by robot velocity, the curved bullet, better bullet-bullet collision checking etc. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
:: Sorry, but 3 battles simply cannot produce a result within 0.2% accuracy. In my experience, you'd need 100 or more before the overall result stays within 0.2%. --[[User:Voidious|Voidious]] 17:40, 13 July 2009 (UTC)<br />
<br />
Hi guys. Thank you for the constructive feedback. I appreciate that. I see many of you have some really good pointer of what to change, and where to make the changes. Currently, I have my house full of guests and is just checking what is going on in this forum. Tomorrow evening, I will take a closer look at all the comments, and I agree that the new implementation for "update movevement" is buggy too. I intend to create some variants that you can download and test for yourselves. Afterwards, you can choose which one is the better one for the next version of Robocode.<br />
Compared to 1.6.x.x, the code has become much simpler than it was before. I am not sure that the code could be any simpler than it is now as we will brake something else (because something is missing) - even though I hope it is possible.<br />
So, tomorrow I will review all comment on this page and take action. =) --[[User:FlemmingLarsen|Fnl]] 17:43, 13 July 2009 (UTC)<br />
<br />
I really agree that the code is a lot more simple and adaptable than 1.6 and before. When I was adapting the internal Robocode's movement engine for my movement predictor, I can't adapt the <1.6 code. I get my head mess when I'm trying to understand it. However, I can adapt the current code really easy (in fact, I did copy almost whole getNewVelocity() method) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:37, 14 July 2009 (UTC)<br />
<br />
I have examined all the comments here, and is trying to figure out how to modify the existing code for getNewVelocity(). I think you are on the right track [[Voidious]], and hence I want to implement your modifications so we could all try them out. However, I have a hard time figuring out how the modified version of getNewVelocity() will look like. If a change the part for the newVelocity, it must be in the two places in the code, where it is assigned. You have only written how you want the first one. [[Voidious]], could you give the full version of your version of getNewVelocity() as you think it should be? This way we all will be able to follow (and discuss) the changes/ideas, and I will be able to implement it straight away. :-) --[[User:FlemmingLarsen|Fnl]] 22:28, 14 July 2009 (UTC)<br />
<br />
Sorry, I was only closely examining the decelerating through zero issue before. I agree with Skilgannon's assessment that decelDist doesn't seem right, though I'm not sure I'm understanding this fully. Skilgannon, you say that decelDist(3) should be 4, but shouldn't it be 1, since we can update the speed before we move? In either case, I don't understand why it would be 3.75, but I'm curious if there is some voodoo at work in this code that I'm not getting yet. I'll study some more and try to figure it out. =) <br />
<br />
And Skilgannon, no harm in posting your rewritten version, I wouldn't mind seeing it. I'll also check out Positive's version. And I'll have some 1.6.1.4 vs 1.7.1.3 [[Wave Surfing Challenge 2K6|WSC2K6]] scores ready to examine tomorrow. Only about 180 more seasons to run. =)<br />
<br />
--[[User:Voidious|Voidious]] 00:23, 15 July 2009 (UTC)<br />
* My understanding (and subsequently, DrussGT's movement simulator, which uses a decelDistance based method of deciding when to decelerate) is if we go with the velocity of 3 this tick, how far will we travel in total if we decide it's necessary to decelerate next tick. ''Basically, do we have freedom with to do as we please with our velocity this tick, and still be able to decelerate sufficiently in the future''. If the answer is "no", then we need to decelerate ''or'' maintain velocity this tick. My statements about 4 and 3.75 assumed the DECELERATION is 2. Fnl gets 3.75 from this little bit of code:<br />
<pre><br />
final double decelTime = speed / Rules.DECELERATION;<br />
final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;<br />
</pre><br />
: ie. <code>3/2 = 1.5 --> 0.5*2*1.5*1.5 + 1.5 = 3.75</code> whereas it should be <code>3 + (3-2) = 4</code>. I'll be very interested to see what the scores look like =) --[[User:Skilgannon|Skilgannon]] 08:59, 15 July 2009 (UTC) <br />
<br />
Wow, this problem really is not trivial. Here's what I came up with, I think it works and is pretty minimal:<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (dx != 0 || dy != 0) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
// If the distance is negative, then change it to be positive and change the sign of the input velocity and the result<br />
if (distance < 0) {<br />
return -getNewVelocity(-velocity, -distance);<br />
}<br />
<br />
double newVelocity;<br />
<br />
// Get the speed, which is always positive (because it is a scalar)<br />
final double speed = Math.abs(velocity); <br />
<br />
if (velocity < 0) {<br />
// Check if we are decelerating, i.e. if the velocity is negative.<br />
newVelocity = speed - Rules.DECELERATION;<br />
<br />
// Check if we are going from deceleration into acceleration<br />
if (newVelocity < 0) {<br />
// If we have decelerated to velocity = 0, then the remaining time must be used for acceleration<br />
double decelTime = speed / Rules.DECELERATION;<br />
double accelTime = (1 - decelTime);<br />
<br />
// New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d<br />
// However, the new velocity must be limited by the max. velocity<br />
newVelocity = Math.min(Rules.ACCELERATION * accelTime, distance));<br />
<br />
// Note: We change the sign here due to the sign check later when returning the result<br />
velocity *= -1;<br />
}<br />
} else {<br />
// Deceleration distance (d) is calculated iteratively due to Robocode's<br />
// discrete time system.<br />
final double decelDist = decelDistance(speed);<br />
<br />
// Deceleration ticks is the number of ticks it will take to get to<br />
// zero velocity. <br />
final long decelTime = Math.round( // VOIDIOUS: for rounding errors? maybe unnecessary<br />
Math.ceil((speed - Rules.DECELERATION) / Rules.DECELERATION));<br />
<br />
// The maximum distance coverable with an equivalent decelTime<br />
final double decelTimeMaxDist = ((decelTime + 1) / 2.0) * decelTime // sum of 1..decelTime<br />
* Rules.DECELERATION;<br />
<br />
if (distance <= Rules.DECELERATION) {<br />
// If we can cover remaining distance and then completely stop,<br />
// set speed = distance<br />
newVelocity = Math.max(speed - Rules.DECELERATION, distance);<br />
} else if (distance <= decelTimeMaxDist) {<br />
// If we can cover distance in decelTime, split any extra<br />
// distance (between decelDist and distance) over decelTime<br />
// ticks<br />
newVelocity = speed - Rules.DECELERATION + <br />
((distance - decelDist) / decelTime);<br />
} else {<br />
// If we need more than decelTime ticks, try to spread the<br />
// extra distance over (decelTime + 1) ticks. This will just max <br />
// the acceleration if it needs to (ie, if we need more ticks).<br />
// VOIDIOUS: I think this part would break if Rules.ACCELERATION<br />
// were set above Rules.DECELERATION; we might need an <br />
// extra case or something. Doh. =(<br />
newVelocity = Math.min(speed + Rules.ACCELERATION,<br />
(decelTime * Rules.DECELERATION) +<br />
((distance - decelTimeMaxDist) / (decelTime + 1)));<br />
}<br />
}<br />
<br />
// VOIDIOUS: I think it makes more sense to do this here; no need to decelerate maximally<br />
// if you don't need to to accomodate a new setMaxVelocity.<br />
newVelocity = Math.max(speed - Rules.DECELERATION, <br />
Math.min(newVelocity, currentCommands.getMaxVelocity()));<br />
<br />
// Return the new velocity with the correct sign. We have been working with the speed, which is always positive<br />
return (velocity < 0) ? -newVelocity : newVelocity;<br />
}<br />
<br />
private static final double decelDistance(double speed){<br />
double distance = 0;<br />
while(speed > 0){<br />
speed = Math.max(0,speed - Rules.DECELERATION);<br />
distance += speed;<br />
}<br />
return distance;<br />
}<br />
</pre><br />
Velocity is updated before the bot moves, right? =) This is a serious brain teaser! Wanted to post what I had before bed, but I'm still not satisfied with the part that would break with different accel/decel values. --[[User:Voidious|Voidious]] 05:06, 15 July 2009 (UTC)<br />
<br />
(maybe we should move this lengthy discussion to another page?)<br />
I've been going through the new velocity formula and have similar concerns as [[Skilgannon]]. Just running some test cases using my [[Darkcanuck/VelocityTest | VelocityTest]] class and have found cases where the bot overshoots the requested distance (e.g. try starting velocity 0, distance 6 -- the bot ramps up to velocity 3 and will thus overshoot badly). I'll put together some tests and then maybe make a fixed version of the routine.<br />
<br />
Regarding deceleration through 0, I have to sympathize with Fnl et al. There's nothing in the rules that says a bot can decelerate through 0 and gain some free acceleration. Deceleration takes you towards 0, acceleration takes you away from it. It's a quirk -- often called a "bug" -- that was perhaps first publicized [http://oldtestwiki.roborumble.org/cgi-bin/robowiki?GamePhysics here] (near bottom) and has been exploited since. Its not a huge quirk, the advantage is minimal so fixing it should also be minimal but only tests can really confirm this.<br />
<br />
--[[User:Darkcanuck|Darkcanuck]] 05:09, 15 July 2009 (UTC)<br />
<br />
Hey Fellas. Great you're doing more research into this! I think the -1, +1 thing is not a major issue, but if the incorrect movement handling bugs can be fixed in a way that the -1, +1 thing stays valid, is there any harm? I think the version I posted is simpler to understand, and it should work effectively. The only thing that you might not agree with is the working of the maxSpeedToStopInDisp function, but that should at least centralize the problem. :) --[[User:Positive|Positive]] 05:53, 15 July 2009 (UTC)<br />
<br />
: I'm sorry I haven't examined yours more. There are two reasons, really:<br />
:* It does look like you're solving the problem efficiently (and I assume correctly), but I think it depends on fixing one or all of Rules.DECELERATION, Rules.ACCELERATION, and maximum velocity=8. I think we want a solution independent of those values.<br />
:* I find this quite an enjoyable brain teaser, and just wanted to figure out an answer myself. =)<br />
:--[[User:Voidious|Voidious]] 13:26, 15 July 2009 (UTC)<br />
<br />
: I did test your solution and it passes all the same tests that Voidious' version 2 does. But as he pointed out, the hardcoded values are problematic. --[[User:Darkcanuck|Darkcanuck]] 17:48, 15 July 2009 (UTC)<br />
<br />
The reason I don't like breaking the +-1 thing is because it makes the precise prediction significantly more complicated, and what's more it assumes that the acceleration has more than one value between 2 ticks, which to me seems to break the whole concept of a discrete time interval. For interests sake, here's the one I wrote:<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (velocity != 0 ) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
<br />
if (distance < 0) <br />
return -getNewVelocity(-velocity, -distance);<br />
// If the distance is negative, then change it to be positive<br />
// and change the sign of the input velocity and the result<br />
<br />
double maxVel = currentCommands.getMaxVelocity();<br />
if (velocity < 0)<br />
return Math.min(velocity + Rules.DECELERATION, maxVel);<br />
//we want to go in the opposite direction, so decelerate <br />
<br />
else{ <br />
//we are going in the direction we want, test what happens if we accelerate<br />
<br />
double accel = Math.min(Rules.ACCELERATION, maxVel - velocity);<br />
//speed up, but not more than max velocity. decel if maxVel is less than velocity.<br />
<br />
accel = Math.max(accel, -Rules.DECELERATION);<br />
//prevent excess deceleration due to bot lowering the maxVel while velocity is high<br />
<br />
if (distance > decelDistance(velocity + accel))<br />
return velocity + accel;<br />
else if(accel != 0 && distance > decelDistance(velocity))<br />
return velocity;<br />
else{<br />
if(distance < Rules.DECELERATION <br />
//we'll be able to cover remaining distance in 1 tick and then decel to stop<br />
<br />
&& velocity - distance <= Rules.DECELERATION <br />
//and our velocity is low enough for us to get to that required velocity<br />
)<br />
return Math.min(distance, maxVel);<br />
//choose the velocity to cover all remaining distance <br />
<br />
return Math.max(-maxVel, velocity - Rules.DECELERATION);<br />
//velocity > 0 and we are close enough, so decelerate. <br />
}<br />
<br />
}<br />
<br />
}<br />
/**<br />
* Returns the linear distance it would take to decelerate from a given positive velocity<br />
*<br />
* @param velocity the positive velocity from which to test<br />
* @return the linear distance required to decelerate to a standstill<br />
*/<br />
private static final double decelDistance(double velocity){<br />
double distance = 0;<br />
while(velocity > 0){<br />
distance += velocity;<br />
velocity = Math.max(0,velocity - Rules.DECELERATION);<br />
}<br />
return distance;<br />
} <br />
</pre><br />
I'm fairly sure this fixes the 0,6 test Darkcanuck is doing. Voidious, one of the problems with your decelDistance() implementation is that your decel distance assumes you decelerate before adding the distance, whereas mine checks if we can still accelerate this tick and be able to decelerate sufficiently in the future. Also, mine considers the case of continuing at the current velocity, which may be a better option, as in the 0,6 test. --[[User:Skilgannon|Skilgannon]] 08:27, 15 July 2009 (UTC)<br />
<br />
: I agree that the new formulas do break the simplicity of the discrete time period. One simple solution would be simply to apply deceleration until 0 velocity is reached -- the extra time for acceleration would be lost. That would both follow the rules and keep the accel/decel values simple. But Fnl's solution does compromise by giving back the extra time for some acceleration, which should help bots that rely on this quirk. --[[User:Darkcanuck|Darkcanuck]] 16:29, 15 July 2009 (UTC)<br />
<br />
(I agree about moving this to a different or its own page. Anyone can feel free, or I'll do it in a bit.) Ah, I'm just imagining a different significance to decelDist: I imagine it as the minimum distance we would cover if we slam on the brakes. The problem with the (0, 6) case (more specifically the (2, 3) case) in mine is similar to the problem I theorize about when Rules.accel is greater than Rules.decel: I assume that if you can't cover ''distance'' in decelTime ticks, you can split the extra distance over (decelTime + 1) ticks, which of course is 1 tick and you go to speed 3. Maybe I should force decelTime to a min of 1, since if it's 0 and distance <= Rules.decel, we hit the first case and don't use it, otherwise we hit the 3rd case and need 2 ticks.<br />
<br />
Mine would also remain at constant velocity if needed, or even speed up a bit, despite lack of a special case. I'll have to investigate that 0 to -2 acceleration... hopefully that's a simple fix. <br />
<br />
I forgot that you'd already be familiar with this kinda stuff, since you are the Lord of Go-To. =) But I still see a problem with yours in that you restrict your decisions to max accel, constant, or max decel. Take the v=6.1, d=15 case: you want to do it in 4 ticks, and mine will (I think =)) go 6.75, 4.75, 2.75, 0.75. I think yours would go 6.1, 4.1, then be presented with (4.1, 4.8) and fail to do it in 4 ticks.<br />
<br />
I swear there must be a known Dynamic Programming problem that reduces to this. Maybe my effort would be better spent finding it and copying the established solution. =) To be clear, we are trying to do this in the optimal number of ticks, right?<br />
<br />
--[[User:Voidious|Voidious]] 13:26, 15 July 2009 (UTC)<br />
<br />
* Yep, what we are attempting to do is minimize number of ticks until velocity and distance are 0. The implementation I have in DrussGT is a highly simplified version of what I posted, and probably runs about 10 times faster =) --[[User:Skilgannon|Skilgannon]] 7:57, 16 July 2009 (UTC)<br />
<br />
I updated my method and posted it to [[User:Voidious/Optimal Velocity]]. I think this fixes both the (2, 3) case and the (0, 2) case, though I feel like the (2, 3) case should go 2/1 instead of 1.5/1.5. Can we agree that Rules.DECELERATION will never be less than Rules.ACCELERATION? Or just accept that caveat in our solutions? I believe changing that would seriously complicate things. --[[User:Voidious|Voidious]] 14:28, 15 July 2009 (UTC)<br />
<br />
Ok, I really need to stop thinking about this and get some work done =), but I found some topics maybe worth checking out: <br />
* [http://en.wikipedia.org/wiki/Bellman_equation Wikipedia: Bellman equation]<br />
* [http://en.wikipedia.org/wiki/Backward_induction Wikipedia: Backward induction] (found linked [http://en.wikipedia.org/wiki/Dynamic_programming#Algorithms_that_use_dynamic_programming here])<br />
--[[User:Voidious|Voidious]] 14:43, 15 July 2009 (UTC)<br />
<br />
I understand your point Voidious. But I think in any case, the whole concept is complex in such a way, it's good to break it up into different functions (like Darkcanuck has already done partially). How about you guys make the following functions for your versions: <br />
<pre><br />
double getMaxVelocity(double distance)<br />
{<br />
// returns the largest possible velocity for the robot to be set to,<br />
// that, if next turn it had to start decelerating, it would still be<br />
// able to stop without overshooting<br />
}<br />
</pre><br />
<br />
Basically, that would refine the problem. Because in that function you don't have to care about the current velocity. :) After this function returns, you only need to check if the returned velocity "wantedVelocity" is actually reachable from the current velocity by the accelerating/deceleration laws of robocode. And if not try to get closest to it (that won't cause any problems, because any speed returned lower than the max velocity won't overshoot either) :) <br />
<br />
So basically, the other function needed is:<br />
<pre><br />
double getClosestReachableVelocityToVelocity(double currentVelocity,double wantedVelocity)<br />
{<br />
// with this function you can basically assume setAhead(Infinity) or setAhead(-Infinity)<br />
// was called, and you determine the next velocity based on the max velocity<br />
// set by the robot. For example, if the current velocity is 0 and the max velocity<br />
// set was 4.0, it would return 1.0. If the current velocity was 8.0, it would return 6.0.<br />
} <br />
</pre><br />
Finally, the getNewVelocities final version would be (independant of the workings of the other functions):<br />
<pre><br />
double getNewVelocity(double velocity, double distance) <br />
{<br />
if(distance<0)<br />
return -getNewVelocity(-velocity,-distance);<br />
double highestVelocity = getMaxVelocity(distance); // highest velocity without overshooting<br />
double wantedVelocity = Math.min(highestVelocity,currentCommands.getMaxVelocity());<br />
// the actually wanted velocity by the robot is the highest possible,<br />
// limited by what the robot set by the setMaxVelocity command<br />
return getClosestReachableVelocityToVelocity(velocity, wantedVelocity);<br />
// return whatever is closest to that velocity<br />
}<br />
</pre><br />
--[[User:Positive|Positive]] 16:50, 15 July 2009 (UTC)<br />
<br />
: I didn't break anything up, just plugged the getNewVelocity functions into a simple (well, the latest version is no longer so simple) testing framework. The best solution is the one that gets the job done in the least code, while still remaining understandable. =) --[[User:Darkcanuck|Darkcanuck]] 17:48, 15 July 2009 (UTC)<br />
<br />
: I really like how you frame the problem here. I think I have a solution to getMaxVelocity at [[User:Voidious/Optimal Velocity]]. This seems like a much cooler and cleaner way to deal with this. --[[User:Voidious|Voidious]] 18:14, 15 July 2009 (UTC)<br />
<br />
:: Okay Darkcanuck, I understand. I just finished creating an implementation of the getClosestReachableVelocityToVelocity here: [[Positive/Optimal Velocity]]. I'll try to combine Voidious's getMaxVelocity routine with it and the code above, and post the results. --[[User:Positive|Positive]] 19:11, 15 July 2009 (UTC)<br />
<br />
It seems like it's working. I posted the results here [[Positive/Optimal Velocity]]. Great job Voidious with your getMaxVelocity function! --[[User:Positive|Positive]] 19:37, 15 July 2009 (UTC)<br />
<br />
You guys are truely amazing. Good job! I knew the "update movement" was non-trivial and could be complex when I tried to simplify things and get rid of the "bugs". But now it seems even much more complex. The rules are simple, but the code behind it complex?! I will put take all the code from the [[Positive/Optimal Velocity]] page and put into Robocode. Then I will make a new Alpha version, which everybody could try out to see if this is what we want in the next version of Robococe (1.7.1.4). And yes [[User:Positive|Positive]], your version of updateMovement is better. --[[User:FlemmingLarsen|Fnl]] 21:41, 15 July 2009 (UTC)<br />
<br />
: Yes, great team-work. And.. it's great to feel appreciated. :) Fnl, please include the temporary fix in the getMaxVelocity that was just added (to speed up robots that use setAhead(huge number)). --[[User:Positive|Positive]] 21:50, 15 July 2009 (UTC)<br />
<br />
: Cool! =) --[[User:Voidious|Voidious]] 22:25, 15 July 2009 (UTC)<br />
<br />
Okay, I will make sure the include the temporary fix. If we find a better solution later, I will of course update the code as well.<br />
<br />
'''Notice:''' If you are not a member of the [http://groups.google.com/group/robocode-developers Robocode Developers Discussion Group] then please do not hesitate with joining this group soon. The way you/we won't miss important aspects in our discussions about changes (and new features) in Robocode. --[[User:FlemmingLarsen|Fnl]] 22:07, 15 July 2009 (UTC)<br />
<br />
Ok, so I ran some tests. With both [[Diamond]] and [[SilverSurfer]], in both 1.6.1.4 and 1.7.1.3, I ran 100 seasons of 500-round [[Wave Surfing Challenge 2K6]]. We've banged on the 1.7.1.3 updateMovement code quite a bit now, and clearly it has changes that could affect both True Surfing (decel through 0) and Go-To (velocity selection). However, the results are extremely close (and surprisingly, 5 out of 6 of the scores are higher in 1.7.1.3.)<br />
<br />
{| border="1" style="border-collapse: collapse; font-size: 85%; color: black"<br />
| '''Bot'''<br />
| '''Bot A'''<br />
| '''Bot B'''<br />
| '''Bot C'''<br />
| '''Total'''<br />
|-<br />
| SilverSurfer 2.53.33<br />
| 99.84/99.85<br />
| 91.15/91.04<br />
| 85.77/85.81<br />
| '''92.25'''/'''92.23'''<br />
|-<br />
| Diamond 1.197<br />
| 99.92/99.93<br />
| 98.46/98.48<br />
| 96.94/96.98<br />
| '''98.44'''/'''98.47'''<br />
|}<br />
<br />
I'll be sure to run some more and different tests with the new Alpha, as well.<br />
<br />
--[[User:Voidious|Voidious]] 22:25, 15 July 2009 (UTC)<br />
<br />
Here is the new Alpha-1: http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-1-setup.jar --[[User:FlemmingLarsen|Fnl]] 22:39, 15 July 2009 (UTC)<br />
<br />
Hey Fnl, that last change Positive made at [[Positive/Optimal Velocity]] is an important one. Without it, setMaxVelocity actually doesn't work at all in this Alpha-1. (Tested with [[Jen]], who starts in a stop and go mode, but just moves full speed in the alpha.) <code>Math.min(highestVelocity,8.0)</code> should have <code>currentCommands.getMaxVelocity()</code> instead of 8.0. --[[User:Voidious|Voidious]] 00:04, 16 July 2009 (UTC)<br />
<br />
I just tested it too, and had the same results. --[[User:Positive|Positive]] 00:08, 16 July 2009 (UTC)<br />
<br />
I like this =) Although there still seems to me to be some clean solution that we've all missed, which doesn't involve different cases. Although it may be the tick-based environment that prevents that. However, Murphy be blamed, now that it's too late, I've finally come up with a decelDistance() function that doesn't have a loop:<br />
<pre><br />
private static final double decelDistance(double speed){<br />
double t = speed / Rules.DECELERATION;<br />
double floor_t = Math.floor(t);<br />
return 0.5*floor_t*(floor_t+1)*Rules.DECELERATION + (speed%Rules.DECELERATION)*Math.ceil(t);//used by Skilgannon's solution<br />
//return 0.5*floor_t*(floor_t-1)*Rules.DECELERATION + (speed%Rules.DECELERATION)*Math.ceil(t);//used by Voidious's solution<br />
}<br />
</pre><br />
--[[User:Skilgannon|Skilgannon]] 07:57, 16 July 2009 (UTC)<br />
<br />
Fnl, to save you from looking all over the place, I think the final evolution of the code is at:<br />
* [[Talk:Positive/Optimal Velocity#Hijack =)]] - old decel-through-zero rules<br />
* [[User:Voidious/Optimal Velocity#Hijack 2]] - new decel-through-zero rules<br />
As of now, Darkcanuck has tested the former but not the latter. You can take a look yourself and decide which you want to try in the next Alpha.<br />
<br />
--[[User:Voidious|Voidious]] 16:00, 16 July 2009 (UTC)<br />
<br />
Results for both can be found here: [[Talk:Darkcanuck/VelocityTest]]. I have yet to break either version, but I'll try... --[[User:Darkcanuck|Darkcanuck]] 16:04, 16 July 2009 (UTC)<br />
<br />
The section itself is 48KB now, longer than most pages =) Did we reach the conclusion on old decel-through-zero or new decel-through-zero rules yet? &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:51, 16 July 2009 (UTC)<br />
<br />
Well, that decision really is Fnl's. I don't think we debated it until there was a consensus among the rest of us. Personally, I believe that the effect on current bots will be immeasurably small. I will run some extensive tests to compare the versions, and hopefully the results will support this. (I've got some more of the 1.6.1.4 test runs going already.) --[[User:Voidious|Voidious]] 17:54, 16 July 2009 (UTC)<br />
<br />
Oh, I think he'll choose the new rules. The older conclusion is to makes Robocode follow its own rules better. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 18:09, 16 July 2009 (UTC)<br />
<br />
<br />
Sorry for the bad Alpha-1. The compiler did not see the update (?) I made on the source for the temporary fix. Nevermind, I have made two new alphas to try out:<br />
* [[Talk:Positive/Optimal Velocity#Hijack =)]] - old decel-through-zero rules - [http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-2-setup.jar Download Alpha 2]<br />
* [[User:Voidious/Optimal Velocity#Hijack 2]] - new decel-through-zero rules- [http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-3-setup.jar Download Alpha 3]<br />
<br />
Actually, I am not sure which version I prefer after this long discussion, but it seems to me that the new decel-through-zero rules is more correct. Actually, it was Mathew Nelson who mentioned that it ought to be fixed too, so that was my motivation for adding it. But I will let it up to you guys to decide.<br />
<br />
Btw. Nice job with making the source code smaller with the two Hijack versions.<br />
<br />
--[[User:FlemmingLarsen|Fnl]] 22:54, 16 July 2009 (UTC)<br />
<br />
Thanks, Fnl. I'm going to run quite a few tests with these two and 1.6.1.4 and post results. So far, [[Diamond]] 1.191 vs [[Barracuda]] over 500 battles (35 rounds) is 99.51 in 1.6.1.4 and 99.52 in 1.7.1.4-Alpha 3 -- not a bad start. =)<br />
<br />
I'm planning to test with [[Diamond]], [[Phoenix]], [[DrussGT]], and [[PrairieWolf]] (vs a few other bots). The first 3 because they are likely among the most precise bots out there, Diamond over Dookious because it's the same precision and surfing but twice as fast, and PrairieWolf because I know he has a +1/-1 movement mode. Maybe I should add [[Wintermute]]? If anyone has suggestions on who else I should test with (and maybe why), let me know. I will definitely do some tests with non-surfers, but surfers do seem the most precise and thus the most likely to be affected.<br />
<br />
--[[User:Voidious|Voidious]] 01:19, 17 July 2009 (UTC)<br />
<br />
FYI: From tomorrow and one week forward (week 30) I will be on a summer vacation in a rented summer cottage together with my family. If I am lucky, I will be able to access the Internet from there. But the connection might be slow. I will check out these pages while I am off, but I cannot promise that I will be able to compile everything into a new version, and I need to fix some other issues before I can release a 1.7.1.4 Beta. Until then, have fun with the alphas here. If other issues needs to be addressed as well, then please create a bug report on SourceForge so we can keep track of all issues. :-) --[[User:FlemmingLarsen|Fnl]] 21:56, 17 July 2009 (UTC)<br />
<br />
[[Sanguijuela]] v0.8 is a micro rambot using the Accel/decel trick. Please, let me know if I'm wrong, but as far as I understand, this trick will be inevitable useless in the future at the RoboRumble, right? If this is correct I will remove the trick and upload a new version (with 50 less of codesize :P ) and we will see the impact. Thanks! --[[User:Jab|jab]] 16:02, 13 August 2009 (UTC)<br />
<br />
Well, it depends on the result of the vote. You can vote against removing it, to tie the vote. --[[User:Positive|Positive]] 18:44, 13 August 2009 (UTC)<br />
<br />
Vote? Ok, it could be against my interests but I vote in favor of removing it. :D I read this discussion by chance while I was checking my bots ranking after more than a year and a half so I see the problem: There are many bots out there using the trick and thinking that others are using it. Many bots are not going to be updated... But it is a trick, we take the advantage of a robocode bug. I read once about the Teleport bug at the old wiki, it is not similar somehow? but the accel/decel bug seems to be accepted for a long time. Solutions? I think that there are two solutions: Removing the bug and reset the roborumble server and only allows newer versions as roborumble clients, or making this Accel/decel phenomenon part of the official [[Robocode/Game Physics]]. That could be another solution. What do you think? --[[User:Jab|jab]] 21:58, 13 August 2009 (UTC)</div>Jabhttp://robowiki.net/w/index.php?title=Talk:Robocode/Game_Physics&diff=10384Talk:Robocode/Game Physics2009-08-13T16:02:39Z<p>Jab: </p>
<hr />
<div>__TOC__<br />
== Robot hitbox ==<br />
I need to know percisely, which might involve rotating a rectangle, I don't know, if a point intersects my bot, given its X and Y location. Remeber that in Robocode, Y is reversed. While I'm at it, I might just ask: What your opinion is on whether I should do surfing or anti-gravity movement to dodge predicted bullets my robot simulates?<br />
--[[User:Awesomeness|Awesomeness]] 21:52, 3 May 2009 (UTC)<br />
<br />
The 'hitbox' of a robot is always a non-rotated square at the bot's location, so the former check is very very simple. As for your second question: It depends. Surfing is going to be stronger almost surely, however anti-gravity movement is considerably simpler. My suggestion would be to do anti-gravity for now, and at a later date try surfing once you feel comfortable with exactly how it works. --[[User:Rednaxela|Rednaxela]] 22:01, 3 May 2009 (UTC)<br />
<br />
Oh, is it a 40 pixel long sqare? that's what it looks like. --[[User:Awesomeness|Awesomeness]] 22:43, 3 May 2009 (UTC)<br />
<br />
No, it is 36px non-rotating square. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 23:42, 3 May 2009 (UTC)<br />
<br />
== Gun turn and fire execution order ==<br />
<br />
When, in the execution order, are bullets fired, and when is the gun turned? Thanks! --[[User:Mageek|Mageek]] 02:44, 28 May 2009 (UTC)<br />
<br />
I believe that's part of #2 in the "Robocode Processing Loop" section. I can tell you for sure, though, that if you do setFire and setTurnGunRight in the same turn, the bullet will fire at the bearing of your gun ''before'' that gun turn happens. Both of them happen on the next tick, but the bullet is fired as if it were fired on the same tick as setFire (the location is from that tick, and it has advanced by its velocity once). Does that answer your question? --[[User:Voidious|Voidious]] 02:53, 28 May 2009 (UTC)<br />
<br />
Thank-you, that is exactly what I was trying to figure out. --[[User:Mageek|Mageek]] 03:39, 28 May 2009 (UTC)<br />
<br />
== Accel/decel rules ==<br />
<br />
(Conversation began on [[Talk:Darkcanuck/RRServer]]...)<br />
<br />
I've almost finished my first robot to enter to the melee rumble :), but I'm wondering: does the (melee)server use the old accel/decel rules (where you can go from -1 to 1) or the new (where you can't)? --[[User:Positive|Positive]] 23:22, 11 Jul 2009<br />
<br />
The RoboRumble currently only allows clients using versions 1.5.4, 1.6.0, and 1.6.1.4, so it should only be the old rule (where you can). I actually didn't realize that was changed -- I really don't like that. =( Lots of legacy bots are programmed to believe you can. --[[User:Voidious|Voidious]] 21:24, 11 July 2009 (UTC)<br />
<br />
Woah, what a quick response! Thanks for the info. :) I don't really like the change either (I have a cool -1, +1 strategy and a nice move simulator), but alas. --[[User:Positive|Positive]] 23:36, 11 Jul 2009<br />
<br />
Are you sure the rules have changed? I thought the only changes to movement in later versions of Robocode (still unsupported in the rumble, btw) were to fix the movement quirks that Simonton had found. I don't remember decelerating through 0 being one of them. --[[User:Darkcanuck|Darkcanuck]] 22:26, 11 July 2009 (UTC)<br />
<br />
Here is the [http://sourceforge.net/tracker/?func=detail&aid=2793464&group_id=37202&atid=419486 discussion at the bug tracker]. Fnl explains that if for example your robot is at -1.0 velocity, it can only reach 0.75 velocity the next turn (as of version 1.7.1.2). --[[User:Positive|Positive]] 02:45, 12 Jul 2009<br />
<br />
Errr.... 0.75 is not 'accurate'... It's what robocode as of 1.7.1.2 does, but it's just as incorrect as before the change... Fnl says it uses a formula of <code>(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION *<br />
accelTime * accelTime)</code>, when the correct formula should be <code>(Rules.DECELERATION * decelTime + Rules.ACCELERATION * accelTime)</code>. Change in velocity, is always equal to acceleration multiplied by time, not time squared... It looks like Fnl got his physics mixed up and looked at a formula to get distance from acceleration (<code>d = a*t*t</code>) instead of getting velocity change from acceleration (<code>v = a*t</code>) :-( --[[User:Rednaxela|Rednaxela]] 01:47, 12 July 2009 (UTC)<br />
<br />
: Ooh, I see this now... Do some tests and file a bug for [[Fnl]]? --[[User:Darkcanuck|Darkcanuck]] 02:48, 12 July 2009 (UTC)<br />
<br />
:: Robocode Developer Google Groups, I think. So Flemming can re-open that tracker instead of creating new one. I always wonder why it go from 1 to -0.75, not 0.5 since it have only half turns left, I always think that I don't have enough physics knowledge. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 02:59, 12 July 2009 (UTC)<br />
<br />
Voidious, do you subscribe to [http://groups.google.com/group/robocode-developers Robocode Developer Google Groups]? I think we have reached the conclusion that we worth this change, unless there are too many effects. After we changed it, Flemming and I did run a lot of test (well, mostly Flemming run, I'd run only one test). I've test [[Dookious]] with [[DrussGT]], on both 1.6.1.4 and 1.7.1.x with new updateMovement(), and the difference is around 1-2%, which is acceptable in margin of error. I chose Dookious and DrussGT because I know that Dookious use FuturePosition library, which is the internal copy of old movement engine. And DrussGT use Skilgannon's special movement predictor which I believe should be the loosely implementation of the 'correct' movement engine.<br />
<br />
Positive, I believe that if you create a good movement under 1.6.1.4, it will be good in 1.7.1.x version too. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:20, 12 July 2009 (UTC)<br />
<br />
- - -<br />
<br />
Hi guys, to you mind I join the discussion? I did the change in "update movement" for many reasons. The issue(s) were raised a long time ago on the old RoboWiki (the 3 caveats raised by Simonton - http://old.robowiki.net/cgi-bin/robowiki?GamePhysics/BotSpeed), and later discussed within the Robocode Developer Group (even Mathew Nelson joined the discussion). That is, if we would make the change or not. Especially with you guys in mind. The conclusion in the groups was to fix the bugs so Robocode would follow its own rules, and because lot's of robots out there counts on the rules as explained, not to the way Robocode was actually behaving. Not everybody replicates the internal code of Robocode to get the formulas correct.<br />
<br />
The old closed bug tracker on SF created is available here: https://sourceforge.net/tracker/?func=detail&atid=419486&aid=2077512&group_id=37202<br />
<br />
Another goal with the change was to make the internal code easier less messy and easier to understand. Regarding the impact of the change, the results are not very different (unless you can prove me wrong here). I ran lots of lots of test with RoboRumble (also Melee and TeamRumble) on my local machines (different single-code, quad-core, Linux, Windows, 32 and 64 bit etc.), and I couldn't tell the difference in rankings or score with or without the change. There was a difference, but it was in average less than 1 percent. Is it really that much of a problem? Really?<br />
<br />
I would really love if people could try out the Betas on RoboRumble and put issues on SF as soon as they are discovered. Then the issues can be fixed or discussed before we do the real release. This way, we could avoid such issues as this one long time after the change was made and released.<br />
<br />
Btw. I am very familiar with physics, even tough the physics in Robocode does not really follow the real physics laws. I might not have explained the details about the fix well enough. <br />
<br />
Instead of shifting between old and new code (like you propose?), I should like you guys to tell me where the problem is in the code instead, since you are obviously the experts. The code is Open Source, so everybody is free to come with suggestions to what and where to correct things.<br />
<br />
Here we go:<br />
<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (dx != 0 || dy != 0) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
// If the distance is negative, then change it to be positive and change the sign of the input velocity and the result<br />
if (distance < 0) {<br />
return -getNewVelocity(-velocity, -distance);<br />
}<br />
<br />
double newVelocity;<br />
<br />
// Get the speed, which is always positive (because it is a scalar)<br />
final double speed = Math.abs(velocity); <br />
<br />
// Check if we are decelerating, i.e. if the velocity is negative.<br />
// Note that if the speed is too high due to a new max. velocity, we must also decelerate.<br />
if (velocity < 0 || speed > currentCommands.getMaxVelocity()) {<br />
// If the velocity is negative, we are decelerating<br />
newVelocity = speed - Rules.DECELERATION;<br />
<br />
// Check if we are going from deceleration into acceleration<br />
if (newVelocity < 0) {<br />
// If we have decelerated to velocity = 0, then the remaining time must be used for acceleration<br />
double decelTime = speed / Rules.DECELERATION;<br />
double accelTime = (1 - decelTime);<br />
<br />
// New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d<br />
// However, the new velocity must be limited by the max. velocity<br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,<br />
distance));<br />
<br />
// Note: We change the sign here due to the sign check later when returning the result<br />
velocity *= -1;<br />
}<br />
} else {<br />
// Else, we are not decelerating, but might need to start doing so due to the remaining distance<br />
<br />
// Deceleration time (t) is calculated by: v = a * t => t = v / a<br />
final double decelTime = speed / Rules.DECELERATION;<br />
<br />
// Deceleration time (d) is calculated by: d = 1/2 a * t^2 + v0 * t + t<br />
// Adding the extra 't' (in the end) is special for Robocode, and v0 is the starting velocity = 0<br />
final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;<br />
<br />
// Check if we should start decelerating<br />
if (distance <= decelDist) {<br />
// If the distance < max. deceleration distance, we must decelerate so we hit a distance = 0<br />
<br />
// Calculate time left for deceleration to distance = 0<br />
double time = distance / (decelTime + 1); // 1 is added here due to the extra 't' for Robocode<br />
<br />
// New velocity (v) = a * t, i.e. deceleration * time, but not greater than the current speed<br />
<br />
if (time <= 1) {<br />
// When there is only one turn left (t <= 1), we set the speed to match the remaining distance<br />
newVelocity = Math.max(speed - Rules.DECELERATION, distance);<br />
} else {<br />
// New velocity (v) = a * t, i.e. deceleration * time<br />
newVelocity = time * Rules.DECELERATION;<br />
<br />
if (speed < newVelocity) {<br />
// If the speed is less that the new velocity we just calculated, then use the old speed instead<br />
newVelocity = speed;<br />
} else if (speed - newVelocity > Rules.DECELERATION) {<br />
// The deceleration must not exceed the max. deceleration.<br />
// Hence, we limit the velocity to the speed minus the max. deceleration.<br />
newVelocity = speed - Rules.DECELERATION;<br />
}<br />
}<br />
} else {<br />
// Else, we need to accelerate, but only to max. velocity<br />
newVelocity = Math.min(speed + Rules.ACCELERATION, currentCommands.getMaxVelocity());<br />
}<br />
}<br />
<br />
// Return the new velocity with the correct sign. We have been working with the speed, which is always positive<br />
return (velocity < 0) ? -newVelocity : newVelocity;<br />
}<br />
</pre><br />
<br />
What must be corrected in order to make everybody happy, following the "physic laws" and rules of Robocode? --[[User:FlemmingLarsen|Fnl]] 22:59, 12 July 2009 (UTC)<br />
<br />
Fnl, it will take me some time to look over the code and discussions before I can give more constructive feedback. But some things I can comment on for now:<br />
* Fixing the issues Simonton brought up seems very reasonable to me. One is a bug that I doubt anyone depends on (the setMaxVelocity / decel). For the others, I'd guess [[DrussGT]] and [[SilverSurfer]] are the only bots that might simulate the quirks (being Go-To surfers). Some [[Wave Surfing Challenge]] tests with SS (I will run some) and feedback from Skilgannon could shed some light on potential impact.<br />
* I'm not clear on what has happened with this, but I believe changing the ability to go from velocity 1 to -1 could adversely impact a lot of bots. Even a bot as old as [[PrairieWolf]] (2002) has a movement mode that depends on it ("buzzing" between 1 and -1), and I'd guess nearly every modern wave surfer also simulates this aspect of the physics.<br />
* One percent ''is'' a lot -- see the "huge" 1% APS gap between DrussGT and Dookious =). That said, it takes hundreds or thousands of battles to get a result accurate enough to see that 1% difference.<br />
* I do not envy your position in these types of matters, and as always, I appreciate the effort you put into developing Robocode. Robocode's impact goes far beyond the "hardcore" Robocoders on this wiki, and I fully understand that you want to polish Robocode as best as you can for the benefit of everyone that uses it. Cheers,<br />
--[[User:Voidious|Voidious]] 00:01, 13 July 2009 (UTC)<br />
<br />
: 1 percent is ''not'' a lot with this major change in physics, especially when it makes the game follows its own rule better. 1% is 'huge' in APS, I agree. But if you look at each battle closely, the results can swing up to 10% &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
<br />
:: 1% is 1% and it ''is'' a lot. You're right that individual battles have a large variance, that's why you need to run hundreds of battles to get a meaningful result. If you run enough battles to get a statistically accurate result, 1% is a lot. If you don't run enough battles, you can't draw any real conclusion from the results. <br />
:: I'm not claiming there is a 1% difference in results. I'm only saying that if tests only narrowed it down to "1% or less", that's not really enough to satisfy my need for accuracy and consistency. No ill will here, I should get involved and run some tests if I care so much. And I do. And I will. =)<br />
:: --[[User:Voidious|Voidious]] 17:40, 13 July 2009 (UTC)<br />
<br />
::: While I wat to argue that 1% is ''not'' a lot for this major physics change, I don't think that is an issue anymore. I think you already accept the changes now =) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:37, 14 July 2009 (UTC)<br />
<br />
I've read the mailing list and bug report concerning the issue. Does the -1, +1 thing really need to be changed to fix the bugs? This is how I would code it, and I believe it should fix the bugs. I haven't actually compiled it into robocode, but the velocity routines themselves have been tested and are working. And excuse me, I'm a bad commenter :):<br />
<br />
<pre><br />
<br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
// small tweak from original version<br />
if(velocity!=0)<br />
{<br />
x+=velocity * sin(bodyHeading);<br />
y+=velocity * cos(bodyHeading);<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
static double getNewVelocity(double velocityArg, double distanceArg) <br />
{ <br />
double velocity;<br />
double distance;<br />
<br />
// Make sure the remaining distance is always positive or zero<br />
// (we switch this back later)<br />
if(distanceArg<0)<br />
{<br />
velocity=-velocityArg;<br />
distance=-distanceArg;<br />
}<br />
else<br />
{<br />
velocity=velocityArg;<br />
distance=distanceArg;<br />
}<br />
<br />
// Get the next most positive velocity the robot can reach for next turn<br />
double mostPositiveReachableVelocity = VelocityToMostPositiveVelocity(velocity);<br />
// Get the next most negative velocity the robot can reach for next turn<br />
double mostNegativeReachableVelocity = VelocityToMostNegativeVelocity(velocity);<br />
<br />
<br />
double highestWantedVelocity = Math.min(currentCommands.getMaxVelocity(), maxSpeedToStopInDisp(distance));<br />
<br />
// The real next velocity is limited by what is actually reachable<br />
double nextVelocity = Math.min(mostPositiveReachableVelocity,Math.max(mostNegativeReachableVelocity,highestWantedVelocity ));<br />
<br />
// Switch return value back if needed<br />
if(distanceArg<0)<br />
nextVelocity = -nextVelocity;<br />
<br />
return nextVelocity;<br />
}<br />
<br />
<br />
static public double VelocityToMostPositiveVelocity(double velocity)<br />
{<br />
// Returns the most positive reachable velocity from the<br />
// specified velocity in one turn<br />
if(velocity>0)<br />
{<br />
double returnVelocity = velocity+Rules.ACCELERATION;<br />
if(returnVelocity>Rules.MAX_VELOCITY)<br />
return Rules.MAX_VELOCITY;<br />
else<br />
return returnVelocity;<br />
}<br />
else<br />
{<br />
double returnVelocity = velocity+Rules.DECELERATION;<br />
if(returnVelocity>Rules.ACCELERATION)<br />
return Rules.ACCELERATION;<br />
else<br />
return returnVelocity;<br />
}<br />
}<br />
static public double VelocityToMostNegativeVelocity(double velocity)<br />
{<br />
// Returns the most negative reachable velocity from the<br />
// specified velocity in one turn<br />
if(velocity<0)<br />
{<br />
double returnVelocity = velocity-Rules.ACCELERATION;<br />
if(returnVelocity<-Rules.MAX_VELOCITY)<br />
return -Rules.MAX_VELOCITY;<br />
else<br />
return returnVelocity;<br />
}<br />
else<br />
{<br />
double returnVelocity = velocity-Rules.DECELERATION;<br />
if(returnVelocity<-Rules.ACCELERATION)<br />
return -Rules.ACCELERATION;<br />
else<br />
return returnVelocity;<br />
}<br />
}<br />
<br />
static private final double[] dispStopArray = <br />
{0.0000,1.0000,2.0000,2.5000,3.0000,<br />
3.5000,4.0000,4.3333,4.6666,5.0000,<br />
5.3333,5.6666,6.0000,6.2500,6.5000,<br />
6.7500,7.0000,7.2500,7.5000,7.7500};<br />
static public double maxSpeedToStopInDisp(double displacement)<br />
{<br />
// Returns the biggest velocity the robot could go to this turn,<br />
// still being able to stop without overshooting. (Or if <br />
// remaining displacement is less than 2, returns that)<br />
// This routine could be improved to match up with robocode's<br />
// older velocity selecting rules.<br />
if(displacement>=0)<br />
{<br />
if(displacement>=20)<br />
return 8.0;<br />
else if(displacement<=2)<br />
return displacement;<br />
else<br />
return dispStopArray[(int)Math.floor(displacement)];<br />
}<br />
else<br />
{<br />
return 0;<br />
}<br />
}<br />
</pre><br />
I also appreciate your effort, Fnl. :) --[[User:Positive|Positive]] 01:48, 13 July 2009 (UTC)<br />
<br />
Ok, I'm up to speed with the discussions and the code. I think, for how it was decided, this line:<br />
<pre><br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,<br />
distance));<br />
</pre><br />
...should be changed to:<br />
<pre><br />
newVelocity = Math.min(currentCommands.getMaxVelocity(),<br />
Math.min(Rules.ACCELERATION * accelTime, distance));<br />
</pre><br />
* The deceleration already takes you to zero, so we just need to use the remaining time for acceleration, right?<br />
* Don't need to square the accelTime (v = at).<br />
<br />
So, as I understand it, your velocities should be, for example: -1, +0.5, -0.75, +0.625? "Legacy" issues aside, I like this solution a lot. It makes sense. I've been considering this issue a bit now, and here's how I'd lay out the impact to affected bots:<br />
* A bot like [[PrairieWolf]] that oscillates between 1 and -1 will now oscillate between roughly 0.7 and -0.7. I'm ''guessing'' this has very minimal impact on performance (though I am curious to test / confirm).<br />
* When Wave Surfers predict a change of direction, their predictions could be off. I believe most surfers are dealing with whole number velocities the great majority of the time. Changing direction from even velocities will not be impacted. Changing direction from odd velocities, their predictions could be off by as much as 4 pixels -- predicting a velocity 0.5 too high for 8 ticks (until they reach max velocity). Some might disagree, and of course I advocate ultimate precision in surfing, but I believe the impact here is negligible. (How many of us even do precise bot width? And I never found much to be gained there, anyway.)<br />
* I'm still not crazy about changing Robocode's physics, and I might've opposed it if put to a vote, but I think the impact is negligible and the new solution is a good one. <br />
<br />
Also, I've started running those [[SilverSurfer]] WSC tests on 1.6.1.4 and 1.7.3 to compare. I'll have the results today or tomorrow.<br />
<br />
--[[User:Voidious|Voidious]] 15:31, 13 July 2009 (UTC)<br />
<br />
: The information in Robocode (mostly the floating point value) isn't digital, means that only 0.5 change isn't impact ''much''. If you can dodge bullets well, the missed 2 ticks with the most of 2 pixels won't make the bullet hit you. If you can't dodge it, the slippage of 2 pixels ''may'' make you dodged it, but only by luck. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
<br />
<Edit conflict> Thanks for taking a look Fnl. I personally think that the current code is more complicated than necessary, and as such, harder to understand. Here's a few things that should be addressed:<br />
* The decelDist. Because robocode follows a discrete time base, it cannot be approximated with calculus. For example, say your speed is 3, your formula gives 3.75 as decelDist. However, 3 + 1 + 0 = 4, so your code would not want to decelerate in the right places. This would be the correct implementation:<br />
<pre><br />
private static final double decelDistance(double velocity){<br />
double distance = 0;<br />
while(velocity > 0){<br />
distance += velocity;<br />
velocity = Math.max(0,velocity - Rules.DECELERATION);<br />
}<br />
return distance;<br />
}<br />
</pre><br />
* One of the ideas of robocode is that your bot has a continuous acceleration/deceleration over a single tick. I see what you have done is, when a bot is decelerating over 0 velocity, it takes 1/2 of the tick to decelerate and then 1/2 of the tick is left to accelerate in the other direction (the split may depend on the amount of time taken to decelerate to 0 first). But many older bots rely on being able to decelerate over the entire tick, using the 2 deceleration value instead of the 1 acceleration value, so that they can 'vibrate' from 1 to -1 back to 1 etc. While I agree that it is not correct, these are the physics of robocode, not real life =) Because of this, you can essentially remove the majority of the inside of that 'if' block, just leaving <code>velocity *= -1;</code>.<br />
* I have re-written this method, and if people want I'll post it, but it seems that with a few quick fixes this one should be up to scratch =), so I don't really think that's necessary.<br />
<br />
As an answer to [[Voidious]], I haven't taken any of the 'quirks' into account while writing DrussGT. It is coded with the rules, as they are described on the [[Robocode/Game_Physics]] page, in mind. --[[User:Skilgannon|Skilgannon]] 16:00, 13 July 2009 (UTC)<br />
<br />
: (edit conflict) In my tests, DrussGT usually performs worse. But just around 0.2% or somethings. I'm not sure since I ran only 3 35-rounds tests.<br />
: While I agree with you that this isn't real life, it still isn't correct under its own Rules. The major reason we have this fix is that we want Robocode to follows its own rule batter. Otherwise we should have the bullet velocity affected by robot velocity, the curved bullet, better bullet-bullet collision checking etc. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:14, 13 July 2009 (UTC)<br />
:: Sorry, but 3 battles simply cannot produce a result within 0.2% accuracy. In my experience, you'd need 100 or more before the overall result stays within 0.2%. --[[User:Voidious|Voidious]] 17:40, 13 July 2009 (UTC)<br />
<br />
Hi guys. Thank you for the constructive feedback. I appreciate that. I see many of you have some really good pointer of what to change, and where to make the changes. Currently, I have my house full of guests and is just checking what is going on in this forum. Tomorrow evening, I will take a closer look at all the comments, and I agree that the new implementation for "update movevement" is buggy too. I intend to create some variants that you can download and test for yourselves. Afterwards, you can choose which one is the better one for the next version of Robocode.<br />
Compared to 1.6.x.x, the code has become much simpler than it was before. I am not sure that the code could be any simpler than it is now as we will brake something else (because something is missing) - even though I hope it is possible.<br />
So, tomorrow I will review all comment on this page and take action. =) --[[User:FlemmingLarsen|Fnl]] 17:43, 13 July 2009 (UTC)<br />
<br />
I really agree that the code is a lot more simple and adaptable than 1.6 and before. When I was adapting the internal Robocode's movement engine for my movement predictor, I can't adapt the <1.6 code. I get my head mess when I'm trying to understand it. However, I can adapt the current code really easy (in fact, I did copy almost whole getNewVelocity() method) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:37, 14 July 2009 (UTC)<br />
<br />
I have examined all the comments here, and is trying to figure out how to modify the existing code for getNewVelocity(). I think you are on the right track [[Voidious]], and hence I want to implement your modifications so we could all try them out. However, I have a hard time figuring out how the modified version of getNewVelocity() will look like. If a change the part for the newVelocity, it must be in the two places in the code, where it is assigned. You have only written how you want the first one. [[Voidious]], could you give the full version of your version of getNewVelocity() as you think it should be? This way we all will be able to follow (and discuss) the changes/ideas, and I will be able to implement it straight away. :-) --[[User:FlemmingLarsen|Fnl]] 22:28, 14 July 2009 (UTC)<br />
<br />
Sorry, I was only closely examining the decelerating through zero issue before. I agree with Skilgannon's assessment that decelDist doesn't seem right, though I'm not sure I'm understanding this fully. Skilgannon, you say that decelDist(3) should be 4, but shouldn't it be 1, since we can update the speed before we move? In either case, I don't understand why it would be 3.75, but I'm curious if there is some voodoo at work in this code that I'm not getting yet. I'll study some more and try to figure it out. =) <br />
<br />
And Skilgannon, no harm in posting your rewritten version, I wouldn't mind seeing it. I'll also check out Positive's version. And I'll have some 1.6.1.4 vs 1.7.1.3 [[Wave Surfing Challenge 2K6|WSC2K6]] scores ready to examine tomorrow. Only about 180 more seasons to run. =)<br />
<br />
--[[User:Voidious|Voidious]] 00:23, 15 July 2009 (UTC)<br />
* My understanding (and subsequently, DrussGT's movement simulator, which uses a decelDistance based method of deciding when to decelerate) is if we go with the velocity of 3 this tick, how far will we travel in total if we decide it's necessary to decelerate next tick. ''Basically, do we have freedom with to do as we please with our velocity this tick, and still be able to decelerate sufficiently in the future''. If the answer is "no", then we need to decelerate ''or'' maintain velocity this tick. My statements about 4 and 3.75 assumed the DECELERATION is 2. Fnl gets 3.75 from this little bit of code:<br />
<pre><br />
final double decelTime = speed / Rules.DECELERATION;<br />
final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;<br />
</pre><br />
: ie. <code>3/2 = 1.5 --> 0.5*2*1.5*1.5 + 1.5 = 3.75</code> whereas it should be <code>3 + (3-2) = 4</code>. I'll be very interested to see what the scores look like =) --[[User:Skilgannon|Skilgannon]] 08:59, 15 July 2009 (UTC) <br />
<br />
Wow, this problem really is not trivial. Here's what I came up with, I think it works and is pretty minimal:<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (dx != 0 || dy != 0) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
// If the distance is negative, then change it to be positive and change the sign of the input velocity and the result<br />
if (distance < 0) {<br />
return -getNewVelocity(-velocity, -distance);<br />
}<br />
<br />
double newVelocity;<br />
<br />
// Get the speed, which is always positive (because it is a scalar)<br />
final double speed = Math.abs(velocity); <br />
<br />
if (velocity < 0) {<br />
// Check if we are decelerating, i.e. if the velocity is negative.<br />
newVelocity = speed - Rules.DECELERATION;<br />
<br />
// Check if we are going from deceleration into acceleration<br />
if (newVelocity < 0) {<br />
// If we have decelerated to velocity = 0, then the remaining time must be used for acceleration<br />
double decelTime = speed / Rules.DECELERATION;<br />
double accelTime = (1 - decelTime);<br />
<br />
// New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d<br />
// However, the new velocity must be limited by the max. velocity<br />
newVelocity = Math.min(Rules.ACCELERATION * accelTime, distance));<br />
<br />
// Note: We change the sign here due to the sign check later when returning the result<br />
velocity *= -1;<br />
}<br />
} else {<br />
// Deceleration distance (d) is calculated iteratively due to Robocode's<br />
// discrete time system.<br />
final double decelDist = decelDistance(speed);<br />
<br />
// Deceleration ticks is the number of ticks it will take to get to<br />
// zero velocity. <br />
final long decelTime = Math.round( // VOIDIOUS: for rounding errors? maybe unnecessary<br />
Math.ceil((speed - Rules.DECELERATION) / Rules.DECELERATION));<br />
<br />
// The maximum distance coverable with an equivalent decelTime<br />
final double decelTimeMaxDist = ((decelTime + 1) / 2.0) * decelTime // sum of 1..decelTime<br />
* Rules.DECELERATION;<br />
<br />
if (distance <= Rules.DECELERATION) {<br />
// If we can cover remaining distance and then completely stop,<br />
// set speed = distance<br />
newVelocity = Math.max(speed - Rules.DECELERATION, distance);<br />
} else if (distance <= decelTimeMaxDist) {<br />
// If we can cover distance in decelTime, split any extra<br />
// distance (between decelDist and distance) over decelTime<br />
// ticks<br />
newVelocity = speed - Rules.DECELERATION + <br />
((distance - decelDist) / decelTime);<br />
} else {<br />
// If we need more than decelTime ticks, try to spread the<br />
// extra distance over (decelTime + 1) ticks. This will just max <br />
// the acceleration if it needs to (ie, if we need more ticks).<br />
// VOIDIOUS: I think this part would break if Rules.ACCELERATION<br />
// were set above Rules.DECELERATION; we might need an <br />
// extra case or something. Doh. =(<br />
newVelocity = Math.min(speed + Rules.ACCELERATION,<br />
(decelTime * Rules.DECELERATION) +<br />
((distance - decelTimeMaxDist) / (decelTime + 1)));<br />
}<br />
}<br />
<br />
// VOIDIOUS: I think it makes more sense to do this here; no need to decelerate maximally<br />
// if you don't need to to accomodate a new setMaxVelocity.<br />
newVelocity = Math.max(speed - Rules.DECELERATION, <br />
Math.min(newVelocity, currentCommands.getMaxVelocity()));<br />
<br />
// Return the new velocity with the correct sign. We have been working with the speed, which is always positive<br />
return (velocity < 0) ? -newVelocity : newVelocity;<br />
}<br />
<br />
private static final double decelDistance(double speed){<br />
double distance = 0;<br />
while(speed > 0){<br />
speed = Math.max(0,speed - Rules.DECELERATION);<br />
distance += speed;<br />
}<br />
return distance;<br />
}<br />
</pre><br />
Velocity is updated before the bot moves, right? =) This is a serious brain teaser! Wanted to post what I had before bed, but I'm still not satisfied with the part that would break with different accel/decel values. --[[User:Voidious|Voidious]] 05:06, 15 July 2009 (UTC)<br />
<br />
(maybe we should move this lengthy discussion to another page?)<br />
I've been going through the new velocity formula and have similar concerns as [[Skilgannon]]. Just running some test cases using my [[Darkcanuck/VelocityTest | VelocityTest]] class and have found cases where the bot overshoots the requested distance (e.g. try starting velocity 0, distance 6 -- the bot ramps up to velocity 3 and will thus overshoot badly). I'll put together some tests and then maybe make a fixed version of the routine.<br />
<br />
Regarding deceleration through 0, I have to sympathize with Fnl et al. There's nothing in the rules that says a bot can decelerate through 0 and gain some free acceleration. Deceleration takes you towards 0, acceleration takes you away from it. It's a quirk -- often called a "bug" -- that was perhaps first publicized [http://oldtestwiki.roborumble.org/cgi-bin/robowiki?GamePhysics here] (near bottom) and has been exploited since. Its not a huge quirk, the advantage is minimal so fixing it should also be minimal but only tests can really confirm this.<br />
<br />
--[[User:Darkcanuck|Darkcanuck]] 05:09, 15 July 2009 (UTC)<br />
<br />
Hey Fellas. Great you're doing more research into this! I think the -1, +1 thing is not a major issue, but if the incorrect movement handling bugs can be fixed in a way that the -1, +1 thing stays valid, is there any harm? I think the version I posted is simpler to understand, and it should work effectively. The only thing that you might not agree with is the working of the maxSpeedToStopInDisp function, but that should at least centralize the problem. :) --[[User:Positive|Positive]] 05:53, 15 July 2009 (UTC)<br />
<br />
: I'm sorry I haven't examined yours more. There are two reasons, really:<br />
:* It does look like you're solving the problem efficiently (and I assume correctly), but I think it depends on fixing one or all of Rules.DECELERATION, Rules.ACCELERATION, and maximum velocity=8. I think we want a solution independent of those values.<br />
:* I find this quite an enjoyable brain teaser, and just wanted to figure out an answer myself. =)<br />
:--[[User:Voidious|Voidious]] 13:26, 15 July 2009 (UTC)<br />
<br />
: I did test your solution and it passes all the same tests that Voidious' version 2 does. But as he pointed out, the hardcoded values are problematic. --[[User:Darkcanuck|Darkcanuck]] 17:48, 15 July 2009 (UTC)<br />
<br />
The reason I don't like breaking the +-1 thing is because it makes the precise prediction significantly more complicated, and what's more it assumes that the acceleration has more than one value between 2 ticks, which to me seems to break the whole concept of a discrete time interval. For interests sake, here's the one I wrote:<br />
<pre><br />
private void updateMovement() {<br />
double distance = currentCommands.getDistanceRemaining();<br />
<br />
if (Double.isNaN(distance)) {<br />
distance = 0;<br />
}<br />
<br />
velocity = getNewVelocity(velocity, distance);<br />
<br />
double dx = velocity * sin(bodyHeading);<br />
double dy = velocity * cos(bodyHeading);<br />
<br />
x += dx;<br />
y += dy;<br />
<br />
if (velocity != 0 ) {<br />
updateBoundingBox();<br />
}<br />
<br />
if (distance != 0) {<br />
currentCommands.setDistanceRemaining(distance - velocity);<br />
}<br />
}<br />
<br />
/**<br />
* Returns the new velocity based on the current velocity and distance to move.<br />
*<br />
* @param velocity the current velocity<br />
* @param distance the distance to move<br />
* @return the new velocity based on the current velocity and distance to move<br />
*/<br />
private double getNewVelocity(double velocity, double distance) {<br />
<br />
if (distance < 0) <br />
return -getNewVelocity(-velocity, -distance);<br />
// If the distance is negative, then change it to be positive<br />
// and change the sign of the input velocity and the result<br />
<br />
double maxVel = currentCommands.getMaxVelocity();<br />
if (velocity < 0)<br />
return Math.min(velocity + Rules.DECELERATION, maxVel);<br />
//we want to go in the opposite direction, so decelerate <br />
<br />
else{ <br />
//we are going in the direction we want, test what happens if we accelerate<br />
<br />
double accel = Math.min(Rules.ACCELERATION, maxVel - velocity);<br />
//speed up, but not more than max velocity. decel if maxVel is less than velocity.<br />
<br />
accel = Math.max(accel, -Rules.DECELERATION);<br />
//prevent excess deceleration due to bot lowering the maxVel while velocity is high<br />
<br />
if (distance > decelDistance(velocity + accel))<br />
return velocity + accel;<br />
else if(accel != 0 && distance > decelDistance(velocity))<br />
return velocity;<br />
else{<br />
if(distance < Rules.DECELERATION <br />
//we'll be able to cover remaining distance in 1 tick and then decel to stop<br />
<br />
&& velocity - distance <= Rules.DECELERATION <br />
//and our velocity is low enough for us to get to that required velocity<br />
)<br />
return Math.min(distance, maxVel);<br />
//choose the velocity to cover all remaining distance <br />
<br />
return Math.max(-maxVel, velocity - Rules.DECELERATION);<br />
//velocity > 0 and we are close enough, so decelerate. <br />
}<br />
<br />
}<br />
<br />
}<br />
/**<br />
* Returns the linear distance it would take to decelerate from a given positive velocity<br />
*<br />
* @param velocity the positive velocity from which to test<br />
* @return the linear distance required to decelerate to a standstill<br />
*/<br />
private static final double decelDistance(double velocity){<br />
double distance = 0;<br />
while(velocity > 0){<br />
distance += velocity;<br />
velocity = Math.max(0,velocity - Rules.DECELERATION);<br />
}<br />
return distance;<br />
} <br />
</pre><br />
I'm fairly sure this fixes the 0,6 test Darkcanuck is doing. Voidious, one of the problems with your decelDistance() implementation is that your decel distance assumes you decelerate before adding the distance, whereas mine checks if we can still accelerate this tick and be able to decelerate sufficiently in the future. Also, mine considers the case of continuing at the current velocity, which may be a better option, as in the 0,6 test. --[[User:Skilgannon|Skilgannon]] 08:27, 15 July 2009 (UTC)<br />
<br />
: I agree that the new formulas do break the simplicity of the discrete time period. One simple solution would be simply to apply deceleration until 0 velocity is reached -- the extra time for acceleration would be lost. That would both follow the rules and keep the accel/decel values simple. But Fnl's solution does compromise by giving back the extra time for some acceleration, which should help bots that rely on this quirk. --[[User:Darkcanuck|Darkcanuck]] 16:29, 15 July 2009 (UTC)<br />
<br />
(I agree about moving this to a different or its own page. Anyone can feel free, or I'll do it in a bit.) Ah, I'm just imagining a different significance to decelDist: I imagine it as the minimum distance we would cover if we slam on the brakes. The problem with the (0, 6) case (more specifically the (2, 3) case) in mine is similar to the problem I theorize about when Rules.accel is greater than Rules.decel: I assume that if you can't cover ''distance'' in decelTime ticks, you can split the extra distance over (decelTime + 1) ticks, which of course is 1 tick and you go to speed 3. Maybe I should force decelTime to a min of 1, since if it's 0 and distance <= Rules.decel, we hit the first case and don't use it, otherwise we hit the 3rd case and need 2 ticks.<br />
<br />
Mine would also remain at constant velocity if needed, or even speed up a bit, despite lack of a special case. I'll have to investigate that 0 to -2 acceleration... hopefully that's a simple fix. <br />
<br />
I forgot that you'd already be familiar with this kinda stuff, since you are the Lord of Go-To. =) But I still see a problem with yours in that you restrict your decisions to max accel, constant, or max decel. Take the v=6.1, d=15 case: you want to do it in 4 ticks, and mine will (I think =)) go 6.75, 4.75, 2.75, 0.75. I think yours would go 6.1, 4.1, then be presented with (4.1, 4.8) and fail to do it in 4 ticks.<br />
<br />
I swear there must be a known Dynamic Programming problem that reduces to this. Maybe my effort would be better spent finding it and copying the established solution. =) To be clear, we are trying to do this in the optimal number of ticks, right?<br />
<br />
--[[User:Voidious|Voidious]] 13:26, 15 July 2009 (UTC)<br />
<br />
* Yep, what we are attempting to do is minimize number of ticks until velocity and distance are 0. The implementation I have in DrussGT is a highly simplified version of what I posted, and probably runs about 10 times faster =) --[[User:Skilgannon|Skilgannon]] 7:57, 16 July 2009 (UTC)<br />
<br />
I updated my method and posted it to [[User:Voidious/Optimal Velocity]]. I think this fixes both the (2, 3) case and the (0, 2) case, though I feel like the (2, 3) case should go 2/1 instead of 1.5/1.5. Can we agree that Rules.DECELERATION will never be less than Rules.ACCELERATION? Or just accept that caveat in our solutions? I believe changing that would seriously complicate things. --[[User:Voidious|Voidious]] 14:28, 15 July 2009 (UTC)<br />
<br />
Ok, I really need to stop thinking about this and get some work done =), but I found some topics maybe worth checking out: <br />
* [http://en.wikipedia.org/wiki/Bellman_equation Wikipedia: Bellman equation]<br />
* [http://en.wikipedia.org/wiki/Backward_induction Wikipedia: Backward induction] (found linked [http://en.wikipedia.org/wiki/Dynamic_programming#Algorithms_that_use_dynamic_programming here])<br />
--[[User:Voidious|Voidious]] 14:43, 15 July 2009 (UTC)<br />
<br />
I understand your point Voidious. But I think in any case, the whole concept is complex in such a way, it's good to break it up into different functions (like Darkcanuck has already done partially). How about you guys make the following functions for your versions: <br />
<pre><br />
double getMaxVelocity(double distance)<br />
{<br />
// returns the largest possible velocity for the robot to be set to,<br />
// that, if next turn it had to start decelerating, it would still be<br />
// able to stop without overshooting<br />
}<br />
</pre><br />
<br />
Basically, that would refine the problem. Because in that function you don't have to care about the current velocity. :) After this function returns, you only need to check if the returned velocity "wantedVelocity" is actually reachable from the current velocity by the accelerating/deceleration laws of robocode. And if not try to get closest to it (that won't cause any problems, because any speed returned lower than the max velocity won't overshoot either) :) <br />
<br />
So basically, the other function needed is:<br />
<pre><br />
double getClosestReachableVelocityToVelocity(double currentVelocity,double wantedVelocity)<br />
{<br />
// with this function you can basically assume setAhead(Infinity) or setAhead(-Infinity)<br />
// was called, and you determine the next velocity based on the max velocity<br />
// set by the robot. For example, if the current velocity is 0 and the max velocity<br />
// set was 4.0, it would return 1.0. If the current velocity was 8.0, it would return 6.0.<br />
} <br />
</pre><br />
Finally, the getNewVelocities final version would be (independant of the workings of the other functions):<br />
<pre><br />
double getNewVelocity(double velocity, double distance) <br />
{<br />
if(distance<0)<br />
return -getNewVelocity(-velocity,-distance);<br />
double highestVelocity = getMaxVelocity(distance); // highest velocity without overshooting<br />
double wantedVelocity = Math.min(highestVelocity,currentCommands.getMaxVelocity());<br />
// the actually wanted velocity by the robot is the highest possible,<br />
// limited by what the robot set by the setMaxVelocity command<br />
return getClosestReachableVelocityToVelocity(velocity, wantedVelocity);<br />
// return whatever is closest to that velocity<br />
}<br />
</pre><br />
--[[User:Positive|Positive]] 16:50, 15 July 2009 (UTC)<br />
<br />
: I didn't break anything up, just plugged the getNewVelocity functions into a simple (well, the latest version is no longer so simple) testing framework. The best solution is the one that gets the job done in the least code, while still remaining understandable. =) --[[User:Darkcanuck|Darkcanuck]] 17:48, 15 July 2009 (UTC)<br />
<br />
: I really like how you frame the problem here. I think I have a solution to getMaxVelocity at [[User:Voidious/Optimal Velocity]]. This seems like a much cooler and cleaner way to deal with this. --[[User:Voidious|Voidious]] 18:14, 15 July 2009 (UTC)<br />
<br />
:: Okay Darkcanuck, I understand. I just finished creating an implementation of the getClosestReachableVelocityToVelocity here: [[Positive/Optimal Velocity]]. I'll try to combine Voidious's getMaxVelocity routine with it and the code above, and post the results. --[[User:Positive|Positive]] 19:11, 15 July 2009 (UTC)<br />
<br />
It seems like it's working. I posted the results here [[Positive/Optimal Velocity]]. Great job Voidious with your getMaxVelocity function! --[[User:Positive|Positive]] 19:37, 15 July 2009 (UTC)<br />
<br />
You guys are truely amazing. Good job! I knew the "update movement" was non-trivial and could be complex when I tried to simplify things and get rid of the "bugs". But now it seems even much more complex. The rules are simple, but the code behind it complex?! I will put take all the code from the [[Positive/Optimal Velocity]] page and put into Robocode. Then I will make a new Alpha version, which everybody could try out to see if this is what we want in the next version of Robococe (1.7.1.4). And yes [[User:Positive|Positive]], your version of updateMovement is better. --[[User:FlemmingLarsen|Fnl]] 21:41, 15 July 2009 (UTC)<br />
<br />
: Yes, great team-work. And.. it's great to feel appreciated. :) Fnl, please include the temporary fix in the getMaxVelocity that was just added (to speed up robots that use setAhead(huge number)). --[[User:Positive|Positive]] 21:50, 15 July 2009 (UTC)<br />
<br />
: Cool! =) --[[User:Voidious|Voidious]] 22:25, 15 July 2009 (UTC)<br />
<br />
Okay, I will make sure the include the temporary fix. If we find a better solution later, I will of course update the code as well.<br />
<br />
'''Notice:''' If you are not a member of the [http://groups.google.com/group/robocode-developers Robocode Developers Discussion Group] then please do not hesitate with joining this group soon. The way you/we won't miss important aspects in our discussions about changes (and new features) in Robocode. --[[User:FlemmingLarsen|Fnl]] 22:07, 15 July 2009 (UTC)<br />
<br />
Ok, so I ran some tests. With both [[Diamond]] and [[SilverSurfer]], in both 1.6.1.4 and 1.7.1.3, I ran 100 seasons of 500-round [[Wave Surfing Challenge 2K6]]. We've banged on the 1.7.1.3 updateMovement code quite a bit now, and clearly it has changes that could affect both True Surfing (decel through 0) and Go-To (velocity selection). However, the results are extremely close (and surprisingly, 5 out of 6 of the scores are higher in 1.7.1.3.)<br />
<br />
{| border="1" style="border-collapse: collapse; font-size: 85%; color: black"<br />
| '''Bot'''<br />
| '''Bot A'''<br />
| '''Bot B'''<br />
| '''Bot C'''<br />
| '''Total'''<br />
|-<br />
| SilverSurfer 2.53.33<br />
| 99.84/99.85<br />
| 91.15/91.04<br />
| 85.77/85.81<br />
| '''92.25'''/'''92.23'''<br />
|-<br />
| Diamond 1.197<br />
| 99.92/99.93<br />
| 98.46/98.48<br />
| 96.94/96.98<br />
| '''98.44'''/'''98.47'''<br />
|}<br />
<br />
I'll be sure to run some more and different tests with the new Alpha, as well.<br />
<br />
--[[User:Voidious|Voidious]] 22:25, 15 July 2009 (UTC)<br />
<br />
Here is the new Alpha-1: http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-1-setup.jar --[[User:FlemmingLarsen|Fnl]] 22:39, 15 July 2009 (UTC)<br />
<br />
Hey Fnl, that last change Positive made at [[Positive/Optimal Velocity]] is an important one. Without it, setMaxVelocity actually doesn't work at all in this Alpha-1. (Tested with [[Jen]], who starts in a stop and go mode, but just moves full speed in the alpha.) <code>Math.min(highestVelocity,8.0)</code> should have <code>currentCommands.getMaxVelocity()</code> instead of 8.0. --[[User:Voidious|Voidious]] 00:04, 16 July 2009 (UTC)<br />
<br />
I just tested it too, and had the same results. --[[User:Positive|Positive]] 00:08, 16 July 2009 (UTC)<br />
<br />
I like this =) Although there still seems to me to be some clean solution that we've all missed, which doesn't involve different cases. Although it may be the tick-based environment that prevents that. However, Murphy be blamed, now that it's too late, I've finally come up with a decelDistance() function that doesn't have a loop:<br />
<pre><br />
private static final double decelDistance(double speed){<br />
double t = speed / Rules.DECELERATION;<br />
double floor_t = Math.floor(t);<br />
return 0.5*floor_t*(floor_t+1)*Rules.DECELERATION + (speed%Rules.DECELERATION)*Math.ceil(t);//used by Skilgannon's solution<br />
//return 0.5*floor_t*(floor_t-1)*Rules.DECELERATION + (speed%Rules.DECELERATION)*Math.ceil(t);//used by Voidious's solution<br />
}<br />
</pre><br />
--[[User:Skilgannon|Skilgannon]] 07:57, 16 July 2009 (UTC)<br />
<br />
Fnl, to save you from looking all over the place, I think the final evolution of the code is at:<br />
* [[Talk:Positive/Optimal Velocity#Hijack =)]] - old decel-through-zero rules<br />
* [[User:Voidious/Optimal Velocity#Hijack 2]] - new decel-through-zero rules<br />
As of now, Darkcanuck has tested the former but not the latter. You can take a look yourself and decide which you want to try in the next Alpha.<br />
<br />
--[[User:Voidious|Voidious]] 16:00, 16 July 2009 (UTC)<br />
<br />
Results for both can be found here: [[Talk:Darkcanuck/VelocityTest]]. I have yet to break either version, but I'll try... --[[User:Darkcanuck|Darkcanuck]] 16:04, 16 July 2009 (UTC)<br />
<br />
The section itself is 48KB now, longer than most pages =) Did we reach the conclusion on old decel-through-zero or new decel-through-zero rules yet? &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:51, 16 July 2009 (UTC)<br />
<br />
Well, that decision really is Fnl's. I don't think we debated it until there was a consensus among the rest of us. Personally, I believe that the effect on current bots will be immeasurably small. I will run some extensive tests to compare the versions, and hopefully the results will support this. (I've got some more of the 1.6.1.4 test runs going already.) --[[User:Voidious|Voidious]] 17:54, 16 July 2009 (UTC)<br />
<br />
Oh, I think he'll choose the new rules. The older conclusion is to makes Robocode follow its own rules better. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 18:09, 16 July 2009 (UTC)<br />
<br />
<br />
Sorry for the bad Alpha-1. The compiler did not see the update (?) I made on the source for the temporary fix. Nevermind, I have made two new alphas to try out:<br />
* [[Talk:Positive/Optimal Velocity#Hijack =)]] - old decel-through-zero rules - [http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-2-setup.jar Download Alpha 2]<br />
* [[User:Voidious/Optimal Velocity#Hijack 2]] - new decel-through-zero rules- [http://robocode.sf.net/files/robocode-1.7.1.4-Alpha-3-setup.jar Download Alpha 3]<br />
<br />
Actually, I am not sure which version I prefer after this long discussion, but it seems to me that the new decel-through-zero rules is more correct. Actually, it was Mathew Nelson who mentioned that it ought to be fixed too, so that was my motivation for adding it. But I will let it up to you guys to decide.<br />
<br />
Btw. Nice job with making the source code smaller with the two Hijack versions.<br />
<br />
--[[User:FlemmingLarsen|Fnl]] 22:54, 16 July 2009 (UTC)<br />
<br />
Thanks, Fnl. I'm going to run quite a few tests with these two and 1.6.1.4 and post results. So far, [[Diamond]] 1.191 vs [[Barracuda]] over 500 battles (35 rounds) is 99.51 in 1.6.1.4 and 99.52 in 1.7.1.4-Alpha 3 -- not a bad start. =)<br />
<br />
I'm planning to test with [[Diamond]], [[Phoenix]], [[DrussGT]], and [[PrairieWolf]] (vs a few other bots). The first 3 because they are likely among the most precise bots out there, Diamond over Dookious because it's the same precision and surfing but twice as fast, and PrairieWolf because I know he has a +1/-1 movement mode. Maybe I should add [[Wintermute]]? If anyone has suggestions on who else I should test with (and maybe why), let me know. I will definitely do some tests with non-surfers, but surfers do seem the most precise and thus the most likely to be affected.<br />
<br />
--[[User:Voidious|Voidious]] 01:19, 17 July 2009 (UTC)<br />
<br />
FYI: From tomorrow and one week forward (week 30) I will be on a summer vacation in a rented summer cottage together with my family. If I am lucky, I will be able to access the Internet from there. But the connection might be slow. I will check out these pages while I am off, but I cannot promise that I will be able to compile everything into a new version, and I need to fix some other issues before I can release a 1.7.1.4 Beta. Until then, have fun with the alphas here. If other issues needs to be addressed as well, then please create a bug report on SourceForge so we can keep track of all issues. :-) --[[User:FlemmingLarsen|Fnl]] 21:56, 17 July 2009 (UTC)<br />
<br />
[[Sanguijuela]] v0.8 is a micro rambot using the Accel/decel trick. Please, let me know if I'm wrong, but as far as I understand, this trick will be inevitable useless in the future at the RoboRumble, right? If this is correct I will remove the trick and upload a new version (with 50 less of codesize :P ) and we will see the impact. Thanks! --[[User:Jab|jab]] 16:02, 13 August 2009 (UTC)</div>Jabhttp://robowiki.net/w/index.php?title=ManuelGallegus&diff=2444ManuelGallegus2008-07-09T17:43:35Z<p>Jab: How ManuelGallegus reach the TOP100!</p>
<hr />
<div>; <nowiki>Sub-pages: </nowiki><br />
: '''[[/Version History]]'''<br />
<br />
{{Infobox Robot<br />
| bgcolour = #AAAAFF<br />
| author = [[User:Jab|Jab]]<br />
| license = [[RWPCL]]<br />
}}<br />
<br />
== Background Info ==<br />
; How competitive is it?<br />
ManuelGallegus 0.6 reached the '''''Top-100''''' on 9th July 2008<br />
<br />
[[Image:ManuelGallegusTop100.png|thumb|651 px|center| The following figure shows his evolution and the reasons that I think were determinant for his success. For more details visit the Version History.]]<br />
<br />
== Additional Info ==<br />
; Where did you get the name?<br />
Manué is from Galicia.<br />
<br />
; Can I use your code?<br />
Of course! You are talking about ManuelGallegus so he is under an open source license.<br />
<br />
Go to [[/Version History]] to download the last version.<br />
<br />
It's also based on the Module bot structure.<br />
<br />
[[Category:Bots|ManuelGallegus]]<br />
[[Category:MegaBots|ManuelGallegus]]<br />
[[Category:1-vs-1 Bots|ManuelGallegus]]<br />
[[Category:Open Source Bots|ManuelGallegus]]</div>Jabhttp://robowiki.net/w/index.php?title=File:ManuelGallegusTop100.png&diff=2443File:ManuelGallegusTop100.png2008-07-09T17:37:48Z<p>Jab: The following figure shows ManuelGallegus evolution to reach the Top100.</p>
<hr />
<div>The following figure shows ManuelGallegus evolution to reach the Top100.</div>Jabhttp://robowiki.net/w/index.php?title=ManuelGallegus/Version_History&diff=2442ManuelGallegus/Version History2008-07-09T17:33:29Z<p>Jab: ManuelGallegus 0.6 Version</p>
<hr />
<div>= ManuelGallegus 0.6 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.6.jar Download]<br />
<br />
'''Released:''' 8 July 2008<br />
<br />
'''Ratings Date:''' 9 July 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 99<br />
| 1834.19<br />
| 2003<br />
|}<br />
<br />
== What's new ==<br />
''Radar''<br />
* WideLock Radar working correctly.<br />
<br />
''Movement''<br />
* Keep the distance from the enemy at the beginning.<br />
* Increased Wall Smoothing constant.<br />
* When the enemy hits the wall we don't throw waves.<br />
* Remove wave on virtual hit after bulletHitBullet event.<br />
<br />
''Targeting''<br />
* Calculate correctly the wave targeting_offset. Bug fixed.<br />
<br />
<br />
= ManuelGallegus 0.5 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.5.jar Download]<br />
<br />
'''Released:''' 5 July 2008<br />
<br />
'''Ratings:''' Not available because of roborumble corrupted results. Position 107<br />
<br />
== What's new ==<br />
* Save targeting and movement brain when we don't win the 70% of the battles.<br />
* Include pre-saved data.<br />
<br />
''Targeting''<br />
* Remove the maximum limit for the visits (255) because we only save to file the most visited.<br />
* For each wave add two visits if the offset is repeated.<br />
* For each wave add one extra visit to the most visited offset, and if each offset is visited once add the extra visit in the middle of the segment.<br />
<br />
= ManuelGallegus 0.4 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.4.jar Download]<br />
<br />
'''Released:''' 25 June 2008<br />
<br />
'''Ratings Date:''' 5 July 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 111<br />
| 1814.41<br />
| 2082<br />
|}<br />
<br />
== What's new ==<br />
* Save targeting and movement brain when we don't win the 60% of the battles.<br />
<br />
''Movement''<br />
* Add enemy bullet power segment.<br />
* Save and restore a small brain with the offset of the maximum risk.<br />
<br />
''Targeting''<br />
* Use byte instead of int to reduce the size of the brain.<br />
<br />
<br />
= ManuelGallegus 0.3 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.3.jar Download]<br />
<br />
'''Released:''' 22 June 2008<br />
<br />
'''Ratings Date:''' 25 June 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 107<br />
| 1815.23<br />
| 2015<br />
|}<br />
<br />
== What's new ==<br />
''Movement''<br />
* Take into account BulletHitBullet event and create a nonexistent enemy bullet that could hit us.<br />
<br />
''Targeting''<br />
* Delete data from old versions of the enemy.<br />
* Save and restore a small brain with only the maximum offset for each segment.<br />
* Save brain if the data already exists or if we lose more than the 45 percent of the battles.<br />
* If there is no visits in the segment use LinearTargeting instead of Head-On.<br />
<br />
<br />
= ManuelGallegus 0.2 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.2.jar Download]<br />
<br />
'''Released:''' 17 June 2008<br />
<br />
'''Ratings Date:''' 22 June 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 136<br />
| 1780.78<br />
| 2029<br />
|}<br />
<br />
== What's new ==<br />
''Specials''<br />
* RamBot flag<br />
<br />
''Movement''<br />
* Distance segmentation improvement. Not only add risk in the current distance, also add something at the previous and next segment.<br />
* AntiRamming movement based on an adaptation of AntiGravity movement.<br />
<br />
''Targeting''<br />
* Save brain only if we lose more than the 60 percent of the battles.<br />
<br />
== Comments ==<br />
<br />
Results against the main RamBots out there.<br />
<br />
{| cellpadding="3"<br />
! BotName<br />
! V0.1 %Score<br />
! V0.2 %Score<br />
|-<br />
| jab.micro.Sanguijuela_0.8<br />
| 51,3<br />
| 59,4<br />
|-<br />
| gh.micro.GrubbmThree_0.9<br />
| 51<br />
| 57,7<br />
|-<br />
| mz.NanoDeath_2.56<br />
| 49,3<br />
| 59,9<br />
|-<br />
| demetrix.nano.SledgeHammer_0.22<br />
| 52,6<br />
| 60,5<br />
|}<br />
<br />
<br />
= ManuelGallegus 0.1 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.1.jar Download]<br />
<br />
'''Released:''' 13 June 2008<br />
<br />
'''Ratings Date:''' 17 June 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 147<br />
| 1765.17<br />
| 2079<br />
|}<br />
<br />
== What's new ==<br />
''Movement''<br />
* BasicSurfer with distance segmentation.<br />
<br />
''Targeting''<br />
* GuessFactor targeting with distance, lateral velocity and distance from the walls segmentation.<br />
* Always save the brain.</div>Jabhttp://robowiki.net/w/index.php?title=ManuelGallegus&diff=2441ManuelGallegus2008-07-09T15:48:05Z<p>Jab: /* Background Info */</p>
<hr />
<div>; <nowiki>Sub-pages: </nowiki><br />
: '''[[/Version History]]'''<br />
<br />
{{Infobox Robot<br />
| bgcolour = #AAAAFF<br />
| author = [[User:Jab|Jab]]<br />
| license = [[RWPCL]]<br />
}}<br />
<br />
== Background Info ==<br />
; How competitive is it?<br />
ManuelGallegus 0.6 reached the '''''Top-100''''' on 9th July 2008<br />
<br />
== Additional Info ==<br />
; Where did you get the name?<br />
Manué is from Galicia.<br />
<br />
; Can I use your code?<br />
Of course! You are talking about ManuelGallegus so he is under an open source license.<br />
<br />
Go to [[/Version History]] to download the last version.<br />
<br />
It's also based on the Module bot structure.<br />
<br />
[[Category:Bots|ManuelGallegus]]<br />
[[Category:MegaBots|ManuelGallegus]]<br />
[[Category:1-vs-1 Bots|ManuelGallegus]]<br />
[[Category:Open Source Bots|ManuelGallegus]]</div>Jabhttp://robowiki.net/w/index.php?title=ManuelGallegus&diff=2405ManuelGallegus2008-07-06T20:46:26Z<p>Jab: Manuel Gallegus</p>
<hr />
<div>; <nowiki>Sub-pages: </nowiki><br />
: '''[[/Version History]]'''<br />
<br />
{{Infobox Robot<br />
| bgcolour = #AAAAFF<br />
| author = [[User:Jab|Jab]]<br />
| license = [[RWPCL]]<br />
}}<br />
<br />
== Background Info ==<br />
; What's special about it?<br />
He's close to enter in the position #100 or better!<br />
<br />
== Additional Info ==<br />
; Where did you get the name?<br />
Manué is from Galicia.<br />
<br />
; Can I use your code?<br />
Of course! You are talking about ManuelGallegus so he is under an open source license.<br />
<br />
Go to [[/Version History]] to download the last version.<br />
<br />
It's also based on the Module bot structure.<br />
<br />
[[Category:Bots|ManuelGallegus]]<br />
[[Category:MegaBots|ManuelGallegus]]<br />
[[Category:1-vs-1 Bots|ManuelGallegus]]<br />
[[Category:Open Source Bots|ManuelGallegus]]</div>Jabhttp://robowiki.net/w/index.php?title=ManuelGallegus/Version_History&diff=2403ManuelGallegus/Version History2008-07-06T20:33:45Z<p>Jab: ManuelGallegus Version History</p>
<hr />
<div>= ManuelGallegus 0.5 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.5.jar Download]<br />
<br />
'''Released:''' 5 July 2008<br />
<br />
== What's new ==<br />
* Save targeting and movement brain when we don't win the 70% of the battles.<br />
* Include pre-saved data.<br />
<br />
''Targeting''<br />
* Remove the maximum limit for the visits (255) because we only save to file the most visited.<br />
* For each wave add two visits if the offset is repeated.<br />
* For each wave add one extra visit to the most visited offset, and if each offset is visited once add the extra visit in the middle of the segment.<br />
<br />
= ManuelGallegus 0.4 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.4.jar Download]<br />
<br />
'''Released:''' 25 June 2008<br />
<br />
'''Ratings Date:''' 5 July 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 111<br />
| 1814.41<br />
| 2082<br />
|}<br />
<br />
== What's new ==<br />
* Save targeting and movement brain when we don't win the 60% of the battles.<br />
<br />
''Movement''<br />
* Add enemy bullet power segment.<br />
* Save and restore a small brain with the offset of the maximum risk.<br />
<br />
''Targeting''<br />
* Use byte instead of int to reduce the size of the brain.<br />
<br />
<br />
= ManuelGallegus 0.3 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.3.jar Download]<br />
<br />
'''Released:''' 22 June 2008<br />
<br />
'''Ratings Date:''' 25 June 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 107<br />
| 1815.23<br />
| 2015<br />
|}<br />
<br />
== What's new ==<br />
''Movement''<br />
* Take into account BulletHitBullet event and create a nonexistent enemy bullet that could hit us.<br />
<br />
''Targeting''<br />
* Delete data from old versions of the enemy.<br />
* Save and restore a small brain with only the maximum offset for each segment.<br />
* Save brain if the data already exists or if we lose more than the 45 percent of the battles.<br />
* If there is no visits in the segment use LinearTargeting instead of Head-On.<br />
<br />
<br />
= ManuelGallegus 0.2 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.2.jar Download]<br />
<br />
'''Released:''' 17 June 2008<br />
<br />
'''Ratings Date:''' 22 June 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 136<br />
| 1780.78<br />
| 2029<br />
|}<br />
<br />
== What's new ==<br />
''Specials''<br />
* RamBot flag<br />
<br />
''Movement''<br />
* Distance segmentation improvement. Not only add risk in the current distance, also add something at the previous and next segment.<br />
* AntiRamming movement based on an adaptation of AntiGravity movement.<br />
<br />
''Targeting''<br />
* Save brain only if we lose more than the 60 percent of the battles.<br />
<br />
== Comments ==<br />
<br />
Results against the main RamBots out there.<br />
<br />
{| cellpadding="3"<br />
! BotName<br />
! V0.1 %Score<br />
! V0.2 %Score<br />
|-<br />
| jab.micro.Sanguijuela_0.8<br />
| 51,3<br />
| 59,4<br />
|-<br />
| gh.micro.GrubbmThree_0.9<br />
| 51<br />
| 57,7<br />
|-<br />
| mz.NanoDeath_2.56<br />
| 49,3<br />
| 59,9<br />
|-<br />
| demetrix.nano.SledgeHammer_0.22<br />
| 52,6<br />
| 60,5<br />
|}<br />
<br />
<br />
= ManuelGallegus 0.1 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.1.jar Download]<br />
<br />
'''Released:''' 13 June 2008<br />
<br />
'''Ratings Date:''' 17 June 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 147<br />
| 1765.17<br />
| 2079<br />
|}<br />
<br />
== What's new ==<br />
''Movement''<br />
* BasicSurfer with distance segmentation.<br />
<br />
''Targeting''<br />
* GuessFactor targeting with distance, lateral velocity and distance from the walls segmentation.<br />
* Always save the brain.</div>Jabhttp://robowiki.net/w/index.php?title=ManuelGallegus/Version_History&diff=2305ManuelGallegus/Version History2008-06-23T20:19:12Z<p>Jab: ManuelGallegus version history</p>
<hr />
<div>= ManuelGallegus 0.3 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.3.jar Download]<br />
<br />
'''Released:''' 22 June 2008<br />
<br />
== What's new ==<br />
''Movement''<br />
* Take into account BulletHitBullet event and create a nonexistent enemy bullet that could hit us.<br />
<br />
''Targeting''<br />
* Delete data from old versions of the enemy.<br />
* Save and restore a small brain with only the maximum offset for each segment.<br />
* Save brain if the data already exists or if we lose more than the 45 percent of the battles.<br />
* If there is no visits in the segment use LinearTargeting instead of Head-On.<br />
<br />
<br />
= ManuelGallegus 0.2 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.2.jar Download]<br />
<br />
'''Released:''' 17 June 2008<br />
<br />
'''Ratings Date:''' 22 June 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 136<br />
| 1780.78<br />
| 2029<br />
|}<br />
<br />
== What's new ==<br />
''Specials''<br />
* RamBot flag<br />
<br />
''Movement''<br />
* Distance segmentation improvement. Not only add risk in the current distance, also add something at the previous and next segment.<br />
* AntiRamming movement based on an adaptation of AntiGravity movement.<br />
<br />
''Targeting''<br />
* Save brain only if we lose more than the 60 percent of the battles.<br />
<br />
== Comments ==<br />
<br />
Results against the main RamBots out there.<br />
<br />
{| cellpadding="3"<br />
! BotName<br />
! V0.1 %Score<br />
! V0.2 %Score<br />
|-<br />
| jab.micro.Sanguijuela_0.8<br />
| 51,3<br />
| 59,4<br />
|-<br />
| gh.micro.GrubbmThree_0.9<br />
| 51<br />
| 57,7<br />
|-<br />
| mz.NanoDeath_2.56<br />
| 49,3<br />
| 59,9<br />
|-<br />
| demetrix.nano.SledgeHammer_0.22<br />
| 52,6<br />
| 60,5<br />
|}<br />
<br />
<br />
= ManuelGallegus 0.1 =<br />
[http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.1.jar Download]<br />
<br />
'''Released:''' 13 June 2008<br />
<br />
'''Ratings Date:''' 17 June 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
| 147<br />
| 1765.17<br />
| 2079<br />
|}<br />
<br />
== What's new ==<br />
''Movement''<br />
* BasicSurfer with distance segmentation.<br />
<br />
''Targeting''<br />
* GuessFactor targeting with distance, lateral velocity and distance from the walls segmentation.<br />
* Always save the brain.</div>Jabhttp://robowiki.net/w/index.php?title=ManuelGallegus&diff=2304ManuelGallegus2008-06-23T19:43:11Z<p>Jab: ManuelGallegus</p>
<hr />
<div>; <nowiki>Sub-pages: </nowiki><br />
: '''[[/Version History]]'''<br />
<br />
{{Infobox Robot<br />
| bgcolour = #AAAAFF<br />
| author = [[User:Jab|Jab]]<br />
| license = [[RWPCL]]<br />
| download_link = http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.3.jar<br />
| source_link = http://www.freewebs.com/robocode/bots/Tests/jab.avk.ManuelGallegus_0.3.jar<br />
}}<br />
<br />
== Background Info ==<br />
; What's special about it?<br />
Many things.<br />
<br />
== Additional Info ==<br />
; Where did you get the name?<br />
Manué is from Galicia.<br />
<br />
; Can I use your code?<br />
Of course! You are talking about ManuelGallegus so he is under an open source license.<br />
<br />
It's also based on the Module bot structure.<br />
<br />
[[Category:Bots|ManuelGallegus]]<br />
[[Category:MegaBots|ManuelGallegus]]<br />
[[Category:1-vs-1 Bots|ManuelGallegus]]<br />
[[Category:Open Source Bots|ManuelGallegus]]</div>Jabhttp://robowiki.net/w/index.php?title=Module&diff=2095Module2008-05-08T19:04:59Z<p>Jab: </p>
<hr />
<div>; <nowiki>Parts Repository:</nowiki><br />
: '''[[/Movement]] - [[/Targeting]] - [[/Radar]] - [[/Gun]] - [[/SelectEnemy]] - [[/Special]]'''<br />
<br />
{{Infobox Robot<br />
| bgcolour = #CCCCFF<br />
| current_version = 0.2<br />
| download_link = http://robocoderepository.com/BotDetail.jsp?id=3378<br />
}}<br />
<br />
== Introduction ==<br />
<br />
Module is a simple bot structure that can be extended to create your own bots. There are many other approaches ([http://www.ibm.com/developerworks/java/library/j-tipreuse.html AbstractBot], [[PluggableRobot]]...) and most of the mega Bots use some kind of modular architecture. <br />
<br />
Main advantages:<br />
*Ease of maintenance<br />
*Reusability capacity<br />
<br />
Module is also intended to be the reference for the beginners to see the different techniques through a reusable parts repository.<br />
<br />
== Get started ==<br />
<br />
[http://robocoderepository.com/BotDetail.jsp?id=3378 Download Module] and take a look at the class ExampleBot that extends Module to see how it works. Then look at the packages movement, targeting etc. to see the implementation that comes with the example.<br />
Now you can build your own independent reusable parts for your bots using the Module structure, or check the parts repository to learn new techniques.<br />
<br />
<br />
== Details ==<br />
<br />
==== Bot parts ====<br />
<br />
The following parts define the bot behavior in Module.<br />
<br />
[[Image:moduleBotParts.png|Movement, Gun, Targeting, Radar and SelectEnemy]]<br />
<br />
*Movement: Move and turn the bot<br />
*Gun: Choose the power of the bullet and fires<br />
*Targeting: Turn the gun to aim the enemies<br />
*Radar: Turn the radar to scan the enemies<br />
*SelectEnemy: Select the current enemy from the list of enemies in the battlefield<br />
*Special: Do whatever you want in that parts<br />
<br />
<br />
<br />
==== Module manages ====<br />
*Information about the enemies<br />
*Information about my own bullets<br />
*Information about enemy bullets<br />
<br />
*Graphical debug of the parts<br />
<br />
<br />
==== License ====<br />
*Module is released with the license [[RWLPCL]]<br />
*Each part of the Parts Repository can have its own license<br />
<br />
<br />
==== Version History ====<br />
*V0.2 Now special parts can be activated/deactivated<br />
*V0.1 Initial version<br />
<br />
[[Category:Tutorials]]</div>Jabhttp://robowiki.net/w/index.php?title=Module&diff=2094Module2008-05-08T19:04:29Z<p>Jab: New Version of Module</p>
<hr />
<div>; <nowiki>Parts Repository:</nowiki><br />
: '''[[/Movement]] - [[/Targeting]] - [[/Radar]] - [[/Gun]] - [[/SelectEnemy]] - [[/Special]]'''<br />
<br />
{{Infobox Robot<br />
| bgcolour = #CCCCFF<br />
| current_version = 0.1<br />
| download_link = http://robocoderepository.com/BotDetail.jsp?id=3378<br />
}}<br />
<br />
== Introduction ==<br />
<br />
Module is a simple bot structure that can be extended to create your own bots. There are many other approaches ([http://www.ibm.com/developerworks/java/library/j-tipreuse.html AbstractBot], [[PluggableRobot]]...) and most of the mega Bots use some kind of modular architecture. <br />
<br />
Main advantages:<br />
*Ease of maintenance<br />
*Reusability capacity<br />
<br />
Module is also intended to be the reference for the beginners to see the different techniques through a reusable parts repository.<br />
<br />
== Get started ==<br />
<br />
[http://robocoderepository.com/BotDetail.jsp?id=3378 Download Module] and take a look at the class ExampleBot that extends Module to see how it works. Then look at the packages movement, targeting etc. to see the implementation that comes with the example.<br />
Now you can build your own independent reusable parts for your bots using the Module structure, or check the parts repository to learn new techniques.<br />
<br />
<br />
== Details ==<br />
<br />
==== Bot parts ====<br />
<br />
The following parts define the bot behavior in Module.<br />
<br />
[[Image:moduleBotParts.png|Movement, Gun, Targeting, Radar and SelectEnemy]]<br />
<br />
*Movement: Move and turn the bot<br />
*Gun: Choose the power of the bullet and fires<br />
*Targeting: Turn the gun to aim the enemies<br />
*Radar: Turn the radar to scan the enemies<br />
*SelectEnemy: Select the current enemy from the list of enemies in the battlefield<br />
*Special: Do whatever you want in that parts<br />
<br />
<br />
<br />
==== Module manages ====<br />
*Information about the enemies<br />
*Information about my own bullets<br />
*Information about enemy bullets<br />
<br />
*Graphical debug of the parts<br />
<br />
<br />
==== License ====<br />
*Module is released with the license [[RWLPCL]]<br />
*Each part of the Parts Repository can have its own license<br />
<br />
<br />
==== Version History ====<br />
*V0.2 Now special parts can be activated/deactivated<br />
*V0.1 Initial version<br />
<br />
[[Category:Tutorials]]</div>Jabhttp://robowiki.net/w/index.php?title=File:ModuleBotParts.png&diff=2093File:ModuleBotParts.png2008-05-08T18:43:29Z<p>Jab: uploaded a new version of "Image:ModuleBotParts.png"</p>
<hr />
<div>Module bot structure parts</div>Jabhttp://robowiki.net/w/index.php?title=File:ModuleBotParts.png&diff=2092File:ModuleBotParts.png2008-05-08T18:41:13Z<p>Jab: uploaded a new version of "Image:ModuleBotParts.png"</p>
<hr />
<div>Module bot structure parts</div>Jabhttp://robowiki.net/w/index.php?title=Robocode/Console_Usage&diff=2086Robocode/Console Usage2008-05-07T08:00:49Z<p>Jab: </p>
<hr />
<div>This page describes how to run Robocode from a console.<br />
<br />
== Starting Robocode ==<br />
Robocode is normally started by the robocode.bat (on Windows) or robocode.sh (on Linux and Mac OS) batch files. The batch files is used for setting required parameters for the Java VM in order to start and run Robocode properly.<br />
<br />
Robocode is started from a console by writing:<br />
<pre><br />
java -Xmx512M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar:libs/codesize.jar robocode.Robocode<br />
</pre><br />
Here you must stand in the 'robocode' directory where Robocode is installed.<br />
<br />
* <code>java</code> is the command used for running the Java VM.<br />
* <code>-Xmx512M</code> sets the ''maximum'' heap size the Java VM to 512 MB RAM.<br />
* <code>-Dsun.io.useCanonCaches=false</code> prevents SecurityExceptions to occur when running code outside of Robocode's secured sandbox.<br />
* <code>-cp libs/robocode.jar;libs/codesize.jar</code> specifies the required .jar files for running Robocode.<br />
* <code>robocode.Robocode</code> specifies the main entry class of the Robocode game.<br />
<br />
With all of the above, Robocode will startup with a graphical user interface (GUI) waiting for user inputs.<br />
But it is possible to change the way Robocode is started how it must run. That is, you can specify additional parameters to the command line that is used for running Robocode. These parameters are described in the following.<br />
<br />
== Console Usage ==<br />
<pre><br />
Usage: robocode [-cwd path] [-battle filename [-results filename] [-tps tps]<br />
[-minimize] [-nodisplay] [-nosound]]<br />
<br />
where options include:<br />
-cwd <path> Change the current working directory<br />
-battle <battle file> Run the battle specified in a battle file<br />
-results <file> Save results to the specified text file<br />
-tps <tps> Set the TPS (Turns Per Second) to use<br />
-minimize Run minimized when Robocode starts<br />
-nodisplay Run with the display / GUI disabled<br />
-nosound Run with sound disabled<br />
<br />
properties include:<br />
-DWORKINGDIRECTORY=<path> Set the current working directory<br />
-DNOSECURITY=true|false Enable or disable Robocode's security manager<br />
-Ddebug=true|false Enable or disable System.err messages<br />
</pre><br />
<br />
=== Example 1 - Running a battle ===<br />
In this first example, Robocode is running the 'sample.battle' from the 'battles' directory without the display (GUI), and where the results are written out to the file named 'results.txt':<br />
<pre><br />
java -Xmx512M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar robocode.Robocode<br />
-battle battles\sample.battle -nodisplay -results results.txt<br />
</pre><br />
<br />
[[Category:Robocode_Documentation]]<br />
<br />
=== Example 2 - Disabling security ===<br />
With this example the security manager is disabled, which allows a developer to let robots access files and classes from outside Robocode:<br />
<pre><br />
java -Xmx512M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar robocode.Robocode<br />
-DNOSECURITY=true<br />
</pre><br />
This allows a robot developer to let a robot access 3<sup>rd</sup> party libraries with suport for e.g. neural networks and similar.<br />
<br />
== See Also ==<br />
* [[Robocode/System Requirements|System Requirements for Robocode]]<br />
* [[Robocode/Download|How to download and install Robocode]]<br />
* [[Robocode/Getting Started|Getting started with Robocode]]<br />
* [[Robocode/FAQ|Frequently Asked Questions (FAQ)]]<br />
<br />
[[Category:Robocode_Documentation]]</div>Jabhttp://robowiki.net/w/index.php?title=Talk:Current_events&diff=2081Talk:Current events2008-05-04T17:15:57Z<p>Jab: Undo</p>
<hr />
<div>[[User:AaronR|AaronR]]: Note that the image links I put on the "Robocode Documentation" pages are temporary. I will replace these with uploaded images later. My first priority is to '''add''' ''all'' documentations. Second priority is "goal plate" the pages. But anybody is welcome to replace the links with uploaded images. ;-) --[[User:FlemmingLarsen|Flemming N. Larsen]] 11:44, 28 November 2007 (UTC)<br />
* Sorry about that, I wasn't sure what pattern you are following. I was going to update this page anyway, and I need to remove one of the items from the list to make room for a new item, so I'll remove the Robocode Documentation one and let you work in peace. ;) --<code>[[User:AaronR|AaronR]]</code> 18:28, 28 November 2007 (UTC)<br />
<br />
== News section, or the lack of such ==<br />
I am wondering.. where do we have a News section? I should at least want a page about news, which again contains a link with "Robocode News", and other people should provide links to interesting stuff on the News page for other matters. So, where should we put it? --[[User:FlemmingLarsen|Fnl]] 22:28, 21 January 2008 (UTC)<br />
:Right here! I believe that was the point of this page. At present, it only contains the contents of {{Tl|CurrentEventsShort}}, but that isn't mandatory (the template version is just a summary of events for the [[Main Page]], hence the name CurrentEvents''Short''). « [[User:AaronR|AaronR]] « [[User talk:AaronR|Talk]] « 20:35, 24 January 2008 (UTC)<br />
::This page now has a separate list from the Main Page, so you can add all the news you want to it. =) By the way, does anyone else think it might be a good idea to move this page into the project namespace (i.e. [[RoboWiki:Current events]])? « [[User:AaronR|AaronR]] « [[User talk:AaronR|Talk]] « 21:10, 24 January 2008 (UTC)</div>Jabhttp://robowiki.net/w/index.php?title=Sanguijuela/Evolution_History&diff=2074Sanguijuela/Evolution History2008-04-27T15:07:22Z<p>Jab: Ratings of evolution 0.7 and what is new at 0.8</p>
<hr />
<div>= Sanguijuela 0.8 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.8.jar Download]<br />
<br />
'''Released:''' 27 April 2008<br />
<br />
'''Codesize:''' 748<br />
<br />
== What's new ==<br />
* Implementation of the deceleration acceleration trick when changing direction.<br />
* Faster in some other special cases.<br />
<br />
<br />
= Sanguijuela 0.7 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.7.jar Download]<br />
<br />
'''Released:''' 20 April 2008<br />
<br />
'''Codesize:''' 588<br />
<br />
'''Ratings Date:''' 27 April 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
! General<br />
| 263<br />
| 1647.54<br />
| 2419<br />
|-<br />
! Mini<br />
| 108<br />
| 1669.87<br />
| 1374<br />
|-<br />
! Micro<br />
| 68<br />
| 1660.69<br />
| 988<br />
|}<br />
<br />
== What's new ==<br />
* Bug fix. When going to the center, stop if the discovered host is not correctly aligned.<br />
* Internal restructuration (Code rewrite).<br />
<br />
== Comments ==<br />
Some codesize left and better performance than evolution 0.6.<br />
<br />
<br />
= Sanguijuela 0.6 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.6.jar Download]<br />
<br />
'''Released:''' 10 April 2008<br />
<br />
'''Codesize:''' 724<br />
<br />
'''Ratings Date:''' 20 April 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
! General<br />
| 262<br />
| 1641.37<br />
| 2043<br />
|-<br />
! Mini<br />
| 109<br />
| 1663.45<br />
| 1038<br />
|-<br />
! Micro<br />
| 67<br />
| 1656.76<br />
| 711<br />
|}<br />
<br />
== What's new ==<br />
* Rollback to linear movement and targeting. The branch of evolution started with 0.4 is over.<br />
* Bug fix that prevents Sanguijuela losing a turn when turning to face the enemy at the beginning.<br />
* Go to the center of the territory until there is no host.<br />
<br />
== Comments ==<br />
Better results than evolution 0.3 but Sanguijuela is still 7.66 points away from GrubbmThree.<br />
<br />
<br />
= Sanguijuela 0.5 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.5.jar Download]<br />
<br />
'''Released:''' 2 April 2008<br />
<br />
'''Codesize:''' 635<br />
<br />
'''Ratings '''Battles:''' 3108<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| <br />
| 1631.88<br />
|}<br />
<br />
== What's new ==<br />
* Choose each round between Linear (90%) and Circular (10%) movement and targeting<br />
* Change the calculation of the best initial Radar direction using [[Smash]] method by [[User:Starrynte | Starrynte]]. My code got the same results but with more codesize.<br />
<br />
== Comments ==<br />
It was not good idea but I wanted to try it.<br />
Looking at the comparison between 0.3 and 0.4, Linear is better in a 76% of the conflictive cases.<br />
If I choose between Linear (90%) and Circular (10%) strategy then<br />
<br />
p(ok)= p(s=L)*P(ok|s=L) + p(s=C)*P(ok|s=C) = P(ok)*P(s=L) + P(ok)P(s=C) =0.76*0.9 + 0.24*0.1 =70.8<br />
<br />
So Sanguijuela lost 5.2% of the conflictive cases but I thought that adding this variability in the strategy could be interesting. The 0.3 (only Linear) has still better performance.<br />
<br />
<br />
= Sanguijuela 0.4 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.4.jar Download]<br />
<br />
'''Released:''' 24 March 2008<br />
<br />
'''Codesize:''' 727<br />
<br />
'''Ratings Date:''' 1 April 2008 '''Battles:''' 2388<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| 296 / 616<br />
| 1619.14<br />
|-<br />
! Mini<br />
| 116 / 306<br />
| 1650.26<br />
|-<br />
! Micro<br />
| 72 / 209<br />
| 1645.37<br />
|}<br />
<br />
== What's new ==<br />
* Change Radar from WideLock to NarrowLock.<br />
* Change linear movement and targeting to circular. The predicted position of the enemy use 8 as velocity for the movement and 11 for the targeting.<br />
<br />
== Comments ==<br />
Involution. After some testing I thought that a circular movement and targeting could be better than linear but, in general, it seems to be false. The previous version appears and disappears misteriously in the RoboRumble so I could make these statistics. <br />
<br />
[[Image:SanguijuelaComparison.jpg|thumb|300px|center| Comparison for v0.3 Linear and v0.4 Circular]]<br />
<br />
<br />
= Sanguijuela 0.3 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.3.jar Download]<br />
<br />
'''Released:''' 8 January 2008<br />
<br />
'''Codesize:''' 749<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
! General<br />
| <br />
| 1638.62<br />
| 4326<br />
|}<br />
<br />
'''Ratings Date:''' 18 January 2008 '''Battles:''' 2024<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| 253 / 604<br />
| 1624.67<br />
|-<br />
! General PL<br />
| 279 / 604<br />
| 612<br />
|-<br />
! Mini<br />
| 108 / 302<br />
| 1643.79<br />
|-<br />
! Mini PL<br />
| 122 / 302<br />
| 338<br />
|-<br />
! Micro<br />
| 67 / 203<br />
| 1645.21<br />
|-<br />
! Micro PL<br />
| 75 / 203<br />
| 236<br />
|}<br />
<br />
== What's New ==<br />
<br />
* Now Sanguijuela doesn’t ignore the walls in the linear movement and targeting.<br />
* It doesn’t bite before it is close to the enemy. (350 pixels).<br />
<br />
<br />
= Sanguijuela 0.2 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.2.jar Download]<br />
<br />
'''Released:''' 6 January 2008<br />
<br />
'''Codesize:''' 743<br />
<br />
== What's New ==<br />
<br />
* Code reduced to 743. Now Sanguijuela is a MicroBot.<br />
* Sanguijuela ignores the walls when moving and targeting.<br />
<br />
== ToDo ==<br />
* '''Done v0.3:''' Don’t ignore the walls and mantain the micro category.<br />
<br />
== Comments ==<br />
<br />
I have tested Sanguijuela's ramming performance (V0.2) with the archived results of [[RamBotChallenge2K6]] (two years ago) and it takes the 3rd place.<br />
<br />
{| border="1" cellspacing="0" cellpadding="3" align="center"<br />
! Bot<br />
! Ramming Percentage<br />
! Overall Score<br />
|-<br />
| [[MaxRisk]] 0.6<br />
| 24.65<br />
| 46.39<br />
|-<br />
| [[SledgeHammer]] 0.22<br />
| 21.42<br />
| 45.26<br />
|-<br />
| [[Sanguijuela]] 0.2<br />
| 21.86<br />
| 44.11<br />
|-<br />
| [[ARAMtocles]] 0.3<br />
| 20.65<br />
| 44.05<br />
|-<br />
| [[NanoDeath]] 2.56<br />
| 23.60<br />
| 43.85<br />
|}<br />
<br />
<br />
= Sanguijuela 0.1 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.Sanguijuela_0.1.jar Download]<br />
<br />
'''Released:''' 5 January 2008<br />
<br />
'''Codesize:''' 869<br />
<br />
== Origin ==<br />
<br />
* Linear Ramming and Targeting.<br />
* It calculates the best direction to start scanning.<br />
* It chooses ramming with the anterior or the posterior suckers depending on host's starting position.</div>Jabhttp://robowiki.net/w/index.php?title=Sanguijuela/Evolution_History&diff=2063Sanguijuela/Evolution History2008-04-22T19:05:14Z<p>Jab: Sanguijuela Evolution History 0.6 and 0.7</p>
<hr />
<div>= Sanguijuela 0.7 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.7.jar Download]<br />
<br />
'''Released:''' 20 April 2008<br />
<br />
'''Codesize:''' 588<br />
<br />
== What's new ==<br />
* Bug fix. When going to the center, stop if the discovered host is not correctly aligned.<br />
* Internal restructuration (Code rewrite).<br />
<br />
== Comments ==<br />
Some codesize left and better performance than evolution 0.6.<br />
<br />
<br />
= Sanguijuela 0.6 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.6.jar Download]<br />
<br />
'''Released:''' 10 April 2008<br />
<br />
'''Codesize:''' 724<br />
<br />
'''Ratings Date:''' 20 April 2008<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
! General<br />
| 262<br />
| 1641.37<br />
| 2043<br />
|-<br />
! Mini<br />
| 109<br />
| 1663.45<br />
| 1038<br />
|-<br />
! Micro<br />
| 67<br />
| 1656.76<br />
| 711<br />
|}<br />
<br />
== What's new ==<br />
* Rollback to linear movement and targeting. The branch of evolution started with 0.4 is over.<br />
* Bug fix that prevents Sanguijuela losing a turn when turning to face the enemy at the beginning.<br />
* Go to the center of the territory until there is no host.<br />
<br />
== Comments ==<br />
Better results than evolution 0.3 but Sanguijuela is still 7.66 points away from GrubbmThree.<br />
<br />
<br />
= Sanguijuela 0.5 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.5.jar Download]<br />
<br />
'''Released:''' 2 April 2008<br />
<br />
'''Codesize:''' 635<br />
<br />
'''Ratings '''Battles:''' 3108<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| <br />
| 1631.88<br />
|}<br />
<br />
== What's new ==<br />
* Choose each round between Linear (90%) and Circular (10%) movement and targeting<br />
* Change the calculation of the best initial Radar direction using [[Smash]] method by [[User:Starrynte | Starrynte]]. My code got the same results but with more codesize.<br />
<br />
== Comments ==<br />
It was not good idea but I wanted to try it.<br />
Looking at the comparison between 0.3 and 0.4, Linear is better in a 76% of the conflictive cases.<br />
If I choose between Linear (90%) and Circular (10%) strategy then<br />
<br />
p(ok)= p(s=L)*P(ok|s=L) + p(s=C)*P(ok|s=C) = P(ok)*P(s=L) + P(ok)P(s=C) =0.76*0.9 + 0.24*0.1 =70.8<br />
<br />
So Sanguijuela lost 5.2% of the conflictive cases but I thought that adding this variability in the strategy could be interesting. The 0.3 (only Linear) has still better performance.<br />
<br />
<br />
= Sanguijuela 0.4 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.4.jar Download]<br />
<br />
'''Released:''' 24 March 2008<br />
<br />
'''Codesize:''' 727<br />
<br />
'''Ratings Date:''' 1 April 2008 '''Battles:''' 2388<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| 296 / 616<br />
| 1619.14<br />
|-<br />
! Mini<br />
| 116 / 306<br />
| 1650.26<br />
|-<br />
! Micro<br />
| 72 / 209<br />
| 1645.37<br />
|}<br />
<br />
== What's new ==<br />
* Change Radar from WideLock to NarrowLock.<br />
* Change linear movement and targeting to circular. The predicted position of the enemy use 8 as velocity for the movement and 11 for the targeting.<br />
<br />
== Comments ==<br />
Involution. After some testing I thought that a circular movement and targeting could be better than linear but, in general, it seems to be false. The previous version appears and disappears misteriously in the RoboRumble so I could make these statistics. <br />
<br />
[[Image:SanguijuelaComparison.jpg|thumb|300px|center| Comparison for v0.3 Linear and v0.4 Circular]]<br />
<br />
<br />
= Sanguijuela 0.3 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.3.jar Download]<br />
<br />
'''Released:''' 8 January 2008<br />
<br />
'''Codesize:''' 749<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
! Battles<br />
|-<br />
! General<br />
| <br />
| 1638.62<br />
| 4326<br />
|}<br />
<br />
'''Ratings Date:''' 18 January 2008 '''Battles:''' 2024<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| 253 / 604<br />
| 1624.67<br />
|-<br />
! General PL<br />
| 279 / 604<br />
| 612<br />
|-<br />
! Mini<br />
| 108 / 302<br />
| 1643.79<br />
|-<br />
! Mini PL<br />
| 122 / 302<br />
| 338<br />
|-<br />
! Micro<br />
| 67 / 203<br />
| 1645.21<br />
|-<br />
! Micro PL<br />
| 75 / 203<br />
| 236<br />
|}<br />
<br />
== What's New ==<br />
<br />
* Now Sanguijuela doesn’t ignore the walls in the linear movement and targeting.<br />
* It doesn’t bite before it is close to the enemy. (350 pixels).<br />
<br />
<br />
= Sanguijuela 0.2 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.2.jar Download]<br />
<br />
'''Released:''' 6 January 2008<br />
<br />
'''Codesize:''' 743<br />
<br />
== What's New ==<br />
<br />
* Code reduced to 743. Now Sanguijuela is a MicroBot.<br />
* Sanguijuela ignores the walls when moving and targeting.<br />
<br />
== ToDo ==<br />
* '''Done v0.3:''' Don’t ignore the walls and mantain the micro category.<br />
<br />
== Comments ==<br />
<br />
I have tested Sanguijuela's ramming performance (V0.2) with the archived results of [[RamBotChallenge2K6]] (two years ago) and it takes the 3rd place.<br />
<br />
{| border="1" cellspacing="0" cellpadding="3" align="center"<br />
! Bot<br />
! Ramming Percentage<br />
! Overall Score<br />
|-<br />
| [[MaxRisk]] 0.6<br />
| 24.65<br />
| 46.39<br />
|-<br />
| [[SledgeHammer]] 0.22<br />
| 21.42<br />
| 45.26<br />
|-<br />
| [[Sanguijuela]] 0.2<br />
| 21.86<br />
| 44.11<br />
|-<br />
| [[ARAMtocles]] 0.3<br />
| 20.65<br />
| 44.05<br />
|-<br />
| [[NanoDeath]] 2.56<br />
| 23.60<br />
| 43.85<br />
|}<br />
<br />
<br />
= Sanguijuela 0.1 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.Sanguijuela_0.1.jar Download]<br />
<br />
'''Released:''' 5 January 2008<br />
<br />
'''Codesize:''' 869<br />
<br />
== Origin ==<br />
<br />
* Linear Ramming and Targeting.<br />
* It calculates the best direction to start scanning.<br />
* It chooses ramming with the anterior or the posterior suckers depending on host's starting position.</div>Jabhttp://robowiki.net/w/index.php?title=Talk:Current_events&diff=2052Talk:Current events2008-04-17T21:37:35Z<p>Jab: Undo revision 2051 by 89.149.236.176 (Talk)</p>
<hr />
<div>[[User:AaronR|AaronR]]: Note that the image links I put on the "Robocode Documentation" pages are temporary. I will replace these with uploaded images later. My first priority is to '''add''' ''all'' documentations. Second priority is "goal plate" the pages. But anybody is welcome to replace the links with uploaded images. ;-) --[[User:FlemmingLarsen|Flemming N. Larsen]] 11:44, 28 November 2007 (UTC)<br />
* Sorry about that, I wasn't sure what pattern you are following. I was going to update this page anyway, and I need to remove one of the items from the list to make room for a new item, so I'll remove the Robocode Documentation one and let you work in peace. ;) --<code>[[User:AaronR|AaronR]]</code> 18:28, 28 November 2007 (UTC)<br />
<br />
== Just saying hi quickly ==<br />
<br />
Hello, <br />
I'm oOgerryOo. <br />
<br />
Just saying hello - I'm new.<br />
<br />
: Welcome to the wiki! Make yourself a username and a page here! (And at [http://robowiki.net/ the old wiki] too, if you like.) --<code>[[User:AaronR|AaronR]]</code> 05:29, 18 December 2007 (UTC)<br />
<br />
== News section, or the lack of such ==<br />
I am wondering.. where do we have a News section? I should at least want a page about news, which again contains a link with "Robocode News", and other people should provide links to interesting stuff on the News page for other matters. So, where should we put it? --[[User:FlemmingLarsen|Fnl]] 22:28, 21 January 2008 (UTC)<br />
:Right here! I believe that was the point of this page. At present, it only contains the contents of {{Tl|CurrentEventsShort}}, but that isn't mandatory (the template version is just a summary of events for the [[Main Page]], hence the name CurrentEvents''Short''). « [[User:AaronR|AaronR]] « [[User talk:AaronR|Talk]] « 20:35, 24 January 2008 (UTC)<br />
::This page now has a separate list from the Main Page, so you can add all the news you want to it. =) By the way, does anyone else think it might be a good idea to move this page into the project namespace (i.e. [[RoboWiki:Current events]])? « [[User:AaronR|AaronR]] « [[User talk:AaronR|Talk]] « 21:10, 24 January 2008 (UTC)</div>Jabhttp://robowiki.net/w/index.php?title=Talk:Migration&diff=2050Talk:Migration2008-04-16T07:09:42Z<p>Jab: New contents should go directly to the new wiki</p>
<hr />
<div>Feel free to bring up any ideas for how to best migrate stuff from the old wiki here.<br />
<br />
== Who's doing what ==<br />
<br />
I'm going through the targeting method pages and subpages right now. I'm still on the [[:Category:Simple Targeting Strategies|simple targeters]] right now. Some of those pages are really messy. =) --[[User:Voidious|Voidious]] 23:06, 11 November 2007 (UTC)<br />
: I'm playing around with the main page. I'm hoping to make it look better than the old wiki's by incorporating some of the more advanced wiki code available in MediaWiki. (Translation: I'm playing with code from Wikipedia's homepage in the [[Sandbox]].) -- [[User:AaronR|AaronR]] 23:29, 11 November 2007 (UTC)<br />
:: Hey, I really like the version you have going on in the [[Sandbox]]! --[[User:Voidious|Voidious]] 00:39, 12 November 2007 (UTC)<br />
::: Thanks. Any ideas for what the "... Whatever ..." section could be? What about the categories at the top? -- [[User:AaronR|AaronR]] 00:57, 12 November 2007 (UTC)<br />
<br />
I just want to point out how useful the [[Special:Specialpages|special pages]] are. For the fastest migration, everyone should start patrolling [[Special:Lonelypages|Orphaned pages]], [[Special:Uncategorizedpages|Uncategorized pages]], [[Special:Wantedcategories|Wanted categories]], and particularly [[Special:Wantedpages|Wanted pages]]. --[[User:AaronR|AaronR]] 05:57, 12 November 2007 (UTC)<br />
:I can start working on these, should be able to get a page or two done :P --[[User:Baal|Baal]] 04:42, 15 February 2008 (UTC)<br />
<br />
I plan to work on radar page and perhaps put a little work into robocode mathematics. --[[User:Chase-san|Chase-san]] 06:23, 12 November 2007 (UTC)<br />
<br />
I'm doing [[Melee]] and then [[Movement]]-related stuff. (Btw, there are 3740 pages on the wiki, removing 'potential empty pages' it can be rounded down to 3,700 pages. And we only have 77 articles :) -- [[User:Starrynte|Starrynte]] 06:11, 18 November 2007 (UTC)<br />
<br />
Right now I'm working on a client-side wiki-bot written in Java that can do things like remove double redirects, etc. I'm using the Java Wiki Bot Framework to interact with the wiki. Since it's my first attempt at a bot, you may see a lot of changes to the [[Sandbox]] in the near future. =) --[[User:AaronR|AaronR]] 06:34, 18 November 2007 (UTC)<br />
: Judging from the [[Special:Recentchanges|recent changes]] log, I got my bot working correctly. =) At present all it does is remove double redirects, but it has a nice pluggable interface and is fully expandable. I'm not using the Java Wiki Bot Framework anymore - it's a server-side framework, and I'm hoping to have the bot run as a client, a bit like the RoboRumble clients. --<code>[[User:AaronR|AaronR]]</code> 07:34, 20 November 2007 (UTC)<br />
:: Cool! Let me know if there's anything I can do to assist you, as it seems like a very useful tool to have around. --[[User:Voidious|Voidious]] 00:53, 21 November 2007 (UTC)<br />
::: Thanks. As soon as you can get the file uploads working, I'll post a JAR of it with source. Because of the long weekend, I should have plenty of time for Robocode over the next several days. --<code>[[User:AaronR|AaronR]]</code> 01:26, 21 November 2007 (UTC)<br />
<br />
<br />
<br />
== Capitalization of page titles when linking ==<br />
<br />
Ok, I've got a style question. If I'm linking to the [[Bearing Offset]] page, should I capitalize it? Should it be like, "A [[Bearing Offset]] gives you a blah blah", or "A [[Bearing Offset|bearing offset]] gives you a blah blah".. ? They each have their merits, in my mind, but I kind of lean towards the latter for anything that isn't obviously a proper name that we basically made up (like "GuessFactor" or "WaveSurfing"). Thoughts? --[[User:Voidious|Voidious]] 06:04, 12 November 2007 (UTC)<br />
: MediaWiki will automatically ignore the capitalization of the first letter of a pagelink. I say we use lowercase for everything except the "made-up words", and create redirects from lowercase to uppercase for any 2+ word page titles. ("Bearing offset" should redirect to "Bearing Offset", but "bearing Offset" is automatically redirected to "Bearing Offset" by the wiki software.) This is pretty much what they do at Wikipedia. I also think WaveSurfing should be Wave Surfing. --[[User:AaronR|AaronR]] 06:19, 12 November 2007 (UTC)<br />
:: Cool, sounds like a plan. I'm all for following what Wikipedia does. And I'm fine with "Wave Surfing", but I suspect we'll forever see it in both forms, anyway... --[[User:Voidious|Voidious]] 06:21, 12 November 2007 (UTC)<br />
<br />
== Robots ==<br />
<br />
If at all possible use the new robot [[Template:Infobox_Robot|infobox template]] when shifting over robots. They look nifty after all, and thus we can change the layout without having to go through and update every single page... --[[User:Chase-san|Chase-san]] 14:40, 12 November 2007 (UTC)<br />
<br />
: I think the infobox looks really sleak, but I wonder what it leaves to actually fill out the rest of the page. I guess if all the fields are optional, authors can decide which go in the box and which make up the main page content? --[[User:Voidious|Voidious]] 16:56, 12 November 2007 (UTC)<br />
<br />
:: I removed the "[[White Whale|White Whales]]", "Inspired By", and "Inspired" options from the infobox. Those three items seem to me to work better as page content. --[[User:AaronR|AaronR]] 18:31, 12 November 2007 (UTC)<br />
<br />
::: They didn't have to use those fields ya know. :P --[[User:Chase-san|Chase-san]] 18:35, 12 November 2007 (UTC)<br />
<br />
: The infobox seems quite nice, it is clear but complete and easy to comprehend. If there is something noteworthy about a bot (and usually there is ;-) ), it can be added below it (I think, I am not familiar (yet) with this kind of wiki) --[[User:GrubbmGait|GrubbmGait]] 23:01, 12 November 2007 (UTC)<br />
<br />
: I added this discussion to the current events listing - maybe we'll get some more opinions. --[[User:AaronR|AaronR]] 18:43, 12 November 2007 (UTC)<br />
<br />
Will uploading be allowed, if not I should remove the image part of the Template, as it can only use images thata re stored on the wiki. --[[User:Chase-san|Chase-san]] 19:33, 12 November 2007 (UTC)<br />
<br />
== Logo ==<br />
<br />
http://chase.tfsnewworld.com/images/RoboWiki2.png<br />
<br />
I got bored and Photoshopped up a newer version of the logo, I doupt people will agree to change it though, but it was fun to make. I ''obviously'' used the original as a basis. --[[User:Chase-san|Chase-san]] 21:51, 12 November 2007 (UTC)<br />
<br />
== Pages that are discussions ==<br />
<br />
Ok, I've reached a page that I'm unsure how to migrate. For [[ABCs Linked List Challenge]], I went and gave it its own page and put it under [[:Category:Discussions]], which seemed like a reasonable setup. For [http://robowiki.net/cgi-bin/robowiki?FuzzyLogicTargeting FuzzyLogicTargeting], it doesn't make as much sense to me. One option is to make a [[Fuzzy Logic Targeting]] page, make it a stub, and add the page content's to the talk page, but that doesn't quite seem right - there is ''no such thing'' as Fuzzy Logic Targeting, so how could it ever get fleshed out? I could just transfer the whole contents and put it under Discussions like with ABCs Linked List Challenge; I guess this option works, but it still just feels a little off. Anybody got any suggestions? --[[User:Voidious|Voidious]] 16:19, 13 November 2007 (UTC)<br />
:It was inevitable that there would be articles that just aren't worth moving. I realize by doing so we lose a little information from the old wiki, but in this case I just don't think it really should be moved. Unless the conversation had something influentual in it, I think it should be left alone aswell. --[[User:Chase-san|Chase-san]] 16:22, 13 November 2007 (UTC)<br />
<br />
== Articles needing revision ==<br />
<br />
Should we make a category for these, pages that we're just mostly copy and pasted from the old wiki, would obviously need revision to shake loose coversation and make them more informative, perferrably by someone knowledgable in the subject. Generally, I think each page should be written in a "for dummies" methodoligy where possible (things such as neural targeting will almost never be able to be put into a "for dummies" contex). In such as guessfactor targeting it is written out in such a way that someone realatively new to java programming can pick up, ergo generally lacking in technical jargan(unless referenced to the jargans meaning) and in plain english.<br />
<br />
People such as I need things put in the simplist way to understand, as I am learning disabled so understanding psudoism's isn't exactly easy. (Just ask Voidious, who I worked with considerabily in an attempt to get my very first traditional gf gun working. Some things I just litterally needed spelled out.<br />
<br />
[[User:Chase-san|Chase-san]] 16:30, 13 November 2007 (UTC)<br />
<br />
: Well, I am trying to revise pages as I move them over, but if you move something and just don't know how to revise it, I think this is a fine solution. I think just marking it a "stub" or putting a note on the Talk page are other good options (either instead of or in addition to a "needs revision" list). --[[User:Voidious|Voidious]] 16:41, 13 November 2007 (UTC)<br />
<br />
:: [[Template:Stub]] should used for articles that are too short. I believe Wikipedia has a generic "cleanup" template also. --[[User:AaronR|AaronR]] 17:11, 13 November 2007 (UTC)<br />
<br />
== File and image uploads ==<br />
<br />
Will these be enabled in the future? I can see some definite utility in allowing uploads: the challenge reference bots, the screenshots for [[The2000Club]] and [[The2100Club]], illustrations for the [[:Category:Tutorials|tutorials]]... --[[User:AaronR|AaronR]] 17:03, 13 November 2007 (UTC)<br />
<br />
: Yes, I will enable uploads today or tomorrow. Yesterday, I looked into how to do it, checked out what kind of anti-abuse measures MediaWiki has in place, and talked to David to make sure he's cool with it. It should be no problem. --[[User:Voidious|Voidious]] 18:13, 13 November 2007 (UTC)<br />
<br />
:: Will we be able to upload our robots to the wiki? --[[User:KID|KID]] 00:29, 16 November 2007 (UTC)<br />
<br />
::: Well, David is working on a replacement bot repository, you'll be able to upload your bots there. If you need to upload your bot somewhere before then, feel free to e-mail me your bot (my handle at gmail) and I'll host it for you. --[[User:Voidious|Voidious]] 00:33, 16 November 2007 (UTC)<br />
<br />
: Are you still on vacation, Voidious? "I will enable uploads today or tomorrow" doesn't seem to have happened... --<code>[[User:AaronR|AaronR]]</code> 00:28, 28 November 2007 (UTC)<br />
:: No, sorry for the wait - image uploads are enabled now. None of the cool stuff like auto-thumbnailing is setup at the moment, but maybe we can set that up down the road. --[[User:Voidious|Voidious]] 01:56, 28 November 2007 (UTC)<br />
::: Great, thanks! --<code>[[User:AaronR|AaronR]]</code> 02:24, 28 November 2007 (UTC)<br />
<br />
== When to move to RoboWiki.net ==<br />
<br />
At what point in this migration should we move this wiki to RoboWiki.net (and the old one to a subdomain, perhaps)? Obviously the migration is going to take a long time before it's "finished". The RoboRumble participants pages work fine in the new wiki format. Any other major issues to resolve before we can "move"? --[[User:Voidious|Voidious]] 15:03, 15 November 2007 (UTC)<br />
<br />
: I still think we have a few too many redlinks for this to be considered "acceptable" as the new wiki. Just look at the Main Page, half of the links are missing (including [[RoboRumble]]!). Furthermore, the site is even less inviting to newcomers than before, since almost any link followed will dead-end them rather quickly. My opinion is that a lot more of the site needs to be finished before we can move over to the new wiki. Of course, at the rate everyone is contributing, that should only take about a few days. =) --[[User:AaronR|AaronR]] 15:52, 15 November 2007 (UTC)<br />
<br />
In my opinion the completely new contents should go directly to this new wiki instead of creating new content in the old wiki. This can slow down the process. May be it could be interesting to put a note in the link of the old wiki. --[[User:Jab|jab]] 07:09, 16 April 2008 (UTC)<br />
<br />
== Signature ==<br />
<br />
Right, I almost forgot in MediaWiki you sign with four tildes :) But then, how do you edit your signature? I didn't see it anyware in "my preferences" [[User:Starrynte|Starrynte]] 20:02, 17 November 2007 (UTC)<br />
: I was wondering that too. At Wikipedia, everyone has flashy multi-colored signatures ... except for me. --[[User:AaronR|AaronR]] 07:00, 18 November 2007 (UTC)<br />
:: Aha! You have to use the "Nickname" field with the "Raw signatures" box checked. See, look at my signature now. I had to do a bit of searching through Wikipedia's help pages to figure that out. --<code>[[User:AaronR|AaronR]]</code> 08:09, 18 November 2007 (UTC)<br />
<br />
== Progress ==<br />
<br />
Woohoo! Largely thanks to [[Fnl]]'s recent updates for the Robocode pages, we are now up over 100 articles on the new wiki. I have been making good progress on the [[Targeting]] pages, too. There are nearly 4,000 pages on the old wiki, but I'd guess a ratio of 2:1 on the old wiki vs new wiki, because the new wiki doesn't count user pages or talk pages in that "article count", plus we are condensing some things over here. Keep up the good work, dudes! =) --[[User:Voidious|Voidious]] 19:50, 28 November 2007 (UTC)<br />
<br />
: I'd call it more like a 3:1 ratio. Actually, according to the [[Special:Statistics|Statistics]] page, it's a 340:113 ratio. Thanks to user pages, talk pages, redirects, and categories, a huge percentage of the old wiki's "articles" don't actually count as articles under the new system - which is a good thing, because that means we're close to 1/10th of the way done! And remember, we don't have to move ''everything''. --<code>[[User:AaronR|AaronR]]</code> 21:33, 28 November 2007 (UTC)<br />
<br />
Wow. Last time I looked at the main page it didn't look nearly as good as it does now. I didn't realize that, I thought it was ... ok. But now it's really sharp! --[[User:Simonton|Simonton]] 03:02, 29 November 2007 (UTC)<br />
<br />
== Bots using <this concept> ==<br />
<br />
A lot of pages on the old wiki include a section of "bots using <this concept>". Most of them are painfully out of date, so I'm not sure they're of much use. Should we come up with some standard way of doing this? For instance, we could have a (potentially VERY long) section at the end of the topic page, or a subpage like "Topic/Bots Using". Or maybe it's not worth doing this at all because it will never be kept up to date - using a "What links here" or an advanced search might always be a better idea, anyway. --[[User:Voidious|Voidious]] 20:16, 30 November 2007 (UTC)<br />
: As you say, these sections are ''always'' out of date. I would just use "What links here". Maybe, for some of the really broad strategies ([[Wave Surfing]], [[Random Movement]], [[GuessFactor Targeting]], [[Pattern Matching]], and [[Dynamic Clustering]] are the only ones I can think of), we could have subcategories of [[:Category:Bots]]. --<code>[[User:AaronR|AaronR]]</code> 20:48, 30 November 2007 (UTC)<br />
: This type of wiki indeed has more powerfull (and automatically up-to-date) features for this. Rambots is the only category I can think of that is not hopelessly out of date, so I think it is not necessary. --[[User:GrubbmGait|GrubbmGait]] 23:22, 30 November 2007 (UTC)<br />
<br />
== ASHighlight ==<br />
<br />
Can we add the [http://www.mediawiki.org/wiki/Extension:ASHighlight ASHighlight] extension to this wiki? It would be really nice to be able to use the &lt;source lang="java5"&gt; tag like you can on Wikipedia. You can see an example of this [http://en.wikipedia.org/wiki/User:MER-C/Wiki.java here] - it's the same source code I used in my wiki-bot I wrote a while ago. --<code>[[User:AaronR|AaronR]]</code> 23:52, 12 December 2007 (UTC)<br />
: I very much second this notion [[User:Baal|Baal]] 05:06, 20 February 2008 (UTC)<br />
: Good idea --[[User:Jab|jab]] 07:09, 16 April 2008 (UTC)<br />
<br />
== InfoBoxes == <br />
<br />
How about infoboxes for movement and targeting pages or something listing relative difficulty and codesize [[User:Baal|Baal]] 05:06, 20 February 2008 (UTC)</div>Jabhttp://robowiki.net/w/index.php?title=Sanguijuela/Evolution_History&diff=2049Sanguijuela/Evolution History2008-04-15T21:31:47Z<p>Jab: Sanguijuela Evolution History (0.5)</p>
<hr />
<div>= Sanguijuela 0.5 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.5.jar Download]<br />
<br />
'''Released:''' 2 April 2008<br />
<br />
'''Codesize:''' 635<br />
<br />
'''Ratings '''Battles:''' 3108<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| <br />
| 1631.88<br />
|}<br />
<br />
== What's new ==<br />
* Choose each round between Linear (90%) and Circular (10%) movement and targeting<br />
* Change the calculation of the best initial Radar direction using [[Smash]] method by [[User:Starrynte | Starrynte]]. My code got the same results but with more codesize.<br />
<br />
== Comments ==<br />
It was not good idea but I wanted to try it.<br />
Looking at the comparison between 0.3 and 0.4, Linear is better in a 76% of the conflictive cases.<br />
If I choose between Linear (90%) and Circular (10%) strategy then<br />
<br />
p(ok)= p(s=L)*P(ok|s=L) + p(s=C)*P(ok|s=C) = P(ok)*P(s=L) + P(ok)P(s=C) =0.76*0.9 + 0.24*0.1 =70.8<br />
<br />
So Sanguijuela lost 5.2% of the conflictive cases but I thought that adding this variability in the strategy could be interesting. The 0.3 (only Linear) has still better performance.<br />
<br />
= Sanguijuela 0.4 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.4.jar Download]<br />
<br />
'''Released:''' 24 March 2008<br />
<br />
'''Codesize:''' 727<br />
<br />
'''Ratings Date:''' 1 April 2008 '''Battles:''' 2388<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| 296 / 616<br />
| 1619.14<br />
|-<br />
! Mini<br />
| 116 / 306<br />
| 1650.26<br />
|-<br />
! Micro<br />
| 72 / 209<br />
| 1645.37<br />
|}<br />
<br />
== What's new ==<br />
* Change Radar from WideLock to NarrowLock.<br />
* Change linear movement and targeting to circular. The predicted position of the enemy use 8 as velocity for the movement and 11 for the targeting.<br />
<br />
== Comments ==<br />
Involution. After some testing I thought that a circular movement and targeting could be better than linear but, in general, it seems to be false. The previous version appears and disappears misteriously in the RoboRumble so I could make these statistics.<br />
<br />
[[Image:SanguijuelaComparison.jpg|thumb|300px|center| Comparison for v0.3 Linear and v0.4 Circular]]<br />
<br />
= Sanguijuela 0.3 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.3.jar Download]<br />
<br />
'''Released:''' 8 January 2008<br />
<br />
'''Codesize:''' 749<br />
<br />
'''Ratings Date:''' 18 January 2008 '''Battles:''' 2024<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| 253 / 604<br />
| 1624.67<br />
|-<br />
! General PL<br />
| 279 / 604<br />
| 612<br />
|-<br />
! Mini<br />
| 108 / 302<br />
| 1643.79<br />
|-<br />
! Mini PL<br />
| 122 / 302<br />
| 338<br />
|-<br />
! Micro<br />
| 67 / 203<br />
| 1645.21<br />
|-<br />
! Micro PL<br />
| 75 / 203<br />
| 236<br />
|}<br />
<br />
== What's New ==<br />
<br />
* Now Sanguijuela doesn’t ignore the walls in the linear movement and targeting.<br />
* It doesn’t bite before it is close to the enemy. (350 pixels).<br />
<br />
<br />
= Sanguijuela 0.2 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.micro.Sanguijuela_0.2.jar Download]<br />
<br />
'''Released:''' 6 January 2008<br />
<br />
'''Codesize:''' 743<br />
<br />
== What's New ==<br />
<br />
* Code reduced to 743. Now Sanguijuela is a MicroBot.<br />
* Sanguijuela ignores the walls when moving and targeting.<br />
<br />
== ToDo ==<br />
* '''Done v0.3:''' Don’t ignore the walls and mantain the micro category.<br />
<br />
== Comments ==<br />
<br />
I have tested Sanguijuela's ramming performance (V0.2) with the archived results of [[RamBotChallenge2K6]] (two years ago) and it takes the 3rd place.<br />
<br />
{| border="1" cellspacing="0" cellpadding="3" align="center"<br />
! Bot<br />
! Ramming Percentage<br />
! Overall Score<br />
|-<br />
| [[MaxRisk]] 0.6<br />
| 24.65<br />
| 46.39<br />
|-<br />
| [[SledgeHammer]] 0.22<br />
| 21.42<br />
| 45.26<br />
|-<br />
| [[Sanguijuela]] 0.2<br />
| 21.86<br />
| 44.11<br />
|-<br />
| [[ARAMtocles]] 0.3<br />
| 20.65<br />
| 44.05<br />
|-<br />
| [[NanoDeath]] 2.56<br />
| 23.60<br />
| 43.85<br />
|}<br />
<br />
= Sanguijuela 0.1 =<br />
[http://www.freewebs.com/robocode/bots/Sanguijuela/jab.Sanguijuela_0.1.jar Download]<br />
<br />
'''Released:''' 5 January 2008<br />
<br />
'''Codesize:''' 869<br />
<br />
== Origin ==<br />
<br />
* Linear Ramming and Targeting.<br />
* It calculates the best direction to start scanning.<br />
* It chooses ramming with the anterior or the posterior suckers depending on host's starting position.</div>Jabhttp://robowiki.net/w/index.php?title=Template_talk:CurrentEventsShort&diff=2038Template talk:CurrentEventsShort2008-04-05T14:43:52Z<p>Jab: Undo revision 2037 by 87.118.116.147 (Talk)</p>
<hr />
<div>Just wanted to say Hello to everyone. <br />
Much to read and learn here, I'm sure I will enjoy !</div>Jabhttp://robowiki.net/w/index.php?title=Sanguijuela&diff=2034Sanguijuela2008-04-04T17:29:46Z<p>Jab: Sanguijuela main page update</p>
<hr />
<div>; <nowiki>Sub-pages: </nowiki><br />
: '''[[/Evolution History]]'''<br />
<br />
{{Infobox Robot<br />
| bgcolour = #CCCCFF<br />
| image = Sanguijuela.JPG<br />
| caption = The leech<br />
| author = jab<br />
| extends = AdvancedRobot<br />
| current_version = 0.5<br />
| license = [[RWPCL]]<br />
| download_link = http://robocoderepository.com/BotDetail.jsp?id=3539<br />
| source_link = http://robocoderepository.com/BotDetail.jsp?id=3539<br />
}}<br />
== Background Info ==<br />
; What's special about it?<br />
<br />
A simple micro RamBot<br />
<br />
The main objective of Sanguijuela's behaviour is to detect and attach the host as quickly as possible<br />
* It calculates the best direction to start scanning<br />
* It chooses ramming with the anterior or the posterior suckers depending on host's starting position<br />
<br />
== Additional Info ==<br />
; Where did you get the name?<br />
Sanguijuela means Leech.<br />
<br />
; Can I use your code?<br />
Of course, it's under [[RWPCL]] license. Let me now if it can be improved in the discussion section.<br />
<br />
; Does it have any [[White Whale|white whales]]?<br />
GrubbmThree<br />
<br />
[[Category:Bots|Sanguijuela]]<br />
[[Category:MicroBots|Sanguijuela]]<br />
[[Category:1-vs-1 Bots|Sanguijuela]]<br />
[[Category:Open Source Bots|Sanguijuela]]<br />
[[Category:RamBots|Sanguijuela]]</div>Jabhttp://robowiki.net/w/index.php?title=Sanguijuela/Evolution_History&diff=2033Sanguijuela/Evolution History2008-04-04T17:24:20Z<p>Jab: Sanguijuela 0.4 Involution</p>
<hr />
<div>= Sanguijuela 0.4 =<br />
<br />
'''Released:''' 24 March 2008<br />
<br />
'''Codesize:''' 727<br />
<br />
'''Ratings Date:''' 1 April 2008 '''Battles:''' 2388<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| 296 / 616<br />
| 1619.14<br />
|-<br />
! Mini<br />
| 116 / 306<br />
| 1650.26<br />
|-<br />
! Micro<br />
| 72 / 209<br />
| 1645.37<br />
|}<br />
<br />
== What's new ==<br />
* Change Radar from WideLock to NarrowLock.<br />
* Change linear movement and targeting to circular. The predicted position of the enemy use 8 as velocity for the movement and 11 for the targeting.<br />
<br />
== Comments ==<br />
Involution. After some testing I thought that a circular movement and targeting could be better than linear but, in general, it seems to be false. The previous version appears and disappears misteriously in the RoboRumble so I could make these statistics.<br />
<br />
[[Image:SanguijuelaComparison.jpg|thumb|300px|center| Comparison for v0.3 Linear and v0.4 Circular]]<br />
<br />
= Sanguijuela 0.3 =<br />
<br />
'''Released:''' 8 January 2008<br />
<br />
'''Codesize:''' 749<br />
<br />
'''Ratings Date:''' 18 January 2008 '''Battles:''' 2024<br />
<br />
{| border="1" cellspacing="0" cellpadding="3"<br />
! Rumble<br />
! Position<br />
! Points<br />
|-<br />
! General<br />
| 253 / 604<br />
| 1624.67<br />
|-<br />
! General PL<br />
| 279 / 604<br />
| 612<br />
|-<br />
! Mini<br />
| 108 / 302<br />
| 1643.79<br />
|-<br />
! Mini PL<br />
| 122 / 302<br />
| 338<br />
|-<br />
! Micro<br />
| 67 / 203<br />
| 1645.21<br />
|-<br />
! Micro PL<br />
| 75 / 203<br />
| 236<br />
|}<br />
<br />
== What's New ==<br />
<br />
* Now Sanguijuela doesn’t ignore the walls in the linear movement and targeting.<br />
* It doesn’t bite before it is close to the enemy. (350 pixels).<br />
<br />
<br />
= Sanguijuela 0.2 =<br />
<br />
'''Released:''' 6 January 2008<br />
<br />
'''Codesize:''' 743<br />
<br />
== What's New ==<br />
<br />
* Code reduced to 743. Now Sanguijuela is a MicroBot.<br />
* Sanguijuela ignores the walls when moving and targeting.<br />
<br />
== ToDo ==<br />
* '''Done v0.3:''' Don’t ignore the walls and mantain the micro category.<br />
<br />
== Comments ==<br />
<br />
I have tested Sanguijuela's ramming performance (V0.2) with the archived results of [[RamBotChallenge2K6]] (two years ago) and it takes the 3rd place.<br />
<br />
{| border="1" cellspacing="0" cellpadding="3" align="center"<br />
! Bot<br />
! Ramming Percentage<br />
! Overall Score<br />
|-<br />
| [[MaxRisk]] 0.6<br />
| 24.65<br />
| 46.39<br />
|-<br />
| [[SledgeHammer]] 0.22<br />
| 21.42<br />
| 45.26<br />
|-<br />
| [[Sanguijuela]] 0.2<br />
| 21.86<br />
| 44.11<br />
|-<br />
| [[ARAMtocles]] 0.3<br />
| 20.65<br />
| 44.05<br />
|-<br />
| [[NanoDeath]] 2.56<br />
| 23.60<br />
| 43.85<br />
|}<br />
<br />
= Sanguijuela 0.1 =<br />
<br />
'''Released:''' 5 January 2008<br />
<br />
'''Codesize:''' 869<br />
<br />
== Origin ==<br />
<br />
* Linear Ramming and Targeting.<br />
* It calculates the best direction to start scanning.<br />
* It chooses ramming with the anterior or the posterior suckers depending on host's starting position.</div>Jabhttp://robowiki.net/w/index.php?title=File:SanguijuelaComparison.jpg&diff=2032File:SanguijuelaComparison.jpg2008-04-04T16:58:33Z<p>Jab: Comparison between linear and circular ramming</p>
<hr />
<div>Comparison between linear and circular ramming</div>Jabhttp://robowiki.net/w/index.php?title=Talk:Exterminans2oo8&diff=2023Talk:Exterminans2oo82008-03-30T16:06:46Z<p>Jab: </p>
<hr />
<div>Hi, two comments:<br />
May be [[RWPCL]] is the license that you want for your bot.<br />
The part of your code when you check if the enemy is shooting you can be easily improved taking into account damage from walls, ramming and your own bullets. --[[User:Jab |Jab]]</div>Jabhttp://robowiki.net/w/index.php?title=Talk:Exterminans2oo8&diff=2022Talk:Exterminans2oo82008-03-30T16:03:36Z<p>Jab: two comments</p>
<hr />
<div>Hi, two comments:<br />
May be [[RWPCL]] is the license that you want for your bot.<br />
The part of your code when you check if the enemy is shooting you can be easily improved taking into account damage from walls, ramming and your own bullets.</div>Jabhttp://robowiki.net/w/index.php?title=Talk:CalculatingScore/ScoreWithRamming&diff=2017Talk:CalculatingScore/ScoreWithRamming2008-03-29T14:22:59Z<p>Jab: Is it possible to calculate the score for an AdvancedRobot?</p>
<hr />
<div><pre><br />
package <package>;<br />
<br />
import java.util.Iterator;<br />
import java.util.Vector;<br />
<br />
import robocode.*;<br />
<br />
/**<br />
* This is the Score class for duels.<br />
* <br />
* Instantiate this once on match start, and at the top of all the needed events<br />
* just pass them to the instance. Call printScore at any time to print the<br />
* scores to the console. Call getScore(id) at any time to get the score of the<br />
* requested robot (0 = self, 1 = enemy).<br />
* <br />
* If you'd like to use this in your robot, feel free to, but give credit!<br />
* <br />
* @author Vuen (original)<br />
* @author Jab (contributor)<br />
*/<br />
public class Score {<br />
<br />
AdvancedRobot robot;<br />
<br />
public Score(AdvancedRobot robot) {<br />
this.robot = robot;<br />
}<br />
<br />
public double enemyEnergy;<br />
public double myEnergy;<br />
public String enemyName;<br />
<br />
public static double[] total = new double[2];<br />
<br />
public double[] survivalScore = new double[2];<br />
<br />
public double[] bulletDamageBonus = new double[2];<br />
public double[] bulletDamage = new double[2];<br />
<br />
public double[] ramDamageBonus = new double[2];<br />
public double[] ramDamage = new double[2];<br />
<br />
public void onScannedRobot(ScannedRobotEvent e) {<br />
myEnergy = robot.getEnergy();<br />
enemyEnergy = e.getEnergy();<br />
if (enemyName == null)<br />
enemyName = e.getName();<br />
}<br />
<br />
public void onBulletHit(BulletHitEvent e) {<br />
if (e.getEnergy() < 0.001) {<br />
System.out.println("Score.onBulletHit()");<br />
return;<br />
} //ignore if enemy dead<br />
bulletDamage[0] += robocode.Rules.getBulletDamage(e.getBullet()<br />
.getPower());<br />
}<br />
<br />
public void onHitByBullet(HitByBulletEvent e) {<br />
if (robocode.Rules.getBulletDamage(e.getPower()) > myEnergy) {<br />
System.out.println("Score.onHitByBullet()");<br />
return;<br />
} //ignore if self dead<br />
bulletDamage[1] += robocode.Rules.getBulletDamage(e.getBullet()<br />
.getPower());<br />
}<br />
<br />
public void onHitRobot(HitRobotEvent e) {<br />
ramDamage[e.isMyFault() ? 0 : 1] += robocode.Rules.ROBOT_HIT_DAMAGE;<br />
}<br />
<br />
<br />
public void onWin(WinEvent e) {<br />
<br />
Vector<Event> v = robot.getAllEvents();<br />
Iterator<Event> i = v.iterator();<br />
while (i.hasNext()) {<br />
Event event = i.next();<br />
System.out.println("Missed event: " + event.getClass());<br />
if (event instanceof BulletHitEvent)<br />
onBulletHit((BulletHitEvent) event);<br />
if (event instanceof HitByBulletEvent)<br />
onHitByBullet((HitByBulletEvent) event);<br />
if (event instanceof HitRobotEvent)<br />
onHitRobot((HitRobotEvent) event);<br />
}<br />
<br />
survivalScore[0] = 60;<br />
if (v.size() > 0)<br />
if (v.lastElement() instanceof BulletHitEvent)<br />
bulletDamageBonus[0] = (bulletDamage[0] + ramDamage[0]) * .2;<br />
else if (v.lastElement() instanceof HitRobotEvent)<br />
ramDamageBonus[0] = (bulletDamage[0] + ramDamage[0]) * .3;<br />
ramDamage[0] *= 2;<br />
ramDamage[1] *= 2;<br />
<br />
total[0] += survivalScore[0] + bulletDamageBonus[0] + bulletDamage[0]<br />
+ ramDamageBonus[0] + ramDamage[0];<br />
total[1] += survivalScore[1] + bulletDamageBonus[1] + bulletDamage[1]<br />
+ ramDamageBonus[1] + ramDamage[1];<br />
this.printScore();<br />
}<br />
<br />
<br />
public void onDeath(DeathEvent e) {<br />
<br />
Vector<Event> v = robot.getAllEvents();<br />
Iterator<Event> i = v.iterator();<br />
while (i.hasNext()) {<br />
Event event = i.next();<br />
System.out.println("Missed event: " + event.getClass());<br />
if (event instanceof BulletHitEvent)<br />
onBulletHit((BulletHitEvent) event);<br />
if (event instanceof HitByBulletEvent)<br />
onHitByBullet((HitByBulletEvent) event);<br />
if (event instanceof HitRobotEvent)<br />
onHitRobot((HitRobotEvent) event);<br />
}<br />
<br />
survivalScore[1] = 60;<br />
if (v.size() > 0)<br />
if (v.lastElement() instanceof BulletHitEvent)<br />
bulletDamageBonus[1] = (bulletDamage[1] + ramDamage[1]) * .2;<br />
else if (v.lastElement() instanceof HitRobotEvent)<br />
ramDamageBonus[1] = (bulletDamage[1] + ramDamage[1]) * .3;<br />
ramDamage[0] *= 2;<br />
ramDamage[1] *= 2;<br />
<br />
total[0] += survivalScore[0] + bulletDamageBonus[0] + bulletDamage[0]<br />
+ ramDamageBonus[0] + ramDamage[0];<br />
total[1] += survivalScore[1] + bulletDamageBonus[1] + bulletDamage[1]<br />
+ ramDamageBonus[1] + ramDamage[1];<br />
this.printScore();<br />
}<br />
<br />
/** returns the score of the requested robot: 0=self, 1=enemy */<br />
public int getScore(int id) {<br />
return (int) Math.round(total[id]);<br />
}<br />
<br />
/** prints the score-card to the console */<br />
public void printScore() {<br />
System.out.println("Total: " + Math.round(total[0]) + " "<br />
+ robot.getName());<br />
double totalMe = survivalScore[0] + bulletDamageBonus[0]<br />
+ bulletDamage[0] + ramDamageBonus[0] + ramDamage[0];<br />
System.out<br />
.println("Total Survival BulletDmg BulletBonus RamDmg*2 RamDmgBonus");<br />
System.out.println(Math.round(totalMe) + " "<br />
+ Math.round(survivalScore[0]) + " "<br />
+ Math.round(bulletDamage[0]) + " "<br />
+ Math.round(bulletDamageBonus[0]) + " "<br />
+ Math.round(ramDamage[0]) + " "<br />
+ Math.round(ramDamageBonus[0]));<br />
<br />
System.out.println();<br />
<br />
System.out.println("Total: " + Math.round(total[1]) + " " + enemyName);<br />
double totalEnemy = survivalScore[1] + bulletDamageBonus[1]<br />
+ bulletDamage[1] + ramDamageBonus[1] + ramDamage[1];<br />
System.out<br />
.println("Total Survival BulletDmg BulletBonus RamDmg*2 RamDmgBonus");<br />
System.out.println(Math.round(totalEnemy) + " "<br />
+ Math.round(survivalScore[1]) + " "<br />
+ Math.round(bulletDamage[1]) + " "<br />
+ Math.round(bulletDamageBonus[1]) + " "<br />
+ Math.round(ramDamage[1]) + " "<br />
+ Math.round(ramDamageBonus[1]));<br />
}<br />
<br />
}<br />
</pre></div>Jabhttp://robowiki.net/w/index.php?title=Talk:CalculatingScore&diff=2016Talk:CalculatingScore2008-03-29T14:20:33Z<p>Jab: Is it possible to calculate the score for an AdvancedRobot?</p>
<hr />
<div>Is it possible to calculate the score for an AdvancedRobot? I'm having problems with the HitRobotEvent<br />
<br />
<pre><br />
public void onHitRobot(HitRobotEvent e) {<br />
ramDamage[e.isMyFault() ? 0 : 1] += robocode.Rules.ROBOT_HIT_DAMAGE;<br />
}<br />
</pre><br />
<br />
When isMyFault=false the enemy doesn't always get points for it. For instance a RamBot against SittingDuck.<br />
The underDevelopment class is here [[Talk:CalculatingScore/ScoreWithRamming]]</div>Jabhttp://robowiki.net/w/index.php?title=Archived_talk:CalculatingScore_20070913&diff=2015Archived talk:CalculatingScore 200709132008-03-29T14:03:24Z<p>Jab: Migration: CalculatingScore by Vuen. Archived talk</p>
<hr />
<div>Vuen, can you post the code for calculating score you mention Fractal uses? -- PEZ<br />
<br />
Sure.<br />
<br />
----<br />
I was just talking with jim and he mentioned that this code could be used for deciding whether or not data should be saved on an enemy. It never really occured to me that this could be a use of this code. For this reason, I just added a little getScore method to simplify how the score is stored. You can call getScore at any point in time to get the realtime score of the robot you want. I haven't actually compiled it though, but that's pretty much what my ScoreGL? code does so it should work :D. Using this for actual competitive algorithms rather than just for the sake of having a realtime score seems like a good idea, and so if anybody'd like to use this code for it, feel free, but give credit somewhere : ). -- Vuen<br />
<br />
Thanks. It was for descision making purposes I asked you to publish the code. What better to base descisions on than yours and your enemy's score? -- PEZ<br />
<br />
Changed a few things. Fixed it up a bit. Simplified it a bit. Looks better now. -- Vuen<br />
<br />
It's interesting that quite a few people are interested in this scoring code all of a sudden; this code is from Cake, which has been open source for well over a year (since the Rumble). -- Vuen<br />
<br />
Okay. I made a few changes to get rid of both the name stuff and the getPacketOffset? stuff; it should just work on its own now. You now also have to pass it scan events. I also have not compiled it and just changed it here in the wiki window, so I have no clue if it works. Hopefully it'l compile :D; if it doesn't or if it has any bugs, please fix them or let me know! -- Vuen<br />
<br />
I'll try to plug this class into Swiffer now. Swiffer is RWPCL. Would you consider placing this class under the same license? -- PEZ<br />
<br />
Or, that might be too constraining. What about RWLPCL? -- PEZ<br />
<br />
Um, I'm not a big fan of licensing, so I don't really mind what happens to it. You can pick a license if you like, and put it under it. It doesn't really matter to me : ). Does anybody want me to make a sample bot that uses this code? -- Vuen<br />
<br />
Bugfix... Should be slightly more accurate now. -- Vuen<br />
<br />
Can someone tell me how to print data in Robocode.I get such an error "Error: The return type of method "java.io.PrintStream? append(java.lang.CharSequence? $1);" does not match the return type of method "java.lang.Appendable append(java.lang.CharSequence? $1) throws java.io.IOException;" inherited from type "java/lang/Appendable?".<br />
<br />
Try installing Java Developer Kit (JDK), this should help. -- remiq<br />
<br />
Hi, I'm interested in having a more simple function for the score... is there a source you used to come up with this code, or is it just from experience, and it's kind of common knowledge for experienced people? I will try to distill the code down to a formula myself if I can find a better source. -- BenHorner<br />
<br />
Robocode is open source, just take a peek at the code, if you really wanna know how. --Chase-san<br />
<br />
That's a pretty good source I guess. :) Thanks. --BenHorner<br />
<br />
Does a robot get credit for a bullet that hits an enemy after the shooter has already blown up? Anybody know? --RobertWalker<br />
<br />
I think it does --Chase-san<br />
<br />
Yes, and you may even get the kill bonus for damage done, but you won't get the survival bonus even if you snuff him. One of the speed optimizations I've noticed in FNL's versions of Robocode has been to chop the rounds short when there is one tank left standing. I've seen many rounds where bullets were on a collision course with a tank and the next round starts prematurely. -- Martin<br />
<br />
[[Category:Archived Talk]]</div>Jabhttp://robowiki.net/w/index.php?title=Archived_talk:User:Voidious_20071111&diff=2014Archived talk:User:Voidious 200711112008-03-29T14:01:36Z<p>Jab: Undo revision 2013 by Jab (Talk)</p>
<hr />
<div>Welcome to the robocode addiction! -- [[Pulsar]]<br />
<br />
Man, you said it! It's good for my programming skills, though, so it's not as hard to rationalize as some of my previous addictions :) -- [[Voidious]]<br />
<br />
I couldn't find any page for "miscellaneous discussion", is there one? Anyway, I wanted to point out this contest: <BR><br />
[http://www.joystiq.com/entry/1234000283066508/ Tank Wars competition seeks smart AI programmers]<br />
<BR><br />
It's an invite-only competition, EA Games looking for AI game programmers... You can still download the package if you want, but you can only enter the competition if you go to one of the 14 eligible universities. Man, I'd bet some of you top-notch Robocoders could own this thing. -- [[Voidious]]<br />
<br />
Wow, I go to one of the 14 eligible universities... but I don't know C++ and the competetion is over. Other than that, boy, I bet a quick guess factor gun implementation and some nice random movement would be useful. -- [[Alcatraz]]<br />
<br />
When will we see the new Dookius in the rumble? -- [[PEZ]]<br />
<br />
Probably tomorrow... I'd like to rush it out and see how it ranks, but I am thinking of taking a short break from Dookious after this version, so I want to polish it a little bit first. (Plus I've released 4 versions into the RR in the last week.) There are a lot of aspects of Robocode that I haven't really explored much, and I would really like to toy with some various ideas soon. I doubt I'll be able to stay away from Dookious for too long, though... -- [[Voidious]]<br />
<br />
Too bad. Just throw it out and while waiting for a rating on it tidy up and polish it some. I'm curious! -- [[PEZ]]<br />
<br />
Well, OK, if you say so ;) I'm heading home now, I'll post it within the next 30 mins or so. -- [[Voidious]]<br />
<br />
I posted version 0.69, since the next release was going to be 0.70. It skips a lot of turns when I have CPU constant set to 1, something I was going to work on before 0.70, but I have my RR client set to 100 now, anyway. (It didn't take much of a performance hit when set to 1, anyway.) -- [[Voidious]]<br />
<br />
Wow, the air really is thin up there! I thought 0.70 would crack 2,000, but it's looking like it won't. Maybe I'll release *one more* version before taking that break from Dookious... ;) -- [[Voidious]]<br />
<br />
A belated congratulations on 2000, by the way. [[Florent]] was the only person to break the barrier in 2005. You've kicked 2006 off to a great start! --[[Corbos]]<br />
<br />
Thanks! I was extremely excited about that. I was workin' on Dookious a *lot* for several weeks before that, and now I'm really enjoying taking a break from him to try some other stuff... -- [[Voidious]]<br />
<br />
I spent much of yesterday tinkering with my first team, and got it to a very basic functional state. What a pain in the neck! That might be the last chance I ever give to AntiGravityMovement - it's generally so simple that it seems like a promising idea, but I feel like I have zero control over my tanks when using it. I will probably try some MinimumRiskMovement and/or some MultiMode strategy ideas next. Pain in the neck or not, it seems like a lot of fun! -- [[Voidious]]<br />
<br />
My attempts went from '5 Ugluks' to '5 Ugluks that didn't shoot each other' to '5 rambots that focused on one target at a time determined by the most senior bot alive in a chain of command' but that was a colossal failure due to the friendly fire that ensued. I spent about two days working on it around Thanksgiving and a few weeks ago I removed the last of the related code. -- Martin<br />
<br />
Hehe, sounds a bit like my development process so far. Of course, you have a working melee bot, so you probably have a much better grasp of strategies with that many tanks on the field. Right now I'm happy to get over 33% of total score against any of the teams rated around 1600. -- [[Voidious]]<br />
<br />
It helps a lot if you have any melee-experience, even if it is just about how to handle the radar. Note that radar only has a 1200 scanrange. Most teams just are 5 meleebots put together, which leaves the door open for some 'real' strategy. [[Troodon]] is a very simple and successfull melee and teambot and one of the few that makes use of droids, I lent its way of communication for GrubbmGroup. My tip is to start with a simple gun and concentrate on movement. And watch your battles, it gives much more info about what goes right and wrong than the results can tell. -- [[GrubbmGait]]<br />
<br />
Whoah, I thought I was at the wrong site for a moment when I saw this headline: [http://www.joystiq.com/2006/03/03/cyanide-launches-loki-web-site/ Cyanide Launches Loki Web Site] ... =) -- [[Voidious]]<br />
* It's not my kind of game, but at least the name sounds good. --[[Loki]]<br />
<br />
A no. 1 rating at 486 battles and a positive momentum: will Dookious be the new top-bot and Voidious the new king? Stay tuned!<br />
<br />
Anyhow, congratulations with your steady improvement on this strong bot. And i noticed you also entered the melee arena! So we will have to fear your presence there as well... --[[Loki]]<br />
<br />
Thanks, Loki! I'm quite pleased with the latest rating, and I'll enjoy my time at the #1 spot, but the [[History/KingsOfRR|official crown]] certainly still belongs to Ascendant, since I'm sure his best version would outrank Dookious by a good 10 points.<br />
<br />
* hehe, you wrote "I'm quite pleased with the latest rating" but i bet you are walking around with a permanent ear-to-ear grin on your face!!! And its earned! (reading this it's almost as if the British flag in front of Dookious is better suited ;) ) --[[Loki]]<br />
* Ha, that comment made me laugh =) I guess "pleased" might be a slight understatement ;) There's a margin of error on anything I post about before lunch... -- [[Voidious]]<br />
<br />
And it might be a while before it's worth fearing me in the melee arena. That fear is probably better placed upon [[Florent]] at the moment. But I'll keep working at it... =)<br />
<br />
-- [[Voidious]]<br />
<br />
My sincere congratulations to you! Real 1st place at RoboRumble. I can only hope, that one day my bot will enter first ten at least. -- [[DemetriX]]<br />
<br />
Wow. I turn my back for a second and you take the #1 space - a very sincere congratulations! I look forward to seeing what kind of hornets nest you stirred up there. Well done. --[[Corbos]]<br />
<br />
----<br />
<br />
I started using [http://en.wikipedia.org/wiki/Darcs Darcs], a free revision control system that runs on Windows, this week. Spoiled by large amounts of disk space, sometimes I'll just make a copy of my whole [[Dookious]] code directory when I want to preserve something, but I do know just how "wrong" that is. I finally put in the effort to find a CVS-type system that I can use on Windows, and Darcs is working very well for me so far; it's definitely worth checking out if you're looking for one. I wouldn't mind hearing what other people use, if anything. (I'd guess some of the Unix-lovers use CVS, which I've used but have never setup myself.) -- [[Voidious]]<br />
<br />
* Gah, I had seen the [[VersionControl]] page, but just found the [[CVS]] page. Maybe I'll give that [http://www.tortoisecvs.org/ TortoiseCVS] a try... -- [[Voidious]]<br />
* I've been using Subversion happily for a little while, and there is a plugin for Eclipse which makes it so easy to commit new versions. -- [[Alcatraz]]<br />
* I have been using [http://www.march-hare.com/cvspro/ CVSNT] since I started [[X2]] along with CVS plugin for Eclipse. It saved me few times. -- [[Florent]]<br />
* I use nothing :o Almost all my bots are using only one sourcefile. (and I also use [[Kawigi]]'s built-in editor) -- [[GrubbmGait]]<br />
<br />
I e-mailed PEZ right when this started, about 1.5 hours ago, just so you guys know. I hope he shows up sometime soon, but if not, it seems very likely to me that he (or I, if he wants me to) could write a script to revert the vandalised pages, and I don't doubt he could come up with some way of filtering out the SPAM edits in the future. I wish I had the time to keep helping with the reversions, but I have a research paper to work on, unforuntately. :( -- [[Voidious]]<br />
<br />
Sorry for the rudeness but... HOLY FRICKIN CRAP! Whoever did this(and their bot) should be shot in the testicles! -- [[Xero]]<br />
<br />
----<br />
<br />
Well, I picked up a MacBook (white, 2 GHz) today, and I am loving it so far. I've only got 512 RAM right now, and I'm going to upgrade to 2 gigs on my own since Apple would charge $450 for that upgrade (sheesh!). I haven't collected hard numbers on how it compares to my AMD2000 Windows machine in Robocode speed just yet, but it seems to be noticeably a bit faster (as I would hope). Also, this machine is still completely usable even when running an intensive benchmark; and I was able to run 2 separate Robocode matches at the same time with seemingly no slowdown. I haven't found anything to let me manually assign a process to a specific core on a Mac, but if anyone knows how, feel free to let me know.<br />
<br />
Of course, even if the speed of Robocode were just ''not worse'' than my AMD machine, I would still be very happy to be using Mac OS X instead of Windows =) So I am quite a happy camper right now. I hope you other Americans are having a good holiday weekend! <br />
<br />
-- [[Voidious]]<br />
<br />
Have fun with the new machine. =)<br />
<br />
Hey, I remember reading somewhere that you changed your RR@H client to fail quickly if the repository was unavailable. Could you send me the class files for that version? My contact information is on ContactInfo. --[[David Alves]]<br />
<br />
I sent you my version (which should be the same as [[Voidious]]'). This version will never download a bot from the repository, if it is available or not. This means that I download a bot manually if necessary and put it in the 'robots' directory. -- [[GrubbmGait]]<br />
<br />
Ah, beat me to it! :) Anyway, I posted my .class files for that version online, too: [http://www.dijitari.com/void/robocode/roborumble_norepository.zip roborumble_norepository.zip]. It's just replacing the part after the "if" in line 205 of netengine/BotsDownload.java with "return false", instead of formulating the robocoderepository.com URL based on the id number. -- [[Voidious]]<br />
<br />
----<br />
<br />
Snipped that discussion over to [[TwinDuel/2v2CompetitionIdea]]. -- [[Voidious]]<br />
<br />
----<br />
<br />
I'm taking a machine learning course at school this semester, and one of the books we are using for the class is available for free online, with the stipulation that you don't print it. (It's also sold as a "real" book by a publisher.) It assumes some familiarity with some high-ish level math, but I figure some of you might find it interesting: [http://www.inference.phy.cam.ac.uk/mackay/itila/ David MacKay: Information Theory, Inference, and Learning Algorithms] -- [[Voidious]]<br />
<br />
----<br />
<br />
Thanks for running those TC battles; though, please don't feel obligated to make up for my laziness. ;) I'm running a few MC rounds to make up for it... - just hard to balance everything with robots, family, work, and my [http://handmodel.co.uk/ hand modeling career]. Cheers. --[[Corbos]]<br />
<br />
Don't worry, I feel no obligation =), I was just curious to see the scores on your latest release. It looks like [[Chalk]] is a strong contender for the most accurate DC gun out there - very impressive. And besides, it's always nice to flex my MacBook's Core Duo muscle during lectures ;) -- [[Voidious]]<br />
<br />
[[Shadow]]'s got nothing to fear for a while. I've noticed (regretfully) that most of my improvement is against the more simple bots. My PL scores remain wanting. Still, my robofire is refueled. I've got a couple more ideas before I go dormant. What's the class schedule like this semester? Don't you have a couple theater credits left so you could go easy on us for a while? --[[Corbos]]<br />
<br />
Well, only one specific class "required" for my degree (it's my last semester), so I get to take my other classes as pass/fail, which is nice. However, like the dork I am, one of those "electives" is a Senior / Grad level Machine Learning course. On the one hand, it might consume my time so that I have less for Robocode; but on the other hand, it's possible I'll learn something that will help in my Robocoding. =) We're soon looking at k-means clustering. -- [[Voidious]]<br />
<br />
Growing a little frustrated by my recent work on BrokenSword, I turn back to an ancient problem that I've never quite solved: hitting [[Shadow]]. =) -- [[Voidious]]<br />
<br />
<br />
----<br />
<br />
By the way, have you finisced your NaNoWriMo? I enjoyed the beginning and would like to read the whole story! --[[Krabb]]<br />
<br />
Hey, I saw your comment, I appreciate that =) Unfortunately, with everything else I had going on in November, I failed miserably to finish my story again this year. But I was really enjoying it, so maybe I'll pick it up again even though I missed the Nanowrimo deadline. Thanks for checking it out, man ;) -- [[Voidious]]<br />
<br />
Well, it's about time I post the reason for my recent hiatus: I've spent the last month or so moving to / starting my new job. I should be at least a little more active again in the next week or two, but we'll just have to see what happens. There are still some more pressing concerns, like adding to my miniscule quantity of furniture. =)<br />
<br />
I'm certainly still reading the wiki regularly. I know I missed the TwinDuel this past week (without notice, too, sorry), but I'll get it going again this week, for sure. Maybe I'll even find time to try and improve LuminariousDuo in time or work on that TargetingChallenge2K7 score.<br />
<br />
-- [[Voidious]]<br />
<br />
<br />
Hey [[Voidious]] i was wondering if you knew how to setup a robot project in xcode so that xcode will compile the bot and copy the class files back to the robots directory in Robocode after a build. Thanks!! -- [[Gorded]]<br />
<br />
Sorry man, I really don't know. I haven't played with XCode all that much yet, though it's always on my list of things to do. I just use Eclipse for Robocode. -- [[Voidious]]<br />
<br />
Hey, who was that from rpi.edu that just edited / reverted the main page? That's only about an hour away from me and I know a couple people who go there. Just curious. =) If it's someone new and you'll be hanging around, feel free to make a page for yourself and your bots. -- [[Voidious]]<br />
<br />
[[Category:Archived Talk|Voidious]]</div>Jabhttp://robowiki.net/w/index.php?title=Archived_talk:User:Voidious_20071111&diff=2013Archived talk:User:Voidious 200711112008-03-29T13:58:27Z<p>Jab: Migration: CalculatingScore by Vuen. Archived talk</p>
<hr />
<div>Welcome to the robocode addiction! -- [[Pulsar]]<br />
<br />
Man, you said it! It's good for my programming skills, though, so it's not as hard to rationalize as some of my previous addictions :) -- [[Voidious]]<br />
<br />
I couldn't find any page for "miscellaneous discussion", is there one? Anyway, I wanted to point out this contest: <BR><br />
[http://www.joystiq.com/entry/1234000283066508/ Tank Wars competition seeks smart AI programmers]<br />
<BR><br />
It's an invite-only competition, EA Games looking for AI game programmers... You can still download the package if you want, but you can only enter the competition if you go to one of the 14 eligible universities. Man, I'd bet some of you top-notch Robocoders could own this thing. -- [[Voidious]]<br />
<br />
Wow, I go to one of the 14 eligible universities... but I don't know C++ and the competetion is over. Other than that, boy, I bet a quick guess factor gun implementation and some nice random movement would be useful. -- [[Alcatraz]]<br />
<br />
When will we see the new Dookius in the rumble? -- [[PEZ]]<br />
<br />
Probably tomorrow... I'd like to rush it out and see how it ranks, but I am thinking of taking a short break from Dookious after this version, so I want to polish it a little bit first. (Plus I've released 4 versions into the RR in the last week.) There are a lot of aspects of Robocode that I haven't really explored much, and I would really like to toy with some various ideas soon. I doubt I'll be able to stay away from Dookious for too long, though... -- [[Voidious]]<br />
<br />
Too bad. Just throw it out and while waiting for a rating on it tidy up and polish it some. I'm curious! -- [[PEZ]]<br />
<br />
Well, OK, if you say so ;) I'm heading home now, I'll post it within the next 30 mins or so. -- [[Voidious]]<br />
<br />
I posted version 0.69, since the next release was going to be 0.70. It skips a lot of turns when I have CPU constant set to 1, something I was going to work on before 0.70, but I have my RR client set to 100 now, anyway. (It didn't take much of a performance hit when set to 1, anyway.) -- [[Voidious]]<br />
<br />
Wow, the air really is thin up there! I thought 0.70 would crack 2,000, but it's looking like it won't. Maybe I'll release *one more* version before taking that break from Dookious... ;) -- [[Voidious]]<br />
<br />
A belated congratulations on 2000, by the way. [[Florent]] was the only person to break the barrier in 2005. You've kicked 2006 off to a great start! --[[Corbos]]<br />
<br />
Thanks! I was extremely excited about that. I was workin' on Dookious a *lot* for several weeks before that, and now I'm really enjoying taking a break from him to try some other stuff... -- [[Voidious]]<br />
<br />
I spent much of yesterday tinkering with my first team, and got it to a very basic functional state. What a pain in the neck! That might be the last chance I ever give to AntiGravityMovement - it's generally so simple that it seems like a promising idea, but I feel like I have zero control over my tanks when using it. I will probably try some MinimumRiskMovement and/or some MultiMode strategy ideas next. Pain in the neck or not, it seems like a lot of fun! -- [[Voidious]]<br />
<br />
My attempts went from '5 Ugluks' to '5 Ugluks that didn't shoot each other' to '5 rambots that focused on one target at a time determined by the most senior bot alive in a chain of command' but that was a colossal failure due to the friendly fire that ensued. I spent about two days working on it around Thanksgiving and a few weeks ago I removed the last of the related code. -- Martin<br />
<br />
Hehe, sounds a bit like my development process so far. Of course, you have a working melee bot, so you probably have a much better grasp of strategies with that many tanks on the field. Right now I'm happy to get over 33% of total score against any of the teams rated around 1600. -- [[Voidious]]<br />
<br />
It helps a lot if you have any melee-experience, even if it is just about how to handle the radar. Note that radar only has a 1200 scanrange. Most teams just are 5 meleebots put together, which leaves the door open for some 'real' strategy. [[Troodon]] is a very simple and successfull melee and teambot and one of the few that makes use of droids, I lent its way of communication for GrubbmGroup. My tip is to start with a simple gun and concentrate on movement. And watch your battles, it gives much more info about what goes right and wrong than the results can tell. -- [[GrubbmGait]]<br />
<br />
Whoah, I thought I was at the wrong site for a moment when I saw this headline: [http://www.joystiq.com/2006/03/03/cyanide-launches-loki-web-site/ Cyanide Launches Loki Web Site] ... =) -- [[Voidious]]<br />
* It's not my kind of game, but at least the name sounds good. --[[Loki]]<br />
<br />
A no. 1 rating at 486 battles and a positive momentum: will Dookious be the new top-bot and Voidious the new king? Stay tuned!<br />
<br />
Anyhow, congratulations with your steady improvement on this strong bot. And i noticed you also entered the melee arena! So we will have to fear your presence there as well... --[[Loki]]<br />
<br />
Thanks, Loki! I'm quite pleased with the latest rating, and I'll enjoy my time at the #1 spot, but the [[History/KingsOfRR|official crown]] certainly still belongs to Ascendant, since I'm sure his best version would outrank Dookious by a good 10 points.<br />
<br />
* hehe, you wrote "I'm quite pleased with the latest rating" but i bet you are walking around with a permanent ear-to-ear grin on your face!!! And its earned! (reading this it's almost as if the British flag in front of Dookious is better suited ;) ) --[[Loki]]<br />
* Ha, that comment made me laugh =) I guess "pleased" might be a slight understatement ;) There's a margin of error on anything I post about before lunch... -- [[Voidious]]<br />
<br />
And it might be a while before it's worth fearing me in the melee arena. That fear is probably better placed upon [[Florent]] at the moment. But I'll keep working at it... =)<br />
<br />
-- [[Voidious]]<br />
<br />
My sincere congratulations to you! Real 1st place at RoboRumble. I can only hope, that one day my bot will enter first ten at least. -- [[DemetriX]]<br />
<br />
Wow. I turn my back for a second and you take the #1 space - a very sincere congratulations! I look forward to seeing what kind of hornets nest you stirred up there. Well done. --[[Corbos]]<br />
<br />
----<br />
<br />
I started using [http://en.wikipedia.org/wiki/Darcs Darcs], a free revision control system that runs on Windows, this week. Spoiled by large amounts of disk space, sometimes I'll just make a copy of my whole [[Dookious]] code directory when I want to preserve something, but I do know just how "wrong" that is. I finally put in the effort to find a CVS-type system that I can use on Windows, and Darcs is working very well for me so far; it's definitely worth checking out if you're looking for one. I wouldn't mind hearing what other people use, if anything. (I'd guess some of the Unix-lovers use CVS, which I've used but have never setup myself.) -- [[Voidious]]<br />
<br />
* Gah, I had seen the [[VersionControl]] page, but just found the [[CVS]] page. Maybe I'll give that [http://www.tortoisecvs.org/ TortoiseCVS] a try... -- [[Voidious]]<br />
* I've been using Subversion happily for a little while, and there is a plugin for Eclipse which makes it so easy to commit new versions. -- [[Alcatraz]]<br />
* I have been using [http://www.march-hare.com/cvspro/ CVSNT] since I started [[X2]] along with CVS plugin for Eclipse. It saved me few times. -- [[Florent]]<br />
* I use nothing :o Almost all my bots are using only one sourcefile. (and I also use [[Kawigi]]'s built-in editor) -- [[GrubbmGait]]<br />
<br />
I e-mailed PEZ right when this started, about 1.5 hours ago, just so you guys know. I hope he shows up sometime soon, but if not, it seems very likely to me that he (or I, if he wants me to) could write a script to revert the vandalised pages, and I don't doubt he could come up with some way of filtering out the SPAM edits in the future. I wish I had the time to keep helping with the reversions, but I have a research paper to work on, unforuntately. :( -- [[Voidious]]<br />
<br />
Sorry for the rudeness but... HOLY FRICKIN CRAP! Whoever did this(and their bot) should be shot in the testicles! -- [[Xero]]<br />
<br />
----<br />
<br />
Well, I picked up a MacBook (white, 2 GHz) today, and I am loving it so far. I've only got 512 RAM right now, and I'm going to upgrade to 2 gigs on my own since Apple would charge $450 for that upgrade (sheesh!). I haven't collected hard numbers on how it compares to my AMD2000 Windows machine in Robocode speed just yet, but it seems to be noticeably a bit faster (as I would hope). Also, this machine is still completely usable even when running an intensive benchmark; and I was able to run 2 separate Robocode matches at the same time with seemingly no slowdown. I haven't found anything to let me manually assign a process to a specific core on a Mac, but if anyone knows how, feel free to let me know.<br />
<br />
Of course, even if the speed of Robocode were just ''not worse'' than my AMD machine, I would still be very happy to be using Mac OS X instead of Windows =) So I am quite a happy camper right now. I hope you other Americans are having a good holiday weekend! <br />
<br />
-- [[Voidious]]<br />
<br />
Have fun with the new machine. =)<br />
<br />
Hey, I remember reading somewhere that you changed your RR@H client to fail quickly if the repository was unavailable. Could you send me the class files for that version? My contact information is on ContactInfo. --[[David Alves]]<br />
<br />
I sent you my version (which should be the same as [[Voidious]]'). This version will never download a bot from the repository, if it is available or not. This means that I download a bot manually if necessary and put it in the 'robots' directory. -- [[GrubbmGait]]<br />
<br />
Ah, beat me to it! :) Anyway, I posted my .class files for that version online, too: [http://www.dijitari.com/void/robocode/roborumble_norepository.zip roborumble_norepository.zip]. It's just replacing the part after the "if" in line 205 of netengine/BotsDownload.java with "return false", instead of formulating the robocoderepository.com URL based on the id number. -- [[Voidious]]<br />
<br />
----<br />
<br />
Snipped that discussion over to [[TwinDuel/2v2CompetitionIdea]]. -- [[Voidious]]<br />
<br />
----<br />
<br />
I'm taking a machine learning course at school this semester, and one of the books we are using for the class is available for free online, with the stipulation that you don't print it. (It's also sold as a "real" book by a publisher.) It assumes some familiarity with some high-ish level math, but I figure some of you might find it interesting: [http://www.inference.phy.cam.ac.uk/mackay/itila/ David MacKay: Information Theory, Inference, and Learning Algorithms] -- [[Voidious]]<br />
<br />
----<br />
<br />
Thanks for running those TC battles; though, please don't feel obligated to make up for my laziness. ;) I'm running a few MC rounds to make up for it... - just hard to balance everything with robots, family, work, and my [http://handmodel.co.uk/ hand modeling career]. Cheers. --[[Corbos]]<br />
<br />
Don't worry, I feel no obligation =), I was just curious to see the scores on your latest release. It looks like [[Chalk]] is a strong contender for the most accurate DC gun out there - very impressive. And besides, it's always nice to flex my MacBook's Core Duo muscle during lectures ;) -- [[Voidious]]<br />
<br />
[[Shadow]]'s got nothing to fear for a while. I've noticed (regretfully) that most of my improvement is against the more simple bots. My PL scores remain wanting. Still, my robofire is refueled. I've got a couple more ideas before I go dormant. What's the class schedule like this semester? Don't you have a couple theater credits left so you could go easy on us for a while? --[[Corbos]]<br />
<br />
Well, only one specific class "required" for my degree (it's my last semester), so I get to take my other classes as pass/fail, which is nice. However, like the dork I am, one of those "electives" is a Senior / Grad level Machine Learning course. On the one hand, it might consume my time so that I have less for Robocode; but on the other hand, it's possible I'll learn something that will help in my Robocoding. =) We're soon looking at k-means clustering. -- [[Voidious]]<br />
<br />
Growing a little frustrated by my recent work on BrokenSword, I turn back to an ancient problem that I've never quite solved: hitting [[Shadow]]. =) -- [[Voidious]]<br />
<br />
<br />
----<br />
<br />
By the way, have you finisced your NaNoWriMo? I enjoyed the beginning and would like to read the whole story! --[[Krabb]]<br />
<br />
Hey, I saw your comment, I appreciate that =) Unfortunately, with everything else I had going on in November, I failed miserably to finish my story again this year. But I was really enjoying it, so maybe I'll pick it up again even though I missed the Nanowrimo deadline. Thanks for checking it out, man ;) -- [[Voidious]]<br />
<br />
Well, it's about time I post the reason for my recent hiatus: I've spent the last month or so moving to / starting my new job. I should be at least a little more active again in the next week or two, but we'll just have to see what happens. There are still some more pressing concerns, like adding to my miniscule quantity of furniture. =)<br />
<br />
I'm certainly still reading the wiki regularly. I know I missed the TwinDuel this past week (without notice, too, sorry), but I'll get it going again this week, for sure. Maybe I'll even find time to try and improve LuminariousDuo in time or work on that TargetingChallenge2K7 score.<br />
<br />
-- [[Voidious]]<br />
<br />
<br />
Hey [[Voidious]] i was wondering if you knew how to setup a robot project in xcode so that xcode will compile the bot and copy the class files back to the robots directory in Robocode after a build. Thanks!! -- [[Gorded]]<br />
<br />
Sorry man, I really don't know. I haven't played with XCode all that much yet, though it's always on my list of things to do. I just use Eclipse for Robocode. -- [[Voidious]]<br />
<br />
Hey, who was that from rpi.edu that just edited / reverted the main page? That's only about an hour away from me and I know a couple people who go there. Just curious. =) If it's someone new and you'll be hanging around, feel free to make a page for yourself and your bots. -- [[Voidious]]<br />
<br />
[[Category:Archived Talk]]</div>Jabhttp://robowiki.net/w/index.php?title=Archived_talk:CalculatingScore_20070913&diff=2012Archived talk:CalculatingScore 200709132008-03-29T13:55:31Z<p>Jab: Migration: CalculatingScore by Vuen. Archived talk</p>
<hr />
<div>Vuen, can you post the code for calculating score you mention Fractal uses? -- PEZ<br />
<br />
Sure.<br />
<br />
----<br />
I was just talking with jim and he mentioned that this code could be used for deciding whether or not data should be saved on an enemy. It never really occured to me that this could be a use of this code. For this reason, I just added a little getScore method to simplify how the score is stored. You can call getScore at any point in time to get the realtime score of the robot you want. I haven't actually compiled it though, but that's pretty much what my ScoreGL? code does so it should work :D. Using this for actual competitive algorithms rather than just for the sake of having a realtime score seems like a good idea, and so if anybody'd like to use this code for it, feel free, but give credit somewhere : ). -- Vuen<br />
<br />
Thanks. It was for descision making purposes I asked you to publish the code. What better to base descisions on than yours and your enemy's score? -- PEZ<br />
<br />
Changed a few things. Fixed it up a bit. Simplified it a bit. Looks better now. -- Vuen<br />
<br />
It's interesting that quite a few people are interested in this scoring code all of a sudden; this code is from Cake, which has been open source for well over a year (since the Rumble). -- Vuen<br />
<br />
Okay. I made a few changes to get rid of both the name stuff and the getPacketOffset? stuff; it should just work on its own now. You now also have to pass it scan events. I also have not compiled it and just changed it here in the wiki window, so I have no clue if it works. Hopefully it'l compile :D; if it doesn't or if it has any bugs, please fix them or let me know! -- Vuen<br />
<br />
I'll try to plug this class into Swiffer now. Swiffer is RWPCL. Would you consider placing this class under the same license? -- PEZ<br />
<br />
Or, that might be too constraining. What about RWLPCL? -- PEZ<br />
<br />
Um, I'm not a big fan of licensing, so I don't really mind what happens to it. You can pick a license if you like, and put it under it. It doesn't really matter to me : ). Does anybody want me to make a sample bot that uses this code? -- Vuen<br />
<br />
Bugfix... Should be slightly more accurate now. -- Vuen<br />
<br />
Can someone tell me how to print data in Robocode.I get such an error "Error: The return type of method "java.io.PrintStream? append(java.lang.CharSequence? $1);" does not match the return type of method "java.lang.Appendable append(java.lang.CharSequence? $1) throws java.io.IOException;" inherited from type "java/lang/Appendable?".<br />
<br />
Try installing Java Developer Kit (JDK), this should help. -- remiq<br />
<br />
Hi, I'm interested in having a more simple function for the score... is there a source you used to come up with this code, or is it just from experience, and it's kind of common knowledge for experienced people? I will try to distill the code down to a formula myself if I can find a better source. -- BenHorner<br />
<br />
Robocode is open source, just take a peek at the code, if you really wanna know how. --Chase-san<br />
<br />
That's a pretty good source I guess. :) Thanks. --BenHorner<br />
<br />
Does a robot get credit for a bullet that hits an enemy after the shooter has already blown up? Anybody know? --RobertWalker<br />
<br />
I think it does --Chase-san<br />
<br />
Yes, and you may even get the kill bonus for damage done, but you won't get the survival bonus even if you snuff him. One of the speed optimizations I've noticed in FNL's versions of Robocode has been to chop the rounds short when there is one tank left standing. I've seen many rounds where bullets were on a collision course with a tank and the next round starts prematurely. -- Martin</div>Jabhttp://robowiki.net/w/index.php?title=CalculatingScore&diff=2011CalculatingScore2008-03-29T13:53:34Z<p>Jab: code snippets category</p>
<hr />
<div>; <nowiki>Sub-pages: </nowiki><br />
: '''[[/Archived Talk 20070913]]'''<br />
<br />
<pre><br />
package <yourpackage>;<br />
import robocode.*;<br />
import java.util.*;<br />
<br />
<br />
/**<br />
This is the Score class for duels. This code is<br />
basically what is included in Fractal and Cake to keep<br />
score.<br />
<br />
Instantiate this once on match start, and at the top<br />
of all the needed events just pass them to the instance.<br />
Call printScore at any time to print the scores to<br />
the console. Call getScore(id) at any time to get the<br />
score of the requested robot (0 = self, 1 = enemy).<br />
<br />
If you'd like to use this in your robot, feel free to,<br />
but give credit! -- Vuen<br />
*/<br />
public class Score {<br />
<br />
Robot robot;<br />
<br />
public Score(Robot robot) {<br />
this.robot = robot;<br />
}<br />
<br />
<br />
<br />
public double enemyEnergy;<br />
public double myEnergy;<br />
public String enemyName;<br />
<br />
public double[] bullet = new double[2];<br />
public double[] curbullet = new double[2];<br />
public double[] survival = new double[2];<br />
<br />
<br />
<br />
public void onScannedRobot(ScannedRobotEvent e) {<br />
myEnergy = robot.getEnergy();<br />
enemyEnergy = e.getEnergy();<br />
if (enemyName == null) enemyName = e.getName();<br />
}<br />
<br />
public void onBulletHit(BulletHitEvent e) {<br />
if (e.getEnergy() < 0.001) return; //ignore if enemy dead<br />
<br />
curbullet[0] += 4 * e.getBullet().getPower() + 2 * Math.max(e.getBullet().getPower() - 1, 0);<br />
}<br />
<br />
public void onHitByBullet(HitByBulletEvent e) {<br />
if (e.getPower() * 4 + Math.max(0, e.getPower() - 1) * 2 > myEnergy) return; //ignore if self dead<br />
//this works regardless of order of hitbybullet and scan<br />
<br />
curbullet[1] += 4 * e.getBullet().getPower() + 2 * Math.max(e.getBullet().getPower() - 1, 0);<br />
}<br />
<br />
public void onWin(WinEvent e) {<br />
survival[0] += 60;<br />
<br />
curbullet[0] += enemyEnergy;<br />
<br />
bullet[0] += curbullet[0] * 1.2;<br />
bullet[1] += curbullet[1];<br />
<br />
curbullet[0] = 0; curbullet[1] = 0;<br />
}<br />
<br />
public void onDeath(DeathEvent e) {<br />
survival[1] += 60;<br />
<br />
curbullet[1] += myEnergy;<br />
<br />
bullet[0] += curbullet[0];<br />
bullet[1] += curbullet[1] * 1.2;<br />
<br />
curbullet[0] = 0; curbullet[1] = 0;<br />
}<br />
<br />
<br />
<br />
/** returns the score of the requested robot: 0=self, 1=enemy */<br />
public int getScore(int id) {<br />
return (int)Math.round(bullet[id] + curbullet[id] + survival[id]);<br />
}<br />
<br />
/** prints the scorecard to the console */<br />
public void printScore() {<br />
if (enemyName == null) return;<br />
<br />
System.out.println(" ***********SCORECARD***********");<br />
System.out.print(" ");<br />
for (int i = 0; i < Math.max(robot.getName().length(), enemyName.length()); i++) System.out.print(" ");<br />
System.out.println(" Total Survival Bullet");<br />
<br />
String p0 = " " + robot.getName();<br />
String p1 = " " + enemyName;<br />
<br />
String pTemp = " " + Math.round(bullet[0] + survival[0] + curbullet[0]);<br />
for (int i = robot.getName().length(); i < Math.max(robot.getName().length(), enemyName.length()) + 7 - pTemp.length(); i++) p0 += " ";<br />
<br />
pTemp = (" " + Math.round(bullet[1] + survival[1] + curbullet[1]));<br />
for (int i = enemyName.length(); i < Math.max(robot.getName().length(), enemyName.length()) + 7 - pTemp.length(); i++) p1 += " ";<br />
<br />
p0 += Math.round(bullet[0] + survival[0] + curbullet[0]) + " ";<br />
p1 += Math.round(bullet[1] + survival[1] + curbullet[1]) + " ";<br />
pTemp = (" " + Math.round(survival[0]));<br />
for (int i = 0; i < 8 - pTemp.length(); i++) p0 += " ";<br />
pTemp = (" " + Math.round(survival[1]));<br />
for (int i = 0; i < 8 - pTemp.length(); i++) p1 += " ";<br />
<br />
p0 += Math.round(survival[0]) + " ";<br />
p1 += Math.round(survival[1]) + " ";<br />
pTemp = (" " + Math.round(bullet[0] + curbullet[0]));<br />
for (int i = 0; i < 6 - pTemp.length(); i++) p0 += " ";<br />
<br />
pTemp = (" " + Math.round(bullet[1] + curbullet[1]));<br />
for (int i = 0; i < 6 - pTemp.length(); i++) p1 += " ";<br />
<br />
p0 += Math.round(bullet[0] + curbullet[0]);<br />
p1 += Math.round(bullet[1] + curbullet[1]);<br />
<br />
if (bullet[0] + survival[0] + curbullet[0] >= bullet[1] + survival[1] + curbullet[1]) {<br />
System.out.println(p0); System.out.println(p1);<br />
} else {<br />
System.out.println(p1); System.out.println(p0);<br />
}<br />
}<br />
<br />
}<br />
</pre><br />
<br />
[[Category:Code Snippets]]</div>Jabhttp://robowiki.net/w/index.php?title=CalculatingScore&diff=2010CalculatingScore2008-03-29T13:52:04Z<p>Jab: Migration: CalculatingScore by Vuen</p>
<hr />
<div>; <nowiki>Sub-pages: </nowiki><br />
: '''[[/Archived Talk 20070913]]'''<br />
<br />
<pre><br />
package <yourpackage>;<br />
import robocode.*;<br />
import java.util.*;<br />
<br />
<br />
/**<br />
This is the Score class for duels. This code is<br />
basically what is included in Fractal and Cake to keep<br />
score.<br />
<br />
Instantiate this once on match start, and at the top<br />
of all the needed events just pass them to the instance.<br />
Call printScore at any time to print the scores to<br />
the console. Call getScore(id) at any time to get the<br />
score of the requested robot (0 = self, 1 = enemy).<br />
<br />
If you'd like to use this in your robot, feel free to,<br />
but give credit! -- Vuen<br />
*/<br />
public class Score {<br />
<br />
Robot robot;<br />
<br />
public Score(Robot robot) {<br />
this.robot = robot;<br />
}<br />
<br />
<br />
<br />
public double enemyEnergy;<br />
public double myEnergy;<br />
public String enemyName;<br />
<br />
public double[] bullet = new double[2];<br />
public double[] curbullet = new double[2];<br />
public double[] survival = new double[2];<br />
<br />
<br />
<br />
public void onScannedRobot(ScannedRobotEvent e) {<br />
myEnergy = robot.getEnergy();<br />
enemyEnergy = e.getEnergy();<br />
if (enemyName == null) enemyName = e.getName();<br />
}<br />
<br />
public void onBulletHit(BulletHitEvent e) {<br />
if (e.getEnergy() < 0.001) return; //ignore if enemy dead<br />
<br />
curbullet[0] += 4 * e.getBullet().getPower() + 2 * Math.max(e.getBullet().getPower() - 1, 0);<br />
}<br />
<br />
public void onHitByBullet(HitByBulletEvent e) {<br />
if (e.getPower() * 4 + Math.max(0, e.getPower() - 1) * 2 > myEnergy) return; //ignore if self dead<br />
//this works regardless of order of hitbybullet and scan<br />
<br />
curbullet[1] += 4 * e.getBullet().getPower() + 2 * Math.max(e.getBullet().getPower() - 1, 0);<br />
}<br />
<br />
public void onWin(WinEvent e) {<br />
survival[0] += 60;<br />
<br />
curbullet[0] += enemyEnergy;<br />
<br />
bullet[0] += curbullet[0] * 1.2;<br />
bullet[1] += curbullet[1];<br />
<br />
curbullet[0] = 0; curbullet[1] = 0;<br />
}<br />
<br />
public void onDeath(DeathEvent e) {<br />
survival[1] += 60;<br />
<br />
curbullet[1] += myEnergy;<br />
<br />
bullet[0] += curbullet[0];<br />
bullet[1] += curbullet[1] * 1.2;<br />
<br />
curbullet[0] = 0; curbullet[1] = 0;<br />
}<br />
<br />
<br />
<br />
/** returns the score of the requested robot: 0=self, 1=enemy */<br />
public int getScore(int id) {<br />
return (int)Math.round(bullet[id] + curbullet[id] + survival[id]);<br />
}<br />
<br />
/** prints the scorecard to the console */<br />
public void printScore() {<br />
if (enemyName == null) return;<br />
<br />
System.out.println(" ***********SCORECARD***********");<br />
System.out.print(" ");<br />
for (int i = 0; i < Math.max(robot.getName().length(), enemyName.length()); i++) System.out.print(" ");<br />
System.out.println(" Total Survival Bullet");<br />
<br />
String p0 = " " + robot.getName();<br />
String p1 = " " + enemyName;<br />
<br />
String pTemp = " " + Math.round(bullet[0] + survival[0] + curbullet[0]);<br />
for (int i = robot.getName().length(); i < Math.max(robot.getName().length(), enemyName.length()) + 7 - pTemp.length(); i++) p0 += " ";<br />
<br />
pTemp = (" " + Math.round(bullet[1] + survival[1] + curbullet[1]));<br />
for (int i = enemyName.length(); i < Math.max(robot.getName().length(), enemyName.length()) + 7 - pTemp.length(); i++) p1 += " ";<br />
<br />
p0 += Math.round(bullet[0] + survival[0] + curbullet[0]) + " ";<br />
p1 += Math.round(bullet[1] + survival[1] + curbullet[1]) + " ";<br />
pTemp = (" " + Math.round(survival[0]));<br />
for (int i = 0; i < 8 - pTemp.length(); i++) p0 += " ";<br />
pTemp = (" " + Math.round(survival[1]));<br />
for (int i = 0; i < 8 - pTemp.length(); i++) p1 += " ";<br />
<br />
p0 += Math.round(survival[0]) + " ";<br />
p1 += Math.round(survival[1]) + " ";<br />
pTemp = (" " + Math.round(bullet[0] + curbullet[0]));<br />
for (int i = 0; i < 6 - pTemp.length(); i++) p0 += " ";<br />
<br />
pTemp = (" " + Math.round(bullet[1] + curbullet[1]));<br />
for (int i = 0; i < 6 - pTemp.length(); i++) p1 += " ";<br />
<br />
p0 += Math.round(bullet[0] + curbullet[0]);<br />
p1 += Math.round(bullet[1] + curbullet[1]);<br />
<br />
if (bullet[0] + survival[0] + curbullet[0] >= bullet[1] + survival[1] + curbullet[1]) {<br />
System.out.println(p0); System.out.println(p1);<br />
} else {<br />
System.out.println(p1); System.out.println(p0);<br />
}<br />
}<br />
<br />
}<br />
</pre></div>Jabhttp://robowiki.net/w/index.php?title=User:Jab&diff=2008User:Jab2008-03-28T16:22:43Z<p>Jab: User:Jab</p>
<hr />
<div>== About Me ==<br />
<br />
e-mail: jabimail gmail com<br />
<br />
== My Bots ==<br />
* [[Batou]]<br />
* [[Sanguijuela]]<br />
<br />
== Other stuff ==<br />
* [[Module]] bot structure<br />
<br />
[[Category:Bot Authors|Jab]]</div>Jabhttp://robowiki.net/w/index.php?title=User_talk:Jab&diff=2007User talk:Jab2008-03-28T15:52:29Z<p>Jab: Chat with RobertWalker</p>
<hr />
<div>Glad to see another Robocoder interested in modular architecture. I was looking over the Module pages and I really like your approach. PluggableRobot and Module have somewhat different philosophies, but I think there's room for both.<br />
<br />
The biggest downside with PluggableRobot is that you're still left with something of a blank canvas. You have modularity, but there isn't really anything that guides you in terms of what components to make or how to share data between modules. Module handles that, which is a big win. On the other hand, Module seems to force your modules to be of particular types, whereas with PluggableRobot you can make modules that may not correspond to the types you've laid out. For example, RabidWombat (which I promise will *eventually* be seen in the wild :-)) has a "taunt" module that listens for events and then writes obnoxious comments in the console. Not terribly mission-critical, I'll grant you, but you get the picture.<br />
<br />
Anyway, looks like some nice work. Keep it up!<br />
<br />
RobertWalker 17:27, 27 March 2008 (UTC)<br />
<br />
Thanks for your comments. Yes, they are different approaches in the way you have said. Looking at the code of PluggableRobot it's easy to get the idea behind its structure, but to see the structure in action you can upload to the robocodeRepository a simple and didactic bot extending pluggableRobot: A bot with less complexity than RabidWombat please :P Let me know about that.<br />
<br />
--[[User:Jab|jab]] 15:52, 28 March 2008 (UTC)</div>Jabhttp://robowiki.net/w/index.php?title=User_talk:Altglass&diff=1995User talk:Altglass2008-03-27T13:17:20Z<p>Jab: Good luck!</p>
<hr />
<div>Good luck with your new bots!<br />
Anti-gravity movement? You're not going to have problems finding information about that topic. I re-wrote the code of the developerWorks article for [[Module]], it is on the Parts Repository. --[[User:Jab |Jab]]</div>Jabhttp://robowiki.net/w/index.php?title=Template_talk:CurrentEventsShort&diff=1993Template talk:CurrentEventsShort2008-03-27T08:11:17Z<p>Jab: Undo revision 1992 by 91.124.49.229 (Talk)</p>
<hr />
<div>Just wanted to say Hello to everyone. <br />
Much to read and learn here, I'm sure I will enjoy !</div>Jab