By Ken Griffith
Game Research
Tuesday, October 24, 2006
http://game-research.com/index.php/articles/conservation-of-objects-in-mmorpg-games/INTRODUCTION
Over the past decade as Massively Multiplayer Online Games (MMOG’s) have grown more numerous the need for a different approach to the management of “game objects” has become evident. Because an MMOG world, regardless of the genre, is populated with objects that players can take, use and trade, it is inevitable that in-game economies develop.
Unlike the real world, game objects are “virtual” and can therefore be created infinitely by the game host with zero marginal cost. This situation can create problems and limitations for the game world and its human participants.
By adopting a software model that conserves the creation of persistent objects several existing problems may be solved as well as opening the door to new possibilities for online games.
This paper sets forth an object management model that is based on theory from the disciplines of economics, financial cryptography, and sociology.
GAME-INFLATION: THE PROBLEM
Description of the Problem
A significant problem with current MM games is in-game inflation and deflation. As the game world progresses in time, the constant creation of persistent game objects in the form of regenerating NPC’s creates imbalances in the ratio of certain objects in the game relative to other objects. This problem may manifest itself in the form of skyrocketing prices of game items in terms of “game money” or the opposite (price deflation) may occur if other objects regenerate faster in the game than money objects.
Ultimately the problem is caused by the unlimited creation of persistent objects in the game world.
One example of the havoc this can create for players of the game is the case where money is so easy to come by in the game that scarcity becomes meaningless. Players buy up all of the outfitting items at the in-game merchants. Game hosts may respond to this by increasing prices in the in-game merchants to consume more money.
This creates a problem for new players because they have to kill an extremely large number of NPC’s in order to save up enough money to buy even the most basic items. In-game inflation creates an ever-widening gap between low-level players and high-level players who started playing significantly earlier.
For experienced high-level players, the game developer has to create ever-harder challenges to keep the game interesting. These high level players may end up with thousands or millions of game money units in their accounts and nothing significant to buy with it. Thus the game money decreases in utility per unit for high-level players. In fact, a cottage industry has sprung up to sell guides to players of certain games to show them how to make hundreds of thousands of game money units per week or month .
In-game inflation causes the return on time invested to decrease for low-level players as well. The number of low-level creep slayings required to save enough money to buy basic items to outfit the player tends to grow as the price index in the game rises.
As time progresses the hyperinflation becomes more pronounced until it eventually becomes a dampening factor on player enthusiasm, as well as a hindrance for recruiting new players to the game.
The Cause of the Problem
In-game inflation is caused by the fact that NPC’s in the game constantly regenerate along with various items that they carry. When PC’s kill NPC’s the players collect the items and can use them in the game. Some items will perish with use, for example those that confer “buffs” to the player character. Others, notably money, are persistent and can be exchanged in the game but not destroyed. (Unless the developer creates a money-sink in the game such as a store that sells items to players and erases the money.)
When persistent objects are created on regenerating NPC’s they will accumulate over time in the game to the point where their value falls due to the supply greatly exceeding the demand. In the case of game money this process manifests itself as in-game price inflation.
This is similar to the root problem that causes inflation the real world, except in that case it is national treasuries that constantly print new currency for use in government spending. Online gamers may find some familiarity in the situation in Germany after World War I. In 1923-27 German Reichsmarks were printed and spent by the German government in such copious quantity that it was actually cheaper to burn a wheelbarrow full of Deutschmarks in the furnace than to use them to buy fuel oil or firewood. This was the first time that the German currency suffered from raging hyperinflation. Notes were printed in denominations of 50 trillion and 100 trillion. One billion paper marks became equivalent in value to one gold mark and many families lost their life savings overnight before some form of stability was restored .
Inadequate Solutions
There are several measures that game developers can currently take to put a bandage on the problem, but these solutions ultimately require a great deal of micro-management because they do not attack the root of the problem - which is the generation of persistent objects on regenerating NPC’s.
For example one superficial approach to the inflation problem is to create money-sinks in the game, in the form of “merchants” that sell items to players for game money and then erase the game money obtained. Another form of money sink is to create new areas of the world with more merchants and items to be purchased.
Money-sinks have not proven to be very effective in controlling inflation because the number of regenerating money sources (NPC’s) greatly outnumber the practical capacity of in-game money-sinks. New areas of the game also have regenerating NPC’s that carry money, so the problem tends to accelerate with the increase of creep generation points in the game. Players generally spend more time killing NPC’s and solving quests than offloading their money at in-game merchants.
CONSERVATION OF OBJECTS
Rather than micro-managing the problems that result from a flawed object management model, it makes more sense to change the model from the very beginning of a game development project.
MMOG’s, whether for entertainment or other purposes, are inevitably simulations of certain aspects of the real world. Therefore, it makes sense to modify the game model to more closely reflect the real world in order to reduce or eliminate economic problems in the game.
Before describing the new model, let us first examine the laws of economics in the real world.
The conservation of mass and energy effectively operates in the universe so that mass and energy can be transformed but not created or destroyed. (There have been recent challenges to this theory, but for our purposes here it suffices.)
Any given sub-system in the universe may experience a net import or export of mass or energy. Energy travels faster and is easier to import and export than mass. So, taking the planet Earth as an example, we have a system where mass is effectively conserved (excepting nuclear reactions, which are negligible), but energy is effectively unlimited because of the constant import of new energy into the system. The sun and stars radiate energy that enters the Earth’s system, and the Earth and its atmosphere radiate excess energy back into space in the form of IR radiation.
The resulting biological system on earth has a constantly replenished input of solar energy. This means that biological objects (flora and fauna) have an unlimited capacity for the capture of energy, and therefore regeneration; but mineral objects are limited by their relative finite supply on the Earth.
The only effective limitation on biological activity is the availability of space and relative availability of water. This is true because the availability of bio-active trace elements and chemical building blocks is far greater than the maximum biomass that could cover the earth’s surface.
As the designers of the fictional “Matrix” found in the movie by that name, human beings like to play in virtual worlds, but we tend to be unhappy unless the world reflects the real world that we were programmed to live in. In order to translate these realities into a game model, we must recognize the difference between regenerating objects and persistent objects. Plants and animals and fuel from plants and animals are renewable resources, while metals, some minerals, and certain chemicals are finite in their supply. Certain elements and compounds are so common as to be effectively unlimited in their supply. This would include rocks, air, salt water, and in some cases fresh water.
There is a further distinction between objects that are consumed with use and those that persist. A leather jacket is effectively persistent (though in real life it will eventually wear out within one to five decades of use). A potato is perishable.
Also, in the case of the leather jacket we see that some perishable regenerating things (cows) can be converted into “effectively” persistent items, at least for the relative time scale of human beings. We see this in some game worlds where regenerating items such as polar bear skins in Everquest can be manufactured into various useful objects in the game.
The game world may mimic the real world with regard to converting perishable objects to non-perishable ones, where the only effective limitation on the creation of persistent objects from regenerating sources is the market price of the finished product. For example, if every human being in the world devoted all of his or her spare time to making denim blue jeans out of cotton fibers, the only limitation on the production of infinite blue jeans is the fact that the cotton-supply that is only limited by the arable land where cotton can be grown. However, given infinite time an infinite number of blue jeans could be created. In reality this does not happen because the price of blue jeans would fall as the supply increased.
Schema
The conservation schema for a game world should recognize two super-classes of objects: persistent and perishable. Persistent objects will be conserved while perishable items may be generated without limit in the game because they are constantly destroyed as they are used.
Here are example subclasses for each super-class:
Perishable:
· NPCs : (NPC’s exist, they die, they regenerate.)
· Products from NPC’s : Meat, hide, fur, etc.
· Fuel : (Food, drink, fuel, wood, power-ups, buffs, ammo, spells etc.)
· Vegetation (trees, bushes, logs, etc.)
Persistent:
· Money : Gold, silver, currency, etc.
· Weapons
· Armor
· Containers
· Special Items
Conservation Engine
The conservation model requires an engine that controls the creation and transfer of persistent objects according to the following rules:
1. Only the conservation engine may create new persistent objects.
2. In all other cases persistent objects can be transferred, and in some cases destroyed, but not created.
Implications
The implications of conservation of objects include:
1. Persistent objects must be recycled in the game. Therefore the game will require a mechanism to recycle persistent objects from players back to NPC’s in the game (if the game has NPC’s). For example, a rule could be made that if a player character is killed by an NPC some or all of the player character’s inventory is transferred to the NPC, or a general account for NPC’s to draw items from.
2. A conservation economy allows the option to directly correlate game objects with real-world objects. For example game money could represent and be convertible to real money, allowing a new game genre that is a hybrid between online gambling and pure entertainment MMOG’s. (This can only work for a conservation engine that is effectively spoof-proof. Otherwise, bugs in the conservation engine might allow the creation of game objects that can be “converted” to real money/objects, allowing the cheater to economically exploit, and possibly bankrupt the game system.)
ACCOUNTING
The Game Currency
The conservation of money means that there is a finite supply of money in the game world. No new money is created in the game; it is only transferred around inside the game. An additional option is to allow money to be imported and exported to and from the game world and the real world, as if the game world is a country in the real world. (This is called a “convertible money model” is covered in the paper “Convertible Money Economies for MMO Games” by the same author.)
Keeping Track of Conserved Objects
Any conservation model requires an accounting system to prevent the unlimited creation of money and other persistent objects inside the game. This is especially important for games that plan to use the convertible money model because a dupe bug could allow a player to get million gold pieces for nothing and cash them out, which would ruin the backing of the game money. These issues have already been worked out for online gaming and online digital currency systems using a set of algorithms and functions collectively referred to as “financial cryptography”. Because of the work done in these other fields the most difficult problems have already been solved, often by several completely different methods.
In order to prevent the unlimited creation of conserved objects in the game, it is necessary to control the way conserved objects are created and transferred. Developers in the field of financial cryptography have invented several methods of doing this kind of thing. One approach is the use of a “book-entry” database system that keeps track of every individual object in massive table.
The other approach to object management, that may be better suited to MMOG’s (and is much more elegant), is to use “signed digital coins” to represent objects and even player attributes (hit points, size, strength, etc.). When an object is used or transferred it is “spent” and a new coin for that object is created for the new recipient. Rather than keeping a massive central database of who owns what, the digital coin model merely maintains a “spent coin number” database to guard against double spending. Possession of a coin constitutes ownership, so the system doesn’t need to worry about who owns what until they actually use or transfer the item. This allows a game to be designed that pushes inventory management down to the client machine, but prevents cheating through the use of digital signatures on the coins.
The digital coin model is harder to understand mathematically, but it is alleged to use 1/10th the processing power and is probably better suited for MMOG’s that run on multiple linked servers . There are many papers and even patents published on digital coin systems , but none that I know of that presently apply the concept to object management in MMOG’s.
A Sample Schema for a Book-Entry Object Conservation Engine
For this paper we will simply assume a book-entry model where the game engine has a database for “persons” in the game, which can include player and non-player characters. This database contains a table for inventory where each entry has the player id and the object id type. One approach for this model is to create an additional inventory table with the same fields called “conserved objects”. Write access to this table will be limited to two functions, MINT and TRANSFER.
Each player character has an account as a “person”, and NPC’s would either have individual “person” accounts, or one master “person” account representing all NPC’s (The Creep Trust Fund). Likewise, each special conserved object would require an entry in the database with the owner_id, class_id, and quantity. Money and special objects can both be handled in the same table this way.
Your object_class table will have entries specifying the properties for each object type (class_id).
The Mint
Regardless of which accounting method is used, conserved objects in the game can only be created or destroyed by the “Mint”. The Mint is a function that adds or removes conserved items from the game world. The Mint would create the items and money to initially populate the game world with value, and occasionally to add new conserved items for the occasional balance tweak after the game has gone live, or to add new areas and objects when expanding the game.
When creating new scenarios, quests, or zones, the Mint will be used to populate the new area with persistent objects.
The Mint is much more important in a convertible system. Whenever a player or the game host imports or exports money to or from the game, the Mint function will be called.
Object Transfers
The second important function in the game accounting system will be the Transfer function.
The first practical application for in-game transfers involves what happens when a player kills an NPC. While there are several ways to approach this, here is one practical way to maintain conservation of money in the game with the least amount of database processing power.
Instead of having a different “person” account for every creep in the game, there is just one master account for all creeps and NPC’s.
When a player character gets killed some or all of his inventory items, including money, on his corpse can by picked up by other players, or the same “regenerated” player if he can get there fast enough. If no one picks up the items within a certain amount of time then any conserved items, including money, go into the creep fund. An alternative would be a master account for each class of NPC or creep. So, if a gnoll kills your character, your money goes into the gnoll account, etc.
When a player kills an NPC, a function is called that determines after the fact what items will be found on the NPC’s corpse. Suppose you set the rule so there is a 33% chance that “Creep Type X” will have 6 units of money, as well as any other non-conserved items that might randomly appear on the corpse. The function is called in the event of NPC_death, and in this case determines that this creep’s corpse should have 6 units of money. The function queries the “Creep Fund” to see if it has at least at least 6 units of money in it. If “yes”, then a Transfer is made from the Creep_Fund to that particular NPC corpse. The Transfer function should be the only function other than the Mint with “write access” to the “conserved_inventory” table, so you shouldn’t have to worry about other functions making unauthorized transfers. This control precludes the possibility of “dupe bugs” creating money from nothing. Like a player corpse, if no one loots the creep corpse in a certain amount of time then the conserved items on the corpse are transferred back into the Creep Fund and the non-conserved items are erased.
But what if the Creep Fund is empty? In that case, even though the “creep_death” function called for 6 units, the transfer is denied and no transfer takes place. The creep corpse has zero money on it. Other inventory items can be recycled in this manner as well.
This method solves the financial implications of the Dupe Bug Problem because:
1. Except for the initial outlay to populate the game world, the Creep Fund is financed entirely by player characters that get killed.
2. If a dupe bug exists, the worst thing that can happen is the player cleans out the Creep Fund. Even if the player cashes all of his game money out, the game host doesn’t lose any money and the integrity of the backing of the game money stays intact. The creep fund will be replenished soon enough by all of the newbie players getting killed on the battlefield. The game host might want to add a routine to flag players who suddenly get rich to have a human look at what the player did to see if there is a dupe bug. If a player finds a dupe bug and exploits it for money, you can be sure he will go back to the same place and do it again and again until the bug is fixed. It isn’t a serious problem as long as the game maintains the conservation of money.
This set of rules would also tend to encourage increased player cooperation. If one player gets his character killed then his buddies can guard his items or carry them with them until his regenerated character can join back up and get his stuff back. Loners would tend to loose more money and items to the Creep Fund than players that group with others.
CONCLUSION
A game schema that properly maintains the conservation of persistent objects can potentially solve the supply demand problems currently associated with MMOG game economies. Furthermore, the use of conservation of game objects allows the possibility of convertible game economies where game currency is fully exchangeable for real money.
Comments may directed to the author of this paper at the following email address:
griffith at goldeconomy.com
TERMS
Buff(s) - One-use items that improve the player’s statistics.
Creep(s) - Industry term referring to “monsters” and other NPC’s in the game that can be killed by the players.
Creep Fund - A money account into which dead player’s gold is transferred. As creeps are regenerated their pockets are funded with money from the creep fund. This conserves money.
Creep Tax - When a creep loots a player corpse a percentage of any money found is transferred to the Creep Tax account for the benefit of the game host.
Dupe Bug(s) - A coding error that enables a player in a MM game to obtain the same item over and over again with no additional expenditure of time or resources. When there is a dupe bug for money the player can get “rich”.
Financial Cryptography - The science and art of using cryptography to protect and authenticate the transfer of financial assets in an online environment.
Inflation - Increase in prices of tradable items in the game world caused by a constantly growing money supply inside the game.
MMOG - Massively Multiplayer Online Games with thousands of players who interact with one another and the game environment.
Non-Perishable(s) - Game items that persist or cannot be destroyed with use: includes money and other objects.
NPC(s) - Non-player character. I.e. monsters, merchants, creeps, slaves, etc.
PC(s) - Player Character. I.e., the player’s in-game persona or avatar.
Perishable Object(s) - Game items that disappear with use.
Persistent Object(s)- Game items that are not destroyed with use and remain in the game world as inventory perpetually.
Power-up - An item that confers a Buff to the PC as soon as the player touches it. It disappears rather then being added to inventory.
Ken Griffith is a website developer at Clinch Mountain Communications and former editor of The Gold Economy Magazine. Reprinted with permission.
