Thread history

From Talk:ScalarBot/Version History
Viewing a history listing
Jump to navigation Jump to search
Time User Activity Comment
06:27, 17 October 2017 Xor (talk | contribs) New reply created (Reply to WaveSurfing rethink)
04:43, 17 October 2017 Beaming (talk | contribs) New reply created (Reply to WaveSurfing rethink)
02:44, 17 October 2017 Xor (talk | contribs) New reply created (Reply to WaveSurfing rethink)
02:19, 17 October 2017 GrubbmGait (talk | contribs) New reply created (Reply to WaveSurfing rethink)
20:55, 16 October 2017 Beaming (talk | contribs) New reply created (Reply to WaveSurfing rethink)
20:14, 16 October 2017 GrubbmGait (talk | contribs) New reply created (Reply to WaveSurfing rethink)
18:52, 16 October 2017 Beaming (talk | contribs) New reply created (Reply to WaveSurfing rethink)
18:44, 16 October 2017 Beaming (talk | contribs) New reply created (Reply to WaveSurfing rethink)
04:47, 16 October 2017 Xor (talk | contribs) New reply created (Reply to WaveSurfing rethink)
04:39, 16 October 2017 Xor (talk | contribs) Comment text edited  
04:38, 16 October 2017 Xor (talk | contribs) New reply created (Reply to WaveSurfing rethink)
04:26, 16 October 2017 Xor (talk | contribs) New reply created (Reply to WaveSurfing rethink)
04:19, 16 October 2017 Xor (talk | contribs) Comment text edited  
04:04, 16 October 2017 Xor (talk | contribs) New reply created (Reply to WaveSurfing rethink)
04:02, 16 October 2017 Xor (talk | contribs) New reply created (Reply to WaveSurfing rethink)
23:10, 15 October 2017 GrubbmGait (talk | contribs) New reply created (Reply to WaveSurfing rethink)
22:35, 15 October 2017 Cb (talk | contribs) New reply created (Reply to WaveSurfing rethink)
22:09, 15 October 2017 Rsalesc (talk | contribs) New reply created (Reply to WaveSurfing rethink)
22:02, 15 October 2017 Rsalesc (talk | contribs) New reply created (Reply to WaveSurfing rethink)
19:39, 15 October 2017 Dsekercioglu (talk | contribs) New reply created (Reply to WaveSurfing rethink)
19:10, 15 October 2017 Skilgannon (talk | contribs) New reply created (Reply to WaveSurfing rethink)
17:34, 15 October 2017 Xor (talk | contribs) Comment text edited  
17:34, 15 October 2017 Xor (talk | contribs) Comment text edited  
15:11, 15 October 2017 Xor (talk | contribs) Comment text edited  
15:08, 15 October 2017 Xor (talk | contribs) New thread created  

WaveSurfing rethink

Even though I have a bot that used to rank relatively high in the 1v1 division, I couldn’t think of myself fully understanding what I was doing and why it works. I was always assuming some GF targeting which fires at the most frequently visited gf, with the most popular attributes in mind. (e.g. segmenting on lateral velocity, accel, wall distance, etc. ).

And even though I tried to consider more types of enemy targeting strategies later, I was still assuming some specific targeting strategy.

But today, after thinking about all that in dreams, an idea just came up.

Can we just don’t assume anything about enemy strategy? Be tough yourself, and they’ll automagically have some trouble hitting you.

But that’s not enough for a top movement. Besides not showing weakness in all senses, it’ll be pity if you lose the chance to be better dodging them.

Statistics will always tell you the truth — once you are sure that they always fire head-on in some situations, why don’t you try your best to make them see the same situation again when aiming? Yes, I’m talking about automagical stop&go, but in my observation far more guns have similar weakness.

Besides firing situations, when you are sure about that they are very likely to fire bullets they’ve fired before, downgrading to traditional wave surfing seems good. And for else, why risk dodging somewhere they aren’t firing at? If their targeting looks quite random (at given firing situation), sitting still or moving randomly are also good choices. And you won’t risk hitting the wall or get yourself stuck somewhere as well if you don’t move at all.

For every bit of the future you can predict, you can always know what you can do better. A lot of bots are too strict, imo, following the design (and the assumptions behind) strictly. But I think we can do better, give more freedom to the bot itself (who always knows the situation better), rather than planning everything in advance. Given the success in GF targeting and then kNN, I’m pretty sure there are still a lot to explore even in today, and there are still a lot for bots to improve.

Xor (talk)15:08, 15 October 2017

I tried something like this in DrussGt 2.6.0, and debugged it until about 2.8.0 when I finally gave up on it. I've had some ideas since then that might help, but at least in a wavesurfing-style framework I was never able to get it to work. Maybe it requires looking further ahead than I did (I only did one wave), or maybe more penalty for entering unexplored parameter space, but I never managed to get any benefit from it.

Give it a try though, if you prove me wrong and find some value behind it I might just have to dust off DrussGT ;-)

Skilgannon (talk)19:10, 15 October 2017

The really important part imo is to decide when to use this strategy. For LT/CT guns this will definitely help, but for guns with distanceLast10, timeSinceXXX, etc. doing so is rather hard — but when the time before impact with wave allowed us to do so, instead of decel randomly like DrussGT, I think this system could give us a better choice ;)

Xor (talk)04:02, 16 October 2017
 

It really helps actually. I once made a bot that always stopped before enemy fired so the enemy always saw the same situation. The problem was that it decreased my MEA a lot but it would be really good if you tried. I have the same thoughts but toooo lazy to do it.

Dsekercioglu (talk)19:39, 15 October 2017

Yes, for guns without fancy attributes this should be more beneficial than MEA, as large part of MEA is always not reachable for most of the waves — and for those you can predict, they are not firing randomly, so decreasing MEA won’t make things much worse as well.

Xor (talk)04:04, 16 October 2017
 

I don't know if I fully undestood your thoughts, but specifically about the auto stop &go thing: I thought of something like that sometime before and it seemed like an amazing think. Most of the guns today are really predictable, and those which are less predictable are just being differently obvious at each situation. The data we have gives us statistical clues of situations the enemies are more obvious. What if besides moving into safer regions we take into account our gun heat tracking and put our enemy into a obvious situation when it is firing. Of course this takes a lot of prediction capabilities because we dont know where the enemy will be next, and different implementations of this idea can lead to very different results. So I think that even if it was already tried before, it is worth another shot.

I've come up with that exactly when I thought about stop&go and why it is good. Its not only about giving no clue of where are you moving to, but mainly about being over and over at a situation where most of the enemies will be kinda obvious. But we do that because we know it. Let's just let our stats decide which situation is that for us :)

Rsalesc (talk)22:02, 15 October 2017

Yes you can never predict firing situations if their movement is not fully predictable — but you don’t really need to get into the exact situation as well. for gf targeting, being near is already not distinguishable most of the time, and for lat vel = 0, lat accel = 0, or time since decel or things like that, you don’t need to predict their movemenr exactly to get to the exact situation.

Xor (talk)04:26, 16 October 2017
 

The only thing I see here is that, well, getting to a safe place is fairly easy given robocodo physics. But being at a safe place when the wave breaks AND at a obvious situation at the same time with too litle reaction time is harder, besides requiring a more complex type of GoTo movement to cover enough possibilities... so yeah, it's perfect theoretically but really hard to work in practice, but Ill definitely try that in the future

Rsalesc (talk)22:09, 15 October 2017
 

I agree that there are many more possibilities in wave surfing and GF targeting that people didn't think of yet. This is what makes Robocode still so interesting, even though, when I look at top bots, I often marvel at how amazingly good they are :)

If a bot is already very strong and we want to make it better, it mostly boils down to reverse engineering. How well can we understand the enemy bot and therefore exploit his learning behavior?

Cb (talk)22:35, 15 October 2017

Yes, a lot of work resembles reverse engineering — but even we know their code, we can still have some trouble knowing their behavior (have a look at the open sourced top bots ;) )

So instead of come up with an idea about a specific opponent, why don’t we build a system that does “reverse engineering” automagically? Since what a bot can do is limited, a lot of the knowledge about the opponent is wasted — but what if we reverse the direction, starting from what our bot can do, and see whether the opponent has some weakness respectively?

Xor (talk)04:38, 16 October 2017

Even if you reverse engineer a bot, there is always randomness. HawkOnFire is well understood bot, but even top bots get only around 30% hit probability. Even Walls is not that predictable unless you really fine tune for its specific algorithm.

Once we have randomness, the best you can do is to collect statistic. Which is rather unfortunate.

Beaming (talk)18:44, 16 October 2017
 
 

Long time ago I have thought about polluting the stats of the opponent, but at that time I couldn't think any further than using the BulletHitBullet for such thing. Specifically going to the place where you would have been hit seemed cool. That idea was soon overtaken by BulletShielding and a bit later by BulletShadows. I think that the major part of new development will be in the movement. Targeting has so much more info than movement, that I don't see any groundbreaking things there. Maybe not automatically shooting when your gun is cool but to wait for a better moment, using tricks to 'hide' shots into other events, but maybe something is waiting around the corner.

For movement a lot more ground is open and I do have some ideas there, especially screwing up the stats of the opponent, but frankly I have no clue how I could implement them. Do note that a lot of better bots are very similar in their handling of gundata, maybe not in implementation, but surely for how they interpret data and act on it. For now I'll concentrate on a flattener, necessary for the GigaRumble, and a second attempt on BulletShadows. The first attempt already failed before I starting shadowing . . .

GrubbmGait (talk)23:10, 15 October 2017

Yes, although I don’t know exactly why BulletShadow works, some guess may be that we are polluting their data ;) For slow learning guns, doing so makes them even more predictable — and for fast decaying guns, they just decays the relevant data for shadowed locations;)

Xor (talk)04:47, 16 October 2017

Amazing part about polluting that it makes the top bot vulnerable. If you look at MoxieBot it performs better against the top bots (relative to its APS neighbors). Unfortunately, MoxieBot has a bug which does not let it shine in the current rumble.

I recall I once made a mistake of counting virtual bullets as successful hits without looking at bullet hit bullet events. Bullet shielders just exterminated my bot. Since I was shooting at the most probable GF but it was protected by the shield.

Beaming (talk)18:52, 16 October 2017

I am always shooting at the most probable GF, I just know how to bend the trajectory just enough to hit what I want (saw it in a movie with A. Jolie)

GrubbmGait (talk)20:14, 16 October 2017
)

But is your most probable GF precise enough? I.e. if the bin width is high you might miss the shield. Do I take your joke too seriously? :)

Beaming (talk)20:55, 16 October 2017
 

I don't think it's the fault of top bots, rather, it's just because it's neighbours are exploited by the top bots.

Xor (talk)06:27, 17 October 2017