Thread history
| Time | User | Activity | Comment |
|---|---|---|---|
| No results | |||
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.
