For edutainment purposes I packaged a separate version of Pugilist 1.3.1 which only runs in RobocodeGLV014. It can look like so in battle:
The blue dots are EnemyWaves created by PugilistGL when the enemy fires. One dot per GuessFactor. The thicker the dots the more visited that particular guess factor is. (Thus should be avoided if a flat profile is desired.) Each wave has an id, seen in the middle of the wave (near the GF0 dot).
Pugilist does WaveSurfing (tries to). It checks the possible, approximated, end points going forward and reverse from its current lateral movement in respect to a particular wave. This is shown with the green dots (forward end points) and red dots (reverse end points). Each end point carries the corresponding wave id and the visit count for that dot (smoothed and weighted for distance). You can see how P estimates the end points a bit wrong especially near walls. Wave id 1920 hasn't impacted yet. But P is already almost past the estimated end point. If you sum the visit counts for all forward points it will end up less than the sum for the reverse points. Thus P will keep going in the current lateral direction.
Check the source /Code if you're curious. It's the WaveGrapher class that's does the drawing job.
-- PEZ
Yes, the EnergyDrop at inactivity time fools PGL (and all my bots) that the enemy is firing. It's OK though, at inactivity time the game is set anyway. -- PEZ
I know, but InactivityProtection? might give you a few extra points (wasn't the whole score made of many of these small parts? :)). Especially for MegaBots there is no reason not to implement it. Not really for MiniBots, but I saw it happening with PGL. ;) -- Jonathan
How would it earn you any extra points? I think it might be a bit tricky to implement. It would even risk cost you points if you introduce bugs with it. And then when you have gotten it bug free it's more code to maintain and such. Anyway, if you have a suggestion on how to implement it please share. It might not be as tricky as I think. -- PEZ
You have to calculate how much energy you lost, besides the events. See the [Robocode FAQ] for formulas. -- Jonathan
While I was testing it, I got two HitRobotEvent?s per turn! The energy loss was 0.6 and the loss according to the events was 1.2, so InactivityTime? would have caused a 0.6 increase. Not really what you want... -- Jonathan
But does it matter for the performance? -- PEZ
I think it does, but not much, unless you set InactivityTime? to maybe 150 ticks or less. - Jonathan
![[Home]](/images/RoboWiki.png)