Oh okay I think Im understanding the dilemma, you can turn a material instance to dynamic to adjust its parameters and you can create global sets of material parameters as well. The idea might be to piggy back extra data onto the instance so you dont have to modify them directly, should be able to do this with structs.
Ahh sorry yes I tend to refer to single dimensional ordered arrays as lists, for example on a 2D array as in your vector field you can describe any solid rectangle just by its corners and I would call that a sub field. Where a list is just every item taken from the vector field that fits a certain criteria. For example if you wanted to search just temperate tiles you could have a shorter list, I think you might be doing this already but another set of lists could be continent boundries like we’ve discussed or any other type of data we could use to seperate our random tiles.
I tend to work via object references, structures and the like so I think its just a difference in thinking. Im seeing alot more flat process from how you work and thats okay, I think we are going back and forward talking about the exact same thing, I think I understand why you need the vector field and I think it might be hurting your maths to some degree or causing you to do more complex calculations on lookups then again…
CurrentIndex+Height gives the next tile right? With a 2D array you can work on each index independently so itd be good to have Macros for those.
I think whats most confusing is perhaps the way I used Climate since it relates to what the tile will be assigned but not the tiles type directly. I might have mixed it up so when you have jungle, desert or water those are the possible tile types based on the climate, the climate though can be got through math you dont actually require the table as you can check if a tile is less than or greater than the index of a Climate.
There is nature in chaos or chaos to nature, one of those, your land masses are kind of limited either way because of the fact its tiles, you can only turn a tile 6 different ways and while you could have a number of different patterns you can turn around not all of them will line up with adjacent tiles. Unless perhaps you make it so you can slice certain tiles and break them down to a smaller tile:
This would allow more complex slices and details on tiles by procedurally generating each of the smaller portions and could allow for rivers without using splines. This is just an idea though there is alot of ground to cover, figuratively speaking, in regards to possibilities. There are rules which tectonics follow which includes the plates overlapping and shifting so you could go into alot of organic details but the generation time would increase with the amount of depth.
Anyway Im getting alittle bit side tracked, Im not exactly up on tectonics but Im pretty sure that they are independent from land mass, they slice through both oceans and land masses. If we ignore that and use a slice method for generating land masses, if you have a start and an end point then you will end up with only a set amount of probabilities each time, which means your map isnt actually random so maybe my question would be do you want a randomized map or are you trying to specify what you want to create?
In terms of completely random outcomes you have no end goal, you have a start position and a set of rules and you just iterate for as long as required, its a similar concept to time based rendering where you specify the amount of time it should iterate for and regardless of the quality of the image it will stop when its told where the opposite is knowing what the image should look like and rendering till you hit that point. I guess the issue is that you could run into a situation where a slice never ends but you could limit it based on the map size, for instance if your map size is 10 then your maximum slice distance could be 30 and you could even take into account branches where it chose to go both ways and create a split. The rules for not overlapping is relatively simple but it can cause problems after a certain length like having to check back over the slice and make sure the current slice wont break any of the others.
I hope youre considering a more layered approach by now atleast, that each part of the generation is important as the next, that using maths for the parts you dont need to cache is the way to go and caching small datasets to improve lookups rather than trying to cache the entire field each time.
