Build Point Resources Function, continuous on the integer range [-5, 30] Options

[Kagetenshi]

I'm looking for ideas for a function that will be able to extend resource purchasing to integers in the specified interval coprime with 5. My most promising ideas (keeping in mind that these are the most promising of the ideas I've had at 2:00 in the morning) have involved log2s of resource totals raised to various powers, but I can't seem to get things to scale right. ceiling(log2(n^4)-49) gives simple results for 5k¥ and the million, but not for 500¥ (and I haven't tested it on intermediate values, either).

Any ideas?

~J

[Critias]

You lost me somewhere around coprime. Sorry.

[Fortune]

I didn't even get that far. :eek:

[Stahlseele]

i know it's got to be english . .'cause i know SOME of the Words he used . . it's like SR3 English/Scientific Jargon/Deckerese/Netspeak x.x . .

[FrankTrollman]

A simple look at the relative and specific differences in the values at each available point show clearly that the specific values aren't the result of any specific function. It's not an exponent, it's not a simple polynomial. It's just a list of numbers.

That being said, the early points differ more proportionately and less absolutely than the later values. That sounds like something stupid like a qudaratic divided by an exponential.

-Frank

[Ryu]

What do you want to achive? I assume you want to increase ressource purchasing beyound current limits, while factoring in that there is a strong law of diminishing returns at that point?

In that case I´d simply take a stepped function and increase money/BP with each 5 points spend. The function would be based on points spend*average money/BP.

Edit: Echo Frank. Keeping that stupid progression is not desireable.

[Kagetenshi]

Ok, let's try this again now that I'm awake.

I'm looking for a function that will accept integers between -5 and 30, inclusive, and will be defined at values that are not multiples of 5. To put it yet another way, I'm looking for a way to fit the existing progression (or a new one if a new one is made) but allow spending, say, 6 or 17 build points.

I guess I should have said that I'm also looking for a continuous derivative, so something like "add n¥ from 5k¥ to 20¥k, add m¥ from 20k¥ to 90k¥…" is undesirable.

So I guess that's a better place to start: what's a better choice than the current progression, and why?

[Fortune]

Doesn't BeCKS include just such a system (or almost), whereby individual points gave an equal amount of money? Or maybe that is not what you are looking for, as the number stuff is beyond me. :)

[Kagetenshi]

I looked at BeCKS (v2), but it failed the continuous-derivative requirement—you get a constant amount of resources for each point spent up until some threshold, where a new (larger) constant amount is used up until some other threshold, so on and soforth.

Edit: now that I look, you actually note that. Yeah, the problem is that in many cases the next point spent gives you the same amount as the point before, but not in all cases (not that I think a constant return would work for this).

There's also the fact that it's in Karma, not Build Points, but that's a minor obstruction compared to the first bit.

~J

[Shockwave_IIc]

Erm as an idea, plot a graph using the data from SRComp or Becks, then use the "Curve" to guesstimate (Lol Spelling checker says that is a real word) the values your looking for.

Though i think someone had a resource table not too unlike what your asking, thought i had it but i can not find it.

[EDIT] Found it.
Resources
BP Nuyen
-5 500
-4 1000
-3 2000
-2 3000
-1 4000

0 5000
1 7500
2 10000
3 12500
4 15000
5 20000

6 30000
7 40000
8 50000
9 70000
10 90000

11 110000
12 130000
13 150000
14 175000
15 200000

16 225000
17 250000
18 300000
19 350000
20 400000

21 450000
22 500000
23 550000
24 600000
25 650000

26 700000
27 750000
28 800000
29 900000
30 1000000

[Kagetenshi]

Yeah, I tried curve fitting first thing yesterday morning. I'll post some of the results I got later; suffice it to say they were ugly.

~J

[Stahlseele]

coincidentally that ressource table fits to the ammount of money you get when using the points buy system in mcmackies NSRCGv3 . . and as we all know, mcmackie made a beautifull program *g* anybody thought of asking him yet? O.o

[Kagetenshi]

No. I respect the work McMackie did, but I don't really see how it's relevant here. The problem with the above table is that it has odd value jumps—nuyen yields are constant from n to n+4, then change at n+5… so on and soforth.

~J

[Kagetenshi]

Ok, it looks like 65/6*x^3+800*x^2-1750/3*x+5000 does what I need for [0,30]—it fits 0, 10, 20, 30 exactly, and is close for 5, 15, 25 (generally a little higher). I'm going to see if I can't find a way to de-uglify it, but first I'm going to try to find something that extends this into the negatives.

~J

[Kagetenshi]

Well, I failed at that. I had a promising possibility, but it turned out that it gave something like 8k¥ at -2, which is obviously undesirable. I guess I can make the negative a separate function and only feel a little dirty. -325/2*x^2+175/2*x+5000 gives me pretty decent results, though it falls off a little too quickly from -4 to -5. I'll have to think about it.

~J

[Ryu]

What function is "best" depends on the percieved ingame utility of money. Economically, a law of diminishing returns IS present. If you assign constant BP/money ratios, the player will assign BP until the money gained fits the utility of the last BP. If you assign a complex function (last BP=most money), you try to fit the utility curve for BPs spend on money to that of the player (utility curves share form but are individual).

You do not want a linear function. You get a certain minimum amount of money (outdated RAW: 500) for zero points (if you invest 0 you could have had 5 BP), and start spending BP. Each point should be worth more than the point before.

Assume 10% growth. Resulting function is 500*0.04*x^3+free cash.

-5 500
0 3000
5 20500
10 68000
15 160500
20 313000
25 540500
30 858000

I´m absolutely not doing the complete table...

[Ryu]

500+20*(BP+5)^3.05 seems to work pretty good.

Ah, whats Excel good for:

-5 500

-4 520
-3 666
-2 1070
-1 1872
0 3209

1 5225
2 8061
3 11862
4 16773
5 22940

6 30511
7 39632
8 50452
9 63121
10 77787

11 94601
12 113714
13 135276
14 159438
15 186354

16 216175
17 249053
18 285143
19 324596
20 367568

21 414213
22 464683
23 519135
24 577723
25 640603

26 707929
27 779859
28 856547
29 938150
30 1024824