ai sensors/directions?( for random maps)

[ConsciouS-0nE]

Current bots
Field of view version 1 "ranges"
Long range
Medium range
Short range
(3) things
The gladiabots ai currently use in the game to define oneself from other things.

Code: Select all

Basic conditions from "ranges"

If enemy 'is at' "out of range"
If ally 'is at' "short range"
If resource 'is at' "medium range"


Id suggest we progress slowly so ill request "directions/sensors" to make the bots smarter.

so it can define its self way more precise than "ranges"

Field of view version 2 "directions/sensors" i dont know what to call them.

Face/front
Back
Left
Right
(4)new things
new things the ai in the game can define itself from other things, not just anywhere around itself but with more direct definition of the place.
img1- example if bot is facing the enemy base at straight line.
▶red line= target lining, directions sync (enemy base)

Img2- example if the bot is facing away.
▶basically every direction will follow from where the bot is facing/targeting at.

Code: Select all

Basic conditions that can be made by this.

If ally 'is at' "my" 'back'
If enemy is at my left

Joined conditions
If ally is at my front +
If resources is at my back

Much more.


I don't know why this is not a thing, maybe i missed it or its something not needed anyways.


////////////////////


But Heres the,
First version I think about.
Its way more simplier but lacking from the one above, as its just 2 things that the ai can use to define oneself from other things.

Front
Back
(2) new things



Just new conditions will be implemented if this 2 things (front and back) is applied rather the 4 things (front, back and left, right) above that requiressss

(lots of new assets, code and configuration for that).

Since the current "moving action" we can use is
Move
Flee


///
https://www.merriam-webster.com/
https://www.google.it/

[pier4r]

I think that when you mention that you said something but people did not care, is because your post are difficult to understand. At least for me.

Let's say that your descriptions are very brief. Would be nicer to write a bit more, otherwise one skips the post.

If I understood you (but I understood the pictures), you would like to know if something is in front of you, or behind, or on the left, etc.

Nice idea. I guess that there was a request with angles somewhere but I don't find it.

[ConsciouS-0nE]

If I understood you (but I understood the pictures), you would like to know if something is in front of you, or behind, or on the left, etc.

Nice idea. I guess that there was a request with angles somewhere but I don't find it.

Yes,
It can do that thing but theres alot more than that.


Even fix pointing too and lots more.

[pier4r]

Then I did not understand those.

[ConsciouS-0nE]

Then I did not understand those.

You dont know what they are?,
Also in which part do i need to elaborate more?

[ConsciouS-0nE]

Main reason im gonna dig this is to make escape routes,
Preventing a bot to crash on the wall.
And even this can be used to make ais move almost freely in the map.


the most lacking thing gladiabots AI doesnt have

[sethcohn]

+1, I agree, adding left/right is critical in my mind. We already have move toward/flee covering the front/back movements, but there is NO way to move to left or right currently, and that is the next major piece missing.

Moving left or right relative to any of the existing objects we can track (ally/enemy/base/resource) would be vast improvement.

[harthag]

+1 I agree that a quadrant system, or field of view, or something similar is needed. However, I believe there would first need to be updates to the bot movement itself. At the very least, rotation speed needs to be a thing, if not for firing arcs, then for the rotation of the bot itself before it starts moving forward.

I'm having trouble putting all of this thought in to word, so I'll come back to it when I've had time to gather my thoughts, but for now, it would be a huge improvement to add directional variations.

[Echo Blue]

I think Directional Conditions would be a good idea. It would also pair very well with the request for flanking (Directional Movement) features.

Although, my first question is about the arc ranges. From the picture:

All the Arcs are 90 degrees. This is fine for one direction, but what if you wanted to find something within two directions. Say, NW, or Front-Right. The Arc is now 180 degrees big and covers some of what would be considered "behind" the bot. That is just too much.

Your first Idea would be worse (or better, cause it's simpler & occasionally simpler = better ).

One would have to define what exactly constitutes "Front" and "Back", "Left" and "Right", and how much of an arc they should cover.

[harthag]

Ok, hopefully this will be a more complete thought.

I've noticed about the animations of the bots that is unrealistic from a physics standpoint: The bots have limitations on their movement speed when walking forward and back, some are intentionally faster or slower, both compared with each other, and in different situations for a single bot (carrying resource or not). However, this does not apply to how fast the bot can change direction.

The slowest bot (any bot), even encumbered with a resource, can still turn a full 180 degrees at the same speed as the AI program, not at the speed of a physical bot. A bot making a run to score at a base can take a full second or more to take a step or two, but can somehow drop the resource, make a full turn, drop the resource, aqcuire a target, and start firing in a quarter of a second? That contradicts the concept that they have a movement speed restriction at all.

For the concept of front, back, left, right, etc., to be implemented, I believe the first step would be to correct this rotation speed of the bots themselves. This would drastically change the dynamic of the game, but I believe the change would be for the better, and still in the original spirit of the game. Now you can't simply assume that your bot will fire exactly when the AI says it will. Instead, you have to plan your AI to consider how long it takes to aqcuire a target, and build contingencies in to the AI for that. The bots would still act on AI, but could not simply immediately fire regardless of which direction they were facing when receiving the command to fire.

There are a number of possible ways this could be implemented, and the simplest would be just that the slowest moving bots are also the slowest turning.

Others would be variations of other suggestions I've seen, such as the concept of a 'turret' that is at least somewhat separate from the 'locomotion' module of the bot whether just. Tanks can rotate a turret and fire it, without changing the positions of the treads on the main body of the tank. Something similar could apply to bots. Limiting the speed of the rotation, or the maximum possible angle of rotation before the main body has to be rotated instead, etc.

In my opinion, this is the ideal solution for this type of game:
No turret, and a bot rotation speed that matches the bot's function or model representation in game, so Shotgun turns fastest, Sniper next, then Assault, then Machinegun slowest. Bots can reload/prep to fire while turning toward the enemy, and fire immediately when pointed in the right direction if they load in time and if AI hasn't given them other instructions in the meantime (target is now out of range, or no longer the priority target. This would not necessarily require any change to the "prep to fire" timer as it currently exists, since this could simply be considered a calculation to aim, rather than a physical reload or weapon charge time, which could be continuously calculated as long as the target doesn't change, and would still need to be restarted if the target does change.

This would open huge opportunities for strategy and tactics, especially flanking maneuvers. Also, it would make movement options such as strafing (crab-walking, not firing), and "move in reverse" (as opposed to "rotate and then move forward in the new direction") significant and interesting options in the future.

[ConsciouS-0nE]

randomize maps

https://trello.com/c/btQsMwJP/461-repla ... andom-maps

Guys where having this soon.
I post with advancements so maybe they will get worked at the same time rather than this is requested in alpha 0.9 which if players wants it, implementation would start alpha 1.0

Although, my first question is about the arc ranges. From the picture:

All the Arcs are 90 degrees. This is fine for one direction, but what if you wanted to find something within two directions. Say, NW, or Front-Right. The Arc is now 180 degrees big and covers some of what would be considered "behind" the bot. That is just too much.

Not just conditions it can be used just like the "ranges" action filters.
And as said maps would be randomized.

About that, ive said we should progress slowly.

Maybe there will be,
Field of view v3 "Ranges" #2
Long range
▶long range 50% (middle of long range and med range)
Med range
▶ med range 50%
Short range
▶short range 50%
(6) things, 3 new this would make 6 circles.
Thats alot.


And heres maybe the later version.
Theyre even more complex.
Field of view V4 "directions/sensors" #2
Front/face
▶RF
Right
▶RB
Back
▶LB
Left
▶LF
(8) anddddddd thats alot. Would face the same problem i think.


Heres the thing why 6-8 is alot;

3 ranges (s-m-l)
Multiplied by all valid node combinations.

4 directions/sensors (f-b-l-r)
Multiplied by all valid node combinations

[sethcohn]

I actually like the 4 directions, but picture it as 180 degree arcs for each:
Front: all 180 in front of bot... fails if item is on even line with bot, or behind that line.
Back: all 180 in back of bot... fails if item is on even line with bot or in front of line.

Left: all 180 to left of bot, again, not if exactly in line with invisible line forward/back or to right of line.
Right: all 180 of right of bot. same limit (not in line or to left of line)

This would be simple to code for, simple to build conditions (Is the enemy to the left of me?... Is the enemy behind me?" Combos make sense...

[Echo Blue]

Like this:

When Stacking/Combining Conditions:

[harthag]

The problem I see with that setup (F, B, L, R, and combos) is that it does not allow for forward firing arcs (eg. Front 90 degrees, half way between F+L and F+R), which seems to me to likely be a primary desired function of this "sense of direction" concept.

How would you accomplish this? :

firing arc.png (10.57 KiB) Viewed 2278 times

[Echo Blue]

This? (Now with Ranges included!)


8 directions total.
Some Combinations:
FL or FR or F = 180 Front
BL or BR or B = 180 Back
FL or BL or L = 180 Left
FR or BR or R = 180 Right

[sethcohn]

If you really feel the "90 front" is vital, then make that be 'front' not 180... it all still works... If something is not front, but is left or right and not back, then it really is left or right but off out of the 90 angle.

So there would be _6_ areas (not including exactly in front/behind/left or right of...)

2 Front (within 90), left or right
Back and to the Left
Back and to the Right
2 Not Front (left or right) - these are 45s to either side of the first two. (this fails both Front and Back conditions... but not left or right)

Moving toward an item that is 'not front', will immediately MAKE it front, of course.

[pier4r]

Nice graphics

[Echo Blue]

Thank you! : )
I've been thinking about this topic, and I felt abit creative today so I opened up Inkscape.

[Echo Blue]

Created blank radars for you all:


Gallery with all of them +1 more I didn't bother showing: http://imgur.com/a/3V5LT

[ConsciouS-0nE]

Just remembered the concept thing to make this,

Theyre called "radars"