A Review of Player Resource Control Strategies

Image source: Team Fortress 2 - Mann vs Machine

Image source: Team Fortress 2 – Mann vs Machine

Despite a previous article in which I explored how to represent a very large number of avatars in a single shared environment, I don’t believe that a single shared world isn’t going to be a mainstream approach. There are some good reasons why a large singular world should exist as one of several different solutions. But that’s a topic for another time.

When your virtual world is faced with a large number of simultaneous users, you’re going to need to find a way to keep the load under control. This article is a (non-exhaustive) review of known techniques which may be used individually or in combination.

We’ll be looking at denial, sharding, time dilation, feature reduction, and location distribution.

Denial: Hard Limit of the Number of Simultaneous Players

“Server is full.” The classic method of handling resource limitations.

Resources are represented in terms of the number of users that a server can handle. If a user was capable of using a maximum of 5 resources units (consider resource units a generic representation of CPU, network, etc), and your server has 150 resource units, you may want to place a cap at 28-30 users so that the maximum can never be exceeded. Additional users are denied access to preserve resources.

If you have to go with this approach, at least consider a waiting list or auto-retry function to enter the system.

PRO: Simplest implementation. Strict enforcement of quality / rules / fairness.

CON: Limited scope.

EXAMPLE: IRC, Second Life (maximum 100 avatars in a region), Team Fortress 2, many others

COUNTER-EXAMPLE: EVE Online

VARIANT 1: Oversubscription. If your environment can support a maximum of 100 users, chances are, not all of them are going to be engaging in resource intensive activities at all times. With 100 users on, most of the time, your resources may only be at 20% of capacity.

You can decide to let 200 users into the system, knowing at some time there could be a resource crunch. If managed correctly (and with dynamic oversubscription), they may not even know that it is happening.

VARIANT 2: Contingency players. If your environment can support a maximum of 100 users, you continue to let in users beyond that limit, but you inform them that it is on a contingency basis. For as long as resources are available, the excess users can remain in the environment. Once resources become constrained, you start (gracefully) removing contingency players from the environment.

This is not a popular design choice. It can lead to player frustration, especially considering that resources may have become constrained because a great deal of activity may have started up. Being kicked out of a virtual world at the moment that things start to get exciting is an unpleasant experience.

VARIANT 3: Premium players. You may decide to keep a hard limit on users to preserve quality, but allow specific users into the system as an exception. (Alternatively, you might allow friends of people who are currently on the system.) Depending on how hard your limits are, you may have to accomplish this by removing existing users as described in the second variant.

Shards: Dividing the Users into Groups

Image source: Warcraft Realms Server Status (US)

Image source: Warcraft Realms Server Status (US)

Shards are multiple distinct copies of the same base environment. Each environment is often identical but isolated from other copies, and players usually have limited to no interaction with players who are in different shards. Shards are an intentional arrangement of similar servers with users distributed among them (hopefully) using an intelligent strategy or self-selection.

Shards may be open or closed. Generally, in an open design, users are free to select the shard that they want to enter. They might choose to enter one shard over another based on user count, where their friends are, or other factors. In a closed shard, a user’s identity may be fixed to the shard that they began in, or a shard is selected for them each time they log in.

At a social level, shards can be both benefit and bane. Shards can be tied to identity. They can foster smaller and more intimate groups of people than might be possible in larger environments. These small groups can benefit from a greater sense of accomplishment, since their yardstick to measure their accomplishments is of a limited scope.

At the other end of the spectrum are the large groups of experienced players, which may believe that shards diminish their experience. They are robbed of the impact when they make huge accomplishments. If they harvest an in-game resource to exhaustion, they really haven’t changed the nature of the game, just their own shard.

Shards can make people feel welcome. Shards can make people feel cheated. Do your users want to be the big fish in the small pond, or the small fish in the big pond?

Additional uses for shards include pooling users together by latency (geography), time zones (geography), user native language, in-game experience, and alternative environmental rule sets (PvP, role-playing, low gravity, etc).

On the development side, shards solve the problem of in-game scale. How you design a popular area for 100 simultaneous users is different from how you design a popular area for 10,000 simultaneous users. More so if competitive activities and in-game resource farming are taking place there.

PRO: Relatively simple implementation. Scales very well at a technical level. Simplifies in-game map/environment design issues. Strict enforcement of quality / rules / fairness. Containment of unwanted in-world situations. Potentially more favorable to smaller groups of users.

CON: Diminished world experience for all users. Limited impact for high-end users.

EXAMPLE: World of Warcraft, Star Trek Online, Chat Rooms

COUNTER-EXAMPLE: EVE Online, Second Life

VARIANT 1: Hybrid shards. World of Warcraft has done something interesting in recent years. After initially dividing up their users by shards (called realms), under certain circumstances, they merge several similar shards together. With cross-realm zones, regions of the map that have a low population of players will be merged with similar realms to create a higher population area. With connected realms, they’re doing the same thing, except, merging the entire realm and not just one area of the map, while preserving the identity of each realm and its participants.

Time Dilation: Slowing Down the Passage of Time

Image Source: Massively, "EVE Evolved: Time dilation and the war on lag"

Image Source: Massively, “EVE Evolved: Time dilation and the war on lag”

The idea behind time dilation is simple. If there isn’t enough time to process everything that is happening in one corner of the universe, then intentionally slow everything down in that corner. Time dilation works where it is important that the rules continue to be enforced in a fair manner but the urgency of real-time action can be sacrificed.

When a region of space in EVE got busy, this worked out well. Players were treated evenly and the existing rules continued to exist, otherwise unmodified. This also worked out well beyond competitive gaming. Before EVE, Second Life also used time dilation as the rate relative to real-time that the physics simulation runs at. It is available in the Statistics panel.

Obvious, this compensation has to be applied thoughtfully. It the world of twitch-based first-person shooters, time dilation would be an agonizing experience, and perhaps more fair to some players or classes than others.

PRO: Strict enforcement of rules / fairness.

CON: Quality of play is degraded. Inappropriate for twitch-based environments.

EXAMPLE: EVE, Second Life

COUNTER-EXAMPLE: Team Fortress 2

Feature Reduction: Reducing Unnecessary Expenditures

GeForce: Simulated Hair Demo

A detailed cloth simulation of a billowing cape? Hundreds of strands of a player’s hair blowing in a simulated breeze? They look great, but they may not be a simulation priority. When resources start to get tight (CPU, network, graphics rendering), you may want to think about what items you’re willing to dynamically sacrifice to keep things going.

Seems trivial? This is going to be more important than ever with head mounted displays which want which require a constant 60fps or even 90fps refresh rate. A few regularly missed frames and it quickly starts to look bad.

In an earlier article, Representing unknown avatars in high traffic public spaces, we tossed around some ideas like the simplification of avatars, and mass representations for thousands of users. Both of those approaches would save on network bandwidth and graphics card load. A reader, Shaun, gave more details about Second Life’s method of saving resources when tracking many avatars. Avatar Imposters are cached 2D representations of avatars that are further away. Not bad.

There are generally a lot of feature reduction tricks seen at the level of the graphic engine, but keep CPU and network in mind too. As we increase the scale of virtual worlds (or we scale down to mobile devices), these constraints will be as important. Again, head mounted displays are going to want not only a fast refresh rate, but a consistent one.

PRO: Only non-essential elements of the virtual environment are suspended to preserve resources.

CON: Inconsistent, altered, or diminished experience.

EXAMPLE: Team Fortress 2, Second Life, many others

Location Distribution: How and Where Resources are Consumed

Image Source: Lucifron from World of Warcraft, via We Are New At This blog

In-game locations can be a great way of spreading load and controlling resource consumption. Different starting areas are a great example of this. In World of Warcraft, raids are not performed on the main map, but inside of their own instances (a pocket universe).

This is great for limiting outside interference in a group experience, but it also means that a certain amount of processing power can now be dedicated to make sure that this group of users has a great experience.

Be careful when looking at in-game ways to balance resources, as this can be a double-edged sword. There may be a lot of users in a particular area to kill a particular type of enemy. If you are using increased NPC respawn times to slow down the action, users may strongly dislike the change.

PRO: The potential to target computing resources where they are needed and to remove extraneous elements.

CON: Additional development time to create these features. Potential unintended consequences if taken too far.

EXAMPLE: World of Warcraft (instances, zones), Second Life (regions)

In Summary

We reviewed some of the ways that computing resources could be conserved in a virtual world. We looked at denial, sharding, time dilation, feature reduction, and location distribution. We have a number of tools at our disposal. Which do you think are the most important? What are some good methods that may have not been mentioned here?

We’ll reference this in a later article which will propose a structure for the Metaverse. Tomorrow’s article will be on why consumer technologies succeed and fail.

Tags: , , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: