Oh, so it’s the edge distances then. That makes more sense.
I wasn’t even thinking about temperatures or spawn areas, but now that you mention it, yes! This could really boost a world’s realism.
Aaand another question, sorry. Do you think the Manhattan equation could be employed in pathfinding? All I have come up with right now is a basic trail the player leaves that enemies can latch onto and follow. With a randomly generated world, it’s not possible to pre-set paths; do you know if it might work for that?
I haven’t looked into it yet, how it can be dumbed-down to make it work in Flowlab, but it is a common one actually used for path finding.
PathFinding
Feel free to grab one of those and implement it @thebrickccentric 
saves me the work
Ok, I’ll try it. I’ll have to do some research, but that should be fun and hopefully helpful.
Thanks for putting up with all my questions.
@thebrickccentric From what I have seen of @TinkerSmith 's Project, I am more than than happy and exited for this. If @TinkerSmith Can have it generate randomly everytime and being able to save with seeds that would be awesome! This is what I have been asking for!
Random is not the problem. Storing the seed coordinates in an efficient way is. Just building my own list bundles to do so.
Soon in a game near you
@thebrickccentric I’m glad someone is asking, lol.
Was worried the details would be too much for this forum.
Ok, so…
Since you seem like you’re on track to get the random world generation finished (after Flowjam, of course), I’ve been doing a lot of research on the pathfinding. And what I’ve found is this: it seems like basically any pathfinding method is going to require either a) some very complex equations that I don’t understand, or b) some kind of array of the entire map which must be analyzed every second of the game, which seems very difficult to achieve in Flowlab. I do understand the basic ideas, for example, the equation that determines a tiles “worth” based on adding its distance from the starting point and its distance from the destination. However, many of the pathfinding methods require a complete calculation of the shortest route to the destination before ever getting moving. The ones that do calculations as they go along seem a little more practical, but even they I think would bog down Flowlab’s code system. Basically every form of pathfinding that I found required the uses of nodes on each tile, and this I think alone would make the game lag considerably. Now, I am absolutely sure that some of these methods could be made to work over time, but I am struggling to see how.
So I instead have tried to invent my own system of pathfinding. This one is built into the land itself. Here’s a link to my experiment with it so far: https://flowlab.io/game/play/661356 (For some reason you have to press escape twice for the game to spawn stuff properly. Also, the system I made is very imperfect and has lots of problems I haven’t worked out yet.)
Essentially the idea is that each obstacle (wall, tree, etc.) spawns objects around it. These objects will point to the player, unless their raycast hits a wall (i.e. they are pointing at the player but a wall is between them and the player), in which case they revert to a preset position based on where they are around the obstacle. The rotation of these objects guides the enemy whenever they run into them. This way, the enemy always moves towards the player, unless it is obstructed by an obstacle, in which case it uses the pointers around the obstacle to navigate it.
Now I know that this doesn’t necessarily find the path of least distance, so I’m trying to think of some way to make each pointer contain a value that is distance from the player, and then maybe have the enemy aim for the one of least value? My overall goal was to take out all the unnecessary calculations that entail forming a straight path to the player (or the destination in general) and instead to only require the pathfinding when there is some sort of obstacle in the way.
For instance, in the following picture, you can see that the majority of the pathfinding is just to make a strait line, which the enemy could simply traverse by pointing at the player and moving, rather than doing a bunch of calculations.
https://upload.wikimedia.org/wikipedia/commons/5/5d/Astar_progress_animation.gif
Again, if my way is used, it means enemies won’t take the absolute shortest path, but they can get to their destination in reasonable time. I know the picture above illustrates the A* algorithm, which is the most basic and least efficient, but it’s one of the few that I understood / think would be at all reasonable to pull off in Flowlab.
One other interesting algorithm I found is ANYA, which outputs the absolute shortest and optimal path to the destination, yet somehow seems simpler than most of the other algorithms. Here’s an article explaining it: https://www.aaai.org/ocs/index.php/ICAPS/ICAPS13/paper/viewFile/6060/6194
I think if I could just learn how to do the calculations at near the end, I could possibly try to implement this one in Flowlab.
What do you think? Should I go forward developing my idea? Or should I scrap it and try again on some existing pathfinding algorithms? (I don’t care which.)
Whoa, how have I never seen this before?!
How far have you gotten? I can answer all of the original questions you asked.
meburningslime, who are you addressing? (Or is it ‘you’ collective?)
@thebrickccentric collectively lol
Here is what TinkerSmith has done:
https://flowlab.io/game/play/1452537
https://flowlab.io/game/play/1452649
https://flowlab.io/game/play/1452942
https://flowlab.io/game/play/1452643
I think these each use different distance formulas to determine what block goes where. It’s a lot more effective to have one block per terrain type and then spawn terrain based on distance from those blocks.
The rest of us have . . . tried . . . but honestly TinkerSmith has carried the bulk of it. The one thing left is to add an ability to save the seed for the random map, so that one can come back to the same world later. Also, I (or whoever else wants to of course) need to figure out how to spawn blocks in and out based on the player’s location (so that the world loads as you go instead of being fully loaded all the time).
That’s where this is; what sort of answers do you have?
@thebrickccentric for your last question, you use an expression to add the randomizer’s choice to the extracted player’s position.
For seeds, this is a little bit difficult.
One option is to have a type-2 randomization, where when you type in a seed, it goes through a very complex (but seemingly random) set of equations to create the randomized numbers. Anotehr option is to use string data to set the seed’s saved random numbers, then have the loading system use those numbers to download the world.
Ok, I think I understand the last part, but can you extrapolate a bit on your first point?
Nice research @thebrickccentric
On the phone atm, will check your example later.
But thanks for taking the time to look into this. Yes, was kinda a mean request, lol, I’m fully aware that path finding pushes FL to the limits.
But good what you found, brings a new point of view to the problem. I hand you a honoray membership card and the spare keys to th TinkerShed, LOL.
We should work on this together.
I also think that FLs options are too limited at the moment. Might change depending on what features @grazer adds in the future. For now I would say ANY path would be great, doesn’t have to be the shortest. I like the idea of encoding precalculated direction info into the map tiles. The only array we have is the map itself.
GOOD WORK
@thebrickccentric you use a randomizer to choose where the objects go. For localized spawnings, just extract the player’s location and add a randomizer to the position, making the items spawn closer to the player. For this, the randomizer numbers should be smaller, in the 300-500 range.
@TinkerSmith I can help you with pathfinding!
The pathfinding is relatively simple once you understand it. Have raycasts test for walls in all four directions, but only is activated if the NPC is facing the same direction. Next, if the raycast hits, then have a boolean randomizer make the NPC turn 90 degrees or -90 degrees. This then turns off the first raycast and starts the one for the proper direction.
On the more complicated part, you can even add in noise sensing! If the NPC gets a message that it hears a noise, then it raycasts in all directions to find the source, then turns to faces it. If it finds no targets, it does not react.
The PRNGs seed can be saved, its just a number. You combine the seed with the X/Y of the coordinate grid to get ‘targeted’ random tiles anywhere on the map. Hard to explain, but it makes sure unique randoms are already reserved for non existing parts of the map.
I’m got that on my To-Do list already. Just have to find the easiest way of factorizing them. Had on, but got too long fir FLs integer number range, LOL
P.S. that was part of the Wang tile map development
@TinkerSmith this is not right. You would need to run this through a set of pre-chosen randomized factorals to have this do more than slightly move some stuff.
Encoding coordinates as part of the seed is quite a common procedure for world generation, it is like pre-chosen. What do you mean?
I think we need a different thread for path finding