Planned investigations

Although this bot is one of the top rammers for more than 10 years and hasn't changed in the meantime, I don't like it that more and more bots get a score above 70% against it. So I plan to try out two possible improvements.

- introduce a 'wobble' in its movement (like MaxRisk), so the LT/CT guns can miss it even from near close range. This will lower the average speed a bit, but hopefully this will be compensated by an occasional miss by the opponent.

- At the beginning of the round, turn the radar in the direction of the center of the field. This will increase the possibility to find the opponent earlier, so I can move earlier and will be on his tail earlier. This should (in theory) increase the score a little against everyone. But you know: The difference between practice and theory is in practice bigger than in theory.

If I get hooked again ( . . . ), prepare for other updated bots, or even a new one.

Hey,

Good to hear about hooked part.

As for the rammer, I look closely at couple battles. I think the CT has its weakness since its tends to overshoot, may be push the firing angle a bit closer to HoT.

I already do that a bit by iterating till I reach the outer hull instead of the center. But now I have one extra idea I can try out: stop iterating one tick before I reach the outer hull . . .

Good to hear a planned better rammer for challenge! I also have some ideas on rammers, etc. using the techniques from wave surfing to precisely track and dodge bullets, while at the same time move closer constantly. Most bots will be pushed to walls or even corners, where their tombs lay. Even the most advanced ones will have very limited movement options, and their advantages at farther distance will be gone.

However, I didn't tried any of them, and the reality is generally very different from the imaginations ;p

A very long time ago PEZ and I made an attempt to a GuessFactor rammer, ARAMtocles. In the Rambot Challenge 2K6 it was adequate, but in the rumble with only 35 rounds it learned to slow to really make a fist. You can always adapt your best bot to a preferred distance of 36 ;-)

The amassing thing that one can still dodge at distance of 36. I recall my desperate attempts to ram DrussGT and getting close to no hits even at short distances.

Seems that all 'improvements' I had in mind actually made its performance worse. Maybe I can better join the 'WorstBot' competition. Last chance is with 0.9d and if that one does not succeed, I will go sit in the corner and cry.

I would also suggest, to relabel old variant and put it in rumble. I feel that old rumble stats had a lot of disabled bots. It might appear that old version is better but it is actually not. Plus we have at least 3 new above top 100 bots which might pull your APS down.

That is true, it is also my intention to do so. I always compare against the older version via Botdetails, it let you see the differences betweeen the common pairings, so that really is the difference, even if only 1000 bots are in common. Just remove the 'd' from versionnumber and press Compare.

My main worry here is about difference in liteclient performance. Most of the old rankings were done with ancient version of robocode. It is possible that your old bot was tuned to exploit a glitch without you even knowing about.

I do know that some bots don't work very well in Robocode 1.9.2.x and/or Java 8. See f.e. Xiongan.xiongan and tcf.Drifter, they get scores of 0 against GrubbmThree, while on my system (1.9.2.5 and Java 7) they just work ok.

There is else but Java 7 vs 8. I ran tcf.Drifter vs. GrubbmThree 0.9d in robocode GUI with Java 8. Drifter constantly wins the match.

So I cannot attribute 100% loss which we see in rumble just to the Java version.

I did read somewhere that tcf.Drifter had some problem with the 1.9.2.5_beta versions, maybe someone is running the rumble with a non-official 1.9.2.5 version ?

Hey, I watched 0.9d wobble. I think it is not big enough to move your bot from HoT direction. It might fool CT, but HoT still gets you. I would increase wobble amplitude.

Really something to try out, although I fear that then it has not enough speed to catch up on the other bot. First I test a re-entry of the original to determine the 'APS-rot'.

In the meantime two more ideas next to the two first ones have popped up that show some promise, at least in theory.

- At start, turn radar towards the middle of the field. Gains nothing (maybe 0.02 APS) and cost quite some code. So dump it.

- Introduce 'wobble'. This shows some promise, but still is rough and needs more exploration. The rough version gains 0.3 APS though.

- next to headingchange, also keep speedchange into account. Although I can't exactly follow the Robocode rules (accel and decell is 1) this gives approx 0.4 APS.

- my 'prevent wall-shooting' aims in the field and adapts bulletpower to intercept the opponent at that point. This works very well at relatively greater distances. At close range, forget that: Aim in the field and fire full power ! Should gain some 0.x APS

It is only a pity that all these things feel a bit 'hacky', while the behaviour of MaxRisk in a battle has much more natural beauty.