Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
Assuming I have an RPG game with monsters, a game you can fight any amount of monsters at any time - What are my options for a gained currency from a battle formula? I've been trying to use Google for any ideas, but couldn't find something solid.
Currently I have the enemy level * user level * 0.1
Pretty sure I need something more realistic and randomized, Hope someone can share any idea about it.
Thanks in advance!
There is no common formula because the formula depends on your game design goals.
In the end the worth of money is the worth of what you can buy with it, so you always need to think of money rewards in terms of the items it is worth (usually. there are of course games where making money is a goal in itself, but I don't think that's the deal here).
So the important game design considerations here are:
Flat or steep progression
Do you want a flat progression where cheap items from the beginning of the game are still valuable in the late-game? Or do you want a steep progression where the player reaches whole new orders of magnitude of wealth opening up completely new tiers of items to them?
When you are going for the first, it's simple: Keep the reward constant throughout the game. This is, for example, done by the Zelda series where a rupee in the beginning is usually as easy to get as in the end.
When it is the latter extreme, you want to go for a polynomial (price * tier ^ x) or even exponential (price * x ^ tier) curve for both item prices and money rewards. That makes sure that when the player wants to make money to unlock tier 10 items in reasonable time they need to fight tier 10 enemies.
Work factor
That's a simple multiplier to both prices and rewards. When you want the player to kill 20 tier 10 enemies to afford a tier 10 sword, have the sword cost 20 times as much as the money reward for a tier 10 enemy.
By the way: The money progression in many RPGs is designed in a way that new item tiers are made available to the player after they acquired enough money to buy them. You usually find the ideal prices by calculating how much money the player should have gained through the expected amount of combat encounters when reaching a given shop and price the items it sells slightly below that amount of money.
As Philipp already wrote, there isn't one algorithm, but I think one could say there are a number of common algorithms with different characteristics, and you take advantage of those for different parts of game progression.
So if you want to ensure a player doesn't get an item too early, you make it dependent on a numeric (currency, in your example, but could also be a reputation, skillpoints level, xp points etc.) that they can only obtain at the desired point.
By handing out that kind of numeric only at predetermined points, maybe even only once, e.g. whenever the player first finishes a given level or mission, give them 10 skill points. Replays can reward a little of that numeric (say, 1), so that a player who is stuck on one level can e.g. skip that and re-play a few other missions to make up for that.
If you don't have any predetermined points (e.g. because your game is a PvP shooter without levels or story mode, just repeated play of the same maps), you usually reward the numeric on other significant events (like enemy kills) and make it increase exponentially, and/or depending on player and enemy level, to make it impractical to grind for with low-tier enemies, and to reward a low-level player who manages to take down a higher-level enemy.
Beyond that, you can select the powers, cool-downs and power levels of both opponents so the time taken for them equates to the amount of currency you want to dispense in a certain amount of time. E.g. in our shooter example, a player can only do a certain amount of damage in a certain time. You select their enemies' health levels so they can withstand that amount of damage for that long, then reward the desired amount of the numeric.
If that's not enough, you can always put an artificial cap on a numeric, like only awarding a certain amount within 24 hours, maybe hiding it behind a conversion (e.g. players earn iron ore, but the iron mongers take 1 day to process it into iron that you can actually give to the blacksmith to have your sword made).
What this generally ends up as is you get a bunch of conversion rates, where it all boils down to a common base numeric in the end, which is what measures progression, or rewards, or whatever. Examples for numerics can be abstract things like experience points, or "junk" loot drops that translate to currency directly, but also very concrete things like "successful damage dealt" that can be used to allot different percentages of a killed enemy's loot when several players take down the same enemy.
There can be separate groups of such base numerics. Often games work with one base numeric for common items, and different ones for endgame items. That way, you e.g. force players to actually play easy PvP content to unlock PvP gear needed for the harder PvP content.
So how do you make PvP gear different from PvE gear? Well, there are many ways. You could just make PvP reward armor/weapons that are so much stronger than PvE ones that you need them to avoid being taken out (works best if PvP is endgame-only). Some games have different "damage types" for different enemies. So PvP armor would just have a much higher resistance to PvE bullets than to PvP ones. This resistance could also take the shape of a buff that is simply applied to every player in PvE areas.
You can even monetize that, by e.g. making players have separate PvP and PvE armor, but offering armor that works in both places for money in your store. A good compromise between monetization and not making it unfair by offering something that couldn't be unlocked by playing. It's just a convenience (as long as a lower-level plater can't wear higher-level armor bought from the store until (s)he has leveled up).
As to your example: If you want to reward/punish players for fighting higher/lower level enemies, you'd want to change <player level> * <enemy level> to something more like min(<player level>,<enemy level>) * max(1,<enemy level> - <player level>) (I'm making this up on the spot, fiddle with it). The first part ensures that a low player doesn't suddenly get rewarded as high as a higher one, but a high player fighting a low-level enemy only gets rewards at that low level. The second part means you get a bonus for fighting up, but you don't ever lose points when fighting down. Or, depending on your numbers, it might be a better idea to calculate a malus for fighting down, just ensuring a minimum reward is still given in such cases.
