View source for Talk:Scalar/Version History

From Robowiki
Jump to navigation Jump to search

Contents

Thread titleRepliesLast modified
Random PIF?117:09, 6 November 2017
Taking your own movement into account when targeting? 1202:04, 3 November 2017
Speed opt.203:20, 2 November 2017

Random PIF?

There is no 1v1 stuff in this release, right? Honestly, I'm kinda impressed by the score you get against some strong bots on melee with a so low survival. This random-pick PIF gun is doing its job :P

Rsalesc (talk)16:51, 6 November 2017

Well I think the low survival is because it’s running constantly (and get hit constantly =) when only two bots left ;p And the high score is because I’m scoring a lot before that, since most of the opponenets are weak.

Anyway, Idk how survival is calculated in melee, so that guess may be completely wrong.

Btw, the random PIF gun is not really random, since it’s doing kde after randomly selecting 50 scans, and that 50 scans is just some rough approximation to the density of the entire data set. So that should be dodged easily.

Xor (talk)17:09, 6 November 2017
 

Taking your own movement into account when targeting?

While in melee PIF is more popular, in 1v1 most people (I guess) is using something similar to GuessFactor, where lateral movement is assumed. And whether you are scaling based on theoretical MEA or orbital MEA or precise MEA, we always assume that enemy movement is only relevant to our initial position and scales as if it moves in a circle — which is not true for real battles.

Sometimes an opponent that always moves perpendicular to you moves in straight lines, not circles, when you keep moving perpendicular to him as well. And for anything that controls attack angle, they won't move in perfect circle either. We've been already adding lat, adv, distance etc. to help our gun distinguish these situations, but what is currently lacking mostly, is about our own movement (although I see DrussGT is adding mirror offset). The lack of attributes about our own movement cannot be compensated by more data, and it can neither be made up by using more prediction power, e.g. PIF.

If we can eliminate the effect of wall (e.g. the use of precise MEA) & our own movement to enemy movement, the accuracy of our guns could ascend to an even higher level, where only the weakness (the flaw of being flat) of enemy is learned. I see this as the holy grail of guns, where each choice affects greatly how good your learning algorithm could perform and with this holy grail, any learning algorithm should reach its theoretical limit.

Xor (talk)07:18, 2 November 2017

What I came up with is, instead of scaling bearing offset arithmetically on GuessFactors and some form of MEA, we run some simulation taking walls and our own movement into account, then treat GuessFactor as the ratio of time of the simulation it will reach, e.g. 1.0 as running constantly, and 0.5 as it stops after half of the simulation time. Then 0.0 would be it hits the brakes immediately.

With this approach, GuessFactors could be treated closer as "run time after bullet fire", rather than just some "guess". We've been already using precise MEAs to better simulate this behavior, but imo we could go even further.

Xor (talk)07:28, 2 November 2017
 

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:Scalar/Version History/Taking your own movement into account when targeting?/reply (2).

 

In those situations of predicting my own movement I always wonder about two cases:

1. true surfing, not sure about my own movement 2. new data coming, decisions changing, but the bullet will be already fired, I cannot regret (this should not be that impactful, though)

I like this approach, the PIF thing would be like the simulation of lateral velocity 1v1 string matchers use, but on top of a more complex curve instead of a circle.

Rsalesc (talk)13:34, 2 November 2017

1. You are partly sure about your own true surfing movement, as you already know most of the information that determines the intersection point.

2. New information definitely can't affect past decisions, but you can always do your best with existing information.


At least before our bullet hit, our movement is mostly determined by the bullets already in air, which is a good news.

Xor (talk)15:44, 2 November 2017

If the optimal point is somewhere between my current point and moving full speed clockwise, for example, I really don't know the intersection point if I allow hitting the brakes. I know the direction, though, which is sufficiently relevant to do some reasonable approximation, which is OK for this use case IMO.

Rsalesc (talk)15:49, 2 November 2017

You can always play your own movement forward right? Although that's too expensive. Anyway, some fast approximation is ok, e.g. Your movement is moving mostly in that direction, and it should be safe to always use that direction instead as approximation, as what you said, you know the overall direction ;)

Xor (talk)16:11, 2 November 2017

Yeah, sure, even though, if I'd decide to use anything related to my own movement I would probably try a GoTo style movement first.

Rsalesc (talk)16:36, 2 November 2017
 
 
 
 

It doesn't assume orbital movement nor enemy circling you. The only thing Guess Factor Guns assume is generally symmetric movement. By the way, PIF with Lateral and Advancing Velocity works very well.

Dsekercioglu (talk)15:00, 2 November 2017

No, it assumes that, as the way it scales between different distance & bullet power. Anyway, that can be overcomed with relevant attribute & more data.

Yes PIF with lateral & advancing velocity should work very well for similar reason.

Xor (talk)15:41, 2 November 2017
 

The question is: how big is the subset of bots which it can be used against?

In 1on1 we have

  • Simple bots moves in what ever pattern they have independent of you and your position.
  • Wave surfers do not care about your position when you far away.
  • HawkOnFire type make the decision once per many clicks and does it based on one point.

So it might work against

  • Mirroring bots
  • Rammers
  • Very sophisticated bots on top of the rumble.

The first two categories usually have relatively small APS already, so there is not much to shave off, the later (i.e. top bots) has to tiny fraction of the population.

Also, surfers which use averaged in time enemy velocity, are sort of already calculated where you are going to be. Since they see where you were and where you are heading.

The problem with melee is that most of bots are moving with respect to their nearest neighbors and not your bot.

I am not sure that a bot can afford to recalculate its path in melee every click, so it is likely that the movement decision is taken on a current to fire time situation and than it is not updated for a while.

Beaming (talk)17:57, 2 November 2017

Well, that true — there’s already not too much room to improve without specializing. But remember how we can do with precise MEA? This is already sacrifing our performance against anything don’t use wall smoothing. But with that, the overall performance increases, because those using wall smoothing is generally the main problem of targeting.

And those moving relate to me is also the main problem of targeting.

Xor (talk)02:02, 3 November 2017
 
 

Speed opt.

Hey, since you are probably diving deep into optimizing a robot, if during the process you happen to benchmark the tweaks you are doing, can you post your results here? I find it beautiful those bots which are strong and fast like Shadow and Ascendant, and although I really feel like doing this someday, I happen to postpone it because Im not sure it is worth it in terms of sacrificing code legibility and effort for a very little speed increase.

Rsalesc (talk)20:29, 1 November 2017

Well, benchmarks are a good thing, since you’ll know the effectiveness of each step, and make sure your optimization is actually optimization, rather than something that does good theoretically but slows the entire program down for some reason. Maybe I’ll do a benchmark comparing Scalar with ScalarBot, after the migration is done. Since the code of Scalar is written to be optimized (and optimization is part of the initial design), it’ll be a lot of work for me to compare it with the most natural way to human of doing things ;)

Anyway, since the optimization is already part of the initial design, I don’t think it sacrificed the legibility in any sense — actually with some interface carefully designed, you’ll feel that even easier to use/read than some traditional way of Java.

E.g. the pre-allocation of objects is mostly done by the custom container, I just use it normally as it were ArrayList. I may post some util here later for everyone to have a try and see the difference to speed ;)

Xor (talk)03:02, 2 November 2017

Yeah, sacrificing code legibility was my excuse before seeing that pooling seems to be a nice workaround. Now my excuse is simply the effort it takes :P

Rsalesc (talk)03:20, 2 November 2017