View source for User talk:Skilgannon

Hi Skilgannon, you said on my talk page that your melee wavesurfing is almost complete. Can you give me your prototype? I hate to suffer all those waves up :) I've idea to surf it in both my talk page and Rednaxela's talk page. You can find my email at my use page. It seem that both you and Rednaxela are working on melee wavesurfing. Thanks! » Nat | Talk » 13:51, 19 February 2009 (UTC)

I actually want to get it working before I release it. And it's definitely still very far from completion. It can barely keep track of waves, never mind precise prediction for figuring out where to move, or stats for figuring out where is dangerous, etc. This is much more difficult in melee because there is no GF-0, because there are many bots that could be the target. Also, being the only bot of it's kind in the wild, I'm going to keep it closed source until other implementations are around. This is so that people figure out their own ways of doing things. I believe the reason the majority of 1v1 surfing bots TrueSurf is because RaikoMX was released as open source. I'll provide ideas etc, but until a significantly different system of melee surfing appears I'm not going to release the code, simply because it will stifle growth. --Skilgannon 19:48, 19 February 2009 (UTC)

Here here! What I find interesting is that we're approaching melee surfing from the opposite directions. I'm starting with a new method system for deciding how/where to move, whereas you're starting with melee wave tracking. It will be interesting to see how our two melee surfing beasts will eventually fare against eachother in combat! I don't plan to release the code until about the same time for the same reason. Also, two bots kicking Shadow off of it's melee throne might result in interesting counters from ABC... --Rednaxela 20:10, 19 February 2009 (UTC)

Ah... I want it because I had problem to create a new thing from scatch! I must have some (or only a little) scaffold to work around. I've ton of ideas about this and want to implemenmts it, but I can't due my currently problem of myself! Please, give me your implementation (the Skilgannon's one). I've no problem reading other people code, no matter how ugly they are. (I almost understand Shadow from its decompiled class now) But if you not want to share it, I must get rid of my problem right away :) Maybe I'll start work on Komarious's instead. I've ideas on both wave tracking and moving now (on my talk page and Rednaxela's talk page). Let see who'll be the first to release it! Maybe 3 bots kicking Shadow throne. If we successfully kick Shadow might result in Deja Vu like in 2003 when SandboxDT successful beaten by Shadow. I'll have school holiday in 2 weeks, I'll spent a month on this melee surfing (plus BlackHole rewrite) » Nat | Talk »

Member of all clubs/parties of Robocode Community

Congratulations! As fas as I know, you have been in all clubs/parties that exist in the Robocode community. That includes:

• The 2000 Club
• The 2000 Club/Mini
• The 2000 Club/Micro
• The 2100 Club
• The 2100 Club/Mini
• Top Ten DC Party
• The Kings Club (even that isn't updated for you yet)

Have I missed any clubs/parties? » Nat | Talk » 14:09, 1 May 2009 (UTC)

Well, my adventures into nanobots haven't been particularly successful. I find I don't have enough room to try anything new, and end up retrying old and tested formulas, in fact last time I tried I ended up with something pretty much exactly the same as WeekendObsession. And I haven't released a Melee Bot yet. I've got big hopes for my Melee Surfing, but it's gotten so complicated just keeping track of enemy waves that I'm not sure it will run fast enough to really be viable. But I think you covered all the clubs I've been in, yes =) --Skilgannon 14:21, 1 May 2009 (UTC)

But there're no melee clubs out there! I've recently work with melee surfing but I don't think it is really effective since you can't detect everything that go over the battle. The better solution I've found is to make it a plug-in for Minimum Risk Movement (as I'm creating in TheRiver) » Nat | Talk » 14:31, 1 May 2009 (UTC)

On the topic, you're the first person since Jamougha (in March 2004) to simultaneously hold the top spots in MegaBot, MiniBot, and MicroBot 1v1. Congrats dude! =) --Voidious 19:06, 1 May 2009 (UTC)

Thanks =D Now, I should probably take time to go do some varsity work... affine approximations and Green's/Stoke's Theorems... bleh. I think there's a good chance I'll be working on CunobelinDC some more in the near future... ;-) --Skilgannon 15:08, 2 May 2009 (UTC)

For some reason, your Toorkild revert isn't appearing in the rumble. --Miked0801 17:52, 30 January 2010 (UTC)

jk.micro.Toorkild 0.2.4 (the reverted to version) is showing fine here. Except.... for some reason only it's mega-battles from before the revert survived... Something is slightly odd on the rumble server --Rednaxela 18:09, 30 January 2010 (UTC)

By the way, a belated congrats on getting to two years as RoboRumble King! Good luck making it to three. =) --Voidious 03:15, 12 April 2010 (UTC)

with the challenge from Voidious =) --Nat Pavasant 05:43, 12 April 2010 (UTC)

Thanks. I'll do my best =) I really believe Boosting has huge promises for improving my surfing, I'm just struggling to figure out how to create an online algorithm that will run within the time constraints of Robocode.--Skilgannon 05:51, 12 April 2010 (UTC)

Congrats also! Hmmm... depending on things, I may just have a lot of time to devote to putting in some more competition in the coming year... Oh, about boosting, I haven't tried such with movement, but one could call my various 'adaptively-mixed-targeting' attempts a type of boosting and I have had some success with it. What I'm not so sure about though, is whether there is enough data to do it accurately enough to be worthwhile in surfing. Really, surfing systems have so much less data to learn from and it's hard to judge the goodness of algorithms from each other without much data. I think the lack of data would be trickier than time constraints (after all, I have made forms that are efficient as far as time constraints go. --Rednaxela 05:59, 12 April 2010 (UTC)

The trouble is, you were weighting 3 (?) different guns, whereas I have 100 buffers to weight. Added to this, I'd rather weight them as each VCS set of bins, rather than weighting the entire buffer at once. So, not only do I have 30x the number of things to weight, but they also come on and offline pretty much unpredictably. They don't all have the same amount of logged hit locations, so my weighting has to be datasize-independant. I've made an algorithm that I'm using to weight the data depending on how 'clustered' it is. I'm thinking of reversing that weighting now, to magnify differences in the non-clustered data rather than try to suppress data that isn't nicely clustered. When I get a moment of free time... --Skilgannon 06:46, 12 April 2010 (UTC)

Well, I do have it datasize independent, because it mixes results using only firing waves, and not using firing waves. In the case of Midboss, it's weighting the result of 4 or 5 differently configured anti-aliased/interpolated VCS configurations. Really, I feel the quality of output for each anti-aliased/interpolated VCS table is good enough that simply throwing more of the same in wouldn't help. The story is rather different with conventional VCS configurations of course. But anyway, yeah, the number of things to weight is quite different. Basing it on how nicely things are clustered sounds interesting. To compare to the "compare where they go to what was expected" model my method is using, it sounds like it could probably make more out of less data, however sounds significantly more intensive to process the data. It would also act differently against adaptive opponents. Simply reflecting on the data spread would work well when their profile stays the same, however I think could get tricked very easily when when they change modes or adapt. That said, perhaps it would make sense to make groups of your 100 configurations that work against different things, use "reflective" weighting within those groups, and then use "functional" weighting to weight those groups overall? --Rednaxela 14:27, 12 April 2010 (UTC)

Hi, Thanks for opening the code. I am looking forward to digest it. One question, I noticed that many bot have booleans labeled TC and MC. Are these for target and movement challenges? If so where is the bots collection and who runs the challenge?

These flags are for competing in the challenges, not for being part of a challenge. So putting TC=true disables the movement, and MC=true disables the gun.

Although maybe I misunderstood you, the following are where it is used: movement challenges: Movement Challenge and Movement Challenge 2K6, targeting challenges: Targeting Challenge, Targeting Challenge 2K6 and Targeting Challenge 2K7.

You run the battles yourself using something like RoboResearch, which puts out the results in a wiki-friendly format.

Also Targeting Challenge RM, which I think is the most useful one.

And also RoboRunner / RoboJogger has some advantages over RoboResearch, the main one being a big speed increase because it doesn't restart the JVM after every match.

Yes, you understood me right. I've seen the pages about those challenges in the wiki, but since I jump the train to late, I missed the discussion of their purpose. Which, I am guessing, are to tune guns and movements separately. But on those pages, I've seen long tables with ranking, so I thought they were created by some sort of a statistics bot, like we have with rumble now.

Also, I am big fan of RoboRunner. I just need to find a proper subset of bots to correlate its results with the full rumble. I sometimes see an improvement vs. my local subset and a drop in a rumble.

Oh, right, I remember seeing that you used RoboRunner, which made me happy. :-)

The targeting challenges I consider pretty useful and a good predictor of rumble performance. The movement challenges, less so. My most useful Robocode testing was usually against large test beds constructed with BedMaker. I updated it in July to work with LiteRumble, if you want to give it a try.

I should try it, but the question is which bots to choose? Assuming incremental improvements, should I aim to gain vs top bots or similar score ones?

The reason I ask for your wisdom is the following. I recall once I gain a couple of points against top bots, but the score was worse for majority of the medium and lower bots. This happens when I added more advance guns to be dodged to an enemy bot. This helped against top bots, but weaker bots gained on me. I still puzzled by it.

So ideal test bed, should have a representative from each group.

Also, a side note. I noticed that Diamond sometimes get disabled right at the beginning of the game. Most likely some minor bug but if you fix it, you might get to the 1st place. I think this bug happens only in melee.

The one movement challenge which I found was a good indicator of rumble performance was the MC2K7, since there you have a gun (everybody has the same gun), and your opponent moves, so you have the same incentives to improve as in the actual rumble.

So I just noticed the "meleeTop30rumble" ... Are we specifically trying NOT to call it the "GigaMeleeRumble"? :-) I was just getting archived rankings working again (and @roborumble on Twitter) and paused at what to call it. Any objection to GigaMeleeRumble?

No objections here. Also, glad to see you pulled back into this world of battle.

I managed to get Nene up two more ranks recently (But haven't really been working on it much tbh).

Haha, thanks. :-) It's nice to get rrtweeter and rrarchiver up and running again, but don't expect a new version of Diamond any time soon. :-P

Why not? ;)

The only thing I'm still interested in is beating DrussGT head-to-head. But ever since I started development on BerryBots, it's just felt wrong to spend any of my recreational coding time on Robocode bots. I've got the new AngularJS web UI mostly done and I also have a cool new stage that I want to write. Plus I've got an entirely new, fully web-based game in mind which is just in brainstorm / research phase... So yeah, Robocode bots are a no-go. :-)

Well, I would argue the GigaRumble should be renamed to the Top30Rumble. I was the one who created the meleeTop30rumble. The name make sense to me. Top30 is self speaking, unlike GigaMeleeRumble which confusingly seems to be opposite of nano/micro/mini, i.e. refers to the size. I presume it has some historical roots, but I joined robocode too late to know the meaning of the Giga name.

May be someone with longer presence can enlighten us about the Giga name history.

Well, originally the name was Strongest Bots Rumble. Yeah, I used "giga" as a riff on (bigger than) "mega" when we finally implemented it, whatever 9 years later.

Hi Skilgannon,

I noticed you removed Morfeas because my clients do not run/process it. Do you have any idea why is happening? May be we need some sort of guideline for robocoders to use a particular java version so rumble clients can process it.

I remember that for a long time I was using the older opejdk version (v6) and it was not capable to run v7 bots. But currently I have the v7 installed everywhere, so I have no idea why a particular bot would be exclude from competition.

I suspect it is compiled with v8. I noticed that the pairings weren't filling, so clearly it has compatibility issues with something on your setup.

Hi, can you please add the flag of Latvia to the literumble? I have posted it here. Thanks.

Sorry I haven't had that much to contribute lately, but I've been doing real work instead ;-) Anyway, I thought you might like to take a peak at a small by-product of my work over the last year and a half - this is a map of one of the floors of the building next to (and above) my lab (caution! 4813x4168 image!)

This is all done with kD-Trees and a bunch of linear algebra on the software side, the hardware side uses a Hokuyo laser scanner and an Inertial Measurement Unit (integrated gyro, accelerometer and 3D compass) all mounted on the top of a radio control car. The map can be built in real-time and shows me a nice position of the car on it as it drives around, so I can easily tell what still needs mapping =)

I hope to be back with something to liven up the rumble soon!

That sounds cool! And pretty fun. =) So the car navigates itself, too? Do you do any pathfinding like with graphs or just trace your way along walls?

Btw, what kind of R/C car is it? Just curious. I was into R/C cars quite a bit when I was really young. (Like too young to build my own cars, just tagging along with Dad and older brother and racing.)

I have some simple wall following in, but right now the car is manually controlled. My project is more based on getting good maps out of it.

It's a pretty tough 4WD thing with knobbly tires. Overkill, but it means that some time in the future we can switch to 3D mapping and send it anywhere.

What brand / model is it? This conversation got me looking at the modern RC10's from Team Associated. :-) But maybe I'm just assuming it's a "real" / expensive R/C car since I remember you were into R/C helicopters too.

Yeah, it's the expensive, modular type. I would estimate it cost ~$300, but the lab owns it, not me. I'm not sure on the brand, I can check when I go in next year =) I actually mostly do quadcopters and planes as well as some DIY things, including all of the embedded programming and electronics for driving motors and speaking with gyros and accelerometers. Fun stuff, but it sucks time and money! I'm also looking at 3D printing, but that can wait until I graduate.

Ah, looks similar to the Team Associated stuff, but electric and 4WD. And we took the cover off and put on a custom platform which holds a bunch of very expensive electronics.

Yeah, I always raced electric, but gas has gotten much more popular since I stopped racing. But I think lots of folks (including Team Associated) still sell electric cars too.

That all sounds pretty neat. But it is indeed a huge money drain, which makes me hesitant to dip my toes in again. :-) So I recall 2 of the 3 main pieces of electronics in cars were "speed control" for controlling the motor and servo for the physical steering. You're saying you actually program those devices yourself, right? Is that just low level programming or designing/modifying circuits too?

A bit of both. It takes some embedded programming knowledge to interpret the signals coming from the radio receiver (I don't bother with trying to make those), figuring out what it is saying, then applying whatever actions you are looking for to the motors or possibly modifying the signal from the receiver and passing it on to servos. The actual 'speed control' is pretty easy electronics wise, particularly if you don't want reverse. If you want reverse and breaking it becomes a bit more complicated and uses about 4x the components, as well as the risk of destroying hardware if you have bugs in your code. You get chips that do it all for you, but then you might as well just buy a commercial solution since you lose a lot of the fine-grained control that the custom solution gives. Servos can also be done custom, but it's easier just to get a commercial one since servo control is a surprisingly complicated problem involving damping, oscillations and holding torque, all of which are dependant on the exact specs of the motor, geartrain and the voltage the servo is running off of. So, low level programming applied to a knowledge of fairly standard power electronics.

That's pretty interesting stuff, and not just in relation to Robocode.

As for Robocode applications, poisoning the enemy's guns with data also carries the risk of not dodging bullets, since the data gathering and the classification are so intertwined. But it's the type of technique you'd only use against high level opponents, like we do with flatteners, so it's already a situation where you're not able to dodge very accurately.

But I wonder... One thing it mentions is that this is possible if you have access to the same data as the enemy. In Robocode, of course we do, technically. But if that were really true, we'd be able to emulate the enemy's gun stats and do perfect curve flattening and never get hit. So I think it's probably closer to true that we don't have access to the same data as the enemy.

Actually it is possible to emulate opponent guns unless they use some pseudo-random technique. But we don't perfectly emulate because there are many different guns from many different opponents and few bots try to classify and specialize against the bot it is battling against (i.e. ScannedRobotEvent.getName()). Generalist bots are more fun.

Interesting fact is, this concept is already being used in RoboRumble for years.

PatternMatching (learning)... Anti-pattern matching (counter-learning)... GuessFactors (learning)... FlatMovement (counter-learning)... Dynamic Clustering... data decay...

In some sense, we are at the bleeding edge of AI advancement. There are very few AI competitions with imperfect information around the world other than Robocode. I can only think of one or two.

Basically what they explains is ways to use the minimum of 'false' information (in Robocode terms that means intentionally skewing your movement profile, but with increased chance of getting hit) in order to maximize the chance that they will incorrectly classify future data (ie, aim in the wrong place next time).

I agree anti-pattern matching and anti-GF have been effective at dodging their specific type of targeting, however this is a different concept entirely. This is about intentionally behaving in a certain way so that they will think you will do this next time, not behaving that way because you know exactly where they will shoot.

I would love to apply this somehow, because I think our learning guns are very susceptible to this. Sure, they all shoot differently at surfers meaning you can't take one gun and dodge another, but when you consider a movement profile with obvious peaks they all tend to shoot in the same way. Our wavesurfing flattens the profile, but all that does is bring us to the edge cases where every gun will shoot differently. If instead we have peaks that are obvious, all of the guns will shoot in the same way, making it possible to better predict their bullets and thus dodge them more reliably.

Hmm. I disagree with all guns shooting the same way at the obvious spikes, because I think there is really a lot of variety in gun configurations, especially once you start getting into Anti-Surfer guns. But most guns, even AS guns, are learning a lot from virtual waves. So the ideal situation is that you're creating really strong spikes in those virtual waves but still dodging the dangerous spots of real waves. That seems pretty difficult, but maybe possible.

On a semi-related note, I definitely think there's lots of room for improvement in surf stats with proactive stuff like this. I've put in a bunch of effort on "light" flatteners to flatten movement even against weaker learning guns, or switching to a different random movement profile each time I'm hit instead of actually dodging past bullet hits. So far I haven't had any success, but I still think there's something to those ideas. It bothers me that I have to get hit to change my movement profile.

I cited the wrong strategies then.

Wave Surfing is a movement strategy which keeps dodging waves the same way until it sees a bullet. The bullet usually means a spike in the opponent profile. Then it exploits the spike by changing the movement.

Screwing up virtual wave data seems a good idea. Put some virtual wave spike evaluation in the WS danger function? Minimize (avoid) real waves spikes and maximize virtual waves spikes... Some kind of anti-"anti-surfer gun" movement...

I think Skilgannon is right that this concept is different than current Robocode strategies, which are not proactive about painting an incorrect picture to the enemy. The only thing I can think of along these lines is oldwiki:AntiMirrorSystem, but even that is not really poisoning enemy data, just an exploit for a specific movement strategy.

Also, from what little I remember of SVMs, I think they may be much more susceptible to poisoning than KNN. They try to find the best plane to split the data space, so this method probably tries to plant points that alter the plane as much as possible. I think KNN would be much more resilient to this type of manipulation.

Hmm, interesting.

Regarding, "proactive about painting an incorrect picture to the enemy", two things come to mind that fit that category:

1. Chase bullets (but that's taking advantage of the 'bookkeeping' not the learning)
2. Robots which 'intentionally' look different to tick waves than bullet waves

A pure flattener also kind of fits this description in my mind, because it's all about going somewhere that it won't go in the future, it just looks at it from the opposite direction in time. It's just that it can't do a hugely accurate job of it due to the variety of configurations.

I think that one of the advantages of the usual "statistical" methods, is that they are more difficult to poison, because they don't "speculate" beyond what they've directly observed. In general I suspect that the same types of things that make a learning method robust to data from both multi-mode bots and random bots, also tend to make it more resistant to poisoning.

Maybe a flattener which instead of going where it was hit the least (most bots), goes where it was hit the most, but still below a certain threshold. Artificially create a spike in the opponent profile, then avoid it when it goes over the threshold. The data is poisoned until another higher spike appears, which might take a while without data decay. If the bot starts flattening the profile afterwards, it might take a looong time for another spike to form.

Can work in theory, but the threshold is different for each opponent. And data decay can quick get rid of poisoned data.