Planet Mud-Dev

April 24, 2017

Optional Realities

Games & Economies

Economics can be a very challenging topic in the real world, but also in game design. Very few games really pay much attention to their economies and for most of them it works out fine. Multiplayer games are a different breed and the cooperative gameplay necessitates a functioning economy on some loves. Since I will assume you are reading this in application to text-based RPGs let us examine why traditional RPGs do not have complicated economies, what challenges multiplayer games have specifically, and some model economies that are very high level and simple to understand.

 

Traditional RPGs are your Baldur’s Gate, Fallouts, and your Pillar’s of Eternity. Each of these games is single player experiences with a strong story progression and difficulty curve. This means that the only requirement of the economy is to provide the player with money to spend at such a rate that they can save throughout the game until the end where they are not only the hero of the story but powerful and wealthy compared to their starting position. The greatest challenge to a traditional RPG implementing their economic model is trying to make the player feel like the money is valuable and worth spending. An example of having a lot of money without many purposes behind it would be any of the assassin creed games. The money has little to no value to the player unless they feel like upgrading their holdings and are a completionist. It isn’t required to win the game and isn’t even really a big factor in making the game easier to beat. It is an afterthought and even then many of the Assassin’s Creed games are considered to be quite enjoyable experiences. Meanwhile, you have a game like Darkest Dungeon where money management is a core function of the game because you need to purchase supplies for each run. You can very easily go broke if you mismanage the money and have to work your way back up to an operating budget. This is a good example of a simple single player economy which succeeds in providing money with value to gameplay.

 

Multiplayer games are fundamentally different from their single player traditional RPG brethren in one significant manner. They have to provide an enjoyable play experience to all their users. This means the balance of gameplay elements and as money is a fundamental gameplay element you have to balance it too. For the most part, multiplayer game economies are treated as variants of the gradual growth models used by their single player counterparts. This leads to inflation or more simply explained a constant growth of total money in the game world. You can look at games like World of Warcraft and even Eve Online as examples. Their player auction houses and player run markets show clear signs of massive game wide inflation as items worth 10 gold on WoW become 100+ gold. There are actually numerous forum threads on the Blizzard boards dedicated to player suggestions and ideas to “fix the economy” indicating they believe it is broken. It is.

 

The problem from a constantly growing money total and rising prices is that it disenfranchises newer players. Game content designed for the lower end no longer pays sufficient rewards to be worthwhile (except in experience) and can be made irrelevant if a new player just does crafting which will out pay any questing and give access to higher quality equipment in many cases. The economic imbalance has not only created a gap between your older players and new players in terms of wealth and expenditures but also directly affected your content experience. That is a major problem because if players are not experiencing the game as intended than that work is going to waste and you could be losing people too poor gameplay experiences.

 

Multiplayer games have difficulties with economies because they can negatively affect gameplay or trivialize content. We’ve identified a problem but what is the solution? I don’t know the perfect answer, it could be that it is very game specific. I do know that there are some models which are believed to be fairly reliable in managing multiplayer conditions. The two models we are going to the example are the “Flow-Thru Economy” and the “Planned Growth Economy”. These are probably the two simplest economics to explain and also the simplest to implement.

 

The Flow-Thru Economy can most easily be visualized as a kitchen sink with some dishes in it. The faucet is where all money, equipment, and valuables come from. The basin and dishes are the gameworlds which the water pools around in for awhile. The sink (or drain) is the exit point where money, equipment, and valuables are removed from the game world. Simply stated value is created, moved around, and then removed. This system is optimal for trying to maintain a static amount of wealth in a game world. For example, if I have 100 players, I would want my wealth to be 1 million units of currency, and this system would try and maintain that. If the player numbers fluctuate the total wealth you’re looking at will fluctuate with it.

 

The system achieves all of this with the money sinks. These can be anything from item repair, fees for auctioning items, requiring the purchase of items from NPCs for crafting or adventuring, and even more thematic options like allowing bribes. All of these achieve the same goal of taking the money from the players and removing it from the game world. Once it is in an NPCs pocket it can be made no longer accessible and then it’s essentially gone. This is a good thing, by the way, you want money to leave the game world, otherwise, it just keeps being created by players creating characters and finishing quests and selling things to NPCs until it’s essentially worthless. Those are the faucets, the things which generate new money and valuables.

 

Even with a visualization and terminology, it can be hard to really get this so let us walk through a quick Flow-Thru Loop. This is an example of what things might look like for a new player, let us call him Jeshin…

 

  1. Jeshin creates a new character called Jeshin
  2. Jeshin is given starting equipment and money [ faucet ]
  3. Jeshin begins a newbie quest
  4. Jeshin defeats the mouse lord for the newbie quest
  5. Jeshin is given cheese and reward money [ faucet ]
  6. Jeshin uses the reward money to repair his armor [ sink ]
  7. Jeshin sells his cheese to an NPC for money [ faucet ]
  8. Jeshin purchases additional equipment [ sink ]
  9. Jeshin seeks a new quest

 

Hopefully, Jeshin has a long and prosperous life-saving people from mice and getting some swag gear. You may notice a couple of things immediately like the fact there are only two identified sinks and three identified faucets. This means that without knowing anything about the numbers involved, more money is coming into the world than is leaving it in this example. This is often the challenge to implementing a Flow-Thru Economy. Players are inventive, they are playing a game, and they will do whatever they can to minimize their grind time or maximize their income. For that reason, you really want to try and find as many sinks as possible because they will always find ways to avoid a goodly portion of them.

 

The Planned Growth Economy is fundamentally different than the Flow-Thru we just looked at. Instead of intending for the majority of wealth to enter the game world and then exit it in a timely fashion you focus your economy on giving out a slow trickle of resources and wealth with the intent to grow over time. This would be good for games that have a strong progressive story or have a lot of time pass and want to empower players to feel like they’re really building the world up themselves. This system will mean a lot more extra work for staff though as they have to update the game world periodically to reflect these changes otherwise content can become desynced from the money players are slinging around.

 

The best way to visualize a planned growth economy is wet sand in your hand dripping down onto a mound. The wet sand dripping is wealth entering the game world and the mound is the gradual build up. I cannot stress enough that this economy is best in a game where you are building up to something via story or gameplay. You’ll have players start fairly poor and things will be scarce and eventually through play and time money will become more plentiful, resources more plentiful, and you start to see players become fairly wealthy able to spend their money on whatever you can put into the game that interests them. It’s a very empowering approach if done correctly.

 

Even with the awesome but odd visualization of wet sand lets try a walk through of a Planned Growth Loop. This is an example of what things might look like for a new player, let us call him Jaunt…

 

  1. Jaunt creates a new character called Jaunt
  2. Jaunt is given starting equipment and money [ Growth ]
  3. Jaunt begins a newbie quest
  4. Jaunt successful activates the mining reactor [ Game Build ]
  5. Jaunt is given a reward and access to the mine for harvesting resources [ Growth ]
  6. Jaunt spends his money on mining equipment
  7. Jaunt begins harvesting resources in the newly opened mine [ Growth ]
  8. Jaunt buys new equipment and looks for more quests

 

Let’s hope Jaunt is a part of a great mining expansion and he doesn’t cause any earthquake with unsafe mining practices in his adventures. A couple of things to note here is that the quests are based on opening up the game world or enabling content. The rewards are likely going to be used to buy equipment for benefiting from the opened up content or to go open up more content. You want the growth portions where money is added to outnumber the game build instances. Expanding the game to quickly means more content creation is required and cheapens the reward for players when they do achieve it.

 

This article is meant to start a discussion on these topics and just get people thinking about how money, gameplay, and player actions can be affected by game economies and what that can mean for game design. Neither provided economic system is perfect but they both have clear goals and ties to game design that can inform decisions and be a great tool in crafting your game worlds. I encourage everyone to look at some of your favorite games and ask themselves what does money get me in this game? Do I care about what it can get me? Do I only care about money because it’s a reward and I enjoy being rewarded for successful game play? These are important questions and can help you identify whether or not an economy is based on feeling good or supporting a larger game world.

 

Join The Discussion Here

by Jeshin at April 24, 2017 03:00 AM

Evennia

The luxury of a creative community

For this blog post I want to focus on the series of very nice pull requests coming in from a growing cadre of contributors over the last few months.

Contributed goodness

People have put in a lot of good work to boost Evennia, both by improving existing things and by adding new features. Thanks a lot everyone (below is just a small selection)!
  •  Contrib: Turn-based combat system - this is a full, if intentionally bare-bones implementation of a combat system, meant as a template to put in your particular game system into.
  • Contrib: Clothing sytem - a roleplaying mechanic where a character can 'wear' items and have this show in their descriptions. Worn items can also be layered to hide that underneath. Had plenty of opportunities for extensions to a given game.
  • Contrib: An 'event' system is in the works, for allowing privileged builders to add dynamic code to objects that fires when particular events happen. The PR is not yet merged but promises the oft pondered feature of in-game coding without using softcode (and notably also without the security of softcode!). 
  • A lot of PRs, especially from one user, dealt with cleanup and adherence to PEP8 as well as fixing the 'alerts' given by LGTM on our code (LGTM is by the way a pretty nifty service, they parse the code from the github repo without actually running it and try to find problems. Abiding by their advice results is cleaner code and it also found some actual edge-case bugs here and there not covered by unit tests. The joint effort has brought us down from some 600+ alerts to somewhere around 90 - the remaining ones are alerts which I don't agree with or which are not important enough to spend effort on). 
  • The help mechanics of Evennia were improved by splitting up the default help command into smaller parts, making it easier to inject some changes to your help system without completely replacing the default one. 
  • Evennia's Xterm256 implementation was not correctly including the additional greyscale colors, those were added with new tags |=a ... |=z.
  • Evennia has the ability to relay data to external services through 'bots'. An example of this is the IRC bot, which is a sort of 'player' that sits in an in-game channel and connects that to a counterpart-bot sitting in a remote IRC channel. It allows for direct game-IRC communication, something enjoyed by people in the Evennia demo for many years now. The way the bot was defined used to be pretty hard-coded though. A crafty contributor changed that though, but incorporating the bot mechanism into Evennia's normal message flow. This allows for adding new types of bots or extending existing ones without having to modify Evennia's core. There is already an alternative IRC bot out there that represents everyone in the IRC room as a room full of people in the MUD. 
  • Evennia's Attributes is a database table connected to other objects via a ForeignKey relation. This relation is cached on the object. A user however found that for certain implementations, such as using Attributes for large coordinate systems, non-matches (that is failed Attribute lookups on the object) can also be cached and leads to dramatic speed increases for those particular use cases. A PR followed. You live and learn.
  • Another contributor helped improve the EvEditor (Evennia's VIM-like in-game text editor) by giving it a code-mode for editing Python code in-game with auto-indents and code execution. Jump into the code mode with the command @py/edit.
  • Time scheduling is another feature that has been discussed now and then and has now been added through a PR. This means that rather than specifying 'Do this in 400 seconds' you can say 'do this at 12AM, in-game time'. The core system works with the real-world time units. If you want 10 hours to a day or two weeks to a month the same contributor also made an optional calendar contrib for that!
  • A new 'whisper' command was added to the Default cmdset. It's an in-game command for whispering to someone in the same room without other people hearing it. This is a nice thing to have considering Evennia is out-of-the-box pretty much offering the features of a 'talker' type of game.
  • Lots of bug fixes big and small!
  • Some at_* hooks were added, such as at_give(giver, getter). This allows for finer control of the give process without handling all the logics at the command level. There are others hooks in the works but those will not be added until in Evennia 0.7. 
About that Evennia 0.7 ...

So while PRs are popping up left and right in master I've been working in the devel branch towards what will be the Evennia 0.7 release. The branch is not ready for public consumption and testing yet But tentatively it's about halfway there as I am slowly progressing through the tickets. Most of the upcoming features were covered in the previous blog post so I'll leave it at that.

I just want to end by saying that it's a very luxurious (and awesome) feeling for me to see master-branch Evennia expand with lots of new stuff "without me" so to speak. The power of Open Source indeed!
  

Image from http://maxpixel.freegreatpicture.com, released as public domain.

by Griatch Art (noreply@blogger.com) at April 24, 2017 12:10 AM