Multiple Choice, You Say ...
Great! Thanks for migrating this so it caught my attention! Now I know what I need to do in the micro category :). --Simonton 14:35, 21 September 2008 (UTC)
God help me, but I actually completely understand that space compressed code. I believe I even found a few ways to improve it here and there. It might be time for me to Microbot. --Miked0801 16:01, 21 May 2009 (UTC)
God help me, if you can put it in a Nano. ;) Anyway, Toorkild is an awesome bot and my everlasting measure of my bots. :) --HUNRobar 18:20, 21 May 2009 (UTC)
I remember reading through Moebius once upon a time and not knowing WHAT was going on... I'm fairly sure my bots are easier to read than yours =). And I certainly didn't get the space compression right the first time, it took a bit of tinkering to get all the casts and brackets all in the right place =). If you can find a way to improve anything without going over the codesize limit I'd be glad for a few pointers ;-) and I'll give you credit. However I'd appreciate it if you didn't lift my gun (as seems to have been happening in the nanos, looking at 6 of the top 8 bots all using the same gun). Feel free to read the code, and understand it, and if you write a gun based on what you've learned that's fine. But I put a lot of work, testing, trial and error, and research of the Java API into writing it, so I feel a bit protective :-p I think Microbots have enough room in them for multiple implementations of the same idea to fit, and I've tinkered in nanos enough to know that the same doesn't hold in there. I actually build a pattern-matcher nano, only to discover later that I'd re-invented Simonton's gun, but using StringBuilders instead of Strings. As it happens, Simonton's implementation was 2 bytes smaller. I'd like to think that I got my gun algorithm in Toorkild about as good as it can be, but there's bound to be better ways out there. I'd like nothing better than for someone to come up with a brand new gun and movement combo that beats mine =) it'll give me something to work on (and distract me from studying for the upcoming mid-year exams ;-) ) --Skilgannon 19:11, 21 May 2009 (UTC)
For fun, I put your bot up against spin bot and walls - 2 very matchable bots. Wow it's fun seeing just how accurate your gun really is. I now have a mark to shoot for. --Miked0801 18:42, 27 May 2009 (UTC)
Robar, thank you very much for the compliment :-). If Miked0801 manages to fit it the gun in a nano I'll be seriously impressed, it was hard enough fitting it in a Micro =). However, while this discussion is mostly about the gun, I think the high score has just as much to do with the movement. After all, it's the same movement Decado, then Waylander, then Connavar, and now Toorkild uses. It got Decado to 3rd, Waylander to 1st, Connavar to 2nd (behind Waylander) and now has Toorkild reigning by over 2%. The way to do well in Robocode is finding a good idea and then squeezing every last drop of life out of it =) --Skilgannon 20:01, 21 May 2009 (UTC)
- What a great quote. =) I want to see that in big bold text somewhere on this wiki! --Voidious 20:09, 21 May 2009 (UTC)
- Haha thanks. It doesn't feel right sticking my own quote somewhere "in big bold text", but if somebody else finds a good place... I'm not gonna stop you =) --Skilgannon 20:41, 21 May 2009 (UTC)
- There's no way that your gun will even come close to fitting in nanoland. Arrays and statics are too expensive. Hell, there's no room to track anything but lateral velocity (no radial velocity offsetting of range nor patterning) which puts plenty of error into the thing as is. And then sort by best match depth value across multiple buckets? Lol. The nano gun I'm using already takes the lion's share of available space and that's with massive range assumptions and no rounding. The only advantage my gun might have is that I can preload values into the string for free allowing me to cheat 30 rounds of aim data in the bot if I really wanted to - but I feel that that is indeed cheating. I could probably fit radial velocity checks into the PM, but then my movement code would basically be setAhead(1.0/0) setTurnRight(1.0/0); die();
- But seriously, I read your comments and I'm not about to put out a clone with a few lines changed and massive credit given to you. In nanos, that's how it's been done for a while, but in micros, you're right - there's still a lot of room for interpretation and implementation (and innovation.) I'm not personally all that convinced that your gun is doing things it needs to do, but that's a gut instinct as I haven't had a chance to really run it through its paces yet. When I get a few hours a breathing space at work (shhh), I'll give my own version a go and see if I'm right. As a starting point, you are only using roughly 9.1 bits of each char's 16 bits at the moment. A little fixed point math could make your gun much more accurate, but would make matching more difficult - hence my need to experiment a bit. A few other ideas as I see them. --Miked0801 21:04, 21 May 2009 (UTC)
- Yeah, changing the granularity of the symbols is always a tough call, especially when working with lateral/advancing velocity when neither of them follow a fixed increment. I ended up just leaving them to max out at their usual +-8, but I always wonder if it wouldn't be better to make it, say, 16 or so. The rebuild would also be slightly more accurate. Anyways, give it a look over, and don't get caught =) --Skilgannon 18:36, 22 May 2009 (UTC)
Hey, I hate to be the bearer of bad news, but the rating for Toorkild 0.1.3 may be somewhat tainted. It's currently beating both YersiniaPestis and Pris, for instance: , . Not sure how much it's affecting the rumble ratings... In a similar boat with latest Diamond, which I think is a legitimate improvement, but is inflated by some bad battles. --Voidious 12:51, 9 October 2009 (UTC)
|Thread title||Replies||Last modified|
|404 error on http://dl.dropbox.com/u/4066735/jk.micro.Toorkild_0.3.7.jar||1||13:28, 10 January 2013|
|0.3.0||13||22:37, 19 December 2012|
Skilgannon, there are 404 error on http://dl.dropbox.com/u/4066735/jk.micro.Toorkild_0.3.7.jar
Sounds like you made some nice improvements in the new version of Toorkild. Looks like I might not get the micro APS throne after all. Oh well, I'll see if I can get a 100% win rate. :)
Sometimes things which sound logical don't always pan out ;-) And the sacrifices made for codesize reduction aren't always worth it... codesize limited development is something I haven't done in a few years now, so it might take me some time to get back in the swing.
As soon as Toorkild reclaims his rightful title, I'd like to see you get back into nanos. You've always been good at thinking outside the box, and the nanorumble sorely needs that right now.
I found that in nanos I didn't have enough space to do anything original. See my conversation at the top of this page with Mike (author of LittleBlackBook and Moebius). Anything less than micro, and sometimes even micro, seems like it isn't something which was specifically designed to perform a specific purpose but rather an amalgamation of code snippets which just so happen to perform the stuff we're generally looking for. There isn't room in nanoland to actually use any of the ideas that I have about how to improve something. But I'm willing to give it another try =)
I know how you feel. I worked for weeks trying to come up with something original for Foilist, but almost all good movements had already been taken. I think that the current nanobot paradigm is nearing its end. If you really want to do something revolutionary, I would suggest trying to code a bot with Jasmin.
I look forward to your next game-changer, good luck.
Great job with 0.3.6!
I guess 1st place is now far out of ÉpéeistMicro's reach. :(
I am honored to be in a race to the top with the best robocoder there has ever been.
I don't think ÉpéeistMicro is completely out of the race. If you remove your colours you will have enough space to maybe add better bullet power management or something, there is always something that can be improved.
You might as well use your own gun from ÉpéeistMicro for your new mini. Chances are it is stronger, considering it is stronger than RaikoMicro which is what Komarious's gun based off of.
Best ever? I'm good at producing a top scoring bot, I'm not arguing that, but I'm better at optimising code so it runs quickly/small and then just using a feature 10x more than anybody else ever has before. Examples are the 100+ buffers in DrussGT, surf-absolutely-everybody in Neuromancer, multiple-choice pattern matching in Toorkild. We'd already had multiple buffers, melee surfing, micro pattern matching, non-micro multiple-choice pattern matching, so nothing I did was really new, I just squeezed every last drop of performance out that it had to give. I guess my real claim to fame is variable-distance Stop-And-Go, the rest is my interpretation of the wealth of knowledge already available on the wiki =) I guess the moral of the story is to think big!
OK, let me rephrase that, you are the most competitive robocoder ever. Paul Evans had a long reign of tyranny in the general class, as did ABC after him, but you are holding four thrones as I am typing this! And you don't give yourself enough credit for Neuromancer. There had never been a successful melee surfer until it came along.
ÉpéeistMicro's gun is not better than Komarious's in any way whatsoever(other than code size, of course), just look at her results in the targeting challenges. Voidious made some huge improvements over RaikoMicro's gun, and I think that her gun is the best in the minirumble.
While I agree that there is something I could improve in ÉpéeistMicro, I don't think that Energy Management really makes that much of a difference. Check out the discussion on PEZ's page, basically, if you fire high-power bullets, you will gain bullet damage but lose survival, and vice versa for low-power bullets.
Also thought you might find this interesting: oldwiki:MostCompetitiveRobocoderEver =) ... Using a slightly different meaning of the word "competitive", as in drive to compete as opposed to high level of performance.
About bullet power selection, several of the top 1v1 unlimited bots have been experimenting with cutting back on bulletpower severely as their energy drops (DrussGT, Diamond, Tomcat, RougeDC). The idea is that against weaker enemies your energy will stay high so you will get just as much bullet damage, but your survival will increase against those strong enough to cause your energy to drop. This exploits the tradeoff so you increase your score on both fronts.
I'm not sure if it is still as applicable when we aren't nearly as good at dodging (RaikoMicro gives ~700 bullet damage against DrussGT, Toorkild 1300), but there has to be something there. Possibly even shooting a higher power bullet if the peak in the buffer is high enough compared to the average. Or, as I've been thinking about a lot lately, doing some sort of smashing it down to bins.
I meant it wasn't important for micros/nanos. In the early versions of ÉpéeistMicro, I had the 10 byte
if (getEnergy() > 2), but I later removed it because it made almost no impact on its scores. Also, firing a constant bullet power 92% of the time saves about 20-30 bytes because it allows you hard-code bullet velocity and bullet damage.
I can definitely see the advantages of conserving energy in megas. Plus, doesn't firing low power bullets increase the chance of creating a full bullet shadow?
I don't want to get into a sunshine-blowing contest =), but I certainly don't think of you as the one-trick pony you paint yourself as here. There's a ton of insight and intelligence that goes into deciding which of the zillion existing Robocode bot features have potential to be exploited 10x further. And to get to the top, you not only have to invent/exploit new stuff, you also have to do everything else as well as everyone else. Especially if your bot is open source.
I do personally think of Skilgannon as probably the "best" Robocoder ever, but it's an impossible comparison to Paul Evans or ABC or other ancient Robocoders, like Michael Jordan vs Wilt Chamberlain. The latter get credit for being pioneers, and rightly so, but can you penalize the former for simply coming onto the scene at a later date? And if you can, how dominant do they have to be to offset that penalty? King of General 1v1 for 4.5 years, or holding all 1v1 thrones concurrently, (or 6 rings in 8 years in the modern NBA,) are pretty strong points on a resume.
But in general, I don't usually try to rank the legendary Robocoders. There are a bunch of folks that have made huge and unique contributions to Robocode and the RoboWiki and they're all awesome in their own ways. =)
Thanks for the vote of confidence guys =) It really is difficult to compare prowess when something is based on acquired (and then freely shared) knowledge. As Robocoders today, we are all capable of putting together a bot that can beat SandboxDT or RaikoMX in a couple afternoons, just by copying and pasting surfing and DC targeting tutorials. The landscape is completely different, and in our current environment I know I excel, but I'm not sure I would do as well against the great minds of the time in the unexplored wild-west days of the Eternal Rumble. Then again, those people may not do as well today, now that we have the art of movement, targeting, even bullet power selection down to a fine art. It really is too tough to call. Perhaps we can tempt Paul Evans back for a showdown =)
Maybe I can get him into BerryBots. =) The phrase "be careful what you wish for" comes to mind. I recently realized how much I take our body of Robocode knowledge for granted when I sat down to write a semi-serious BerryBots bot, and similarly at a live programming game event I attended.