questproquo

If you don’t know how you got here, head back to the Introduction or Part 1.  Otherwise, read on:

Part 2: Building the Theory

In a perfect world, developers would just make content all the time to keep players of all kinds entertained by the game world, but that is not possible. Developer resource constraints limit how much content a team can produce in any given amount of time.  As a result, there is a natural design triage where teams must choose to implement new features that can most positively impact the game.  I have seen people suggest before on forums that this problem can be solved by hiring more programmers, designers, and artists.  That is not a real solution because the numbers you would need to hire to eliminate the problem are probably staggering.  Further, that many people would bring a host of of organizational issues that would probably impact quality in unintended ways.  Given these issues, I am not even considering that avenue an acceptable solution to the problem.

Further, resource constraints are not a problem unique to the gaming industry. In the military, people who didn’t understand the principles were described as  “good idea fairies” because their decisions resulted in ineffectual changes that only served to drain resources in time, money, and manpower without actually effectively improving a situation or organization. Unfortunately, the military has been so awash with resources over the past decade, much of this behavior isn’t penalized the way it should be.   That is not an option for a gaming business. So I’m going to assume that, at present, the average developer produces content at a mostly fixed rate thanks to effective resource allocation.  The way to improve the output of the equation is to find ways to make the content created last longer when faced with players’ content avarice. This is no small feat, given that even veteran game companies sometimes fail to retain players. I cannot claim that it is fool proof, but I think it is possible.

The Theory:

Accepting the reality of resource constraints leads to the first half of end-game primacy: the bulk of any MMO development time should be spent on maximizing end-game content.   Most MMOs embrace some form of individual progression system where players consume static content until they finally hit a hard cap on player development.  Any content consumed along that progression track essentially comes with an expiration date.  It is only consumed for a very small portion of a players overall game experience.  In contrast, content at the end-game can be–and is–consumed for much longer, even when it is static.  If enough static content exists at the end-game, developers can eventually issue an expansion, pushing the progression wall a little further and starting the cycle over.  The most successful games already embrace this half of end-game primacy.  Others spend too much time on the initial progression, expecting to have time to expand later only to realize their players did not feel like waiting around.  While even this strategy can work, pushing static content to players is still limited.  Players still consume it and content themselves with repetition and brand loyalty as the glue that keeps them around long enough to see the next cycle.

Arguably the method of pushing static content is more in line with standard software development practices like object oriented design and agile development.  If that was the only way to build content, I think it would be the best way given those advantages, but there is another option. Going back to Ralph Koster‘s quote from Part 1, I want to highlight a particular portion:

You can try a sim-style game which doesn’t supply stories but instead supplies freedom to make them. This is a lot harder and arguably has never been done successfully.

There have been a few attempts at more sim-style content over the past few years, but it is definitely the harder model to do right.  That is probably why so many companies choose the safer route.  The second half of end-game primacy is that complex systems driven by player interaction provide more longevity than static content.  These systems differ from static content in that they allow players to pull content on-demand.  An example found in many current games is an auction house.  An auction house is always there for players to engage in when they want it. Some players will use it some times, others will use it never, and a rare few will use it as if it is the game itself.   It provides a constant stream of content that becomes more dynamic and interesting the more players interact, improving the game play experience for everyone.   It can go for years without ever losing player interest, providing maximum impact for developer resources spent.  Even if player progression is expanded, the auction house grows with that new bound, while older static content like dungeons generally get left behind.

Limitations:

On paper, dynamic systems like auction houses are superior to static content because they offer players new experiences over longer periods of time.  I recognize, however, that they are not all quite so easy to make in practice.  Economic models are fairly well developed, so predicting player economic behavior is substantially easier than say, predicting how a player will respond to a powerful monster or even another player.  These models make it easier for developers to build tools and mechanisms to govern that behavior (like the auction house) but modeling social behavior is a different animal.  Implementing many player versus player systems, for instance, end up being a lot like trying to make a communist economy.  It is great in theory, but horrible in practice.  There are few games that successfully implement player versus player mechanics and end up with a lot of digital pacifists running around cooperating.

Given these challenges, the end-game systems need to be designed in such a way that they do not cause more harm than good — no small task, to be sure.  If this can be accomplished, I feel the amount of development time that these systems entail far outweighs the benefits of spending that same development time creating static content.  The initial upfront investment might be higher, but over the long run they end up costing far less in terms of resources.  Taking in total, these ideas all left me with the conclusion that bulk of any MMO development time needs to be spent on maximizing end-game content and that this goal is best achieved by embracing complex systems driven by player interaction, rather than static content.

But a principle is only useful if you can make good on it,  so in Part 3 I will give a few of my ideas on building meaningful simulations at the end-game of an MMO.