Flow fields and gameplay

Hello, I am a passive forum reader but as I am a programmer myself I found this very interesting and here is my first post! Thanks for the great live stream btw.

Flow fields can really make units smart but I think that in some situations it can be annoying?

For example, I want to send a unit from point A to point B:
1) The cheap path sends the unit to point B passing in front of a lot of enemy turrets
2) A more expensive, but still viable path, brings me to point B going on top of a cost hill and hence taking longer but avoiding the turrets.

As you can see in the scenario above the user would prefer option 2 whilst the flow fields would chose option 1 unless of course the presence of an enemy turret influences the flow field as well (by adding cost) making units even smarter.

How are you planning to solve this problem?

If turrets and similar did influence the flow field at this point I think units would be getting a little "too" smart and it may hinder game play in some circumstances?

Another example, taken directly from the live stream, is units trying to squeeze in a little space to get to the other side. It can happen that units may decide to go around, but what if I don't want them too? That can be annoying.

The only immediate solution I see to this is an override move command or forced way-points as such so that users can "force" a path for certain tactical reasons. I can see how this can be difficult to solve nicely.

A clarification on this would be great!

shift-click

Agreed.

Mike

Great. I can see how there is potential for some nasty edge cases but I will just wait and see the results

Too bad !

I prefer ctrl-click...

People don't seem to be getting that unless arbitrarily changed (which I can't see happening without some visual indicator), flow fields will simply mimic terrain. In starcraft or any other RTS, if the quickest route to a chosen destination takes you close to enemy turrets, the units will move past those turrets. If you want units to not take the quickest route, tell them not to.

I just watched the video, and I had a similiar question about the flow field mechanic, so I'll just add it here I guess

Since I have no knowledge of the tech other then the vid, I'll just state the stuff I'm assuming:
From what I understand the direction of anything moving is determined "on the fly" while moving, one decision at a time, based off a map that is generated off the general terraincost for that particular movementtype.

Desireability decreases towards difficult terrain and obstacles on that map.

So the first thing I was wondering is if "fog of war" clouds that flowfield data too, so units don't actually avoid stuff without seeing anything?

The second question is about bottlenecks.
Is there some way to give a bunch of units a cost tolerance that makes them stay together as long as it doesn't bottleneck them too much?

The way I understand the technique there would not be an easy way to ignore cost without breaking the whole pathfinding, since the technique does not evaluate the cost for the entire path, but rather for the next step/direction. So any "tolerance" would possibly incrementally add up to the point where some units make a detour up hill and won't be able to efficiently catch back up again.

So will we have Units running a circle as bottlenecks open and close with other units passing through? Or will they decide to travel over a distant bridge and catch up on the other side?

EDIT:
I just thought about that and it seems to me that having dynamic objects add "cost" over time when they don't move would be a nice solution. You can set tolerance that way if you decrease the rate at wich that would happen, but likely units would start "bumping" into each other the first moment anything gets "stuck" or "blocked" in any way. Since cost does build up and propagate outwards it should still be able to avoid major congestion tho, if balanced carefully.

Anyway, the more I think about that stuff the more I appreciate the work that goes into it.
Keeping this pathfinding business clean simple and efficient is really hard

Some things to think about that may answer some of the concerns I'm seeing. It looks to me that the concept of cost is mainly to be used for extremes. In other words, cost is associated with impassable terrain, such as walls, cliffs, etc. Think of it as a binary value of being passable or impassable. The falloff is used for determining how extreme the cost is. The larger this wall, the more you want the cost to flow outwards, so units can find a smoother and more efficient path associated with it.

Now if you're clicking directly on the opposite side of this impassable area, you can certainly expect that your units will have a mess of a time getting there by taking multiple routes, because your order is too vague. (You are saying "Go through this wall" and the units have to find the nearest door.) More logically, you will order your units to follow a path to the destination, which will be more specific.

The key is that along the way they may encounter smaller obstacles. Navigating these with flow fields is trivial, and in the grand scheme of things, your course wouldn't deviate in any significant way. If enemies were going to shoot your units as they navigate around obstacles, they would probably be able to shoot you had there been none at all. But the result will still be a much quicker travel than if the units were moving blindly, like in previous RTSs.

Now I'm sure that with such a handy tool at their disposal the Uber devs will use it for a lot more than just completely impassable terrain. There may be units for which hills present a challenge to traverse, and so smaller cost values can be associated with this location. Now the units would have a threshold for how much of a benefit it would be to go around the hill. If they are just moving to the other side of the hill, it would actually cost them more to go around it due to distance. Conversely, if the hill is in the way of a long destination, the amount of time they save going around it is so small that they wouldn't bother. (Though this can depend on how much it causes congestion by slowing down the units.)

So these supposed issues aren't really issues at all. They are only perceived by the community because the demos that were showed to us in the livestream were essentially very small scale examples. The key is to get the overall system working, and then to tweak the thresholds so that it plays well. (And that's where testers come in.)

DISCLAIMER: I'm just making assumptions from what I've seen, but if I can guess at these solutions knowing only cursory information about the system, I'm sure that the devs can come up with a system that will take care of those concerns.

I didn't realise that total travel distance was being considered at all. Is that true?
I imagined it would make no sense to calculate a path and measure that when that is exactly the kind of calculation you wanted to avoid in the first place by using flow fields.

Sometimes you should probably read more then 2 enties

If anyone is reading this and has more questions, check this out:
viewtopic.php?p=695373#p695373

And apparently it does have an estimation of distance by using another field. So nvm my question in this post.

Best answer ever! :mrgreen:

In the context of my post, travel distance doesn't necessarily need to be considered at all. I'm just pointing out that there are instances in which adjusting course based on the flow field, such as going around hills, is not beneficial in the long run. In these cases, the system needs to be smart enough to determine whether it is beneficial to take those costs into account or ignore them.

Calculating whether it's beneficial or not is a different matter, however. One can definitely use distances to calculate the distance/time ratios and use that as a metric for which route to take. But statistically speaking, the decision often tends to fall within the same curve. This means that it's often quicker and cheaper to approximate the solution with something like a threshold value. It may not be perfectly accurate in comparison, but the inaccuracies would be insignificant in comparison to the cpu resources saved by not calculating ratios for each movement of each unit. It just remains to calculate the correct threshold.

(Of course, this depends on the method being used.)

Correct answer.

Its weird that people think that all this is going to be some massive radical change in game effect from what we had previously. at the end of the day it will basically just be what we have always known but with less traffic jams.

I think perhaps people don't realise that some games have already used this type of tech - albeit not on a sphere. Games like Supreme Commander 2 and Starcraft 2 use similar methods to achieve their silky smooth path finding, and it worked out incredibly well.

I might be a little "snobbish" is saying this, but when I saw the PA pitch video, I just passively assumed flow fields were going to be used. From the RTS point of view, they're basically flawless in comparison to the alternatives.

We're in good hands

Only if done right. Sup Com 2 sufferred from all sorts of silly sliding around.

The difference we are forgetting is this isn't star craft or supcom 2 its PA the best sequel to the best prequel ever TA this method does work and less capable versions of it worked well so this can't be any worse, the struggle is making it work in 3d and not just in a 2d map where its easy plus there is multiple layers as explained in the live stream, these guys are the proven professionals they know what needs to be done, if the system doesn't work when it is released for alpha then that's what's alpha is for to find the major problems, iron them out, so let's wait and see what they come up with first because even that hour long video was not even barely all of what is going on it was just a behind the scenes view of how it works (do more by the way, I loved it )

From what I understand the cost is only a certain amount of deterrent to the units, if the cost is 255 then it will tell you to get lost and walk the other way I understand that but of its only say 5 and the way around it is to walk to the other side of the planet it will just go through the 5 as walking to the other side would take much longer taking him through different zones that cost rather than just proceeding, this would prevent units getting trapped, for example if a unit is built around in your base it won't stop it from getting out like it did in TA because even if the least cost is 200 then that's the best option so it will take that route, I am sure anyone who has played TA knows that sound when a unit is trapped and can't move classic sound

Flow fields don't by themselves prevent units from being trapped.
Also, learn to full stop

I know it doesn't its just a way to explain, and I'd love to use full stops more but it's easier to just type on the phone, I hope you didn't have trouble breathing while reading it in your head ;D

As a 3rd semester programming student I found the march 22nd livestream to be very insightful and inspiring. Even though some of the concepts we're new to me I had no issues following along. The logic of how flow fields work in relation to unit pathing and cost generation for those units was presented in a straightforward way.

That's a result of the steering behavior and animation of the units rather than the flow fields, it's a completely separate issue.