Will we be able to create own mods for the flowfield?

Also gotta ask;



Wut? How did those units get so far off course in the first place?

Mike

I think what everyone is forgetting is that units will probably not really care about staying far away from walls anyways. The cost doesn't need to linearly fall off with distance - you could have an incredibly steep fall-off giving only one pixel of cost next to the wall.

you people are taking a fundamental base system for movement and assuming it's a game mechanic. As someone commented about the livestream, the amount of dumb questions about the tech starts to show on their faces during the questions.

No we don't. We think about how and if this could be implemented as a game mechanic.

Also there were not as many dumb questions during the live stream as you might think, they simply assumed the people did not understand the concept. I rather think they did well understand and were asking for possible additional applications - just as I/ we do.

Spacing? In many games units leave some space between each other if they have the chance - when they are not moving through a choke for example.

More goals don't make your units hug the wall more.

But yes, your other points are valid. Of course this might need tweaking. But it also is the way that actually potentially works, in contrast to setting a dozen waypoints.

I neither get the motive nor the purpose of your posts.

Not true.

Taking three expensive points might be cheaper than taking 30 cheap points. Hell, 15 kinda' cheap points might be the cheapest overall.

Point is, FF doesn't actually give a flying hoot about the globally cheapest points, or even the locally cheapest points.

FF cares about the sum.

Seriously, are you spouting crap? Each unit cares ONLY about the local 9 closest points (including the current one they are on top of). They will move to whatever point is cheapest. This should be common knowledge by now.

EDIT:

I suggest you read this: http://aigamedev.com/open/tutorials/potential-fields/

And yes, potential fields and flow fields are just 2 different words for the same thing.

EDIT:

The actual generation of the field is what takes care of the "sum" problem, and it isn't even using anything fancy to add up to find the sum of a set of point. It has 2 components - "cost" fields and "distance" fields. The distance field is simply just a field that creates a want to go to the target by having low cost at the target, then adding cost to each point as they move outwards away from the target. The cost field is stuck on top of this, and this overall means they'd usually prefer a shorter route than a longer one.

Here, I just mocked this up in Excel. Move from A to B. By your logic the optimal path is take the low-cost path around.

That's a total cost of 9.

Climb the damn cost hill and the total cost is 6.



You're confusing cost with potential.

You've ignored the "distance" field.

EDIT:

Here's a proper example:



Top left is cost field (radiating from center), top right is distance field (radiating from target point B), and the bottom is the combined flowfield. The point "B" in the second example has a value of 0.

As you can see, starting from A the route with lowest overall cost is the own that goes directly through the middle, which is also the route you are led when moving directly to the point of lowest cost/value.

You may also notice that from point A, there are 3 potential points you can go to. This is simply just a slight kink with how the cost and distance falloff is done - for example, if the cost fell off more sharply, or if the distance field added 2 per increment instead of 1, that issue wouldn't be there.

In your specific example, that's co-incidental. If distance only increased in increments of 0.5 instead of 1, then straight over the top (green) is no longer the smallest immediate value (yellow), yet it's the lowest cost overall (8 vs 13).

Bullet, I'm sorry but I don't think you're right on this one.

To find a globally optimal path is an expensive process, period, because you have to be able to be totally sure, this is the cheapest path. It is far faster to calculate a 'locally' optimal path(local in immediate neighbors, not physically local), which is what.

As causeless pointed out, the field you suggested is only the component that pushes you away from obstacles, an important part is the goal/distance component. When you combine them you get the pink (or purple?) and white field that we were shown in the stream (approx., devs may be doing things I don't know (tm)).

Imagine a bowl with the center being the goal, and a field tiny hills being obstacles of limited cost. You put the tiny hills inside the bowl, and you start from any point and follow it down taking the steepest path, like a marble.

Now, depending on how steep you make the hills and bowl, and exactly where you start, you get different behaviors, you may go over the hills, around, depends on the tuning.

Can you create sets of hills that gets things stuck? Yes, but it's a known problem that you can avoid if you build things right (which the devs are).

Well, firstly areas of cost are wanted to be avoided anyways. Depending on how high the cost is (reducing the distance radius makes the cost larger in comparison), you want to avoid it more, even if the overall cost is different.

Secondly, it's all a matter of balance. As I pointed out, the current example I had showed 3 different possible routes depending on which of the "6" values are chosen adjacent to the starting point, but making the distance larger or the cost lower would change that to give a more direct route, or a route that goes farther along the outside.

It's pretty clear you can see balance is already something considered at least a little in Uber's demos - the high cost areas have VERY sharp fall-off. Where the cliffs are, there's only one or two pixels of cost outside them before it turns to null, and even when painting it the blobs are only a few pixels thick. In the example shown, the cost fall-off is pretty linear.

So it depends on the size of the hill...

Well, when we throw those numbers into the magic box it blinks all kinds of bright. When we throw these numbers in, it beeps all kinds of loud. When we just unplug the darn thing we all shout for joy and head home.

Sorry, I didn't get your post and felt silly.

Hmmmmm... I doubt anyone will trust my authority. But, Causeless is 100% right. The whole reason Flow Fields even exist is so that the units don't have to think about the cheapest route, because pathfinding like that takes up Loads of extra calculation time. The benefit with Flow Fields isn't smarter units, it is the ability to make your units intelligent and efficient, without doing overly complicated calculations. The fun thing about Flow Fields though, is that you can make REALLY intelligent pathfinding when all your units are doing is looking at what is directly around them.

Knight, there's a really really simple reason that Painting like that won't be available in the game, which is that if you paint onto a flow field, you are painting onto server side calculations that effect everyone. So if you paint that little wall of cost then yes, your units will hug that wall, but so will everyone else's, as long as they are the same unit type. Also, the whole idea you are worried about, isn't even as big of a problem in Flow Fields. Because the units only give a damn about other units if they directly collide into them. There is no inherent tendency towards spacing in this pathfinding system, any unit spacing is totally up in the air, and I bet it would be really really easy to convince them that Tight spacing is optimal for formations. (There is a tendency towards units occasionally going on totally unpredictable paths, and the very reason he was showing us Debugging is because he's using that system to find variable settings that cut down on that randomness)
This problem could be solved by giving everyone a personal, client side Flow Field that they could "edit" with a UI, but you'd only get one or two of them, and there would be no complex way to interface with them. It'd be a toggle for which group of units pays attention to which of your custom cost painting. Honestly though, there's no way in hell Neutrino is gonna like that idea. But it might become a really really cool mod.


Also, something I recently noticed about the demo with the Debugger, is that those "light" shades of green probably represented REALLY high cost values. I mean, he said only red was impassible, so i'm guessing that red is a max value that has a different meaning in the code, and that all other cost values were on a scale from really dark green to really bright green, where almost white means one less than max, made in a way that doesn't reflect at all how actual gameplay will go. They were just little representations that he was using to tweak around variables, and I'm guessing is that the final goal is to get variables that make those tanks go over the dark green parts at least occasionally, to have them stay as persistent to the goal as possible, and potentially to make them take their own turn rate into account when it comes to cost (they didn't mention that at all, but it seems like an intriguing potential idea, to me at least, because I would want my tanks to plow through cost instead of turn and run, I mean, what else is a tank good for).
But honestly, even that is a mute point, since "cost" refers directly to what's costly for that unit to go through, so a tank is probably just going to ignore a debris field even though all your other units skirt around it like pansies.

And well.... My argument is probably really flawed, so if someone would back me up before people nit-pick it, that would be nice...

I think those excel sheets show things accurately, especially the distance included ones however the starting position doesn't matter. The entire field is calculated and the unit, wherever it is, always tries to move to a smaller number each tick. To quote myself:

You can put it in terms of 'solved games' like tic tac toe. At any point there is always a best move to make. The flow field 'solves' unit pathing and then each unit does that.


The difference between the 1 point distance and .5 point distance costs are just a measurement of scale (and then the size of the hill compared to the distance).

Yes, of course! It's just a bit easier to convey what the unit itself exactly does when you can put yourself in it's shoes, so to say, and think about where it currently is and where it would go next.

So I just made my own FF calculator in Excel. Did this distance field thing too.

I was probably wrong earlier.

However, my calculator gets a bit derpy when you want to go to a location that happens to have non-locally minimum cost (like on the side of a hill). However, I think that's because diagonal steps are 41% larger than adjacent steps but aren't being accounted for properly.

Maybe I should try this in MatLab.

does it work exactly the same as normal pathfinding only backwards?

That's an interesting way of thinking about it, and the answer is... Sorta? I think the major difference is that the units aren't thinking ahead to be optimal, they are just looking at a grid beneath their feet that's already been constructed to be roughly optimal.

I mean... There are a lot of ways of approaching pathfinding in a "Normal" sense, so I'm not sure what you mean.

It's more that the goals and the obstacles yell out "hey I'm here" and the unit just listens with some simple math. Instead of the unit looking out at the world with more complex math, and recognizing what is or isn't an obstacle.