Targeting
Movement
Wall Avoidance
I have seen a few mentions of things that would be the HolyGrail of this or that which are being implemented today. It could be interesting to see where we are on these in the future.
Unrealistic sort-of-cheating idea: You figure out the class name of your enemy. Then you start a simulation of the current game 'inside' your bot and you overload all of the robocode api calls and load that class file of your opponent into this simulation. Now you try to bring your simulation in sync with the real game and feed that data to your sandboxed version of the enemy code which will then happily answer with calls to setTurnGunRight() etc. If you really achieve to have this both versions of the game in sync the reactions of your enemy should be the same as the ones in your simulation, provided the enemy doesn't use Math.random() or such. So you know where he is going and where all of his bullets are: the holy grail :-) Ok, just a weird idea I though I'd share. This is obviously cheating if you could get it to work, which would be extremly difficult (maybe even impossible?) because as the chaos theory shows us, even small differences can result in a completely different outcome (and to start with, you don't know the heading of your enemy right from the begin of a new round). Besides, reimplementing the robocode api is quite a lot of work. :-) --jav
That would be one hell of a MegaBot if it had the classes of all the good RoboRumble tanks ;) If you're willing to do something like this, you'd probably be better off just using CassiusClay as a base and tweaking it to your liking. Funny idea, though, and I bet there are at least a few good tanks that don't use Math.random(). -- Voidious
You would quickly run into a recursion problem if you pitted two bots like that against one another. Bot A would have to have a copy of bot B in it's package. Bot B has a copy of bot A in its package, which has an earlier version of bot B within its package. And so on. Fortunately bots do not have access to files outside their own sandbox.
I do something similar, though not as extreme, in some of my targeting, specifically oscillation and mirroring. I give the enemy a movement system (which I had to design) and plot out how he will react to my anticipated movement, the fire a virtual bullet at his future position. If I would have hit him consistently enough (and moreso than with other targeting paradigms) then I assume he is moving in that fashion, or close enough to it for my needs.
I am sure other bots do something similar to determine the targeting techniques of the enemy, though I do not. -- Martin
Well, I was thinking more of open-source tanks that you would compile into your own package and bot, so the security wouldn't be an issue. Still, the issue of any Math.random()'s, minor miscalculations, and keeping up-to-date versions of every open source tank just makes it far from worthwhile. Digressing... Early on, I had a bunch of "enemy aimers" and tried to figure out what aiming algorithm the enemy was using, and then dodging it, but it never really worked too well. It turns out WaveSurfing is a lot more efficient and effective, though only useful in 1-on-1. (And, at its base, is really just a more refined version of said idea.) -- Voidious
My class in Uni had to make a robot which could survuve against a spin shooter more than 60% of the time. While I opted to make a team (anticipating that I would have to face a team of SpinBots?, which it could do sucessfully), several people opted to collect three positions for the spinBot from the Radar and use them to calculate the position of the circle which the spinbot traces. They then could simply calculate the position of the SpinBOt? and know exactly where to fire to hit it. I finstead of assuming the motion was a circle, statistical fitting code was applied, then the x and y positions could be found with respect to t, and you would ahve a reasonably accurate idea of where htey will be. HTe only problem would be doing it fast enough.
![[Home]](/images/RoboWiki.png)