Movement for "any/all" to angle

mcompany
Autonomous Entity
Autonomous Entity
Posts: 872

Movement for "any/all" to angle

Post#1 » 22 Aug 2017, 19:06

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

User avatar
LuBeNo
Autonomous Entity
Autonomous Entity
Posts: 532

Re: Movement for "any/all" to angle

Post#2 » 22 Aug 2017, 20:08

Sounds good.
How do you calculate this? (0° / 360°)
Image
My algorithm of life: if(self.tired) sleep(); else if(self.hungry) eat(); else follow(Jesus);

pier4r
Skynet
Skynet
Posts: 3389

Re: Movement for "any/all" to angle

Post#3 » 22 Aug 2017, 20:54

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.
http://www.reddit.com/r/Gladiabots/wiki/players/pier4r_nvidia_shield_k1 -> Gladiabots CHAT, stats, insights and more ;

User avatar
LuBeNo
Autonomous Entity
Autonomous Entity
Posts: 532

Re: Movement for "any/all" to angle

Post#4 » 22 Aug 2017, 21:52

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
angle.png (7.99 KiB) Viewed 1508 times


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?
Image
My algorithm of life: if(self.tired) sleep(); else if(self.hungry) eat(); else follow(Jesus);

User avatar
Ritter Runkel
Neural Network
Neural Network
Posts: 498

Re: Movement for "any/all" to angle

Post#5 » 22 Aug 2017, 21:54

LuBeNo, that's nice and easy

+1

MrChris
Automaton
Automaton
Posts: 170

Re: Movement for "any/all" to angle

Post#6 » 22 Aug 2017, 22:54

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

User avatar
GFX47
Dev
Dev
Posts: 2914

Re: Movement for "any/all" to angle

Post#7 » 22 Aug 2017, 22:56

Or scale vectors by 1/distance?

User avatar
GFX47
Dev
Dev
Posts: 2914

Re: Movement for "any/all" to angle

Post#8 » 22 Aug 2017, 22:58



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

User avatar
LuBeNo
Autonomous Entity
Autonomous Entity
Posts: 532

Re: Movement for "any/all" to angle

Post#9 » 22 Aug 2017, 23:08

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.
green.png
green.png (2.65 KiB) Viewed 1494 times

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.
Image
My algorithm of life: if(self.tired) sleep(); else if(self.hungry) eat(); else follow(Jesus);

Chilio
Algorithm
Algorithm
Posts: 52

Re: Movement for "any/all" to angle

Post#10 » 23 Aug 2017, 00:35


Chilio
Algorithm
Algorithm
Posts: 52

Re: Movement for "any/all" to angle

Post#11 » 23 Aug 2017, 00:53

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.

mcompany
Autonomous Entity
Autonomous Entity
Posts: 872

Re: Movement for "any/all" to angle

Post#12 » 23 Aug 2017, 02:28

GFX47 wrote:Or scale vectors by 1/distance?

That works too

User avatar
LuBeNo
Autonomous Entity
Autonomous Entity
Posts: 532

Re: Movement for "any/all" to angle

Post#13 » 23 Aug 2017, 02:32

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.
Image
My algorithm of life: if(self.tired) sleep(); else if(self.hungry) eat(); else follow(Jesus);

User avatar
GFX47
Dev
Dev
Posts: 2914

Re: Movement for "any/all" to angle

Post#14 » 23 Aug 2017, 09:21

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.

Chilio
Algorithm
Algorithm
Posts: 52

Re: Movement for "any/all" to angle

Post#15 » 23 Aug 2017, 09:43

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)

User avatar
GFX47
Dev
Dev
Posts: 2914

Re: Movement for "any/all" to angle

Post#16 » 23 Aug 2017, 09:59

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

Chilio
Algorithm
Algorithm
Posts: 52

Re: Movement for "any/all" to angle

Post#17 » 23 Aug 2017, 13:33

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.

MrChris
Automaton
Automaton
Posts: 170

Re: Movement for "any/all" to angle

Post#18 » 23 Aug 2017, 14:25

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

User avatar
GFX47
Dev
Dev
Posts: 2914

Re: Movement for "any/all" to angle

Post#19 » 23 Aug 2017, 14:44

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.

User avatar
Kanishka
Skynet
Skynet
Posts: 1421
Contact:

Re: Movement for "any/all" to angle

Post#20 » 23 Aug 2017, 15:54

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. :cry:
Fixes break an AI more than bugs do. :ugeek:

Gladiabots Off-Topic Chat


My Stats: Kanishka_RN3;Kanishka_MiPad

Return to “Feature Requests”

Who is online

Users browsing this forum: No registered users and 1 guest