http://www.flowlab.io/game/play/909947You 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.
Comments
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!
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.
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.
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
wow...
I wish I was this good at circuits...
Seriously.