Path Finding ... don't get lost

Sorry, i’m back.
@TinkerSmith yeah, lag is going to be a hge issue! I crashed the server twice in my lifetime already…

HAHAHA … I tried to spawn 1x1 pixels to populate the map :lol:

What we need is an option to exclude certain objects from being evaluated, turn them into ‘decoration’. Like a local pause mode. Checking if the new pause option would help, but i kinda need the opposite :slight_smile:
Maybe something we could ask @grazer, but we would have to work out the details of what is needed. @grazer, in case you are reading this, do i make any sense?

I alread asked him, he hasn’t responded in either thread.

@TinkerSmith I killed flowlab by giving 30K objects gravity lol

@thebrickccentric 's pointer blocks reminded me of some example I did a while ago. Hopefully not too unrelated (verbal abuse myself)

Get it? Node targets …

Now, then I have this old dungeon generator project:

(Sidewinder algorithm for the curious ones, unfinished)

I can see total use for the pointer blocks here. Yes, on an open map it asks for lag, depending on the map size, but in a dungeon like this you would only need to place a node at each intersection that has a little look around (raycast) to see what other nodes are in its sight. Then you give each a value depending on its distance (tbd).
So they could then point out the shortest way through this dungeon. Or with a different scan to the player/monster, whatever.

Just a thought …

P.S. The game this was for is a single level side scroller RPG, along the style of ‘Darkest Dungeon’.
The player starts in the top row and can only see/explore that row (side scroller wise).
The exits are shown as doors to the front or back of the level (transparent at the front for sure).
Then he has to find its way to the exit, with the usual trouble along the way (find key, fight monster, etc)
One day … LOL … might make it a co-op, I’m bad at gfx

Quick ‘pointer’ test. The ‘parallel’ processing is actually not too bad.
Link: Flowline Test

I actually fell in love with the so called “Dijkstra” way of evaluating small grid based dungeon maps. If we manage to get that logic into the cell logic … would be soooo sweet :slight_smile:

Wow, that’s neat! I am wondering, though, where you find those functions for the expressions (I’m assuming they’re from a programming language?)
About the Dijkstra way, I’ve seen an example someone made in Flowlab before where they just had a fixed, unmoving goal which had the numbered blocks placed around it for a creature to navigate. I can’t find it now; do you or anyone else know the one I’m talking about?
My question then is how will we account for obstacles? So far, it looks like an enemy would try going straight to the player and get stuck on a wall. With the Dijkstra method, perhaps if the walls are set to some specific number then the enemy avoids them?
I love the way this is going so far.

@thebrickccentric The language you can use within the expressions is Javascript.
There are many online references available that explain them and where you can even try it, like here:

When I get more serious I normally use one of the many online IDEs like

Like when i played around with the PRNG i had a go there.
Once I got it sorted there I ‘just’ modify it so that it fits into Flowlab.

About the obstacles, you just assign an incredible high value to them, then they will be avoided. Found an ecxel example where someone managed to do it without VBA, just basic functionality. That gives me hope :slight_smile:

About the Flowline thingy, that is nothing serious. Just wanted to see how Flowlab behaves when I put all map tiles ‘to work’.
But looking at it, if you add an option to the pointer that checks if he sits on a wall … and then modify the pointer direction to guide along the wall …

… better …

Now I ‘only’ have to figure out how I make the ‘blind’ spots to point to the ‘seeing’ pointers :slight_smile:
… you know what I mean …

Use logic gates to test for walls, and if it finds a wall, it points to the nearest pointer.

That looks like it’s going to work! (Unlike my original one!)
I like meburningslime’s idea a lot better than what I had, since it’s more streamlined.

Have you tried the Dijkstra algorithm at all? It seems like it could function in a random world. Maybe I’ll try it out in pointer test game.
Oh, that reminds me . . . I have something to add to the random world thread . . .

Mini update:
So now I can identify the cells that can ‘see’ the player and for the ones that can not I can apply a distance value … that should bring me somewhere.

About the Dijkstra algorithm, @thebrickccentric , had a play on excel but it would be so much easier if we had arrays. That’s why I went back to my original plan of making that bundle generator, as mentioned in my other thread :slight_smile:

Wow, I’m glad the pointer idea turned out to be useful; what you’ve done here is amazing! I’m excited to see this in action.
With the distance value, would an enemy travel from a lesser value to a greater value or something like that? I guess I’m just wondering, how do you keep the enemy from simply aiming for the highest or lowest value block and getting stuck along the way? How does the enemy know to travel along a specific path in the distance valued blocks? (I’m probably missing some fundamental mechanic here.)
About arrays, is there some way to build one using a bunch of switches and number blocks? Or maybe to use a related function from Javascript in an expression block? (I’m not that familiar with Java so I don’t really know what that would entail.)

About the distance, that’s where now the Dijkstra method needs to come into play. In the image above its just the distance to the player, just to show that each cell can ‘remember’ something.
Now they have to evaluate themself one by one, lets see if over the weekend my head is clear enough to work that out.

Arrays, yes you can build them. That’s what I am talking about in the ‘Tales from the Tinkershed’ thread.

Yes, you can define lists/arrays in the expression block, but they are ‘static’ and it would be easier if we had multilines. I asked @grazer about it but haven’t heard back anything yet.

Do you have any experience in any other kind of programming? It looks like it the way you approach things :slight_smile:

The basic thought I have is this.
Each colored cell shown will evaluate its neighbours. For simplicity I will restrict it to 4 way movement for now. NSEW
If it can detect one or more of the ‘seeing’ ones it will point to the one that is closest to the player (they also have a distance value) and mark itself as ‘seeing’.

If the cell does not have a seeing neighbour it stays marked as ‘blind’ and will try again next frame.
That way I imagine the seeing cells basically extend/grow frame by frame until they reach every corner of the map.

Now every npc that spawns or stands anywhere on the map just has to follow the arrows… for sure in the real game they would be invisible.

The field has to be updated every time the player moves. That will be the interesting bit, to see how fast we can regenerate the map.
For static targets, like in Tower Defense games it should be fine.

Also i wonder if the update can be optimized for moving targets … considering that it only moves cell by cell.

@TinkerSmith you could utilize this for an epic, orignal gameplay mechanic though! Have the arrows visible and by spending some points or money, you can mess with them!

That’s interesting . . . would enemies have a way to decide between two tiles pointing different directions but of the same value? I think it indeed would be tricky to optimize for moving targets; is there a way to limit the range of these pointers maybe? That way the player wouldn’t deal with all of the enemies in the game at once, and it would make only the relevant pointers operate at any given time.
I have only dabbled in programming with Java, and I am currently trying to learn Python as a gateway to learning other programming languages.
meburningslime, that would be crazy (in a good way)! You could make enemies confused when they get near you, go in circles, run away, all come from one side, herd them into an enclosed area . . . there are so many options; that’s a very unique idea!

Love the idea @meburningslime … didn’t think of that.
First I have to get it to work though, lol.
Python is a good pick @thebrickccentric , I think it has a great future ahead. I love the ‘makes sense’ structure of it and it has all the bells & whistles it needs. I only dabble with JS because it is easier at this stage to use it within HTML.
Godot brought my interest back to Python, their script language is quite similar. And somehow I prefer its structure to Unreal or others. But that’s just personal taste :slight_smile:

P.S. and it’s portable, runs from a memory stick … don’t tell my boss, MUAHAHA

About tiles with the same value @thebrickccentric , if done right it wouldn’t matter what the npc chooses. Done right it would mean that each choice is the same distance away from the target.