Designing an in game economy

📝In this article, we cover:

• An introduction to basic game economy concepts
• How design decisions can impact the economy

Economic openness

The openness of a project's economy refers to how easily external parties can participate without participating in the game. Generally, the easier it is for an external party to participate, the more difficult it is to manage the economy.

Here are three examples:

1. Closed economies
2. Open economies
3. Hybrid economies

Closed economies can only be participated in by players. This is common in Web2 games, where assets and markets are locked within the game. These are the easiest to control as no external forces are acting on them; however, incentives between players and game providers are not aligned.

Open economies can be participated in by everyone. Everything is tokenized and tradeable in the outside world. These align incentives between players and game providers, however, are difficult to control since the economy is exposed to external parties (e.g. non-players can buy any asset that a player could earn).

Hybrid economies have some open (on-chain) and some closed (off-chain) elements. Off-chain resources can only be generated by playing the game, and external parties cannot buy these resources. An example is Gods Unchained, where Flux is an untradeable resource earned by playing, which can be used to upgrade NFT cards (or mint NFTs from off-chain cards). Hybrid economies are more complex to design, however, receive benefits from both worlds - off-chain elements can be used to manage the economy, while on-chain means that incentives are aligned between players and providers.

Sinks & Sources

If the net outflow of value exceeds the net inflow in your project, then the value of a game's economy will trend to zero. Early on, player growth and the potential for value extraction can defer this, and even simple games built with poor tokenomics can see short-term success. However, to achieve medium- and long-term success, a game must consider sinks and sources in its design.

Sinks are ways to spend or burn a token within the game economy. Sinks are alternatives to selling a token and compete against the financial incentive to sell. Sinks could increase earn rates (e.g. upgrading an NFT), give status (e.g. unlocking collectibles), or provide other utility (e.g. lotteries for rare items, gambling, etc.). If all sinks in a game increase earn rates, then inflation is deferred but increased in magnitude. Examples:

• Crafting - Spend tokens to create or repair items
• Collectibles - Spend tokens to acquire collectible items (e.g. cosmetics)
• Content - Spend tokens to unlock content

Sources (or faucets) are ways to attain a token. This can be through in-game staking, winning, or participation in various activities. Examples:

• Dailies - Complete daily activities to generate tokens
• Quest rewards - Complete certain tasks to generate tokens
• Competition - Beat other players to generate tokens

Sinks can also have different impacts depending on the user. Thus, it is important to design a range of sinks. While players are primarily motivated by enjoying the game, some may want to be on top of the leaderboard, while others may want to obtain rare cosmetic items. On the flip side, earners will benefit more from sinks that reduce value extraction (e.g. spending tokens to repair items).

Additional in-game interactions

Pay to win

A common critique of financialised games is that players can spend money instead of playing the game to overplay other players and destroy the game balance. Some approaches to address this include tokenizing items that do not impact gameplay (e.g. skins), or creating game elements that can only be obtained by engaging with the game.

Tokenizing inputs and outputs

Extending on the previous point - if all outputs are tokenized then players can pay to win (e.g. buy the best gear instead of crafting it themselves). In addition to ensuring not all outputs correlate with game outcomes, games can also experiment by tokenizing the inputs (adjusting the resources required to craft the gear).

Time interactions

Some elements of an economy will evolve with time:

Economic relevance

Tokenize assets selectively and avoid anchoring value to assets. Many in-game economies are brought to life when players determine the value of assets based on their own reasoning e.g. utility or rarity.

Seasonality

Introducing new assets (e.g. a new season of cards) creates new reasons to buy and changes the meta. It builds an expectation that the economic relevance of game assets will fade over time, prevents stagnation, and reduces the ability of early adopters to dominate gameplay and value extraction. Seasonality can also be achieved with 'resets' over time, or resources that decay if not used.

Player lifecycle

In-game interactions may change as players spend more time playing the game or if the game acquires more players. For example, a source may decrease its token distribution as players level up. Or if there is a defined source pool (a set number of tokens) - the tokens earned per player may reduce as the player base grows.

Success Metrics

Before designing your economy, it's important to determine what success looks like aside from token price. Success metrics will differ for every project, and you will need to model and experiment to determine what works for you. Some examples include:

• The floor price of the collection
• Player stickiness
• Trade volume
• Token velocity - How long are players holding tokens for (either ERC721 or ERC20)

These may change depending on the project life cycle - projects may prioritize maintaining a floor price when they first start; however, as the game progresses, projects may want to improve stickiness and trading volume. Understanding user personas specific to your project will align these goals with project goals.

We've found that it's worth taking a micro view (e.g. if I make a specific change to XYZ sink, what will happen) and a macro view (e.g. what will our token distribution look like in 3 years), and attempting to model these out. Spreadsheets or online services can be used, however, the main benefit of putting numbers on a page is creating a baseline model that you can continually adapt and improve.