# Question
Title: How to deal with "Scrooge McDucks" in my fixed-currency-amount game?
I'm currently working on a very small scale MMO game planned to support approximately hundred players per server, but we're having trouble with our economical model.

For various reasons we have decided to go with a fixed-currency-amount system; meaning that there is only a certain amount of "gold" that can *ever* exist in the game at the same time. In this early play-testing version (9 players) that amount is 9000 gold but we are planing to have around 1 million gold per server (100 players).

A brief example how this system works:

1. At a certain point in time this is how the gold amounts may look in the game.

```
| Max Gold | Bank | Shopkeeper | Player A | Player B |
| 100      | 90   | 0          | 5        | 5        |

```
2. Player A sells 2 gold worth of loot to the Shopkeeper. The Shopkeeper has 0 gold and so he "borrows" 2 gold from the bank (only NPCs can).
3. Player A sells 3 gold worth of loot to Player B. Player B pays from their wallet.
4. Player A buys a sword for 5 gold from the Shopkeeper. Player A pays from their wallet. Now we have:

```
| Max Gold | Bank | Shopkeeper | Player A | Player B |
| 100      | 88   | 5          | 5        | 2        |

```
5. Repeat the above loot-and-sell step a few times and you may end up here:

```
| Max Gold | Bank | Shopkeeper | Player A | Player B |
| 100      | 0    | 27         | 59       | 14       |

```
6. Player A tries to sell a 30-gold item to the shopkeeper, but cannot because the Shopkeeper only has 27 gold and cannot borrow from the (now empty) bank. Player A have to lower their selling price, trade wares in return, or wait until the Shopkeeper gains money in other ways.

This system is working fine – for the most part. Recently one of our testers did something that completely broke our system; they sold, traded, and haggled their way into owning about 60% of the total currency amount available in the game then **refused to use it** (becoming the RPG equivalent of Scrooge McDuck). This caused a big problem because suddenly approximately 5500 gold out of our 9000 total was **unusable**.

Of course in the release of the game one player owning 60% of all money is unlikely, but 60 players each owning 1% of all money can cause the same effect. We have considered deleting old characters and returning their money to the "bank" but decided against it since if a player comes back and his character is deleted I would imagine they would be quite sad (especially if it was super rich!).

So on to the actual question; **how can we avoid this happening and how can we limit the damages caused by this?**

# Answer
> 157 votes
**Fees & Taxes**

One common way to deal with this in real economies is to add a periodic fee that redistributes hoarded wealth back into the community. A few forms this can take:

* Wear on gear items that requires they be repaired periodically, so even a player who's hit a steady state and buys no new items still needs to pay NPCs (or other players) for repairs / repair materials
* Luxury/property taxes or ownership fees for items like real estate, stabling & food for mounts, etc.
* Banking fees or wealth taxes charged when carrying a large balance.

(These last two can continue to ding a miser's in-game gold account at a slow trickle even while they're offline, so a player who abandons the character can't keep the wealth tied up indefinitely)

**Theft**

Allow players some means to steal from each other. Cap the amount that can be stolen to a fixed percentage of current wealth in any given timeframe, so a player cannot be completely ruined by a group of players ganging up on them.

A percentage based cap makes it more profitable to go after misers since they have more loose money to steal. Now your player characters have a financial incentive to help you with your miser problem by sniffing out who has excess cash (make sure they have some gameplay means to do this) and targeting them.

If you can steal from a player's sleeping character / camp / land even while they're offline, then again this gives money a route out of dormant character accounts.

You can also offer players means to defend against stealing, giving rich player characters something valuable to spend their money on: security. This could include paying NPCs / other players as guards or to install & maintain security devices, or storing their money in a bank, which charges fees (see above).

**Logistics**

Make it impractical to store that much wealth at once.

* Make a limited size purse for spending money held at any one time (giving players cause to invest in buying/crafting/maintaining upgraded capacity)
* Add a weight to each gold piece so you sacrifice mobility or carrying capacity to hoard lots on you at a time.
* Have stacks of coins in your inventory take up inventory slots. The more coin you carry, the less room you have for gear.

This can create additional gameplay around acquiring & trading higher-density stores of value, like gemstones or valuable items, so player characters can "compress" their wealth (and in doing so, release coinage back into the market)

It can also create demand for long-term storage in a bank or investments like real estate. (Where the above rules can erode it)

**Other Options**

You could also consider allowing your currency supply to expand gradually over time, which can introduce a little inflation. Inflation at a controlled rate can be a good thing: it means it's more valuable to spend money now than to hold onto it and spend it later, disincentivising hoarding (especially in the absence of interest) and ensuring that there's always at least some more coin entering the system.

If you keep the currency supply absolutely fixed, then the inverse can happen: your currency area (the set of things you can buy with gold) grows as players join and quest for/craft desirable items and updates release new goodies. If the currency supply available to spend on all these valuables stays fixed, then the currency *deflates*, gaining value per gold piece over time, making it more sensible to save this valuable & appreciating commodity than to spend it, worsening your miser problem.

For some more ideas of how to make money tougher to hoard or have other interesting game mechanical characteristics, check out Vili Lehdonvirta's GDC talk on currency design.

# Answer
> 86 votes
There is a critical flaw in your system. You assume players will play forever. In the real world, this is the case. "Players" keep "playing" the game until they die, and then their remaining wealth gets redistributed to their heirs.

Not so in an MMO.

Players play until they get bored. Then they find a new game and forget about yours. Then their wealth stays on their unplayed character, which effectively removes it from the system. This is the natural lifecycle of an MMO character. Nobody needs to intentionally play "Scrooge McDuck" for this to happen.

This constant drain of rich players quitting the game is why MMOs usually do not use closed money systems.

But there is a solution: **negative interest.** In regular intervals, remove a small percentage from all ingame accounts and move them to the bank. This gradually diminishes any dead wealth in the game. It also motivates people to spend their wealth, which will lead to a more active ingame economy.

It might seem like players could escape this system by investing their cash into items and hoard these instead. This, however, is an illusion. While cash is constant, items are constantly being created in your game. More items in the game means the items which exist constantly lose value. So no matter if you hoard items or cash, the value of your hoard will decrease over the long term.

# Answer
> 21 votes
You're going to need some kind of forced, "hard" sink to return the money to circulation. Without it, as painful as it might be to implement one, you will only be postponing the inevitable.

Character death can act as a hard sink, returning a portion of the character's wealth to the pool available to NPCs. Gameplay incentives revolving around upkeep can push players towards spending their money.

For example, perhaps characters need to pay a monthly (real time) fee to their house guards while the player is logged out to maintain their security. Otherwise there is a chance the character will be "killed by an assassin" or whatever while offline.

Obviously, as you note, this can be frustrating so the death should not be permanent and you should probably have a pressure relief valve for characters that end up completely penniless so they can bootstrap themselves back when they return to play after a year. It's better than deleting the character wholesale, though.

You may also want to consider modelling the economy around, rather than an absolute fixed amount, a relative amount (based on the number of players). If you have 9000 gold and your game is a hit and you have 9001 players...

# Answer
> 14 votes
### Background

In the real world, there are (almost) no Scrooge McDucks. Instead rich people invest most of their surplus money, i.e., they lend it to other people.

### Suggestion

Let *x* be the amount of gold available per player (1000 or 10000 in your examples). Every piece of gold that a player has above *x* is available for lending to shopkeepers, i.e., your Scrooges become banks¹. This way, somebody entering the game, hoarding a lot of gold, and quitting is a neutral action that should not affect your economy².

### What if Scrooge stops hoarding?

…, i.e., he buys something or even decides to suddenly spend all his gold? Say, Scrooge decides to spend *y* gold pieces. In that case, your have to accept that the banks (including rich-player banks) have a temporary negative balance *−y.* If the banks were at 0 before and nothing else happens, this would mean that your shopkeepers would have to earn back *y+z* gold before they can buy anything for *z* gold. That may sound bad, but then consider whom Scrooge can give our money to:

* He can buy something from a shopkeeper. This means that the balance is immediately settled.
* He can buy something from a regular player. Then the balance problem gets settled as soon as the player buys something from a shopkeeper with their gold (which they tend to do, because this is what regular players do in their game if I understand you correctly). While this may be the worst of the three cases, the effect is also limited by the time consumed by the required player–player interaction.
* He can buy something from another gold hoarder, say Flintheart Glomgold. In that case, the balance is again settled immediately, since Flintheart now has more money available to lend. (This also partially covers the case that Scrooge gives a lot of money to another previously poor player.)

### Superscrooge and a World of Scrooges

One problem with the proposed system is that the gold lent back to the system by Scrooge can again be amassed by Scrooge himself (becoming Superscrooge) or other players (eventually leading to a World of Scrooges, where every player hoards money).

A Superscrooge could own a multiple of your original maximum gold. This in turn could pose a problem as Scrooge could suddenly release insane amounts of gold into the system (or something he buys with his money, if shopkeepers have unlimited supply).

On a World of Scrooges, money would become irrelevant for the players and whatever motivation you had to fix the amount of gold would very likely be broken. To avoid this, you have to ensure that amassing gold is not an interesting option for most players. Another option would be to introduce negative interest for hoarded gold that scales with the total amount of hoarded gold on the world.

### Sidenote

If Scrooges are a problem, so may be quitting Donalds (i.e., poor players), as they cause more money per player to exist in the system than intended.

---

¹ While you can do this silently under the hood (such that nobody notices), you could also make it a bit more explicit in the game mechanics by introducing an in-game bank where players must store money above a certain amount, e.g., because it exceeds their carrying capacity. However, players may consider this tedious, it opens new pathways to break the game (e.g., people using mules), and you do not have the nice property that a quitting Scrooge has exactly zero effect.

² Consider the following simple example in a system where the bank gains *x* = 10000 gold for each player joining the game:

1. Initial state: The bank has 90000 gold. There are no Scrooges. This means that 90000 gold is available for lending to shopkeepers.
2. Scrooge joins the game having no gold. The bank now has 100000 gold. Since there are
3. Scrooge sells a valuable item to a shopkeeper for 100000 gold. (Let’s assume that the shopkeeper does not re-sell this item, so it is not part of the economy.)
4. Scrooge stops interacting with the economy, e.g., because the player stopped playing.
5. Final state: The main bank has 0 gold, and Scrooge has 100000 gold. Of this 100000 gold, 90000 gold = 100000 gold − *x* is available for lending to shopkeepers (like the bank).

For all practical purposes, the initial and final state are identical.

# Answer
> 7 votes
Provide your Scrooge McDucks with an **alternative commodity they could hoard** instead of money. E.g. sell super-expensive unique items from time to time, or give people visible achievements for acquiring a certain amount of useless goods which cannot be sold back to the shopkeeper.

As for money lost in **abandoned accounts**, you could do the following. Every time you detect an account which was inactive for e.g. 90 days, you **lend their money to the bank**. Should those players return, the game could transfer their money back to them. This means that the bank could theoretically end up with a negative account, but it would require an organized effort from several players and so is unlikely to happen in practice.

You could actually treat Scrooge McDucks the same way you threat abandoned accounts, only instead of verifying account activity, you would check for the **amount of inactive money**, which the player continuously possessed for a given period of time.

This way you can have a (quasi-) fixed amount of active currency without penalizing the players in any way.

# Answer
> 4 votes
Look at the Circular flow of income model used in real-world Economics.

One of the best ways to redistribute money is to look at supply and demand. Do the players with most of the wealth have an incentive to spend their money? If not, they won't.

Another way to redistribute wealth is to use Fiscal policy (taxation). By charging a small amount of tax at a certain time interval, or on each purchase, you can control where the gold ends up.

# Answer
> 3 votes
First of all, an observation - you show "the bank" as independent from "the shopkeeper" - since there is free exchange between those, I'm not sure why you would do that? Just a thought.

If it were me, I'd rethink your decision to have a hard currency limit.

If you don't want one person to collect a large proportion of the money, your options are: to disincentivize them somehow, to make it harder the more they get, or to rob from the rich & give to the poor.

Examples of disincentivizing have already been mentioned: theft, tax, expenses and so forth. IRL inflation is another option, though if your money is worth less goods, then your goods are going to be worth more money.

Another option is to have a fixed currency-to-gold coin exchange rate. For example, if you have a million of your fixed currency, you can steal 10% off everybody, and increase the ratio by 10%. Someone might have had 10 gold coins before, which might have been 10 currency (if the ratio was 1:1); you stole one currency from them, and at the same time changed the ratio so those 9 remaining currency are still worth 10 gold coins. A player need not have any idea of the underlying currency, so would never know.

Another option is to create an item - e.g. "a giant gold coin", worth, for example, 100 gold coins. At any point, if a player has more than 100 gold coins, you could steal 100 gold coins from them and give them one of these; if they look at their stash, it could count it as if it was 100 individual gold coins; if they are about to spend money, you can swap it back.

Or you could have "giant gold coins" items, and make them optional - players could buy & sell the same as other items. I think "Scrooges" would tend to collect these instead of regular gold pieces. And/or push or force it on them if each time they trade with a shop keeper - at the end of a transaction "Oh, I see you have 300 gold pieces - would you like me to swap that for 3 giant gold coins? They are guaranteed redeemable at all shops, for 100 gp each".

Inherently, if you keep adding items trade-able for money, with a limited money supply, you're going to run out of money, even if you don't end up with a Scrooge.

I would expect that, as the amount money "in the bank" decreases, the prices in the shop would rise to compensate, and the amount offered to buy from players would go down. It might even be that, when Scrooge turns up to sell something, the NPC shopkeeper offers them less; if they want to buy, the shopkeeper demands more. They can afford it! If players can see how much money other players have, they might even join in. This might lead to "puppet" players, controlled by Scrooge to be poor, buy cheap & sell to Scrooge.

One option for making sure money to buy items is available, is to count the value of items as part of the money supply. If that 5-gold-piece sword counts as 5 gold pieces in someone's inventory, then "selling the sword" to a shopkeeper is a net transaction of 0 - the value of the items owned by the player does not change, so there is always enough money. This does mean that there is a limited number of items+gold in your universe, you cannot spawn items your universe can't afford to pay out, unless you devalue other items in your universe.

# Answer
> 3 votes
In the vein of Josh Petrie's comment on your original post, hoarding need not be an insurmountable problem in the first place. It's a matter of the value of gold relative to other goods. With sufficient decimal precision, you can have 1 ouce of gold in the entire game and the economy would still be able to function if prices are flexible. Of course, that would require NPCs to be able to handle changing relative prices, which might or might not be reasonably doable in your case. But by your example of a player trying to sell a "30 gold item" to the shopkeeper who only has 27 gold, so that the player has to take the 27 gold or leave it, I'd say you're already on to something.

Also, money is basically a commodity that rose to be generally accepted as a medium of exchange. Real gold, for example, has aesthetic and social status appeal, as well as industrial applications. So if you can treat gold as a normal item rather than a separate value, other convenient commodities would likely emerge as "money" by way of barter. It might lead to other complications - for example, if you need to bribe someone in a quest, instead of checking how much money a player has in their purse and transfering it to the NPC, you would have to use a barter interface.

There's also the matter of how exactly Scrooge McDuck gets to keep all that money for himself in a hard world full of dishonest people. In the real world, storing gold safely costs a not insignificant amount of money. So a storage fee that gets cycled back into the general economy is an interesting idea. Especially since, as gold becomes more and more valuable relative to other items due to the hoarder's own activity, the risk of theft is bound to increase, and the storage fees along with it.

For added realism, you could make theft itself - by other players or a computer-generated event - a real possibility. The less you pay in storage fees, the wimpier the vault's guards, and the higher the chances that a chunk of your gold will go missing.

You could impose a "maximum gold in your purse" limit - or just a storage limit if gold is treated as a normal item - to force wealthy players to pay a storage fee while not penalizing paupers. This would have the additional advantage of slowly bleeding gold from a long-absent player's bank account and back into circulation. If you're gone a long time, maybe everyone thought you were dead and the bank lent out all your cash (like Cianfanelli's in The Witcher 3: Blood and Wine)!

Hard "gold sinks", like repairs or basic materials that can only be obtained from NPCs at FIXED prices, are a BAD idea with a fixed amount of currency. It works in games that have no hard cap on the amount of cash in circulation, and instead try to balance the rates of money creation and destruction per player. They do not, in principle, prevent gold from being concentrated in a few hands, so you could end up with people who cannot for the life of them get enough cash to pay repair bills. It's probably a good idea to implement some sort of "rock bottom" failsafe so that characters have a chance to progress even if they're left completely destitute - unless you're OK with players having to rely on charity.

# Answer
> 3 votes
You are missing a major flaw in your system which is the players themselves. One developing a game, especially a multiplayer one, there is one major rule that should never be forgotten. Players will take advantage of any flaw in the system in order to gain advantage for themselves or to disadvantage others. I think this is highly important so it bears repeating.

Players will take advantage of any flaw in the system in order to gain advantage for themselves or to disadvantage others.

Why this is important to repeat is that if it has been shown to happen in testing you can guarantee that it will happen after the game is launched to the same degree if not more on at least one server.

Now lets break this down into why this causes a problem for them game, specifically in attracting new players. As you have a fixed amount of gold that can be in the game at any given point then chances are it was in existence in one of three ways at the start of the game.

1. Out in the world waiting to be discovered.
2. On merchant and bank npcs
3. On the players starting characters.

Now over time all of this money is going to be removed from those sources and gather in the hands of the players which is where you are going to start running into problems.

If you look at your example where a merchant could not buy loot because they do not have sufficient (or any) gold you will start causing a major problem for players. The issue comes up in the fact that merchants will both sell and buy from the players (and from what I am understanding is the price can be changed). So a rich player who has the ability to farm more valuable loot can easily suck all the money from merchants leaving them useless to anyone else.

1. Rich player finds a merchant with items they want
2. Purchases what they need
3. Unloads all the loot they don't need leaving the merchant with no money
4. If the merchant was not broke before the transaction they now have more money then they started with
5. Rinse and repeat in order to control a large chunk of the money

With a system like this I would see very little incentive for a player to join any sever that is not just starting off as they can quickly become at a large disadvantage to anyone who has a head start on collecting the money.

# Answer
> 3 votes
Volatile coinage: Once each coin leaves the treasury (e.g. NPC nobles or government making purchases from NPC merchants or giving quest rewards to PCs) it has a limited lifespan before it "expires", at which point a new coin is minted back at the treasury.

You *can* store wealth by buying expensive items that don't expire - which are not limited - but to make a purchase you then have to find NPCs who will buy them from you to turn them back into coin. Obviously, this means that you can't just call your currency "Gold". Well, unless it's "Leprechaun Gold"?

Players will, of course, automatically spend their Oldest coins first.

To make this easier to implement, group the expiry dates together (e.g. at Noon on Tuesdays, all coins 26 weeks old expire.)

NPCs and Auction houses will need some sort of check to make sure that they don't give PCs a load of Gold that's about to expire - but, this is already done by real countries when they change to new coins/notes. Any coin over 25 weeks would be swapped for a stockpiled coin that's a week old.

There *are* still ways to game the system, but they require that Ducky McScroogeFace be actively working to keep his money "fresh" instead of just hoarding it.

# Answer
> 2 votes
First off, it's important that you understand how wealth should end up distributed on average. If you've got 100 players on a server, then on average over a long period of time, everyone *should* have approximately 1% of the player owned wealth with a minimum owned by NPC's, ideally with a very low variance. In a short-term situation though, small to medium imbalances are *good*, they're what drives the economy.

So, don't make the amount of gold truly fixed on an instantaneous scale. In other words, long-term, it ends up being a roughly fixed amount of gold, but short term, it varies. One way of doing this is to do all of the following:

* Give players options for earning gold that don't require them to give up some other form of net worth. Good options for this include random drops from hostile NPCs they defeat, rewards for completing tasks for NPCs, and other similar stuff. This also solves the issue of a player running out of money, because it gives them a way to earn it without already having any. In an ideal situation, this should be a reasonably inefficient way to make money, otherwise people will just do this instead of trading and crafting.
* Have player crafting 'create' value. In other words, if the player spent time crafting something, they should see a net return on that investment when selling the result to an NPC. This should also generally be less efficient than trading to other players if you want to encourage player trading. This 'extra' value created should be paid for not from the NPC's pockets, but by adding gold to the game.
* Have NPCs purchase things at a price based on the trading price of those items among players. More specifically, I would implement this as follows:
    + Provide a 'base' price for the item. This should be based solely on the materials, skills, and time required to produce the item if it's crafted, or on it's rarity and how useful it is if it's not crafted.
    + If there is no pricing data at all for the item, or there have been no recent player-to-player sales, NPCs purchase it at the 'base' price.
    + If recent player to player sales of the item have been too infrequent to get good data, NPCs will purchase the item at the 'base' price.
    + If there have been recent player-to-player sales of the item with high enough frequency and a reasonably consistent price, NPCs will purchase it for a small percentage less than the average price paid by players.
    + If there have been recent player-to-player sales of the item with high frequency, but inconsistent pricing (for example, the price varies wildly, or some people are buying and selling at far above or below the average price), NPCs will calculate a weighted average of the average price paid by players and the 'base' price, weighing more in favor of the 'base' price the higher the variance in the prices paid by players is. This helps to stabilize pricing with player trades, and disincentivizes players from trying to make a fortune selling off some highly sought after item at insane prices unless they can actually corner the market.
* Give players three practical options to trade with other players:
    + They can advertise in a (dedicated) chat channel. When they get a PM with an offer, they coordinate where they will meet up, go there, and perform the trade directly. This is high-cost in terms of time spent and having to pay attention to chat, but it's also free of fees and taxes.
    + They can list their items for sale on an in-game auction house. They pay a small fee, list the items for a fixed period of time (higher fees for longer listings), and then just sit back and wait until someone decides to buy the item. Items remain visible while the player is logged out, and can be sold without them needing to acknowledge the sale in real time. This is the most convenient method for general trade, but requires you to pay a fee, and possibly a tax (see the next major point).
    + They can coordinate with other people outside of the game. To do this, they still have to figure out a time and place to meet up in-game (or agree to have third player who they both trust broker the sale for them), so it's still more limited in terms of convenience than the auction house. However, it's still direct trade that avoids the fees and taxes.
* Tax trade. This gives you a way to remove gold from circulation. I would implement this two ways:
    + Put a small *flat* tax on the sale of items *by* NPC's. Make this invisible to players so that they don't avoid purchasing from NPC's to keep gold in circulation. The exact value should be a function of how much gold is flowing into player hands through the mechanisms of my first two points and what percentage of all goods sold by players are sold to NPC's instead of other players (higher percentage equals lower tax, so that you are on average removing a constant amount of gold from circulation this way).
    + Put a tax on player-to-player sales. This should be completely visible to players, but should only apply to game-mediated sales (that is, those done through the auction house). In most cases, this should be a small percentage of the sale cost, optionally with an increase to a higher percentage for very high value items.

If you allow transfers between servers (and you ideally should, so that people can play on the same server as their friends), add the following two points to the above list:

* The auction house should span multiple servers (items listed on one server can be purchased on one of multiple others). It should not span the entire set of servers (spanning all of them gives you *one* economy, which makes it harder for players to get away from the economic influence of other players). Cross-server trading should have the same tax as regular trading, and should only account for the transfer of gold *out* of the originating server.
* Server transfers should not be free in-game (independent of what they cost IRL). This helps limit the transfer of wealth between servers. Ideally, I would implement it as an amount of time you have to wait for the transfer to finish, which is based on how much wealth you're transferring, and the option of paying gold (which goes into circulation of the server the player is transferring off of) to expedite the transfer by some fixed amount per unit of gold paid.

With this approach, you have four levers to control the amount of gold in the game:

* How much is earned by players through things like quests and drops.
* How much is earned by players through crafting and selling to NPCs.
* How much is removed from circulation by taxes on items sold by NPCs.
* How much players spend on the auction fees and the auction taxes. This will tend to impact hoarders the most.

Using those four levers, you can tweak things to keep the total amount of gold roughly even on average, while still allowing for enough variance that hoarding is not as much of an issue. It also gives a much closer approximation of the real-world economy than just allowing a fixed amount of gold in circulation.

You may also consider having a system whereby players can purchase from NPC's on credit with a fixed limit, but only if they have less than some total amount of wealth. Combining this with the above system will limit how much impact hoarders have on the game, because being out of gold doesn't mean you can't do anything.

# Answer
> 2 votes
The only known solutions to these issues in the economics community is to manage your currency. Most nations now have some organ such as the US Federal Bank whose role is to manage the stability of currency. These organs have very few fixed rules, and instead rely on the wisdom of the members of its governing council.

We can divide your problem up into two categories. The first is the accidental misplacement of currency. This happens when people just don't care, and the result of them not caring is that the currency does something you (as a developer) do not like. This can be solved with rules like taxes and bank limits and death penalties.

The second category is the intentional manipulation of currency. This happens when people are trying to game the system. In the real world, monopolies are often viewed in this way. There's a way corporations are "supposed" to work in a free market, and monopolies work in a different way.

This second category is harder to fix with rules. Indeed, it is the economic rules you put in place that they are exploiting. Often adding rules just gives them more exploits!

You can write draconian rules to limit the intentional manipulation of currency. However, it is hard to do so without hurting those who are playing by the rules. An infintessimal fraction of people want to blow up an airplane, so we have to put rules and checkpoints in place which cause millions of lost man hours every year. This is deemed acceptable because the populace presumably wants this problem solved via a set of rules, so they're willing to pay the cost. However, your populace may not be willing to accept your rules.

The solution is to not play by the rules yourself. Give your leadership team the power to manipulate the rules of the game on the fly to manage the currency. If you have a death penalty, make it be a slightly randomized penalty, and permit GM intervention to increase this penalty in the name of the health of the entire server.

The more creative this is, the better. You may even find win-wins because you can handle things on a case by case basis. Perhaps you find out that 70% of your currency hoarding is done by players who want to see some twitch-combat like quake or half life. If your creative team can make a new zone which has this combat, and also happens to be an effective money sink because of all the deaths, then its a win-win. You got the server stability you wanted, and they got the enjoyable game they wanted.

Its almost impossible to find these win-wins up front because you don't know who your hoarding customers will be. You have to balance it for a cardboard-cutout of their playstyle. Once you see what they actually want, it's much easier to find solutions.

So perhaps your solution should be to have your fixed-currency-amount game, but add one small change. Permit your dev team to add or remove currency from the bank with the expressed goal of stabilizing currency in your realm. When that one player corners 60% of your currency, just let more money trickle in. When that player tries to release the currency, soak some up.

# Answer
> 1 votes
With regards to the hoarders and people who have stopped playing: They must be storing their gold somewhere, and if that somewhere is the bank then you don't have a problem: The bank is holding onto their gold and can lend it out to the shop to reintroduce it to the economy, until the player withdraws the gold from the bank again. On the other hand, if they are not storing their gold in a bank, then that's dangerous. There's a reason why people prefer not to bury shoe boxes full of cash in their backyards (create disincentives to carry the gold on their person).

---

Your main problem is that you have a shop that's not breaking even: it's losing money over time (and realistically, it should be profiting as shops do). You can solve the shop problem in many ways, but the simplest would be to make the shop adjust its prices to be unfair or very generous depending on how much gold the shop has in supply. This makes sense because if gold has become scarce then the shop owner should value gold more comparatively to items.

# Answer
> 1 votes
This is nearly impossible to achieve without penalising players.

---

You could have a system where everyone loses money gradually over time, but that would punish all players by stripping money from them.

You could get away with it if the amount was so miniscule that the players barely noticed it but it amounted to a large sum of money when factoring all players in, but you'd need a suitable amount of players for it to be viable.

You could have an 'AFK' tax that reduces a player's income if they stop playing after a while, but that would penalise players who don't have time to play.

You could declare a point where the 'bank' siezes a player's funds if the player isn't around for a period of time (e.g. 6-12 months), but that suffers the same "punishing people who don't have time to play" issue and might not be fast enough to claim enough money back, even if player creation is scattered.

---

The only possible solution I can think of is this:

1. Cap the amount of gold a player can keep on them.
2. If the player would receive gold with a full wallet, that gold either gets sent to the bank by 'magic' or the player simply won't receive it
3. Force the player to store any gold beyond that cap in the bank.
4. Make the bank charge a tax for its storage services, e.g. 1% per transaction, a percentage per month for anyone below a certain threshold and a fixed-fee per month for anyone above a certain threshhold

This ensures a steady stream of money going back into the enconomy. But even then, this could be seen as penalising players.

---

Unless your game is trying to prove a point about fixed-limit economies (like bitcoin), it's probably a waste of time trying to have an imposed limit on the number of coins. Even real world economies do quantitative easing (i.e. generate more coins). As other answers have said, if players feel that the system isn't good enough, they'll start trading in common objects like apples, nuts or shells.

# Answer
> 1 votes
Adding to other answers, you will have a problem with hoarding in a fixed economy. It will force you to supply currency to the game. This means you have to extract it somehow: bank fees, trade fees, durability impact, contests, etc., all of those things serve only to extract money from the game.

Lots can be learned from other MMOs but the first ones to encounter this in-practice (and to write about it) were the Ultima Online authors. Their article on the topic is worth reading.

# Answer
> 1 votes
Due to all the various problems mentioned in the other answers, you have to build a dynamic, realistic economical system, in which the currency is generated and may change its value. The reason why we witness inflation, massive money printing and extreme national debts is not due to the errors of the system of currency, but rather due to governments being able (with the help of "highly cooperative" banks) to print money with barely any limitations. It's a form of quasi nationalized monetary system which renders it disconnected from normal boundaries. If you wonder why - war is one reason to go out of boundaries of common sense in order to quickly generate money to finance the war machinery, which was quite rampant in the 20th century. And once that process started, it is hard to stop, especially not if socialism is an additional source of money spending.

In order to make an economical system work for a game, cause it to work in a natural way, without the need of any external interventions to arbitrarily "fix" it and without setting absolute limitations (like limited amounts of currency). As admin you should never lay hands upon the economy. Given that you are making a game, dismiss the idea of banks. Just use a currency which has some inherent value in itself, can be gathered with roughly equal effort (meaning the more powerful the enemy, the higher the effort to kill (or being sufficiently progressed for it), the better the loot as of raw value). But keep the value of loot rather low.

One consideration is to allow default prices to vary based on how much they own of it. This also implies that all items must have a purpose, and not be just "vendor junk." However, this may eliminate player trading, especially if vendors sell items they bought. That would lead them to buy and sell reasonably, which should be the domain of player interactions.

The other possibility is to use vendors as default buyers. This will set default values and ensure that currency is bound to something consistent. Players may buy items at (much) higher costs through voluntary trading with each other this way. Also you have the option to include "vendor junk."

One important part is to have a way to "burn" money - meaning taking it out of players' hands in somewhat reasonable ways. One example is having repair costs (although it's just a minimal compensation of what loot yields). Another one is having costs (possibly relative costs) for putting items into a market list or auction house, thus disincentivizing keeping items for too long in said areas if they are not bought at the given prices. Another one is selling lucrative items through vendors, which are either repeatedly bought or acquirable at high prices. One more is having players (and the Scrooge McDucks) hoarding money and never spending it or going offline forever.

This way you have a system which has natural currency generation and burn, which keeps itself in check. If players hoard money, they will not infringe on the total functionality of the economy, no matter if they never spend it or spend it all at once. Remember, those occasions are more theoretical and certainly very rare - and the impact it may have is usually minuscule, even if it appears otherwise. And even if it destabilizes the market temporarily - why should that be a problem? A well functioning market is working dynamically, not with static elements.

Also you will have a economical scalability based on the amount of players, their playing behaviors and play times. This solution may be similar to how World of Warcraft works, and it is indeed a good and simple solution to have for MMOs in general. Remember, WoW is among the most successful MMOs out there, so it's a good source for learning.

Btw, there is one optional method: Reduce the yield by loot even more, relative to vendor prices. This is more a solution by fiddling with numbers, rather than systematic. But given that humans have limited time to play, you could simply make it hard (require a lot of time) to acquire currency and make it rare that way. Optionally add ways to reward everybody somewhat equally (daily/weekly quests) to equalize currency generation between players who play less and those who play a lot - so that it is not pure play time which determines currency generation. You'd have to find a good compromise for this, given that you don't want to bully your players who play the most (and thus naturally tend to gather the most money).

# Answer
> 1 votes
NPCs should not be traders of finite resources.

NPCs are unable to adjust to a real market. Make an auction house that allows players to craft and trade items using this currency instead. But the auction house should allow any kind of trade, without any restriction, not limiting players to use this finite currency. Even though it's a small MMO, consider players don't want to compete with bots. Whatever finite tradeable resource in the game exists, it will increase in value relative to infinite resources. Create a system that has sinks for infinite resources so that bots can be dealt with at first. Also because it makes sense in a realistic model, proving itself of good educational value. Eg: wood is destroyed after consumed to make a fire, armor requires a supply of iron for maintenance, food is eaten, etc. The way the finite currency enters the economy should be similar to mining. The currency doesn't need to have any "intrinsic" value, as long as it is finite. Make it as divisible as desired. Its value is determined by players, and it should be **clear** to them that it is finite.

# Answer
> 1 votes
Currency acts as a store of value, unit of account and most importantly a price signal. If you're operating with a fixed currency, then the accumulation of units that any one person saves should not be an issue as long as prices are flexible throughout the entire economy.

For example, if only 100 foobars were available throughout the world, all goods must be available for less than that amount. Through flexible pricing, each exchange will be a matter of negotiation between the asking price of said good and the perceived value of that good by the buyer as his fraction of buying power. asks vs bids.

Your unit of account needs many decimal places and sub units, since prices with leading zeros behind decimals are annoying to use. dollars and cents(x10) or bitcoin and satoshis(x100000000).

Over time, all prices will deflate as the economy grows larger. An individuals savings/hoard (purchasing value) will increase as the economy grows causing people to go on shopping sprees which bring old currency back into the market and may spark short term price inflation. But over time, all of it should balance out and wealth will distribute to those who provide value.

I don't see an issue with "wealth" imbalance, because if prices are flexible it's all relative. Even if players stop playing, there's no reason to return their hoard back to the economy, simply destroy it. Thinking of currency as a fixed unit of account and store of value seems to be much easier than trying to create some socialist paradise where everyone has equal shares of "wealth" and trying to determine what is fair.

Also if your unit of account is unapologetically fixed, more time can be spent creating things of value within the world by following price signals. Killing a bunch of rabbits for fur only makes economic sense until the market is flooded and price drops to zero...Then players have to find something else to do. Perhaps making coats, boots, or finding some other raw material to mine. Your unit of account should provide a price signals to market participants to seek out things that provide value.

Setting out for goals like steady pricing, fixed exchange rates or fair wealth distribution in games causes you to chase your tail optimizing all the things, creating imbalances.

Technically, you can start a world with 1 dollar and as the economy grows, through the power of price negotiations, everything can and will fit within that unit. It's completely arbitrary, you just need division.

I'm surprised how majority of the answers to your question are focused on creating wealth sinks, taxes, redistribution, etc. I supposed if your in game currency is easy to create (like fiat), then you must go this route, but once you switch to fixed currency units, you can ignore managing the games unit of account and instead focus on price signals.

# Answer
> 0 votes
I would suggest that have a disease algo which will start effecting the player after he starts hoarding X amount of gold , he can cure himself after visiting the medic/healer and spending some Y% of his X amount of gold. Also this prevent the players from abandoning the game after accumulating gold because they would die if not cured and their wealth goes back into the game system.

# Answer
> 0 votes
You could also use a cap on player purse/bank size combined with something like bonds/bank notes for larger amounts. This would keep actual currency in circulation, but give the players a way to store/keep money that doesn't hit their cap or tie up the money. Maybe make these notes tradeable so that the player can't trade it directly to the bank for cash. It's less liquid, but allows the player to hold above the maximum amount of money.

---

As an example:

Hard cap on currency is 100, make player purse size max out at 10

5 currency bank notes are available, so a player with 10 units who wants to hold more has to convert at least 5 to a bank note

If they need that money later they have to find another player willing to buy a bank note from them

---

In reality this is really just keeping two currency systems, where one is liquid and the other is not, but players hoarding the non-liquid currency won't tie up the liquid currency that will be used as the core of the game's economy

# Answer
> 0 votes
So this isn't *necessarily* a bad thing.

Eco explores this with minted currencies and it's very easy to manipulate prices if the mint is not issuing new currency (the mint can also manipulate the currency pretty well as well via minting new currency, but that was not done in our case):

* Farmers can clear out a food merchant and, since your ability to grow/do work is based upon food they can horde it to the detriment of others (or broadly, anyone who can create value without expending energy).

+ This is because they made massive fields and then could sell enough product to pay for *all* of the food merchants goods and all his cash reserves, therefore leaving him penniless and stockless (but with raw materials. In practice, these materials were not well balanced and his ability to stock goods went down as he acquires massive surpluses of specific goods)
    + The root issue is twofold:
        - farming is an inherently profitable business, has no precursor skill and the energy expenditure is nearly nil. This allows players to mega-crop, which then gives a massive gain over many other professions which are limited by energy expenditure or availability of input goods
        - shop are frequently not configured properly, so as to allow this sort of behavior: Buy all cooked goods and sell 1000 corn to cover the purchase
* I ended up with \> 40% of the total wealth (and ~60% of the active wealth) on a ~20 pop server by cornering the market on a couple skills and running positive feedback loops between player stores (it's worth noting those are not strictly free money: being a porter is a legit job which no one else was willing to do).
* This led to a lot of internal strife as players raised prices to try and milk currency from me (which made their wares un-affordable for others and in doing so reduced their own income). I then had even less incentive to spend which increased my net gain. I started funding public works to try and fairly redistribute what I had, rather than give in to the price fixers.
* After that we saw a resurgence of player credits (essentially structured IOUs issued by various people - that player can issue an unlimited amount, others can trade on it)

But Eco is also about teaching people how this kind of behavior is destructive, so it's *Won't Fix: As Designed*.

The core issue is nothing else in the system is hard capped like the currency, so if I can farm apples for 24 hours straight and acquire 1% of the total gold, then I can farm it for a month straight and acquire apples worth 30% of the total gold... (insert whatever is the most profitable thing to farm... because that is what farmers will go after). Given that, if prices are also fixed, the central bank will very quickly be bled dry and a player economy will supplant it.

Whether you want the additional friction this adds, well that's up to you.

# Answer
> 0 votes
The following are edited from excerpts of design docs from some of my past projects. Depending on your setting, these might work for you. At the very least, they should help spur some thought.

* Players have the option to sponsor "Renovations and Repairs" of one of the points of interest in your game
* In turn, the player's name get put on the plaque of the location
* The threshold-worth of currency is taken from the player and is deposited into the bank to be distributed to shopkeepers
* The names can be overwritten by whichever player comes up with the cash next

Lets say you have an economy with 1000 coins. A player accumulates 900 of them. The player notices that the awesome statue in town square of the dude killing a dragon can be sponsored for 800 coins, and his name will be added to the plaque. The player makes the purchase, now has a balance of 100 coins, the bank got 800 coins from him, and the statue now says

"*Our Greatest Hero* \- Renovated by Marco1028"

If Polo42 gains 800 coins, he can sponsor the statue, which now makes it read

"*Our Greatest Hero* \- Renovated by Polo42"

Mechanics like this give players a sense of being part of the world, feel voluntary, and spurs competition. Most of the time, players will willingly participate.

However that's not always.

* You should always have a sales tax on every trade
* Require consumables to either be consumed or rot. This prevents food or potions from flooding the market and sapping all of the coinage.
* The NPC shopkeeps should redistribute goods to each other. Maybe they all need to eat, so ultimately they trade with each other to buy food which they destroy, and keeps money moving between the shopkeeps.

With regard to bank accounts:

* The game should mint a fix amount of coins per player account
* The player should have a dedicated "coinpurse/wallet" slot that can hold a maximum amount of coinage at a time. Coins cannot be held in other slots.
* The player should have a "free checking account" at the bank with a max balance that is equal to the mint\_value\_per\_player - coinpurse\_size
* Allow them to purchase an "unlimited checking account" at the bank which removes the balance cap, but has a service fee that gradually bleeds the account down to the max free account balance.

This setup allows for the following

* Players are encouraged to spend their money if they posses more than their "fair share"
* Players can only carry so much coinage, so any further transactions have to go direct deposit. if the deposit will put them over the limit, you can prompt them for the fee.
* Inactive players can only permanently hoard their "fair share" for ever. If they have a huge balance and go away, the bank will bleed them down to their share over time. (maybe once a week)

# Answer
> 0 votes
I'm pretty sure you've seen enough answers to know that you need to have some sort of taxing system. I don't want to be redundant by telling you what you've already read, I do however want to warn you about the effects of these solutions on returning users.

## Consider returning users in your design

Taxing the player in some way in the hopes of bringing the money back to the internal bank sounds like the right thing to do, until of course, your player who also apparently spent real money on your game, returns a couple of months later to find that he's money's gone. You will have lots of players who return back to your game, leaving almost immediately. And if you use email campaigns, advertisements, etc. to pull players back to the game, you'll effectively be throwing money down the drain.

Now to circumvent this, you could try giving the player some of the money from the bank as a bonus for returning back to the game. I've noticed this in Top Eleven, where your items keep increasing (money, rest packs, medic packs, etc.) until you return (I'm pretty sure there's some cap). Though Top Eleven doesn't use a fixed currency amount system, one cannot forget making sure that you have to also hook players back to your game if they return.

Make sure you make it clear why the player's money/resources were drained. So telling the user that x player attacked his base is one way, even showing the amount of resources taken (War Commander's Attack log is a good example of this). And when possible, try and design the game so that it isn't the game's fault that the player lost some resources, this keeps you in the player's "good" books and redirects their anger else where.

# Answer
> 0 votes
You have two things in your game: items (to buy and sell) and gold.

The items are unlimited. The gold is limited.

They play off each other but they and controlled by you differently. Of course there is going to be an eventual imbalance.

You can either limit the items (X number of swords, Y number of horses) or make the gold unlimited. If you limit the items, the amount of gold in the game will make the items worth a certain amount. If you have one million coins in the game, a horse might be worth 9872 coins. If you have 10000 coins in the game, a horse might be worth 582 coins (made up numbers, but you understand).

# Answer
> 0 votes
Another alternative is to have copper and silver coinage, too. Then set maximum amounts of gold, silver, and copper that can exist in the game world at any time. Track how much money is in the wild, how much is in player's possession or banking accounts, and how much is held by merchants.

All items are priced in one of the three metals. Any attempt to buy them with either of the other two coin types involves a hefty exchange fee (say a 20% premium). There are also money-changers, whose premium is only 10%. Of course, any fractions are rounded in the NPC's favor.

Index all prices by how much money of the specific denomination there is in the merchant's hands, and all drops from monsters by the amount not held by players or merchants.

When you do this, Scrooge McDuck's hoarding will cause the amount of findable money to drop, but the prices will drop as well, and his efforts to retain all of the money of any denomination will yield progressively smaller returns for his effort.

To this, add a limited player character lifespan. After playing for so many days or hours, the player character dies from old age. He/she must either transfer the money held to an heir--here is where you apply an inheritance tax--or the money is forfeited entirely. Also helps deal with players who reach their level caps.

# Answer
> 0 votes
Let's assume that every player is a hoarder, if they can.

Now, to minimize cash hoarding you just need to keep the available cash below the value of available commodities. The trick here is to implement an automatic system that dynamically change the rate at which specific commodities can be looted.

For instance, let's say that food is becoming scarce and rich players are hoarding food with the objective of making a bigger profit. On other words, massive amounts of money are converted into food, that will be converted back into money as soon as its perceived value reaches a certain high point. You can detect that because few players are buying lots of food, and food price is going up rather abruptly. Randomly wait for a few cycles, and increase the looting rate for food until prices go down. Players will try to hoard something else, but meanwhile they would have an overstock of food, and a net loss of wealth. The thing here is to detect trends and know how low/high player would go, then notch it back a little and start raining food all over your universe. Give it a few hundred cycles, and eventually veterans (usually players with more means) would stop flipping commodities for personal gain. This solves one aspect of the problem.

Another aspect is to manage your sources of income against your cash sinks in an automated way. Obviously, your expenses will always be higher than your income. So, for instance, keeping 1,000 gold coins should be more expensive than keeping 1 gold coin; selling 1,000 hamburgers should be more expensive than selling 1 hamburger, and so on. Make some items "perishable". Let's say that food has a 10% chance of getting spoiled after a week, but if you have 100 units of food, that percentage is doubled, and now 20% of your food will be spoiled after a week...

In other words: for every unit of wealth earned, you'll have to spend a random percentage of wealth between 90-105% (note that it is as twice likely to lose than to earn). As long as the negatives are little more than the positives, you can be sure that the economy will be fixed.

But wait: there is more!

Let's say you have the following essentials: food, meds, weapons, ammo, armour, and money. You can convert one into the other. Now let's create a random trend for a random number of cycles in which a specific commodity would become scarcer and scarcer. Now, generate another random outcome to determine if we will allow players to "win". Of course the house always win, so the probabilities should be:

49% Player wins 51% Player loses

Note that this skewed economy will affect the whales mainly. They would think they can control the economy (about 50/50, even thouugh we know they will lose more often than not).

Practical example: Dead Frontier is a zombies where every weekend there is a big event. The kind of event is unknown until a few hours before it starts. Let's say that the event is to hunt bosses. Thus you will need a lot of ammo and meds and food, but mainly ammo. So you go looting, and instead of getting food, meds, or ammo, you loot tons of cash. You can convert the cash into whatever you need, but since there is so much cash, goods start to get more expensive than before. And naturally, those who only play the market, not the game, would grab as much ammo as they can. Then, suddenly all you can loot is ammo. Ammo here, ammo there, but not a single banknote. The price drops down, and now everybody is trying to sell ammo cheaper and cheaper (because cash is scarce). Eventually, everybody goes into barter: ammo for food, meds, or whatever. Rinse and repeat as neccesary.

Note: You still need ways to erode wealth, like having food, meds, and ammo go bad after a while, but the idea is solid.

# Answer
> -1 votes
**The currency-server-system has another downside**

Players can't easily change servers, because they can't take keep their gold across servers. Servers that have space for 100 players could make it hard for people to play with their friends. As long as you don't start at the same time, you will most likely spawn on different servers (in case the servers will automatically be filled). Once you have some money on a server you don't want to change to another one because you would lose all your gold. Nevertheless you could spend all your gold on items and take them to another server. Once a server has 100 players, no one can join the server unless someone else is leaving the server and gives all his gold to the bank/other players or spends all his gold.

**The moving system**

You might need to implement some kind of moving-system. If a player is offline for 30 days straight or so, he is removed from the server and all his gold will automatically be transferred to the bank. When he logs in again he will be able to choose another server that has player-slots open and has enough capacity to give him his gold back from the bank. So you don't make the player angry by stealing his gold nor limit the gold capacity on the server he is inactive on.

# Answer
> -1 votes
I think a simple solution would be to incorporate some kind of stealing. Like being able to employ the thieves' guild to steal a % of someone's wealth. The thief charges a fixed amount, say 5g, and steals 1% of the target's money. So it only makes sense to steal from the rich.

And then to make this less frustrating for the rich, you can introduce a protection mechanic, like a secure vault, which charges the player a % of their stored money as a fee. So one way or another, the money is getting recirculated back into the system.

---
Tags: game-design, mmo, economy
---


# Question
Title: Why use convex polygons and not concave ones in path-finding?
I read in Unity's path-finding documentation that they use convex polygons because there won't be any 'obstruction' between 2 points. Then they add their vertices as nodes along with starting and ending points and traverse them using A\* algorithm to reach the required destination.

However, I do not understand what they mean by "no obstruction between 2 points". I tried to check the differences between concave and convex polygons but only the angle differences come up (in convex the interior angles must be less than 180 degrees)

# Answer
A convex polygon has a very nice property:

The shortest path between any two points in the polygon, or anywhere on its edges, is just the straight line between those points, and that line segment lies wholly within the polygon. So if your polygon represents a section of your level known to be obstacle-free, then you're guaranteed you can do the very simplest thing, walk straight from point to point, and it will work.

For a concave polygon, this isn't always true. Here's an example:

Our intrepid navmesh agent just wanted to cross from one edge of the polygon to another, but the simplest and shortest path to do so takes it outside the polygon - into potentially uncharted territory! We can't guarantee that's a safe place to go. It could contain impassable obstacles or hazards or higher-cost terrain, or even game-breaking glitches.

We can't know for sure that it's safe without consulting other polygons in the mesh, or erring on the side of caution and taking a longer path that stays wholly inside the polygon. But such a path could itself be hard to compute, if the polygon has many of these concave notches that we have to navigate around. All this means extra computational expense we'd love to avoid if we can.

But on the plus side, any concave polygon can always be decomposed into a finite set of convex polygons, bringing us back to the easy case. Now we can just find a sequence of polygon-to-polygon hops that takes us to our destination, and within each polygon, just navigate straight from our entry edge to our exit edge, with no risk of wandering into unsafe territory:

This way, we pay a little extra cost when setting up our navmesh, breaking it into convex parts wherever we find a concave corner, and storing some extra polygons as a result. This investment pays dividends every time we do a pathfinding query, because now it can just do the simplest and most obvious thing and get a correct, working result, without handling all the special cases that concave polygons require.
> 79 votes

---
Tags: unity, ai
---


# Question
Title: Decorating a 3D procedurally generated interior
There are lots of materials on how to procedurally generate levels for a videogame, but they mostly focus on obtaining the layout of the level and exist in a vacuum where having generated said layout means you have reached the end goal. For 3D games, however, it is rarely ideal to just have empty rooms connected by similarly empty corridors - you want to have some kinds of props and decorations all over the level to make it more appealing.

What approaches are there to reasonably decorate a procedurally generated level?

Before you can even begin to place props in a room you need to know what type of room it is, because what props are acceptable candidates for placement depends on the room(bookcases are welcome in libraries, but not in bathrooms). The problem with any generic level generation algorithm is that you end up with a bunch of nondescript rooms, so you will need to have an algorithm that somehow identifies and assigns room types by their properties.

The problem grows more complex when you realize that some props have more placement constraints - chandeliers can't be placed randomly as we expect them to be placed according to some spatial patterns.

# Answer
> 1 votes
To begin with, let us set some constraints: -we are working with a 3D tile based system (the procedural environment is made of 3D model segments) that can be connected logically to each other. -the tiles are used to form rooms and hallways, and you need to keep track of rooms for theming.

Each 3d tile contains more than just its mesh and texture. It will also contain positions for the props in the scene. Each prop position should be tied to a list which contains the acceptable props. E.g. a prop position next to a wall might be able to have bookshelves, tables, or banners, whereas a prop position on the ceiling might be able to have lamps, or skulls dangling, etc. You can further refine this by assigning theme tags to the individual props to know what options you have to pick from for a particular room theme.

When you generate your room, you can randomly assign a theme for the room and then scatter a random number of props to the available prop positions. Or, you can make every position have a prop. It is all artist's choice at that point.

As I recall, this is very similar to how Bethesda made the dungeons for skyrim and oblivion, although they created premade templates of tile/prop combinations and used those to quickly assemble the dungeons manually.

---
Tags: procedural-generation
---


# Question
Title: Game shifts to edge of screen when clicking Play button in Unity
I’m attempting to help my young daughter who is trying to learn Unity. I know very little about the program.

Recently, she developed a basic game consisting of a dragon and a person.

When she presses the play button, the game shifts to the edge of the screen and does not start.

I have attempted to research the issue but with my limited knowledge on the subject I could not find anything. Any help or suggestions would be appreciated!

09/22 - After reading the comment and following the recommendations I do believe it’s a camera issue. I’ve attempted to move the camera around using the X, Y and Z axis is but I can’t get it to actually change the view. See the attached screenshot.

10/02/2020 - My daughter went back and redid the game from the start. The issue is that the game will not allow her to enter play mode until she places the dragon. However, as soon as she places the dragon and presses play the game moves the camera. So the issue apparently occurs prior to or at the time she places the dragon but because she can't enter play mode prior to this point I'm not sure where the issue occurs.

# Answer
> 0 votes
Try opening the Window menu and choosing Layouts --\> Default. That should change your window to look something like this:

(You can also try the other standard layouts to see if any of them behave better for you)

Click the Game tab indicated by the red arrow in the screengrab above, then click the Maximize on Play button:

With this enabled, clicking the Play button should make the game expand to fill your whole Editor window.

If it's still not behaving correctly for you, editing your question to include a screenshot of what you're seeing may give us some clues for what to try next.

# Answer
> 0 votes
The problem might be the camera,

In Unity, the Camera is the viewpoint through which the player is able to view your game. The problem might be that your camera is not set up correctly. There are two ways to do this:

1. In the screenshot above, I have selected the Main Camera in the hierarchy, it is highlighted in blue. In the Scene View, you can see the small pop-up in the bottom-right corner, this shows what the player can view on running the game. Going back to the scene view, there is a white rectangle with some handles (squares) on its side. This represents what the camera can see. You can move this around or adjust its size, try to adjust, and resize it so the camera popup in the bottom-right shows what you want the player to see.
2. My preferred way to this is to drag the Game Tab from next to the scene tab (above the scene view) and bring it to the bottom. If you do this, you will see that the lower tabs show what the camera can see, while the upper tab shows. the scene view. Keep adjusting the camera as stated in (1) until the girl and dragon are visible in the Game View (lower tab).

If this doesn't work, then edit your question to include a screenshot (and some more details). That might help us figure out what exactly the problem is.

---
Tags: unity
---


# Question
Title: How to detect which car T-boned the other in a collision?
# Setup

The game has cars and collisions, and I'm trying to create the following system:

* When a car T-bones another, the one getting T-boned is destroyed;
* When the cars collide laterally (usually just bump into each other), a normal physics collision happens (and nothing is destroyed);
* When the cars collide head-on, the lighter one is destroyed.

The cars are all instantiated from 1 prefab. This can't be changed.

## Car Setup

The main body **sans the bumper** has a normal, non-trigger collider and the dynamic Rigidbody. It has the tag "Destructible".

A child object (which also houses the bumper model, but that shouldn't matter) has a normal, non-trigger collider for the bumper. It has no Rigidbody and reports to the parent's Rigidbody. It has the tag "Destroyer".

# Attempted Solutions

## 1) The `transform.forward` solution

Get the `transform.forward`s of both cars and compute their dot product.

* If the 2 vectors are opposite each other (or close to it), destroy the lighter car.
* If the vectors are facing away from each other (or are close to parallel), let a normal collision happen.
* If the vectors are perpendicular (or somewhere in that ballpark)... then I'm lost. How do I know which car T-boned which?

That brings us to the solution #2.

## 2) The 'multiple colliders' solution

Assign another collider to the bumper of the car and give it a separate tag (e.g. "Destroyer). As a consequence, give the other — main — collider a tag, too (e.g. "Destructible").

* If a Destroyer collider hits a Destructible, the latter is destroyed.
* If a Destructible hits a Destructible, a normal physics collision happens.
* If a Destroyer hits a Destroyer, destroy the lighter one.

But here, I run into an issue.

1. You can't have multiple colliders on the same game object. Ergo, create an empty child and attach it there. I won't set it to Trigger, or otherwise it won't detect collisions with another of its type (i.e. Destroyer).
2. In order to destroy colliding objects, I need a script and an `OnCollisionEnter()` inside it.
3. `OnCollisionEnter()` won't run if neither of the game objects has a non-kinematic Rigidbody. This means I need to give the bumper colliders a non-kinematic Rigidbody.
4. But if I give them dynamic Rigidbodies, they'll just... float away from the car.

In other words, I need a way to create a 2nd collider but keep it firmly attached to the car. Furthermore, if the main collider covers it, then I need to exempt it from collisions with the 2nd collider (let's call it the sub-collider), and I can't use layers to do that or otherwise the sub-collider won't detect main colliders on other cars.

If I don't cover it, then I need the sub-collider to act as a normal physics collider, too, when it hits, for example, a wall, and not have the bumper sink into it. That means it needs a non-kinematic Rigidbody.

**How can I solve this issue?**

# Answer
> 1 votes
> If the vectors are perpendicular (or somewhere in that ballpark)... then I'm lost. How do I know which car T-boned which?

Shoot a ray from the center of mass of the vehicle through the front. If the ray hits the other car, it was the other car that was t-boned. If they ray doesn't hit something, reverse the roles of both cars, shoot again.

You might need more than one ray and shoot through the front left/front right edges of the car as well.

`Physics.Raycast` should work well for that.

---
Tags: unity, collision-detection, physics
---


# Question
Title: How to add an icon to a script registered as a class?
While learning Godot, the tutorial dictates how to add an icon to a class.

Tutorial

> You may add a comma and an optional path to an image to use as an icon. You will then find your new type in the Node or Resource creation dialog.

Steps taken:

1. Added a 16x16 svg file to the resources named **something.svg** .
2. Created a script with a path to that icon.
3. Added a node of that kind.

I don't see that icon? Not sure why.

# Answer
> 0 votes
For Godot 3.2.2, saving the scene and reloading the project should fix the issue.

---
Tags: godot
---


# Question
Title: Linux Mint Godot window when ran very small
I am running my game on Linux Mint 20 Cinnamon. When I run my game I get a very small window that is about 1 pixel tall. This happens across all projects. I have tried uninstalling Godot and reinstalling it from the package manager. I have also tried the official launcher from their website. Updating through update manager does not help as well. I get the same issue using Godot 3.2.2 and 3.2.3

# Answer
I needed to enable DPI in my display menu
> 1 votes

---
Tags: godot, linux
---


# Question
Title: Can I add extra widgets to a child widget in UMG-UE4?
I have a widget base class and I would like to reuse (logic and wigdets as well) it.
I created an empty widget and set the parent class to the base class I would like to inherit from in the class settings.
Works fine.  But when I am trying to add any widget on top the pre-existing ones just disappear, they get overridden by the children, I guess.

I found this post for a feature request, but it is quite old.

Just wondering if it is possible to add extra widgets without getting rid of the parent ones?

# Answer
> 1 votes
You need to use an overlay which will allow you to put multiple widgets onto one widget.

---
Tags: unreal-4, ui-design, inheritance
---


# Question
Title: How do I increase the spawn rate of an object as the "difficulty" goes on?
I just want my objects to spawn in a faster rate as time goes by. The `print(SpawningInBetween);` print out shows the percentage of the difficulty overtime.

This is the code I have:

```
public Vector2 spawnsMinMax;

//Spawn Positions
Vector2 SpawnPosition;
float secondsBetweenSpawn = 1;
float nextSpawnTime;

void Update()
{
    if (Time.time > nextSpawnTime)
    {
        float SpawningInBetween = Mathf.Lerp(
            spawnsMinMax.y,
            spawnsMinMax.x,
            Difficulty.GetDifficultyPercent());
        print(SpawningInBetween);
        nextSpawnTime = Time.time + SpawningInBetween;

        nextSpawnTime = Time.time + secondsBetweenSpawn;
    }

    // ...

```

I was thinking of going like this:

```
if(Time.time > Difficulty.GetDifficultyPercent < 0.9)

```

but it got a compiler error.

# Answer
You can control the spawn rate by changing the value of `secondsBetweenSpawn` to a value between 1.

One way to do that would be via script. For example, you can reduce the time at a rate of 10% every 5 seconds with this line in your Update function:

```
secondsBetweenSpawn = Mathf.Pow(0.9f, Time.timeSinceLevelLoad / 5f);

```

But another solution I find far more elegant is to control such game features with a Timeline asset. It allows you to define the progression of variables over the course of the game with curves which you can edit in a visual editor. Note that before you can control the value of a variable with a timeline, you need to make it public.
> 3 votes

---
Tags: unity, c#
---


# Question
Title: Performance problem when multiple enemies are grouped up
I have enemy with simple behavior: Reach the player's current position. In game are increasing waves, which are increasing the number of enemies. But when are more enemies (like 14), and they got too close to each other, there is big physics spike in profiler.

There are significant drop of performance... And as Profiler says, it's because of Physics...

Now I am little lost, I tried turn of the ignore collision on layer (which was turned on), so they don't overlap, but there is still little touch of course, when they group up, so still so much to process...

What is the best solution here?

I build it around rigidbodies for the use of Velocity, and detection of collisions with walls (edge collider), so when the object reaches there, it is easily stopped... But for this cases it seems now like not the best solution.

# Answer
Ok, as was stated in comments, I tried to use simple circle collider... And now was everything working. The original polygon collider was generated automaticaly by Unity, which was trying cover whole shape of sprite, see below. There was two array of points (one with 22 point, another with 120 points).

As I would like to cover the shape of sprite with the collider, I set up custom, much simplier with 4 points. And is working like with the Circle collider. From 6 thousand contacts to compute, there is only around 30 with the 15 enemies stacked in group.

Beware of complex shapes!
> 2 votes

---
Tags: unity, physics
---


# Question
Title: After baking my lights again in Unity, my character is black?
I had to re-bake my scene several times before getting the look that I wanted. This last time, the scene looks great, but my characters are now very dark and the playable character is completely black. He lights up only when the directional light hits him.

Saying this makes me realize the problem (sort of): All the spotlights from the room's interior were probably baked while the characters were turned off, making their solution require the only real-time light in the scene in order to be seen.

Still, I didn't think the characters would be involved in the lightmap data? How do I redo the lights just for characters and moving objects? How can I fix this and keep the scene lighting?

# Answer
So um...kids: don't bake your lights before you set up blend-probes or all your characters and other non-static objects are only going to be lit by real-time lights. Real-time solutions might not require this but any baked-lighting solution probably will.
> 1 votes

---
Tags: unity, lighting, lightmap, hdrp
---


# Question
Title: How do I share a downloadable WebGL build in Unity?
When I make a WebGL build for my project, I get a folder that lets me click a .html to play my game in a browser. Is there a way I can share a folder like this for playtesters?

I tried sending a .zip folder to playtesters, but they only got a Unity loading screen that didn't do anything.

# Answer
> 2 votes
The Unity WebGL builds are intended to be played from websites. They don't work when loaded from a `file:///` url. When you launch a WebGL build from inside Unity, then Unity actually starts a tiny webserver to host the game, so your browser can load the game from `http://localhost/`. So when your testers want to do that too, they need to set up a local webserver. Which might be too much of a hurdle for less technically inclined playtesters.

But there is an easier way: Just upload the WebGL build to a website and send your testers the link.

One great website for that purpose is itch.io. In order to publish a game you need to register with a valid email address. If you don't want to publish your build to the world yet, set your project "Visibility & access" to "Restricted" and either set a password or ask your testers to register accounts on itch.io so you can whitelist their usernames.

But if you also have an own website, then you can just upload the folder to it.

---
Tags: unity, unity-webgl
---


# Question
Title: C++ map isn't finding key even though it exists
I am in the process of learning C++ for the Unreal engine. I am trying to figure out why when I use the \[\] operator on a map\<Vector2, ControlNode\> with a value that *I know* is in the map, it returns nullptr.

Here are the relevant pieces of code:

**Vector2**

```
**Vector2.h**
class MAGICGAME2D_API Vector2
{
public:
    Vector2(float x, float z);
    Vector2();
    float X;
    float Z;

public:
    friend bool operator< (const Vector2& c1, const Vector2& c2);

};

**Vector.cpp**
bool operator< (const Vector2& c1, const Vector2& c2)
{
    return (c1.X < c2.X ||
        c1.Z < c2.Z);
}

```

Creating the map:

```
for(auto values : *data->getAutomata()) {
    auto pos = values.first;
    shared_ptr<ControlNode> node = make_shared<ControlNode>(pos,values.second);
    controlNodes.emplace(pos,node);
}

```

And this is the place I make the call to check if the value is in the map:

```
shared_ptr<ControlNode> node = (*(*data).getControlNodes())[pos];

```

The data variable is a pointer, that points to an object that holds a shared\_ptrstd::map\<Vector2,shared\_ptr\<ControlNode\>\>. So that is why I am double dereferencing that part of the code.

This call to retrieve from the map acts a bit odd. Sometimes it will work. For example, where `pos = Vector2(0,0)`. But then it will fail where `pos = Vector2(0,25)`, and it will return a nullptr. The weird thing is that I have confirmed that `pos = Vector2(0,25)` is already in the map.

Is there something I am doing wrong with the call to retrieve the `shared_ptr<ControlNode>`?

# Answer
As noted in the comments, your `operator<` is wrong.

For `std::map` to function properly, the `operator<` must follow the so-called *strict weak order*. It may sound complicated, but it just means that `operator<` must produce sensible results.

With your implementation, given for example `a = Vector2(1,0);` `b = Vector2(0,1);`, both `a < b` and `b < a` return true at the same time, which doesn't qualify as "sensible results".

A proper implementation of `operator<` could look like this:

```
if (c1.X != c2.X) return c1.X < c2.X;
if (c1.Z != c2.Z) return c1.Z < c2.Z;
return false.

```

Or, the same thing but shorter:

```
return std::tie(c1.X, c1.Z) < std::tie(c2.X, c2.Z);

```
> 3 votes

---
Tags: c++, unreal
---


title: SFML test app feels slow/clunky

text:
# Question
Title: SFML test app feels slow/clunky
Similar to this question https://stackoverflow.com/questions/33904998/sfml-extremly-slow-irregular-framerate, I have created a small program to experiment with SFML

I have a very simple SFML test application on ubuntu 20.04 using SFML 2.5.1. There are three circles. One under user control and one bouncing left to right.

Problems:

* The one moving left to right is not very fast.
* Even so the one under user control cannot keep up with it.
* I am using a delta of 1 (pixel per frame?). If I increase this motion is jumpy rather than smooth.

Put simply it feels clunky. So I am assuming I've made a noob error of some kind. However, this seems to be the same basic SFML game loop commonly used. How can I make this fast and slick feeling instead?

```
#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    const float FPS = 120.0f; //The desired FPS. (The number of updates each second).
    bool redraw = true;      //Do I redraw everything on the screen?
    window.setFramerateLimit(FPS);
    sf::CircleShape shape2(100.f);
    sf::CircleShape shape(10.f);
    sf::Clock clock;
    shape2.setFillColor(sf::Color::Green);
    shape.setFillColor(sf::Color::Red);

    sf::CircleShape alien(10.f);
    alien.setFillColor(sf::Color::Yellow);
    auto alienSpeed = 1.f;

    while (window.isOpen())
    {
        sf::Event event;
        float xDelta = 0;
        float yDelta = 0;
        bool moved = false;
        if (window.pollEvent(event))
        {
           if (event.type == sf::Event::Closed)
           {
              window.close();
           }
           if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
            {
               xDelta -= 1.f;
               moved = true;
            }
            else if (sf::Keyboard::isKeyPressed(sf::Keyboard::Right))
            {
               xDelta += 1.f;
               moved = true;
            }
            if (sf::Keyboard::isKeyPressed(sf::Keyboard::Up))
            {
               yDelta -= 1.f;
               moved = true;
            }
            else if (sf::Keyboard::isKeyPressed(sf::Keyboard::Down))
            {
               yDelta += 1.f;
               moved = true;
            }
        }

        if (xDelta !=0 || yDelta != 0)
        {
           shape.move(xDelta,yDelta);
        }

        alien.move(alienSpeed, 0.f);
        if (alien.getPosition().x >= 190)
        {
           alienSpeed = -1.f;
        }
        else if (alien.getPosition().x <= 0)
        {
           alienSpeed = 1.f;
        }

        if(redraw)
        {
           window.clear();
           window.draw(shape2);
           window.draw(shape);
           window.draw(alien);
           window.display();
        }
    }

    return 0;
}

```

Note: cross posted to https://en.sfml-dev.org/forums/index.php?topic=27617.0

# Answer
Answered in the SFML forum by eXpl0it3r:

> You should not be mixing events and real-time inputs, see the dedicated tutorials.
>
> Events: https://www.sfml-dev.org/tutorials/2.5/window-events.php Real-time input: https://www.sfml-dev.org/tutorials/2.5/window-inputs.php

It is (as I thought) a noob error. `sf::Keyboard::isKeyPressed()` is not an event and does not belong inside the event processing loop. With `isKeyPressed()` outside that loop its much better. It should be:

```
    if (window.pollEvent(event))
    {
       if (event.type == sf::Event::Closed)
       {
          window.close();
       }
    }

    if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
    {
           xDelta -= 1;
    }

```
> 1 votes

---
Tags: sfml
---


# Question
Title: Is there a name for this kind of mini-game? (cursor moves on a bar, press key in part of the bar to win)
Today I played a game which has a mini-game in it, basically it looks like this:

here's a bar:

```
----------=====----------

```

and a cursor moves back and forth on it:

```
-|--------=====----------  ( cursor "|" moves in this direction -> )

-----|----=====----------

----------===|=----------

----------=====---------|  ( when the cursor reaches the end, it goes back <-)

```

If I hit a key when the cursor is on the specific part of the bar (which I used the "=" sign to represent), I win. Otherwise I lose.

This kind of mini-game is pretty common as I've seen many variant of it in a lot of games, yet I don't know the name of it. Does it have a name? What's the origin of it?

---

EDIT: There's an answer mentions QTE. Well... I'm aware of that and I don't think this mini-game belongs in that category thus I avoided using that term. Here's the reason for that:

QTEs have time limits, after all it's **Quick** time event, this kind of mini-game I'm asking about usually doesn't. Well, I've seen variations of it that does count as lose if you didn't hit the key in some amount of time, it's not the main focus of it.

Unlike how QTEs are all about testing player's reflex, this kind of mini-game is all about precision, as seen in many rhythm games. However, it doesn't necessary have any audible cue like rhythm games do, it's all about learning the pattern/speed of the moving cursor then press the key at the right time.

It's not about how quick you can press a key, but when to press the key. Hence I don't think this counts as a QTE.

# Answer
The description of this "mini-game" made me think of all the simple actions a game may ask its player to take during non-playing/cut-scene sequences. There are many forms and levels of complexity of such actions, e.g. from simply spamming buttons to the one you've described.

These are called Quicktime Events (QTE), and my guess is the "mini-game" you described may fit this category depending the context it is encoutered in. I don't know of a specific name for it though, but this might help you finding it.
> 1 votes

---
Tags: game-design, terminology
---


title: Converting shader to ShaderGraph

text:
# Question
Title: Converting shader to ShaderGraph
Is there a way to convert the below piece of shader code to shader graph? I am not sure how to find `float2(i, i)` in shader graph.

```
fixed4 frag (v2f input) : SV_Target
            {
                float2 res = _MainTex_TexelSize.xy;
                float i = _offset;

                fixed4 col;
                col.rgb = tex2D( _MainTex, input.uv ).rgb;
                col.rgb += tex2D( _MainTex, input.uv + float2( i, i ) * res ).rgb;
                col.rgb += tex2D( _MainTex, input.uv + float2( i, -i ) * res ).rgb;
                col.rgb += tex2D( _MainTex, input.uv + float2( -i, i ) * res ).rgb;
                col.rgb += tex2D( _MainTex, input.uv + float2( -i, -i ) * res ).rgb;
                col.rgb /= 5.0f;

                return col;
            }

```

# Answer
> 3 votes
This is a pretty straightforward translation.

First, let's compute the vector `(i, i) * res`, which is `(offset / texture width, offset / texture height)`:

Then we can multiply that by `(1, 1)` (no-op, so I skip that node), `(1, -1)`, `(-1, -1)`, and `(-1, 1)` to get the four shifts from our sample point, and add them to our UV to sample at those shifted positions.

We also have one sample done at our UV coordinate, with no shift applied:

Lastly, we add all five samples together, and divide by 5 to get our output:

---
Tags: unity, unity-shader-graph
---