One thing I have been looking into for difficulty control is the possibility of setting the perlin function itself to scale with difficulty. Perlin complexity scales exponentially with dimension of the seed, so this might be a nice place to inject computational difficulty. I think that it would make more sense to increase complexity of frame calculation as opposed to increasing complexity of map generation (so that we never get into a situation where a user can't start a game because they don't have sufficient hardware to generate a map in reasonable time) but I'm not really sure if this is a better approach or not. I could imagine a similar situation where users' framerates are throttled to something annoyingly low simply because they can't calculate the perlin quickly enough to maintain.
What was that? I only see a bunch of words with no sense. Perlin function has no scale difficulty. What does it mean a "perlin complexity"?
Uhhhh, wut?
Perlin complexity is 2^N where N is the dimension of the seed. This is well known, is even on the wikipedia page under "complexity" heading.
Right now we are calculating a two dimension perlin coherency from a two dimension seed, so we have constant complexity of 2^2. There is nothing preventing us from calculating a two dimension coherency by first calculating a three dimension coherency from a three dimension seed, and applying a (modular) combiner to "flatten" the resulting noise into a 2d coherency. (Arguably we could also scatter the 3d coherency back onto a 2d plane, and re-seed a second perlin round from the resulting (now 2d) noise, but this gives us an overall polynomial exponential complexity, instead of the nice, clean "2^N curve like bitcoin has" outcome.)
Perlin noise computation is not related to the map size it is always calculated from the 4 nearest points.
It is calculated from 4 points only in a 2d space. It would be calculated from 8 points in a 3d space, 16 points in a 4d space, 32 points in a 5d space, 64 points in a 6d space, and so on. See where the 2^N comes from, now?
And we aren't looking where to inject computation difficulty it is not a PoW currency.
Huh? It is most certainly a PoW currency (just with a very "fancy" work function) and we certainly are looking to inject (in some form) computational difficulty. (Any proposed solution that doesn't result in increased computational difficulty doesn't do anything to hamper bots. The only real metric for the bots' performance is computational difficulty of the work challenge!) I'm just proposing that we might be able to do it directly/explicitly via a complexity curve, instead of trying to come up with some way of "indirectly" coupling difficulty and targettime, likely by playing with block acceptance semantics, as we've proposed previously. I'm just trying to offer more options. I'm not saying that this would necessarily be better in the long run than doing it indirectly (I think there are pros and cons both ways, and multiple trade-offs to be taken into consideration) I'm simply pointing out the possibility.