User talk:Skilgannon

From Robowiki
Jump to navigation Jump to search

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:

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)

Contents

Thread titleRepliesLast modified
Poisoning Enemy Learning Systems 901:48, 24 July 2012
First page
First page
Next page
Next page
Last page
Last page

Poisoning Enemy Learning Systems

Skilgannon17:21, 22 July 2012

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.

Voidious18:47, 22 July 2012

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.

MN18:59, 22 July 2012
 

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.

MN18:54, 22 July 2012
 

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.

Skilgannon22:52, 22 July 2012
 

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.

Voidious00:01, 23 July 2012
 

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

MN01:55, 23 July 2012
 

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.

Voidious03:51, 23 July 2012
 

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.

Rednaxela05:21, 23 July 2012
 

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.

MN01:48, 24 July 2012
 
First page
First page
Next page
Next page
Last page
Last page