After a bunch of digging and verification, I think I can offer the solution you’ve been looking for.
Using this source as my basis, I can produce an approximate match to your progression of terms by slightly tweaking it like this:
public float a = 1f;
public float d = 0f;
public float b = 1f;
public float r = 1.2f;
public int n = 3;
// Return the sum of first n term of AGP
static float sumofNterm(float a, float d, float b, float r, float n)
{
float ans = 0;
ans += a;
ans += ((d * r * (1f - Mathf.Pow(r, n - 1f))) / (1f - r));
ans -= (a + (n - 1f) * d) * Mathf.Pow(r, n);
return (ans * b) / (1f - r);
}
// Driver Code
public void Start()
{
Debug.Log(1f + sumofNterm(a, d, b, r, n));
}
The problem, though, is that this is pretty ugly as-is. Let’s reorganize and rename this a bit to give it some more clarity and relevance, but before we do that, let’s look at how this is constructed to begin with:
Starting with the Wikipedia entry on Arithmetico-geometric sequences, here’s an example of a progression of terms:
0/1, 1/2, 2/4, 3/8, 4/16
In this case, the numerator increments additively (+1) while the denominator increments multiplicatively (x2). However, this isn’t also factoring in the sums of these values; this is just the sequence itself. If you also add each new value to the running total, it would look more like:
0/1, 1/2, 4/4, 11/8, 26/16
Going based on the example script I gave above, this pattern would come about with:
(A) (D) (B) (R) (N)
sumofNterm(0f, 1f, 1f, 0.5f, N);
where the first value (A) is the initial value of the additive sequence, the second (D) is the additive incrementing rate, the third (B) is the initial value of the multiplicative sequence, the fourth (R) is the multiplier for each step, and the fifth (N) is the number of times this is repeated and added together. To write out the sequence:
A*B
(A+D)*BR
(A+2D)*BR2
(A+3D)*BR3
(A+4D)*BR4
(A+5D)*BR5
…
(A+ND)*BRN
First, how does the fractional example fit into this?
0.5 = 1/2
1/2*1/2 = 1/4
1/4*1/2 = 1/8
In this case, the denominator is multiplied by 2 for each step in the sequence. Extrapolating from this, we can fit it into your own sequence using 1.2 (or, rather, 1.2/1) instead.
(A+ND)*BRN
(1+(N*0))11.2N
1*1.2N
1.2N
Well, that became simple. Let’s see what the first few values are, anyway:
1.20 = 1
1.21 = 1.2
1.22 = 1.44
Well, that already starts to check out. Incidentally, that script example at the top of this post already factors in a lot of (n-1) elements, which inherently accommodates a few convenient cases. This means that we can plug in your numbers, add 1, and we have a perfect(-enough) match to your goal…
So now, let's rewrite it for clarity, and make a simplified version for efficiency:
public static float ArithmeticGeometricSequenceSum(float arithBase, float arithIncrement, float geoBase, float geoMultiplier, int term)
{
float result = arithBase;
result += ((arithIncrement * geoMultiplier * (1f - Mathf.Pow(geoMultiplier, term - 1f))) / (1f - geoMultiplier));
result -= (arithBase + (term - 1f) * arithIncrement) * Mathf.Pow(geoMultiplier, term);
return (result * geoBase) / (1f - geoMultiplier);
}
// Simplified version, since you aren't using arithmetic incrementing (0)
// and your arithmetic and geometric bases are both 1
public static float CalculateClickPower(float basePower, float multiplier, int ranks)
{
return basePower + ((1f - Mathf.Pow(multiplier, ranks)) / (1f - multiplier));
}
// ...
public float clickBasePower = 1f;
public float clickMultiplier = 1.2f;
public int clickRanks = 0;
private float clickPower;
// On upgrade...
clickRanks++;
clickPower = CalculateClickPower(clickBasePower, clickMultiplier, clickRanks);
Edit: To clarify why I describe this as “approximate” as much as I do is because there are clearly, definitely small floating point errors that come up regularly under these conditions. They’re basically all negligible, but it’s why I’ve phrased things the way I have.