I've discussed of this idea as well with a French server owner.

Demonstrating the idea using a classical probability density function

We came up with the idea of making the value of a block follow a very specific exponential function, which instead of increasing exponentially, decreases increasingly slower:
value(x) = ke^(-kx), k>0.

Some maths lessons

This density function comes from the probability field of maths.

It has a few interesting properties:

• the area below the curve is always equal to 1 (integrals).
• the ordinate of the point whose abscissa's 0 always equals k.
• all the values of this function are > 0.

Demonstrating the behaviour of such function

k ≈ 1

Greater value of k

The greater k is, the steeper the function decreases, which in my opinion is the behaviour we want: the more valuable is a block, the faster its value should go down.

Small value of k

On the opposite, with a very small value, it decreases way slower:

How to apply this to the block value calculation?

It obviously needs some tweaking. We don't want server owners to mess around with the formula itself, firstly because they may not understand it at all, secondly because it's not adapted to fit our use case.

k = actual value of the block

Definition

k mathematically being the very first value our function returns, it must therefore obviously be the actual value of the block. As such, k should follow the formula below:

v and p are values that are already part of the configuration, so it's clearly going to be backward-compatible 😛.

Examples

Along the whole explanation, I will use two examples : cobblestone and emerald block.

p = 100 (kind of default configuration)

• Cobblestone: v = 1, therefore k = 0.01.
  

• Emerald block: v = 100, therefore k = 1.
  Keeping the same scale on the x-axis therefore shows this result:
  

n = number of blocks already placed

Definition

n is mathematically the abscissa of all of the points of our density function.
In practice, this is the numbers of blocks that have already been placed, and value(n) is the value of the n-th block.

A hard limit of blocks can be implemented, yet, ideally, we want the value of the block to reach 0 once we reach this limit.

This leads us to this formula, with l (= limit) being the limit of the block:

Examples

• Cobblestone: l = Integer.MAX_VALUE (because there are just no limit to it).
  

• Emerald block: l = 1500.
  

You can see on the image above that the value of the block when we reach the limit is not equal to 0, but 0.37.

Fixing the limit?

Actually, it's mathematically impossible to ever reach a value of 0 because of one of the properties of the exponential function.

If we want the value to reach 0 at some point (the limit), we need to do the following:

This fixes the limit... But value(0) will no longer be equal to k.

Calculating the actual island level

Up to now, we only calculated the value of a block corresponding to how many blocks are already placed. If we want to calculate the actual points it provides, we will need to use some integrals.

And just because this is funny to write things down in LaTeX:

from level.

I discussed of this idea again with an experience Skyblock player. He raised a few concerns:

• it should be clarified in the value command that points are decreasing the more blocks you place down;
• the original value of the block and the value of the n-th block should also be precised;
• this might piss off the big players as the more levels they have, the slower they will achieve further progression.

from level.

I like this idea... but dynamic it will be hard to explain to players how much each block would cost.

one solution would be to create a ladder system when you could specify in config each step size (or dynamic) but all blocks in this step should be the same value.

That could fix or simplify the first two problems.

The last issue... it is not an issue. If they had so large island, there is no problem to create it bigger :)

from level.

Simple is good. The current system is simple. As someone who has to handle support requests from admins who don't understand the current system (usually once I point them to the console report, they start to understand), I'd prefer not to increase the support load. Anyway, if there's a PR to do it, I'd look at it.

from level.

Simple is good. The current system is simple. As someone who has to handle support requests from admins who don't understand the current system (usually once I point them to the console report, they start to understand), I'd prefer not to increase the support load. Anyway, if there's a PR to do it, I'd look at it.

Current system is simple, this is the point. By rewarding players who just farm a lot, buy diamond blocks and place it, we encourage players to stay AFK on their island and wait for the resources to come, to climb to the top of the ranking.

On the other hand, the system imagined by @Poslovitch would force players to diversify blocks on their island, by building and island, not just amass a huge quantity of ugly diamond blocks. So, players are more interactive (with other players, by trading rare blocks for example).

Also, I suggest k decreases when the total number of blocks on the island increases (to prevent experimented players to be blocked at a certain stage of the game).

from level.

I believe this was implemented as a result of the equation-style level calculation. So, blocks can be worth less as levels rise. Closing.

from level.