So i think we can all agree that if there is not obstacles between your unit ( point A) and your destination (point B ), they should just go in a straight line
So my proposition is exactly that : check if there is an obstacle between point A and point B, if there is no obstacle just go in a straight line ( it doesn’t fix all the issues btw )
Plus i think it should be faster ( for the CPU ) than using pathing/regrouping every time ?
It’s urgent ! Pathfinding has never been so bad! It has become impossible to make Micro archers or other units. This is not the only “new problem” (I am thinking of units which favor attack farms rather than other units…) but it is clearly the most urgent! DEVS Read this!
Computers don’t work with abstract concepts. These kind of stuff isn’t “easy” by any means.
Don’t you think that millions of game developers wouldn’t have already used that system if it was that easy to program? Some of them have IQs of 150 or even higher.
Ofc you could try shoot an arrow with no damage and very high speed in the direction of the walk. BUT this will only trigger something when it hits a hitbox on a specific frame, so there is a limitation.
BUT this could indeed help for short distance pathfinding - esepecially when you differentiat between the different types of units that are hit (friendly, obstacle or enemy).
Still there are limintations to that and it requires computing time aswell.
PS: Also, there might currently be an issue with the “direct line” walk. I read several times that units shall take direct lines, but often they don’'t despite there is literally nothing to stop them from taking it.
I remeber T-West made a video about one pecific command (I think it was called “find closest” or so, which was changed when DE came out. At that time it mostly affected the ressource spawn locations which could only b in specific spots cause that command did use a different metrik thatn the standard euklidian. Probably we still have one or several of these legacy issues that still haven’t been found.
“Computers don’t work with abstract concepts. These kind of stuff isn’t “easy” by any means.
Don’t you think that millions of game developers wouldn’t have already used that system if it was that easy to program? Some of them have IQs of 150 or even higher.”
Indeed having a perfect pathing is impossible ( in real time btw ), i never said otherwise, I’am just proposing a simple fix
“BUT this could indeed help for short distance pathfinding - esepecially when you differentiat between the different types of units that are hit (friendly, obstacle or enemy).”
Yeah you got my point
for the computing time, it could be faster or slower it needs tests, but basically i don’t see how going in a straight line can be slower than using the pathing system
( indeed if you check along the line if there is an obstacle and there is one you have to calculate the pathing anyway so it may cost 1 extra step if the pathing is needed but overall i think it should be worth it because you don’t have to use the pathing all the others times )
And for your post scriptum part yeah i didn’t know those problems, but make that calcultation is not hard at all in theory so I hope they would be able to correct it without rewritting everything
Plus find_closest sounds more like findind close unit / building ? Also are we sure this function uses distance and not pathing to find the closest thing ?
I don’t want to sound mean or anything, because obviously you like this game as much as we all do but, all these people have dozens thousands of hours of experience and if they haven’t found a solution, it means it’s not an easy solution
Why couldn’t the devs just write code like
if pathingRoute == bad {
calculateBetterRoute();
}
It’s just that simple!!! (/s)
I just thought about the idea with projectiles to see if there are obstacles.
When we send projectiles from both the current location and the location the units are destined to go in a way they hit each other at a specific point, we can check if there are bigger obstacles in these paths they take.
it only works for bigger obstacles though as these projectiles have to fly with an absurd speed and therefore will only hit like every 5 th tile or so in every frame. If they would fly way slower, the unit would have already go in a certain direction before it gets the information wether it’s “good” or not. It may also cause issues with other information that might trigger path changing then, which could result in really weird behaviour.
It’s aslo probably best to not make this for every unit individually but rather only for each movment order the player gives which is longer than a given distance.
When programming this a highly accurate calculation has to be made, as it is required that these super fast projectiles have to hit each other at a specific frame to signalize a free path.
And ofc to reduce the calc time for that the points where they hit have also to be chosen wisely. I’m speaking about maps like Black forest. So their needs to be a good coverage in different paths to make sure it always finds one through the forests, optimally the shortest.
Probaly it’s suboptimal for this kind of hyper closed maps, but it should work on most semi-open map types.
This is not the pathfinding problem at all. Its mostly related to group behaviors.
If you select a group of units, they are at different points in the map and you task them to reach a point, how should they move?
Should they try to become a group as quickly as possible or just join other units along the way?
What if fastest units are quite close to the destination while slower units are trailing behind?
How much of a detour can units take from their shortest path to join the largest group?
Under what circumstances should units ignore “group” and try to reach the destination in the shortest time?
What if the route for one or more units gets blocked while they are on the way when another subgroup is trying to group-up?
If the units are supposed to group-up at places in between - What if some units got killed or trapped?
There’s definitely more such cases and no easy answer to them. I believe most of the unit behavior we observe as poor pathing comes as a side effect of the solution implemented to some of these cases.
The main thing that I’d recommend changing is the shuffling behavior of a group when direction changes. When you click forward and a bunch of units form a 10 rows 5 column group and if you click backward, they should just rotate and the last 5 should become the front 5. Shuffling should be limited to places where its necessary like right clicking to a very far-off point and they need to switch 5x10 to 10x5.
Haha, that was a nice satire.
Devs do not needs arrows to see if there are obstacles, there is no physics calculation related to the arrow to do ( but the problem is the same I cannot check every 0.000001 inch on my line, and “my line” is just a vector3 containing the direction)
So let’s say we need that for buildings only ( make sense if there is a ennemy unit and there is no building between you and him, you wanna go towards it )
Knowing the the buildings are placed on a grid, DOOM 1 implemented a technolgy that does something really close to that really fast (i mean they did exactly that but they did more than that)
Also for me units should not block pathing, I can show you 10 exemples of it beeing a good thing and 10 eemples of it beeing a bad thing , but i think i would prefer units not taking other units in their pathing, but they should still be blocked by collisions
But yeah i have not idea if that can be faster than what we have
Anyway we have a new pathing and probably new bugs to report, let’s hope they atleast fixed the units going the opposite direction
Yeah i agree with you it was clearing regrouping but calling it a pathing issues is not that wrong imo
If they are not already inside a formation they should go the the destination as quickly as possible
If they are inside a formation, formation should go the the destination as quickly as possible
Join the units along the way
Fastest unit should go to the destination, unless they already are in formation ( also in previous patch they said if you right click to attack fastest units wil go fast i think that’s fine)
My dream would be less than half a tile, but i guess that can affect performence
They should always ignore grouping unless they are less than half a tile away
I have never said i know how to fix that, my solution is for fixing units going in a straight line with no obstacles
So you are probably going to say , yeah but what if someone drops a house on your line after you clicked ?
Same anser as above , i’am not pretending to fix that, i’am just asking for units to go in a straight line over 5-10 tiles when there is no obstacle
So if i understand what you are asking (i’am exagerating the situation ):
=> You clicked in the upper screen with group A and group B (group A is on the left of your screen, group B is on the right )
=> They try to regroup in the middle of your screen
=> But group B is dead on the way
=> Group A has no more reason to regroup in the middle of the screen, so instead of going in the middle they go directly Up
Welll first yeah i think having units regrouping from far away is not a good thing to have
Second, dead units should not affect the current pathing of the remaining units
But once again i never pretented to fix something like that
Yep that is why my “solution” could work only where there is no obstacles, i don’t blame them for bad pathing, but having having units going the opposite direction for no reason (i mean if there is no obstacles and for me regrouping is not a valid reason too) is not normal, and that is all i’am asking them to fix
For colunms yeah there is no doubt
What I meant is these questions are hard to answer and aren’t independent of each other. And probably not trivial enough to have a single “simple” solution.
What if reaching destination earliest is not what the player wants for a subgroup. Like lets say monks and siege are a part of the group. Its better if they regrouped with others and stay protected.
This behavior could be suboptimal in some situations depending on the length of the path and distance between sub groups. I think they did keep implementing such “simple” fixes thus far which ended up “breaking” the pathing in some other situations.
So if a few monks are a couple of tiles behind a group of crossbows, the crossbows should just walk at their normal speed to the destination leaving the monks behind?
Its actually nice of you to post your opinion on these questions but I was just highlighting that people might expect different behaviour in some of these situations. And addressing all of that in the right way for all possible scenarios might be more difficult than it might seem to be.
( not exactly sure of the situation you are talking about , you said subgroup but you only talk about 1 group of siege + monks )
First i don’t agree with “What if reaching destination earliest is not what the player wants for a subgroup” :
I think players want their units to go to the destination the earliest, If they don’t want that and they want to group instead, they can group their units by themselves
This way i can have control over my unit at any moment
Well the player can move his subgroup close to the group and then they will group, wich is imo better than miss the timing ( on a villager walling for exemple )
Also you could argue that i could just select the few units close to the thing i want to attack, but i think it is way more intuitive and easier to select all the military that is close than just the few units ( and sometimes it is just hard to select the rights ones)
I think it is the exact opposite, they tried too complicated things but i guess we won’t know ^^
If they are not already in formation yes
If i want my archers to slow down and go at the same speed as the monks, i will put them in a formation with the monks by myself
Well when i started this game 5 years ago i had differents toughts on that aswell, but i think if a behaviour is fine, people will agree that is fine, and people agreed that units going in the opposite direct was bad
So yeah removing the bad parts and arguing to improve the rest is fine to me
I atleast have an idea on how difficult it is addressing all the grouping issues and I can tell you I would not want to do that
Wich is kinda my point : less grouping, less problems ? ( not removing the grouping but i think they should avoid to use it as much as possible )
And in bonus a brand new grouping bug => https://www.youtube.com/watch?v=YJGwXqXcOIU&ab_channel=AnnoNyme