It has been some time since my last blog post. I have spent the time between then and now reading and doing various things. I have decided to engage upon the Epic Project; putting all that reading and doing (mostly experimenting and learning by hands on experience) to some practical use. The Epic Project is the creation of a full fledged commercial quality (hopefully) video game.
The purpose of this blog post and further ones is to convey thoughts on the things I encounter as I develop the Epic Project for a few reasons. One, I am hoping to garner some attention in the project. Two, maybe I will get some helpful advice. Three, maybe I'll get some encouragement. Four, I find that typing (or whatever form of communication) helps me to work problems out. I have found myself solving more than one problem as I am explaining my problem to someone. More than once I had an answer to a problem before I got done explaining it. Onward to the Epic Project!
Side Note: After typing for some time this post has become pretty stream of consciousness (as I often tend to do). I will/have go/gone over it a few time to try to clean it up but if it doesn't make much sense I apologize in advance. Also, I write some things in 'code' so if it doesn't make sense I apologize for that as well.
To be honest, I have already started, but I am going to restart the project. It is still in it's wee infancy so I'm not really losing any ground. The reason I restarted has to do simply with one thing: entities.
An entity, to me at least ( you will find much debate over what an entity is), is anything in the game the player can interact with in some way. Even if it is simply the background image that does nothing but sit there and be displayed; the player interacts with it by viewing it, therefore it is an entity.
The reason I'm restarting is because of the way I decided to handle them. There are two methods, and much grey area between them, of how to handle entities. On one end you have the regular object-oriented method. This involves classes (in C++ which is what I program in) for the various different objects and inheriting them and so on and so forth. The other side of the spectrum is called many things, some of them being data oriented or component based. There are also many hybrids of the two.
I had started out with what I consider to be a hybrid of the two. I was utilizing classes, but not in some of the inane (in my opinion at least) examples of what has been done in the past (dear god I hope not because they are awful). An example (of something awful) I saw was that of a car object inheriting an engine object. It makes no sense logically. A car is not an engine, a car has an engine. It would make much more sense for the car object to contain an instance of the engine object. The car would then tell the engine what to do in some manner, and the engine would respond to the commands it is given. It's logical. However, from what I've read, it can get quite messy as the number of entities increase and as you get more entities that are similar but not quite similar enough (one example I've read was a werewolf and a regular wolf, similar but not quite similar enough).
That is the approach I was doing at first, which I consider to be a hybrid (based on examples I've read). It is composition and object oriented at the same time. However, and this is what got me thinking of going further down the other side of the spectrum, I would encounter objects that I thought of making into their own class and just have a pointer from the object that would contain it to the relevant data and then I would have a centralized function that would take the data and use it to take the appropriate action.
This system was no mystery to me; I had read about it multiple times. However, what was a mystery to me was how to actually go about implementing such a system. It is such a foreign concept and it is so loosely connected that it is hard to wrap your head around (though that loose connection is actually one of it's main benefits and a very good thing in writing programs). It was that line of thinking with the object (an animated image object to handle displaying the correct portion of a sprite sheet) that got me started down the path of working this thing out logically in my head.
That sort of system would also work fine for a small number of things that aren't going to change. It's also faster to get things working as it requires less work up front.
However, if you have a lot of things and plan for things to change a lot and over time and wish to be able to add new things in the future easily, that is where component based entities come in.
The component based entities (which is what I'm going to call it) instead goes about handling entities completely differently, and each implementation of it is different. Overall though, you have two sides of the system: components and systems. Components are data and systems are logic. Systems use and manipulate the data in components that they care about. For example, if you have something that has an image component so it can be shown on the screen, the component would be the information for the image. The rendering system would then draw all image components on the screen. So if you wanted your entity to get drawn to the screen, you would simply add an image component and fill the data in the component with the data of the image you wanted the entity to have.
It has the distinct advantage of having only one real instance of functions. In the above example, all of the data is stored in a component and given to the rendering system, which contains all of the functions for rendering an image to the screen.
This allows you to create any sort of entity by defining what components make it up. You could turn a heat seeking missile into a pollen seeking bee by simply removing some components and adding some others. For this example, you would need to change its' image component data from that of a missile to that of a bee. You would then have to change its' target component data from heat to pollen. You just transformed a heat seeking missile into a pollen seeking bee ( in a crude way). You could then kill the bee by making it's health component zero and turning it's image into a corpse. You could then turn this into a zombie bee by changing its image into a zombie bee and changing its' target to brains. You just turned a heat seeking missile into a brain seeking zombie bee. That's the idea in rough terms. The devil of this system is in the details.
One detail is system communication. Ideally, one system shouldn't give to cents of care (to use friendly language, much harsher was planned but deleted) about what goes on in another system. However, some of the things are inherently linked together. For example, the missile turned bee would be drawn in the same spot all the time if its' position was never updated. Somehow you have to communicate the position of the entity to the rendering system so the rendering system can place the missile/bee where it actually is. A lot of this could be done through a simple function, such as Draw(entity, position). Utilizing a messaging or event system of some sort is usually required. I'll follow the YAGNI (you ain't gonna need it) principle here and develop what I need when I need and not before (unless it's blazing obvious I'm going to). At least, that's how I take YAGNI to mean.
Another detail is defining an entity. Some make an entity the container of components. This makes sense. You need something to related the components together so you know what position component relates to what image component other wise you would get bees drawn where there should be missiles and cats drawn where there should be brains. It is also closely related to an object oriented method of doing things. However, I'm going to other extreme ( as I'm wont to do which should be obvious if/when/once the scale of my game comes to light) and an entity is merely a unique ID of some sort. The ID is what binds all the components together.
My plan is to have components be constructed in a map object (probably an unordered map because they are faster to parse through). When a component gets added to an entity, it will simply look at that component's map storage, create the new entry and fill in the data. Boom, component added.
This will mean that the image stored at imageComponents[123573] would be drawn with position that is stored in positionComponent[123573]. The example I gave above of function of Draw(entity,position) would then look like Draw( 123573, positionComponent[123573] ).
You also have to order your systems operations in the correct sequence. You would not want to run your function for drawing, then change positions, and then determine what you should change positions to. You would want to determine positions changes, make the changes, and then draw the objects.
At any rate, this long winded post needs to end sometime and that time shall be now for no other reason than I declare it to be so.
Sunday, April 7, 2013
Sunday, April 29, 2012
How do you prevent inflation in a virtual economy?
This started off as a simple answer to the question in the title, but ballooned into something way bigger than I originally planned, so I decided to post it here so that I could share it.
To solve a problem, you must first understand the problem. So let's talk about and define the problem.
Inflation is an increase in the money supply.
Deflation is a decrease in the money supply.
The money supply is the total amount of money available in the world.
Money is not necessarily a currency. Money is really whatever thing is easiest to trade; IE the most liquid asset. These definitions hold true in any economy, real or virtual.
Rising prices over all things is a symptom of inflation, it is not inflation itself. The reason inflation causes a rise in prices is because as the amount of money available increases, the demand for an individual unit of money decreases, thus, its' value goes down and therefore it takes more of said money to purchase something.
The opposite is true. Decreasing prices over all things are a symptom of deflation. If the amount of money available goes down, the demand for an individual unit of money increases, thus, its' value goes up and therefore it takes less of said money to purchase something.
In a game, the money supply increases ANYTIME something from the game gives money to a player, any player. Completed a quest and got a monetary reward? Inflation! Sold that trash item to an NPC? Inflation! The total amount of money available to players goes up.
In a game, the money supply decreases ANYTIME something from the game takes money from a player. This causes the money to vanish from the players' collective hands. Bought an item from an NPC? Deflation! Paid that NPC to repair your items? Deflation! No player will ever have access to that money ever again.
Player to player transactions do not affect the money supply at all. It just shifts part of the big pile around; it does not add or subtract from it. It changes the individuals' in question money supplies, but not the total amount of money available to all players. The player that received money in the transaction could then trade that money to another player.
Inflation and deflation are problems because it changes the way the players interact with the game. The game has points where the money interactions are fixed. Inflation can trivialize these interactions, and deflation can monumentalize these interactions.
Inflation can also cause problems for newer players. They typically enter the game with no money. Inflation causes their financial interactions with NPC's to be less valuable than when the game was new. This requires the new player to have more positive NPC financial transactions to purchase something of worth from another player because the other players value the money less than the NPC's do. Player's need more money in order to interact financially with other players than they would if they interacted with the NPC's.
To counter inflation and deflation the money supply must remain as fixed as possible.
One way to do this is to have money going into the supply be equal to money coming out of the supply. If someone receives X amount of money from an NPC, someone somewhere else gives an NPC X amount of money. X came in and then X went out. This has problems in that you cannot insure that events going on in the game over time will balance the equation. It could be that players are selling more items to NPC's than they are buying and they are not utilizing the NPC services enough. Thus, you have gradual inflation.
Another way is to have a fixed amount of money possible. All funds going out of the system to players comes from a large pool in the system. If the money runs out then the system cannot inject more money into the supply available to players. This has problems because you cannot insure that the system won't run out of money. It also raises the question, what does the game do when the NPC's have run out of money? Make more money and do the transaction anyways? It carries the same problems as above; there is no way to guarantee long term ( I prefer infinite) stability. If players are selling to NPC's more than they are buying, then eventually the NPC's will run out of money. Then you end up with lots of annoyed players with heaps of trash items and no recourse other than to trash the trash. This is a waste of player and system resources at this point. A good design should work for infinity.
Well, we could have the NPC's adjust their prices and offers based on the amount in question. If the amount of money available to NPC's is low, then they will offer less money when buying things and demand more money when selling things. This still doesn't guarantee the system won't break. It is still possible for the system to run out of money. It would just take a longer time to do so. If the overall trend is players selling to NPC's, it WILL run out of money.
If the NPC supply of money is very low, NPC's will be buying things from players for very low amounts of money and be selling them for very high amounts of money. The money couldn't be divided any lower than the smallest unit of currency, so eventually everything sold to NPC's would get the player 1 unit of currency, no matter if it were a grain of sand or the mightiest, most epic item in the game. And it would eventually run out of money still.
If the NPC supply of money is very high, NPC's will then be buying things from players for very high prices and be selling them for very low prices. Wait.... what? This clearly isn't going to work. In this situation, all players would clearly flock to the nearest NPC vendor, buy something, and then sell it back, over and over until the price equalized.
Instead of having the relation be inversed, why not just have it be that as the amount of money in the game goes up this causes NPC's to offer more money AND demand more money. This solves the problem of newer players combating inflation and it adjusts the prices of things from NPC's so that the financial scale of them remains as the developer intended. However, this also doesn't work because it causes the inflation gains to exponentially increase.
As the amount of money in the game increases, NPC's increase the amount of money they give out so that the value of what they give out is the same over time, and they also ask for more money as the money supply increases to cause a larger decrease in the larger money supply. However, the problem still remains of what if the player's are selling more than they are buying. If this is the case (which it is out of necessity in any game, I'll get to that), then this solution only causes the eventual inflation to come faster because as the inflation grows, so does the rate at which it grows. This will cause a break in the game as you can only have a number be so big in a computer system before the system says, nope, no more, and crashes, or flips itself into the maximum negative value (assuming that the data is signed, but why would you do that anyways).
Inflation is, however, a necessary evil in a game world where the number of players present in the world can grow. If there were no inflation, then eventually the game would be destroyed by deflation. If the amount of money were fixed, then as the number of players increases, the value of the money would also increase in the eyes of each individual player. Each player would have less of the total supply. Well, what happens if the amount of money available isn't enough to support the number of players you have? Remember, you can't subdivide your smallest unit of currency, there IS a minimum. You would get to the point that each player would have 1 unit of currency, or very close to it, without inflation. This means that all items would be valued at or very close to 1 unit of currency. Your rusted knife carries the same value with another player as the epic sword of doom. In effect, the economy would come to a grinding halt as no one is able to effectively transact. All value gets tossed out of the window. This isn't a problem in the real world because we are always making newer, more valuable things and making less valuable things more valuable through improvements. This is a lot harder for the players to do in a game environment without causing other problems in the game.
I will now identify the real problem.
NPC's.
This is the source of all woes. NPC's. The reason these guys are to blame is because they are stupid. They cannot make any decisions for themselves. They are static. Players are dynamic. You can't have a dynamic system influenced by a static system and treat them as separate systems. If one system is altered by another system, they are necessarily part of the same system. The static system will break the dynamic system or the dynamic system will break the static system.
In the above section, where I talked about improving items, it is again NPC's and their static nature that causes trouble. If there were no static NPC and players interacted with only other players, allowing player's the ability to enhance items sufficiently to make them more valuable would be OK since all players would have the ability to utilize the improved items. This article assumes there are NPC's.
NPC's are necessarily static because they can't make decisions for themselves. They can make pseudo decisions based on what they are told is valuable. They can even decide to change their values based on logic they are given. The one thing they can't do however is make their own logic. There is a name for a computer system that make its own logic and that is true AI (cue The Terminator theme song). That's the real difference between a person and a computer. We can change our logic whenever we feel like, a compute can only change its' logic when it's told to.
You could program some good AI that could stretch you game's economic life for a very long time, but if it is carried out infinitely, it will break because of NPC's.
It's not this directly though. This static nature forces the programmer to have a predictable method of financial interaction with the players, who by their nature as a living being is unpredictable. You can make reasonable assumptions, but you cannot ever say with 100% certainty what someone will do for any given circumstance.
The need for a predictable nature of interaction because of the nature of programming a computer forces the developers to create a static, knowable medium of exchange between the NPC's and the players, a hard coded currency. THAT is the real culprit.
What do we do about this? Remove NPC's? That's one solution and I've come up with an idea for a MMO that does just that in my spare time for fun. The answer is, follow the money. It's ALWAYS about the money!
Players need the NPC's in normal games because they start, usually, with nothing. Zip, nada, zilch. Nothing but moths in their pockets. A necessary thing to otherwise players could just get rich by making new characters and giving the new characters money to their desired character, ad infinitum.
Since no one starts with money, then the only way to get money is by getting it from the system, NPC's. Not just the guys in the store either, enemies count too.
Players could use items they get from enemies they kill as money, trading items that drop off enemies for other items that also dropped off enemies, and that would work. But if there is any sort of limit (and there is) this could get messy. This is what will have to happen, players using resources they get from the world to trade with (cause hey, guess what, that's how it works in real life as well). Let's talk about money for a moment, and what makes a money good.
First, anything can be money. However, society will gravitate towards certain things being money naturally, as long as something like government doesn't dictate what will be money (This is actually exactly the real world analogue of the virtual world. The programers dictate what is to be money and have sole control over its creation. Governments tend to dictate what is to be money and have sole control over its creation. And in both instances, they will eventually break the economy because of it.)
The characteristics of good money are as follows:
In most prisons, or at least how most people think of prisons, cigarettes are money. They are a good money at that.
It is the above reasons that made cigarettes money in prison. Plenty of people want them since a lot of people in prison smoke apparently. Even a non-smoker would want them because they know they could use it to get something from the smokers.
Now, lets look at an example of bad money. The good ol' U.S. dollar. A terrible money. It is bad money because of the last reason. Their only purpose is to facilitate financial transaction. They don't have any value beyond that. Their value lies in the fact that (for now at least) you can reasonably expect someone else to accept the dollar so you accept it in exchange. However, if people stop accepting it in exchanges, what can do with it? I'll show you:
And even then, toilet paper would get the job done better and without clogging your toilet.
In the cigarette example, if prisoners stopped accepting cigarettes you could still do something valuable with it, like smoke it.
The currency in games falls victim to this same failing; it has no value outside of facilitating exchange.
So, to recap so far (this is a lot longer than I originally thought it would be, but such is the subject matter!). Economies in games break because of the nature of the NPC's.It is the static nature and the need to have a known, predictable means of interaction with NPC's that creates the need for an environment that is going to inflate itself until it breaks. So what do we do about it?
Get rid of the financial interactions with NPC's. This will put the power of money creation in the hands of the players. If one money turns bad, they will be able to adopt another one.
Sounds extreme, but that's what needs to be done to make an economic system that will not break.
Firstly, treat money as an item no different than a suit of armor or a sword or a gun. In reality, it isn't different. Money is a thing that can be traded no differently than a piece of armor or a sword in the real world. It is treating money as something different that causes the break to begin with.
Coinage is a good money. It has a high value density (lots of value without having to carry a lot of it around). Coinage doesn't have to be money. Money could also be jewels or jewelry for the same reason. It's not as easily divisible as coinage, but it has a good value density.
However, coinage itself would not be money, but rather the type of coin. A copper coin would not (and should not) have a fixed exchange against the silver and gold coin. A player would not automatically convert a silver coin into a gold coin just because he got 100 silver coins. Each type of coin would maintain their own inventory space. The player could have 853 copper coins, 245 silver coins, and 103 gold coins. Their exchange rate would depend on the value of copper, silver, and gold in the total market place. This would depend on some concrete things as well as some abstract things.
For instance, how many gold coins does it take to make a gold bar? What is the value of the things that can be made out of a gold bar? How do these compare to the same aspects of silver and copper? The programmers only need to worry about the concrete things. The players are the ones that need to worry about the abstract things.
Thus, it is important that as many things as possible in the game can be reverted back into their respective components, when it makes sense. For instance, if I have a magical ring, it would make sense for me to be able to take out the gems and melt the metal down. I could then trade the gems and the resulting metal for something else, or use them to make something else. This allows for the fluidity needed to facilitate the dynamic nature of this economic model. It allows the players to self regulate the valuation of things in the economy. When a coin's value drops to the point that the bar is worth more than the coins it could make, the players could turn the coins back into a bar and sell the bar. This could occur because something that you need a bar to make wouldn't let you use coins to make it. The coins would need to be turned into a bar and then the bar turned into the new item.
But, are we trading monetary inflation for price inflation? Perhaps. As something goes down in value, players will make less of it or harvest less of it. One item that goes down in value can get turned into something of higher value. It will be necessary for items to be consumed in some manner, such as breaking from use or just being outright consumed, such as ingredients when making a potion or doing an enchantment. There could also be inefficiencies involved in transformations and creation to represent waste. And other items will not be able to be transformed at all. Some items would also not be able to be traded.
NPC's should also not give monetary rewards, because it's impossible for it to know what the current money is. Instead, it should give generic items out in its place or experience, or anything else other than a monetary award, or anything that resembles a monetary award. Instead of gold coins, give out a gold nugget or a gold bar.
Gone also are NPC's vendors. Instead, players would be the suppliers of everything. NPC's vendors would instead act as brokers. They would be a list of players trying to sell and buy things. A player could list something as being for sale and what they want in exchange. Potential buyers could try to offer something else for the item. The seller would then have the option of accepting or denying the offer. It could, for the sake of ease, have an automatic message and the player could respond to the offer remotely without having to go visit the broker NPC. You could have an auction for the item and players bid in units of whatever the seller is looking for. This will most often be whatever is being used for money. It could sometimes be something else, but most of the time it will be the current money of the world, that's why there is money! Money exists to facilitate exchange. It's bartering but one side of the barters are always the same thing, MONEY! You might have a pig and need a cow, but you can't find anyone that wants a pig and is willing to give you a cow. I bet you could find someone willing to give you money for your pig and someone willing to give you a cow for money. What the money is doesn't matter.
NPC offering services, such as armor repair, could instead be made into extensions of players with those skills, and players could offer those services directly. The game could provide a player with the ability to turn themselves into an automated repair vendor by setting a rate of X amount of effort for Y units of Z item.
This system has some problems of its own, namely that it increases complexity and possibly makes some things less convenient. However, I think the bonuses of having a truly dynamic economy and the extra robustness and options for players in the crafting/industry sector of the game it would force developers to make far greatly outweigh those things.
So how do you prevent inflation in virtual economies? You decouple as much as possible the dynamic players from the static system. Give ALL economic power to the players. It must exist solely in the hand of the player's collective hands for long term stability.
To solve a problem, you must first understand the problem. So let's talk about and define the problem.
Inflation is an increase in the money supply.
Deflation is a decrease in the money supply.
The money supply is the total amount of money available in the world.
Money is not necessarily a currency. Money is really whatever thing is easiest to trade; IE the most liquid asset. These definitions hold true in any economy, real or virtual.
Rising prices over all things is a symptom of inflation, it is not inflation itself. The reason inflation causes a rise in prices is because as the amount of money available increases, the demand for an individual unit of money decreases, thus, its' value goes down and therefore it takes more of said money to purchase something.
The opposite is true. Decreasing prices over all things are a symptom of deflation. If the amount of money available goes down, the demand for an individual unit of money increases, thus, its' value goes up and therefore it takes less of said money to purchase something.
In a game, the money supply increases ANYTIME something from the game gives money to a player, any player. Completed a quest and got a monetary reward? Inflation! Sold that trash item to an NPC? Inflation! The total amount of money available to players goes up.
In a game, the money supply decreases ANYTIME something from the game takes money from a player. This causes the money to vanish from the players' collective hands. Bought an item from an NPC? Deflation! Paid that NPC to repair your items? Deflation! No player will ever have access to that money ever again.
Player to player transactions do not affect the money supply at all. It just shifts part of the big pile around; it does not add or subtract from it. It changes the individuals' in question money supplies, but not the total amount of money available to all players. The player that received money in the transaction could then trade that money to another player.
Inflation and deflation are problems because it changes the way the players interact with the game. The game has points where the money interactions are fixed. Inflation can trivialize these interactions, and deflation can monumentalize these interactions.
Inflation can also cause problems for newer players. They typically enter the game with no money. Inflation causes their financial interactions with NPC's to be less valuable than when the game was new. This requires the new player to have more positive NPC financial transactions to purchase something of worth from another player because the other players value the money less than the NPC's do. Player's need more money in order to interact financially with other players than they would if they interacted with the NPC's.
To counter inflation and deflation the money supply must remain as fixed as possible.
One way to do this is to have money going into the supply be equal to money coming out of the supply. If someone receives X amount of money from an NPC, someone somewhere else gives an NPC X amount of money. X came in and then X went out. This has problems in that you cannot insure that events going on in the game over time will balance the equation. It could be that players are selling more items to NPC's than they are buying and they are not utilizing the NPC services enough. Thus, you have gradual inflation.
Another way is to have a fixed amount of money possible. All funds going out of the system to players comes from a large pool in the system. If the money runs out then the system cannot inject more money into the supply available to players. This has problems because you cannot insure that the system won't run out of money. It also raises the question, what does the game do when the NPC's have run out of money? Make more money and do the transaction anyways? It carries the same problems as above; there is no way to guarantee long term ( I prefer infinite) stability. If players are selling to NPC's more than they are buying, then eventually the NPC's will run out of money. Then you end up with lots of annoyed players with heaps of trash items and no recourse other than to trash the trash. This is a waste of player and system resources at this point. A good design should work for infinity.
Well, we could have the NPC's adjust their prices and offers based on the amount in question. If the amount of money available to NPC's is low, then they will offer less money when buying things and demand more money when selling things. This still doesn't guarantee the system won't break. It is still possible for the system to run out of money. It would just take a longer time to do so. If the overall trend is players selling to NPC's, it WILL run out of money.
If the NPC supply of money is very low, NPC's will be buying things from players for very low amounts of money and be selling them for very high amounts of money. The money couldn't be divided any lower than the smallest unit of currency, so eventually everything sold to NPC's would get the player 1 unit of currency, no matter if it were a grain of sand or the mightiest, most epic item in the game. And it would eventually run out of money still.
If the NPC supply of money is very high, NPC's will then be buying things from players for very high prices and be selling them for very low prices. Wait.... what? This clearly isn't going to work. In this situation, all players would clearly flock to the nearest NPC vendor, buy something, and then sell it back, over and over until the price equalized.
Instead of having the relation be inversed, why not just have it be that as the amount of money in the game goes up this causes NPC's to offer more money AND demand more money. This solves the problem of newer players combating inflation and it adjusts the prices of things from NPC's so that the financial scale of them remains as the developer intended. However, this also doesn't work because it causes the inflation gains to exponentially increase.
As the amount of money in the game increases, NPC's increase the amount of money they give out so that the value of what they give out is the same over time, and they also ask for more money as the money supply increases to cause a larger decrease in the larger money supply. However, the problem still remains of what if the player's are selling more than they are buying. If this is the case (which it is out of necessity in any game, I'll get to that), then this solution only causes the eventual inflation to come faster because as the inflation grows, so does the rate at which it grows. This will cause a break in the game as you can only have a number be so big in a computer system before the system says, nope, no more, and crashes, or flips itself into the maximum negative value (assuming that the data is signed, but why would you do that anyways).
Inflation is, however, a necessary evil in a game world where the number of players present in the world can grow. If there were no inflation, then eventually the game would be destroyed by deflation. If the amount of money were fixed, then as the number of players increases, the value of the money would also increase in the eyes of each individual player. Each player would have less of the total supply. Well, what happens if the amount of money available isn't enough to support the number of players you have? Remember, you can't subdivide your smallest unit of currency, there IS a minimum. You would get to the point that each player would have 1 unit of currency, or very close to it, without inflation. This means that all items would be valued at or very close to 1 unit of currency. Your rusted knife carries the same value with another player as the epic sword of doom. In effect, the economy would come to a grinding halt as no one is able to effectively transact. All value gets tossed out of the window. This isn't a problem in the real world because we are always making newer, more valuable things and making less valuable things more valuable through improvements. This is a lot harder for the players to do in a game environment without causing other problems in the game.
I will now identify the real problem.
NPC's.
This is the source of all woes. NPC's. The reason these guys are to blame is because they are stupid. They cannot make any decisions for themselves. They are static. Players are dynamic. You can't have a dynamic system influenced by a static system and treat them as separate systems. If one system is altered by another system, they are necessarily part of the same system. The static system will break the dynamic system or the dynamic system will break the static system.
In the above section, where I talked about improving items, it is again NPC's and their static nature that causes trouble. If there were no static NPC and players interacted with only other players, allowing player's the ability to enhance items sufficiently to make them more valuable would be OK since all players would have the ability to utilize the improved items. This article assumes there are NPC's.
NPC's are necessarily static because they can't make decisions for themselves. They can make pseudo decisions based on what they are told is valuable. They can even decide to change their values based on logic they are given. The one thing they can't do however is make their own logic. There is a name for a computer system that make its own logic and that is true AI (cue The Terminator theme song). That's the real difference between a person and a computer. We can change our logic whenever we feel like, a compute can only change its' logic when it's told to.
You could program some good AI that could stretch you game's economic life for a very long time, but if it is carried out infinitely, it will break because of NPC's.
It's not this directly though. This static nature forces the programmer to have a predictable method of financial interaction with the players, who by their nature as a living being is unpredictable. You can make reasonable assumptions, but you cannot ever say with 100% certainty what someone will do for any given circumstance.
The need for a predictable nature of interaction because of the nature of programming a computer forces the developers to create a static, knowable medium of exchange between the NPC's and the players, a hard coded currency. THAT is the real culprit.
What do we do about this? Remove NPC's? That's one solution and I've come up with an idea for a MMO that does just that in my spare time for fun. The answer is, follow the money. It's ALWAYS about the money!
Players need the NPC's in normal games because they start, usually, with nothing. Zip, nada, zilch. Nothing but moths in their pockets. A necessary thing to otherwise players could just get rich by making new characters and giving the new characters money to their desired character, ad infinitum.
Since no one starts with money, then the only way to get money is by getting it from the system, NPC's. Not just the guys in the store either, enemies count too.
Players could use items they get from enemies they kill as money, trading items that drop off enemies for other items that also dropped off enemies, and that would work. But if there is any sort of limit (and there is) this could get messy. This is what will have to happen, players using resources they get from the world to trade with (cause hey, guess what, that's how it works in real life as well). Let's talk about money for a moment, and what makes a money good.
First, anything can be money. However, society will gravitate towards certain things being money naturally, as long as something like government doesn't dictate what will be money (This is actually exactly the real world analogue of the virtual world. The programers dictate what is to be money and have sole control over its creation. Governments tend to dictate what is to be money and have sole control over its creation. And in both instances, they will eventually break the economy because of it.)
The characteristics of good money are as follows:
- It is easily portable
- It has a high value density
- It is easily divisible
- It is relatively scarce
- It is useful in and of itself beyond facilitating financial transactions
In most prisons, or at least how most people think of prisons, cigarettes are money. They are a good money at that.
- They are easy to carry
- Their value is high relative to their size
- You can easily divide them. A single cigarette could be cut in half or what have you
- Not everyone has access to cigarettes or can easily make them
- You can smoke a cigarette.
It is the above reasons that made cigarettes money in prison. Plenty of people want them since a lot of people in prison smoke apparently. Even a non-smoker would want them because they know they could use it to get something from the smokers.
Now, lets look at an example of bad money. The good ol' U.S. dollar. A terrible money. It is bad money because of the last reason. Their only purpose is to facilitate financial transaction. They don't have any value beyond that. Their value lies in the fact that (for now at least) you can reasonably expect someone else to accept the dollar so you accept it in exchange. However, if people stop accepting it in exchanges, what can do with it? I'll show you:
And even then, toilet paper would get the job done better and without clogging your toilet.
In the cigarette example, if prisoners stopped accepting cigarettes you could still do something valuable with it, like smoke it.
The currency in games falls victim to this same failing; it has no value outside of facilitating exchange.
So, to recap so far (this is a lot longer than I originally thought it would be, but such is the subject matter!). Economies in games break because of the nature of the NPC's.It is the static nature and the need to have a known, predictable means of interaction with NPC's that creates the need for an environment that is going to inflate itself until it breaks. So what do we do about it?
Get rid of the financial interactions with NPC's. This will put the power of money creation in the hands of the players. If one money turns bad, they will be able to adopt another one.
Sounds extreme, but that's what needs to be done to make an economic system that will not break.
Firstly, treat money as an item no different than a suit of armor or a sword or a gun. In reality, it isn't different. Money is a thing that can be traded no differently than a piece of armor or a sword in the real world. It is treating money as something different that causes the break to begin with.
Coinage is a good money. It has a high value density (lots of value without having to carry a lot of it around). Coinage doesn't have to be money. Money could also be jewels or jewelry for the same reason. It's not as easily divisible as coinage, but it has a good value density.
However, coinage itself would not be money, but rather the type of coin. A copper coin would not (and should not) have a fixed exchange against the silver and gold coin. A player would not automatically convert a silver coin into a gold coin just because he got 100 silver coins. Each type of coin would maintain their own inventory space. The player could have 853 copper coins, 245 silver coins, and 103 gold coins. Their exchange rate would depend on the value of copper, silver, and gold in the total market place. This would depend on some concrete things as well as some abstract things.
For instance, how many gold coins does it take to make a gold bar? What is the value of the things that can be made out of a gold bar? How do these compare to the same aspects of silver and copper? The programmers only need to worry about the concrete things. The players are the ones that need to worry about the abstract things.
Thus, it is important that as many things as possible in the game can be reverted back into their respective components, when it makes sense. For instance, if I have a magical ring, it would make sense for me to be able to take out the gems and melt the metal down. I could then trade the gems and the resulting metal for something else, or use them to make something else. This allows for the fluidity needed to facilitate the dynamic nature of this economic model. It allows the players to self regulate the valuation of things in the economy. When a coin's value drops to the point that the bar is worth more than the coins it could make, the players could turn the coins back into a bar and sell the bar. This could occur because something that you need a bar to make wouldn't let you use coins to make it. The coins would need to be turned into a bar and then the bar turned into the new item.
But, are we trading monetary inflation for price inflation? Perhaps. As something goes down in value, players will make less of it or harvest less of it. One item that goes down in value can get turned into something of higher value. It will be necessary for items to be consumed in some manner, such as breaking from use or just being outright consumed, such as ingredients when making a potion or doing an enchantment. There could also be inefficiencies involved in transformations and creation to represent waste. And other items will not be able to be transformed at all. Some items would also not be able to be traded.
NPC's should also not give monetary rewards, because it's impossible for it to know what the current money is. Instead, it should give generic items out in its place or experience, or anything else other than a monetary award, or anything that resembles a monetary award. Instead of gold coins, give out a gold nugget or a gold bar.
Gone also are NPC's vendors. Instead, players would be the suppliers of everything. NPC's vendors would instead act as brokers. They would be a list of players trying to sell and buy things. A player could list something as being for sale and what they want in exchange. Potential buyers could try to offer something else for the item. The seller would then have the option of accepting or denying the offer. It could, for the sake of ease, have an automatic message and the player could respond to the offer remotely without having to go visit the broker NPC. You could have an auction for the item and players bid in units of whatever the seller is looking for. This will most often be whatever is being used for money. It could sometimes be something else, but most of the time it will be the current money of the world, that's why there is money! Money exists to facilitate exchange. It's bartering but one side of the barters are always the same thing, MONEY! You might have a pig and need a cow, but you can't find anyone that wants a pig and is willing to give you a cow. I bet you could find someone willing to give you money for your pig and someone willing to give you a cow for money. What the money is doesn't matter.
NPC offering services, such as armor repair, could instead be made into extensions of players with those skills, and players could offer those services directly. The game could provide a player with the ability to turn themselves into an automated repair vendor by setting a rate of X amount of effort for Y units of Z item.
This system has some problems of its own, namely that it increases complexity and possibly makes some things less convenient. However, I think the bonuses of having a truly dynamic economy and the extra robustness and options for players in the crafting/industry sector of the game it would force developers to make far greatly outweigh those things.
So how do you prevent inflation in virtual economies? You decouple as much as possible the dynamic players from the static system. Give ALL economic power to the players. It must exist solely in the hand of the player's collective hands for long term stability.
Subscribe to:
Posts (Atom)