Hey all,
I've lurked but this is my first post. Upgrading has always been my favorite but now that I've mostly finished a mobile game, I'm not sure how to create a function that will scale cost efficiently.

For example, you might have a gun that costs 500. Then to upgrade, 2000. Another upgrade could set you back 8000. Is there a reason to this rhyme? My simple solution would be this. You are upgrading from level 5 to level 6. We will call the level n.

(n*1000)2

Therefore, the upgrade cost would be 36000 while the next one would be 49000. But I don't like that.

Does anyone have anything better? Maybe an asymptotic doohickey?

Altar of science-
Yeah, I'm a doof. I meant (n*100)^2. Usually my head is somewhere else from what I'm actually doing.

I like the way cubes turn out. That seems to be a good solutions but I will have to actually implement it and test it to see if difficulty escalates properly. Walking the line between difficulty and "Nintendo Hard" is always a fine one.

powerneg-
1) I considered using an array (or table in this case of this Lua game). {500,2000,8000,n} However, math usually is much more precise than I am. Also, an algorithm provides the ability for never ending upgrades, and that is always a fun prospect.

2)Of course the game should be balanced. I'm not sure what you mean here. The intent is that the more the user upgrades, the more they can earn. It's fun as a gameplayer to look back and say, "When I first started, I got 20 bucks my first run through. Now I get over 9000".

For example, you might have a gun that costs 500. Then to upgrade, 2000. Another upgrade could set you back 8000. Is there a reason to this rhyme? My simple solution would be this. You are upgrading from level 5 to level 6. We will call the level n. (n*1000)2

Therefore, the upgrade cost would be 36000 while the next one would be 49000. But I don't like that.

Does anyone have anything better? Maybe an asymptotic doohickey?

Another method of looking at it is to establish a window of opportunity for the gun, say player level five to player level five + 10 hours, and how much money the player will have made during that time -- perhaps a million credits average. At this point the developer can then decide how expensive the gun will be. Maybe the gun is a very expensive item to the player, and we want the total upgrade cost to consume 1/3 of all the money the player would make in that window. So 1/3 of 1 million, rounded to approximately 300 000 credits to reach level cap for the gun.

Breaking up the individual level-ups within that time line is just a matter of marking off points on the 300 000 credits where the level ups will occur. Maybe thinking a bit about what's going on during that segment of time, and how much the player will have, and what else the player wants to spend it on.

After roughing out the price points, then it's possible to create a formula that maps closely to the desired values.

Sometimes this happens just for inflation.

When the 1st level upgrade (500cr) becomes viable, the average kill gives you say 1 credit. So, real price is 500 kills.

Enemies are made tougher, but often they pull out more rewards. So, if the average kill pulls out 5 credits, paying 2500 is still the same thing: real price is 500 kills.

Personally I'm against formulas. Most of the time upgrading has been screwed badly in my opinion. I recently played a tower defense game (I don't even remember the name) where upgrading was basically the last choice - you would sooner run out of space, turrets were often impractical to build and (perhaps the whole advantage) upgrading could run "in parallel".

Unfortunately, besides a couple of exceptions, 1st level upgrade would give you less benefit than a new turret, albeit it would cost just as much.