Title. It would definitely make movements much more accurate if "any" or "all" was based on average angle instead of average position

## Movement for "any/all" to angle

### Re: Movement for "any/all" to angle

Sounds good.

How do you calculate this? (0° / 360°)

How do you calculate this? (0° / 360°)

My algorithm of life: if(self.tired) sleep(); else if(self.hungry) eat(); else follow(Jesus);

### Re: Movement for "any/all" to angle

How do you calculate the angle while the bot is moving? (I mean I know it can be computed, but how would you use it?) The average position of the enemies is stable even if "self" rotates, but if self moves and angles are computed, it changes continuously.

it is like the directions North, south, east, west. If they are compared to a bot, are more difficult to be useful vs absolute references.

it is like the directions North, south, east, west. If they are compared to a bot, are more difficult to be useful vs absolute references.

http://www.reddit.com/r/Gladiabots/wiki/players/pier4r_nvidia_shield_k1 -> Gladiabots

**CHAT**, stats, insights and more ;### Re: Movement for "any/all" to angle

pier4r wrote:How do you calculate the angle while the bot is moving? (rotate)

The bot rotation angle should not be relevant here. The angle is always 0° for north, 90° for east, 180° for south and 270° for west.

I think I found the solution without messing with angle calculations: (blue instead or orange)

One only has to scale the enemy bots to the same distance. Then add the vectors together and you get the blue reference points. (or use the average position - should give the same results) The example at the top greatly benefits from the new escape route (the blue scaled average position is better than the orange average position).

Anyone could think of an example where this new algorithm is worse?

My algorithm of life: if(self.tired) sleep(); else if(self.hungry) eat(); else follow(Jesus);

- Ritter Runkel
- Neural Network
**Posts:**498

### Re: Movement for "any/all" to angle

LuBeNo, that's nice and easy

+1

+1

### Re: Movement for "any/all" to angle

Yes, this makes a lot more sense and it makes it possible to escape from a situation where you are enclosed on both sides.

You can see the difference in my Gladiabots simulation software I use to test retreatment times:

Flee from average angle:

https://cmrichards.github.io/glad_simul ... 2A2TCM4LxO

Flee from average position:

https://cmrichards.github.io/glad_simul ... WTQe_PR8BJ

You can see the difference in my Gladiabots simulation software I use to test retreatment times:

Flee from average angle:

https://cmrichards.github.io/glad_simul ... 2A2TCM4LxO

Flee from average position:

https://cmrichards.github.io/glad_simul ... WTQe_PR8BJ

------------------------------------------------

My in-game name is MrChris

Creator of the unofficial Gladiabots stats page: https://gladiabots-stats.info.tm/mrchris

And the Gladiabots retreatment simulator: https://cmrichards.github.io/glad_simulation

My in-game name is MrChris

Creator of the unofficial Gladiabots stats page: https://gladiabots-stats.info.tm/mrchris

And the Gladiabots retreatment simulator: https://cmrichards.github.io/glad_simulation

### Re: Movement for "any/all" to angle

evilgeenius2 wrote:Flee from average angle:

https://cmrichards.github.io/glad_simul ... 2A2TCM4LxO

Flee from average position:

https://cmrichards.github.io/glad_simul ... WTQe_PR8BJ

Wait, I didn't know this simulator existed, that's awesome guys!

### Re: Movement for "any/all" to angle

GFX47 wrote:Or scale vectors by 1/distance?

Should be something like the green line: A closer enemy is considered more than the further away one.

Either way blue and green will make small differences. If left is the sniper it would be bad, if right is the mg it would be great.

My algorithm of life: if(self.tired) sleep(); else if(self.hungry) eat(); else follow(Jesus);

### Re: Movement for "any/all" to angle

If anyone wants to test different fleeing points: try this sheet

https://docs.google.com/spreadsheets/d/1WrnQST6IPdOPBf5N3sY2Om-Dl6vrTRIb8SIWIBJNyLc/edit?usp=sharing

https://docs.google.com/spreadsheets/d/1WrnQST6IPdOPBf5N3sY2Om-Dl6vrTRIb8SIWIBJNyLc/edit?usp=sharing

### Re: Movement for "any/all" to angle

LuBeNo wrote:pier4r wrote:How do you calculate the angle while the bot is moving? (rotate)

The bot rotation angle should not be relevant here. The angle is always 0° for north, 90° for east, 180° for south and 270° for west.

I think I found the solution without messing with angle calculations: (blue instead or orange)

angle.png

One only has to scale the enemy bots to the same distance. Then add the vectors together and you get the blue reference points. (or use the average position - should give the same results) The example at the top greatly benefits from the new escape route (the blue scaled average position is better than the orange average position).

Anyone could think of an example where this new algorithm is worse?

So far, it seems that your algorithm (well, I edited it a little bit because I am lazy, improve it yourself if you want ) gets the same direction response as the avarage location.

### Re: Movement for "any/all" to angle

GFX47 wrote:Or scale vectors by 1/distance?

That works too

### Re: Movement for "any/all" to angle

Chilio wrote:If anyone wants to test different fleeing points: try this sheet

https://docs.google.com/spreadsheets/d/1WrnQST6IPdOPBf5N3sY2Om-Dl6vrTRIb8SIWIBJNyLc/edit?usp=sharing

Mh I think we talk about the same. The LuBeNo approach was wrongly implemented, as the vectors have not been scaled (see description above). I corrected it in the sheet.

I thought GFX47 meant something else with 1/x.

My algorithm of life: if(self.tired) sleep(); else if(self.hungry) eat(); else follow(Jesus);

### Re: Movement for "any/all" to angle

I think there's a problem with my method implementation too.

Each enemy's vector should be scaled to (not multiplied by) 1/<distance between me and the given enemy>.

For instance an enemy at 5m from me should have a 0.2m vector length, while another one at 1m from me should have a 1m length vector, making it much more preponderant in the fled position computation.

Each enemy's vector should be scaled to (not multiplied by) 1/<distance between me and the given enemy>.

For instance an enemy at 5m from me should have a 0.2m vector length, while another one at 1m from me should have a 1m length vector, making it much more preponderant in the fled position computation.

### Re: Movement for "any/all" to angle

GFX47 wrote:I think there's a problem with my method implementation too.

Each enemy's vector should be scaled to (not multiplied by) 1/<distance between me and the given enemy>.

For instance an enemy at 5m from me should have a 0.2m vector length, while another one at 1m from me should have a 1m length vector, making it much more preponderant in the fled position computation.

Well, I didn't use the 1000=1 m but 1 =1 m so that should be exactly the same. I'll look into it.

It shouldn't be an exact 0.2m and 1m length though: it should be a 0.2 weight to position far and a 1weight to position close. Those exact distances are impossible with many enemies/only enemies at distance<1.

(One could go further by giving all the points a 1/distance**2 weight because then the flee point will get between self and the closest enemy)

### Re: Movement for "any/all" to angle

Why impossible?

If distance = 0.5m then weight = 2, right?

If distance = 0.5m then weight = 2, right?

### Re: Movement for "any/all" to angle

Jup, I just meant that when you want to find a point where the distance to 3 or more different points is set at a specific value, that point might not exist. (Simple example: there is no point with distance 0.5 to both enemies (0, 0) and (4, 0) when you're at (2,0).)

"Each enemy's vector should be scaled to (not multiplied by) 1/<distance between me and the given enemy>." is just impossible for that reason.

Was mostly to make sure we mean the same thing: "For instance an enemy at 5m from me should have a 0.2m vector length" should be 0.2 vector weight if I'm right.

"Each enemy's vector should be scaled to (not multiplied by) 1/<distance between me and the given enemy>." is just impossible for that reason.

Was mostly to make sure we mean the same thing: "For instance an enemy at 5m from me should have a 0.2m vector length" should be 0.2 vector weight if I'm right.

### Re: Movement for "any/all" to angle

GFX47 wrote:evilgeenius2 wrote:Wait, I didn't know this simulator existed, that's awesome guys!

I made it using the stats you've given and that other people have discovered about the game. Although I'm not 100% sure about the bullet speed, which is currently set at 35 m/s.

All the source code is here (which i've just updated now): https://github.com/cmrichards/glad_simulation

And the game/unit-stats are here: https://github.com/cmrichards/glad_simu ... ameInfo.js

------------------------------------------------

My in-game name is MrChris

Creator of the unofficial Gladiabots stats page: https://gladiabots-stats.info.tm/mrchris

And the Gladiabots retreatment simulator: https://cmrichards.github.io/glad_simulation

My in-game name is MrChris

Creator of the unofficial Gladiabots stats page: https://gladiabots-stats.info.tm/mrchris

And the Gladiabots retreatment simulator: https://cmrichards.github.io/glad_simulation

### Re: Movement for "any/all" to angle

evilgeenius2 wrote:Although I'm not 100% sure about the bullet speed, which is currently set at 35 m/s

Actually it's 40m/s.

### Re: Movement for "any/all" to angle

GFX47 wrote:evilgeenius2 wrote:Although I'm not 100% sure about the bullet speed, which is currently set at 35 m/s

Actually it's 40m/s.

Now the simulator will be even more accurate.

P.S. People are making GB Sims and I'm sitting here doing nothing.

### Who is online

Users browsing this forum: No registered users and 1 guest