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?

No problem. Ahh, well as a note, DrussGT is not the easiest surfer to read IMO.

Hmm.. for the questions:

1) A kd-tree is a data structure used to do a "k-nearest-neighbor" search fast. What the "k-nearest-neighbor" search does, is it allows you to search a history for the past situations most similar to the current situation. You give numeric values to different aspects of the situation, and it finds the most similar several past situations, and this can be used in either targeting or movement to predict the opponent, based on the premise that they'll react to the situation similarly both times.

2a) To save between rounds, you just use a "static" variable in Java. The "static" keyword makes it so the value is is common between all instances of a class, such as between separate rounds. Basically all bots that learn use this.

2b) To store between matches you need to use some robocode APIs for writing and reading files. I don't like using it because it makes a bot rank more favorably in the rumble if fewer clients are running at a time, due to learned information being separate between each client. Note that LittleBlackBook is different because it only reads this way, because it's whole strategy is having a pre-written data file. I would also note that relatively few robots use cross-round data saving.

3) Well... my first robot was a weird multi-mode thing that took several weeks to make, but I never released it. The first bot I ever released was LunarTwins. For LunarTwins it took 24 hours for "the inspiration to ferment", and the first released version of the code was finished within a 36 hour period of time. Really though, LunarTwins was fast to write because it's a non-learning robot. My second publicly released robot was RougeDC which was my first surfer. I don't remember how long that bot took, but I know I spent most of Summer 2008 working on various versions of it.

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 =)

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