Smart bots competition
← Thread:User talk:Beaming/Smart bots competition/reply
I like the idea of more processing time in order to attempt more complex stats, but to be honest I've tried some pretty complex stuff (including Spectral Clustering) for KNN on recorded data and nothing has beat simple KNN with a square kernel and weighted on sample distance. Not to mention that a lot of these algorithms aren't just a constant 50x slower or whatever, they essentially become unsolvable at sizes above ~500 data points, scaling quadratically or worse.
A problem with unlimited processing time is that it becomes possible to simply keep a copy of other bots and simulate them to determine where they will shoot/move.
Does anybody have any specific techniques that they would use if there was more processing time available?
I personally was aiming to a better movement algorithm. I.e. one can do better than 1 or 2 wave surfing. That would be super critical in melee, where you can track/react/predict more than just the closest bot.
Idea of enemy simulator is also attractive. I personally do not like clustering algorithms, I would rather prefer emulate and distill a subset of physically possible and optimal tracks for a current situation.
A clustering algorithm probably would seize to work once you apply it in melee, since you have to account for a neighboring bot subset as an input.I would think this would drastically increase the problem dimensions.
Displacement vectors of Voidious would be the closest to real emulation but it is still just an approximation.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:User talk:Beaming/Smart bots competition/reply (5).
I had some movement algorithm things in the works, and they would have been more straightforward to implement with more processing time sure, but half the fun so to speak was coming up with the right optimization strategies to make it very fast.
Honestly, overall I don't feel like higher per-tick processing time would be too helpful at this point. My reasoning is, high level Robocode tends to require a very large amount of automated testing to know if some tuning was was actually an improvement or not. If the processing time limit was increased, it would also increase how long that testing takes.
Basically, I think the potential gains from slower algorithms are outweighed by the gains of faster iterations during tuning/development.
If anything I'd be more interested in a "FastBots" league, except I think the engine's control over the processing limit is too unreliable/unstable for that to be reasonable.
Well I wouldn't mind implementing full and proper n-wave surfing, right now Nene just does 2 wave surfing in simple way. Full n-wave would be very time consuming to calculate. But I am unsure of any major improvement it would bring to movement.