Planned investigations

Jump to navigation Jump to search

Planned investigations

Edited by author.
Last edit: 10:57, 4 September 2017

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 theory and practice is in practice bigger than in theory.

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

GrubbmGait (talk)13:23, 3 September 2017

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.

Beaming (talk)02:55, 4 September 2017

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 . . .

GrubbmGait (talk)11:21, 4 September 2017
 

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

Xor (talk)05:51, 4 September 2017

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:GrubbmThree/Planned investigations/reply (4).

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.

Beaming (talk)15:09, 4 September 2017
 
 

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.

GrubbmGait (talk)02:40, 9 September 2017

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.

Beaming (talk)03:19, 9 September 2017

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.

GrubbmGait (talk)09:25, 9 September 2017

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.

Beaming (talk)14:44, 9 September 2017

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.

GrubbmGait (talk)16:58, 9 September 2017

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.

Beaming (talk)19:59, 9 September 2017

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 ?

GrubbmGait (talk)13:24, 10 September 2017
 
 
 
 
 

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.

Beaming (talk)20:01, 9 September 2017

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'.

GrubbmGait (talk)13:26, 10 September 2017
 
 

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.

GrubbmGait (talk)14:05, 21 September 2017