Pathfinding test

Wizardry

http://www.flowlab.io/game/play/909947

You can drag the green 'player' around to test it from different approaches and/or move the black walls to test out different obstacles. The player in this example needs to be positioned beyond the 1-9 radius, basically he needs to encounter the "9 block" first, but as long as he can do that he should reach the goal. This is because once he reaches the 9 block he then travels to the nearest 8, then 7, and so on, and eventually reaches the goal.

The 1-9 block radius around the goal is generated instantly with raycast. It has to be done instantly otherwise spawn behavior gets bugged, this means you can't simply turn it off after 7 or 5 if that's all it takes to encounter the player, and so this is why the player needs to be beyond the 9 block radius in the beginning. Otherwise he might run toward higher valued blocks instead of progressively lower ones. But maybe I can fix this, this was just a test after all and it seems to work.

The 1-9 block radius can be increased, probably to absurd amounts if you have the patience. It's the same logic is used within all the blocks, you just copy/paste and change the spawn values to the next higher value, i.e 5 block spawns 6, 10 block spawns 11, and so on. It's not hard but kind of tedious making new blocks for each one so I"m not doing that yet. There also might be an easier way to do this with only a single block type but I haven't figured that out yet.

CrimsonBlackGames

So, theoretically, if you could have all these blocks spawned and then replaced with new ones every frame, and combine it with your 3D concept and the multi position thing, theoretically, you could make some sort of FPS/Tower Defense.

Mhx Aîr

You're the only person I could see making extremely advanced AI bosses, or even a computer player for checkers. These concepts are always so beyond my expectations of what I thought flowlab would be used for back a few years ago.

grazer

@Wizardry - you are living up to your username. These past couple of demos are bananas.

CrimsonBlackGames

@Wizardry get outta flowlab! We don’t need no insanely complex examples of insanely cool things that were really wel thought out

PixelPizza

DAMNNNNN SON.
genius.
Don't leave flowlab. It's so awesome seeing someone taking flowlab to next level.
Really talented boi.

It's still buggy with straight lines. but this is awesome.

You are hired!

Mhx Aîr

Is this basically always forward velocity point at raycast 9 collision 9 raycast 8 collision 8 raycast 7 collision 7 raycast... Etc?

I haven't looked at the behaviors or anything, but just out of curiosity. It just seems like it's something kind of like that. It actually might not even use raycast, I don't know.

Wizardry

@Mhx Aîr
Yeah, just to test the actual pathfinding the movement is simplified, so it's always moving in forward velocity. Initially it points to the goal, and when it proximities a 9 block, that updates the point-to behavior with the 9 block's position. The proximities only fire once for this as well, so after the 9 block it will go for 8, then 7, and so on. The numbered blocks (basically representing the total move cost or distance to the goal) are the only things using raycast to create the paths.

I tried out switches to automate this behavior without making it a one-time thing, but it's hard. And I also found a way to use just 3 numbered blocks and also a different way using a single pulsing block (no 1, 2, 3, 4 ,5, etc, just 1 that propogates itself outward, then destroys itself on reaching player, and repeats until player reaches goal) but they cannot be generated instantly like the test i posted above, it messed with them destroying themselves in a consistent manner upon reaching the player and even the fastest timer is actually really slow for these purposes. So it might be worth developing more the original demo here instead.

Mhx Aîr

Instead of using switches, you could try using number filters, where each number filters to equal a block to point towards, and you can have something else change the main number that gets filtered, or even just subtract 1 per new block Collision, or whatever you like. You could do almost like a Candyland board game, with a 5 4 3 2 1 5 4 3 2 1 5 4 3 2 1 pattern.

Wizardry

That's basically what the 3 block system I described above tried, it cycles between 3 2 and 1. I've tried filters and switches, it's too hard though. To gain more control over detection I can only think of using raycasting of the player, you would have complete control over when you try and detect for the next path block, but I've yet to start anything on it. The easiest way I know to change targets is to destroy that unit/spawn another object with its own target/repeat, you can see that method along with the 3 path block/kind of infinite range in this demo:


http://www.flowlab.io/game/play/910221

Not ideal for games but as a maze solver it works alright. You can make a different maze or move the player/goal around, but again to keep it simple it first targets the number 3 block. If the closest 3 block is behind a wall it won't run right, so just move him around until the sequence starts properly. It doesn't do anything upon reaching the goal for now as well

kyrophene

wow just...
wow...
I wish I was this good at circuits...

Super Daniel Maker

Mind blown.



Seriously.