Welcome

Welcome to the Robowiki! Feel free to ask any questions you might have.

I'd say going for a surfer this early in your robocoding if fairly ambitious but doable! I'd suggest you make sure to test a lot against something like HawkOnFire that just fires straight at you, because this is good for getting some for making sure you don't have certain types of common bugs. Hope it goes well :)

Thank you!

I changed my mind a lot over time (even if I created my profile yesturday!), and I decided that it is better to start with a safe and proven firing and moving technique. I think you are right that I could make it, but it would be to frustrating for me, after taking a look at DrussGT code ^^.

I never thought anyone would notice my profile, and I am happy you stopped to say something :). I am really impressed by the play-style of your Lunar Twins, seriously.

So, for Exode, I thought I could use random Stop and go moving. For the firing system, I don't know. Maybe multi-mode later, but for the first version I want something more valuable than Head-on.

And, yes, I do have some questions :

Can you tell me more about the kd-tree? What is it? How can it improve a bot? How can I save information between rounds and between matches (Like little black book)? How long it took you to release your first bot?

Yeah, DrussGT isn't designed to be easy to read. There are a lot of things that could be done simpler, but it is optimized for fast execution so the code is a lot larger than it could be. Also, I have a very messy coding style =)

To be fair I doubt any of the top 10 to 20 are easy to read. Having thrown out easy to read for performance. Not sure about Diamond or Dookious, I think Voidious might have made a fair attempt at both.

This came up in another thread recently, but I'd say good/readable code vs good performance is a false dichotomy. I think it's more good code vs "I'm addicted to Robocode and just want to cram in this latest feature right now instead of taking a few minutes to refactor anything, and I'm the only one working with this code anyway so who cares." =) Most of the CPU time in top bots is in the trig for precise prediction and the targeting algorithm. Whether you have good or messy code in the rest of your bot doesn't have much relative impact on performance.

Dooki's code is pretty good, but I haven't looked at it in a while. I'm quite happy with the state of Diamond's code after the latest huge refactor. Chalk's code is pretty clean, and there are some open source newcomers in the top 25 that I've never really looked at.

Nene's was suppose to be nice and clean, but had `that` problem. Eventually the movement class got rather bloated. I have been meaning to refactor it for some time, but never got around to it. But who cares, it's not like anyone else is working on that code. ;)

I'm getting up the courage to do a readability/extendability refactor on deBroglie before I then get back to adding in the features that are still missing.

I'm hoping to go the anti "I'm the only one working with this code anyway so who cares" route because I'd like to show the source to my CS/engineering students once I'm done. Doing a trace of exactly what happens on a single onScannedRobot() with every called method having a readable comment explaining it would be a treat. :)

Coming back after a hiatus has often been a great time for me to work on refactoring and cleanup. You're a bit free from the crazy addiction mindset and can just enjoy getting into the code and making it something to be proud of. And the flip side is that by slowing down and looking over all the code in detail, instead of feverishly looking for the next thing to tweak, you find lots of bugs and come up with good ideas. I read a Thomas Edison quote recently that I really love, and which that scenario really reminds me of: "Great ideas originate in the muscles."