http://robowiki.net/w/index.php?title=Thread:Talk:RoboRumble/Client_java_version/reply_(26)&feed=atom&action=historyThread:Talk:RoboRumble/Client java version/reply (26) - Revision history2024-03-28T13:50:39ZRevision history for this page on the wikiMediaWiki 1.34.1http://robowiki.net/w/index.php?title=Thread:Talk:RoboRumble/Client_java_version/reply_(26)&diff=51219&oldid=prevMultiplyByZer0: Reply to Client java version2017-09-04T19:18:00Z<p>Reply to <a href="/wiki/Thread:Talk:RoboRumble/Client_java_version/reply_(22)" title="Thread:Talk:RoboRumble/Client java version/reply (22)">Client java version</a></p>
<p><b>New page</b></p><div>I took a look at your results. Your bot ''is'' performing below expectations, most prominently with 37.71% survival against sample.Crazy (???), which I cannot reproduce on my own computer.<br />
<br />
I do agree that bugs (particularly ones that produce unfair results) ought to be squashed ASAP. However, you cannot expect the amount of work-per-turn your bot is allowed to perform to remain constant between machines (and possibly not even between battles or rounds). Perhaps a CPU-intensive background process is running, or the user decides to play video games, or the OS starts throttling Java, or the CPU drops to 0.15 GHz for no good reason (I've actually seen that happen), or gamma rays hit your computer and flip a bit in the tick time counter, or whatever.<br />
<br />
My point was that high-CPU bots must adapt to changing circumstances. Too many bots just ignore SkippedTurnEvent, when it's practically a blaring flashing-red-lights warning from Robocode. You could respond by reducing CPU load, e.g. disabling features, virtual guns, second wave surfing, etc. It's better for your bot to function suboptimally than to not function at all.</div>MultiplyByZer0