This article is much longer than I would have liked, yet I wasn’t able to dive into each of the subtopics in as much detail as I would have hoped for. Still, it provides some foundational material for a later examination and proposal for a metaverse implementation. If you are a serious virtual world or metaverse enthusiast, this article is probably for you. The more casual reader may want to skip this article.

If you are involved in a metaverse project, you may find it referenced below. Nothing you read here should be considered a harsh criticism of any one particular approach. In most cases, these implementations are named to illustrate an example or a counter-example. This article doesn’t attempt to perform a complete review of platforms or to call winners.

INTRODUCTION

Previously, we identified seven issues which hold back our current metaverse implementations. Can a metaverse actually break through all of these issues to become a major platform?

What if we build on a distributed services architecture? Should we position the desktop client as a 2D/3D content browser? What if we use open standards, or build upon a proven engine? These and other suggestions may turn out to be very good ideas, but we don’t know. We’re still trying to understand the underlying issues which are holding us back.

SPECIFIC PROBLEMS ILLUSTRATE SYSTEMIC ISSUES

Clearly, there are more problems than the original seven which were provided in the first article, but those seven create a pool from which we can look for more systemic issues.

Why do we want to hunt for systemic issues? Efficiency. If we can identify core issues that we want to solve, then addressing one of them can knock out multiple problems. In that pursuit, we’re going to investigate three candidates: management, engine, and scope.

THE SEARCH FOR A SYSTEMIC ISSUE: CENTRAL MANAGEMENT

If there has been a lightning rod for criticism of a metaverse, in both science fiction and the real-world, it has been the idea of centralized management. There are so many aspects of a centralized approach which attract negative attention. Here are a few:

The self-appointed king. When a company (or large organization) starts a metaverse project, they automatically bake in some assumptions. One of them is that they (or a specific technology that they are promoting) will always be at the center of everything. This one assumption guides every design decision which follows, and most often places the needs of the organization before the solution itself. One way this exhibits itself is in a metaverse that is more walled garden than worldwide computer network. In truth, it resonates through the whole design.

Lack of autonomy for participants. The central management usually accepts only a very controlled guidance in the rules which they use to govern their virtual world. At any time and without recourse, they seem to reserve the right to decide that your business is unwanted and to brush you aside. How do you stake your claim in the metaverse if you’re really just building inside someone else’s empire? This is inferior to the Internet experience of staking a claim and setting up your own shop.

Limited (if any) internal competition. The position held by a central organization means that while they may see competition from the outside, they do not see competition from inside their world. There are no competing organizations which are trying to build better in-world services such as marketplaces, land ownership, graphical standards, and search functions. You’re stuck with whatever they provide, at the pace that they provide it, at the cost they charge for it.

Local restrictions become global. A metaverse that is controlled in India would likely ban pornography (as would many other countries). A metaverse that is controlled in the United States would likely ban in-world gambling. (In fact, Second Life went through the effort of removing all gambling a number of years ago.) A metaverse that is controlled in a number of other countries would ban insulting royalty or heads of state. This is not to suggest that we should reject lawful restrictions in the jurisdictions which they apply. While we acknowledge that this is a complex issue, at a minimum, a centrally organized metaverse would be expected to globally implement the laws they inherit from their own jurisdiction. To the majority of online users, this represents a problem. Today’s Internet does not globally apply the laws from a single jurisdiction, and the metaverse should not do so either.

It is worth noting that High Fidelity is at least opening the door to outside competition in some of their core services (possibly the nameserver, marketplace, and currency server). They believe that they can continue to provide the best services in the face of potential or realized competition from the outside.

OpenSimulator (based on the Second Life engine) represents a group of interconnected worlds which is no longer under the control of Linden Labs. They saw some success, but the odd thing is, if central management was the problem, then why didn’t OpenSimulator spread like wildfire and take over the virtual world? As it turns out, there is more than one systemic issue to deal with.

THE SEARCH FOR A SYSTEMIC ISSUE: THE WORLD ENGINE

The search for a systemic issue led us to the world engine. The world engine is just a convenient label to reference the sum of the overall design, protocol, back-end servers, databases, and client software. If that scope seems unwieldy, just focus on the client-side software.

Trade-offs in the underlying language. The selection of the underlying language has a massive impact on a platform’s characteristics. Do you choose the language which will be less vulnerable to exploitation, or the one which will attract the most developers? Most platforms will choose the language which favors a larger developer population. How far can you trust a platform which is built upon “the perfect mix of unsafe and easy to abuse” for purchases, secure communications, or to check on your home automation system?

A single engine. Almost all metaverse implementations are based around a single world engine. (It is unusual to see multiple engines with truly diverse functionality operating within the same metaverse.) Everything that you can see or do is channeled through the engine. These engines are often geared towards bandwidth optimization, navigation, in-world communication activities, in-world transactions, and in-world building. They tend to be poorly suited for other tasks, for example, twitch-based action, or cryptographically secure communications, and real-world financial transactions. The metaverse should be capable of so much more.

A ceiling for creativity. In a virtual world, the first tier of creativity, and the most obvious, belongs to the builders of in-world environments. The second tier of creativity is for those people who play in the environment and act out their own stories in the virtual world (the inhabitants, or role-players in some contexts). We often overlook the the third tier of creativity, which is in the structure imposed by the world engine itself. As an example, you may want unvisited areas in your creation to be shrouded in a fog of war. If the platform you are using prevents this, it limits your creativity. The engine itself is often an unappreciated but important contributor (or impediment) to the creative process.

A ceiling for technology. The world specification and the implementation of the client engine sets the limit on the technological limits of a metaverse. This limitation explains everything from dated graphics to the lack of modern features (such as real-time streaming of positional sensors onto avatars). The ceiling must constantly be raised and the scope must constantly be expanded to incorporate new features. At the same time, compatibility must be maintained, which creates friction.

High costs and limited risk taking. The aspect of central management mixed with a single world engine usually results in a large implementation. With a single large implementation, the direct and indirect costs of making changes are high. A large implementation also limits the amount of risk taking (in terms of technical innovation and design innovation) that is done in a metaverse, for fear of upsetting an existing population of users. The problem only becomes more pronounced as the number of users increase. Increasing costs usually yield technical stagnation in the long-term, which reduces the value of the platform.

The current generation of metaverse implementations seem to show some appreciation for engine-based limitations.

VRChat allows developers to create shared content through the well-known Unity game engine. When players enter VRChat and select a destination, the area is dynamically loaded and pulled under the existing structure of VRChat’s shared universe. Updates to the Unity engine are regularly provided by Unity Technologies and new plugins are available from third parties. Using a well known engine may not solve every problem, but it seems a more efficient choice than rolling your own engine and keeping it fresh.

JanusVR deviates from the standard engine with their MMOB (massively multiplayer online browser) design. They run a custom engine which is based on the concept of connected rooms. Users build and then host the contents of their own room on the open web. JanusVR has its own room definition language, but they have demonstrated that they are able to incorporate externally created technologies, such as SceneVR.

I think that we are starting to see the benefits of new approaches in this area.

THE SEARCH FOR A SYSTEMIC ISSUE: WORLD SCOPE

Finally, the search for a systemic issue led us to issues of scope. Metaverse implementations have exhibited a number of scope issues, including:

Walled garden. It certainly isn’t a path to the metaverse, but walled gardens are commonly found in metaverse implementations. You either build your virtual world inside of their platform, or not. The platform never tries to reach out to external virtual worlds or communities to bring them into a greater whole. Part of this is due to the central management, part of this is due to intricate details of the world engine. It is a shame, because it fragments both users and content.

Never quite reaching reality. Aside from divorcing themselves from other virtual worlds, metaverse implementations have a habit of divorcing themselves from the real world, too. There was a time where you could visit the American Apparel store in Second Life. Could you buy an in-world shirt for your avatar? Sure. But if you wanted to browse their selection and buy one of their real world shirts, the best you could do was access an in-world web browser window and shop in 2D. This is not unlike the 1990s Internet where businesses would put up a web page with some basic information and ask people to call them on the phone if they wanted anything more (such as support documentation, or to make a purchase). It is a missed opportunity of massive proportions.

The latest generation of metaverse implementations seem to be taking on the issue of scope in different ways.

High Fidelity is opening the door to outside competition in some of their core services (nameserver, marketplace, currency server). They believe that they’ll be able to provide the best services under the process of potential (or realized) outside competition.

Most of the remaining metaverse implementations seem to have the potential to allow interaction with real-world systems (beyond presenting a web browser interface), but I haven’t yet stumbled across any significant examples of real-world utility. It may be worthwhile for them to demonstrate the capability with a few examples.

ARRIVING AT THE SYSTEMIC FAILURE

So when we look at the systemic issues in metaverse implementations, it really is a combination of all three (management, engine, scope). Some of these issues impact certain implementations more than others.

As I worked through these systemic issues, I made one important observation: choices which unite are also choices that exclude. Every decision that is made by central management is a choice that in-world developers cannot make for themselves. We’re baking a ton of choices into most of these implementations.

Are centralized choices actually good or bad, and why? It depends on the goal that you are trying to achieve. We’ll revisit the impact of centralized choices again when we dive into a specific metaverse proposal.

The next article in this series will define what the Metaverse is, explain the purpose it serves in the real-world, and show the applications that can be made to take advantage of it. It should also put you in a position to start thinking about how we actually build the metaverse, which will be explored in more detail in upcoming articles.

This blog is about going beyond the science fiction descriptions of the Metaverse and actually fleshing out some of the concepts, designs, and details that are useful in bringing it to life. The ideas described here are not to be interpreted as the exclusive way for the Metaverse to be designed. We’re here to put a stake in the ground. We hope to start the conversation (where it doesn’t already exist) and to move the conversation forward.

How do you navigate between unrelated virtual worlds?

Back in August 2013 when I first envisioned how I wanted a different model of the Metaverse to work, one of the fundamental questions I had was in how to glue everything together. Instead of building one large Metaverse and splitting it into pieces, as has been done before, I looked at a different solution. How do we start with a bunch of unrelated pieces of software and combine them together to form a larger Metaverse?

Our universe starts with completely different and unconnected virtual environments, games, and virtual worlds. There are different authors, languages, graphics libraries, and more. If you wanted to create a way for players (avatars) to actually move between them, how could it be done? How would you move from JanusVR to Minecraft? How do you walk from Minecraft into VRChat?

What do we want to communicate between worlds?

To start, we should try to figure out what kind of things we might want to communicate.

Identity information. (Who is the user? Are they under 13 years of age? What country are they in?)

Technical capabilities. (How much network bandwidth and latency? What kind of input devices and settings are they using? What kind of output devices and settings?)

Real-time positional information. (Position and orientation relative to a share reference point in both worlds? Specific destination in the remote virtual world? Limb positions? Standing or sitting?)

This really doesn’t strike me as a difficult problem. We might want to start simple and evolve into greater capabilities as time goes by. I, for one, believe that the most important elements for version 1.0 might be only two factors:

Basic identity information

Real-time positional information

Why would I put real-time positioning as a key feature? The transfer will be facilitated by a limited and pre-defined shared environment, which a later post will explain and illustrate in more detail.

If we could get two different pieces of software to closely render a very limited shared environment, maintaining the relative position and orientation of the player would avoid an abrupt jump during the hand-off between environments. If I am trying to create the feeling of a cohesive virtual world using completely different software elements, at a minimum I need to create the visual illusion of continuity.

How do we want to communicate that information between worlds?

It is pretty obvious that we’d want a standard data format for communicating that information. The client could simply initiate a new session at the destination and pass along the information. We could also have the source and the destination talk with each other. Or maybe we could go through a third party service which handles some of the identity services. Say, wasn’t Brendan Iribe saying something about that here recently?

While Iribe admits that a billion-person MMO is “going to take a bigger network than exists in the world today,” he says Facebook’s network makes a great place to start, and suggested it could be a Metaverse that joins disparate virtual worlds. Source: The Verge, Oculus wants to build a billion-person MMO with Facebook

Well, it looks like Oculus/Facebook may already be pursuing this direction. Disparate virtual worlds joined together by Facebook’s network.

Wait a second, did he say disparate virtual worlds?

Myself, I had been searching for a better way to communicate the idea of connecting unrelated virtual worlds which were based on totally different platforms. When I saw the phrase “disparate virtual worlds”, I found it to be astonishingly accurate, if not somewhat curious. It struck me that someone had really given some thought about how to communicate a very specific idea.

I took to Google to see if I could find how and when the phrase had been used. [I have since watched the TechCrunch Disrupt video and did not hear Iribe say those actual words.] As it turns out, it has been used a few times since 2006 and… OH NO… wait a second…

Patent US 8,584,025 B2 – VIRTUAL WORLD TELEPORTATION

Image Source: US 8,584,025 B2 via Google Patents

As I was writing this article, I discovered that there is actually a patent which does a pretty good job of covering this whole idea. It was submitted by IBM employees in 2008. Crap. This is bad. They patented the whole freaking idea, didn’t they?

SIDE TOPIC: This illustrates an aspect of software patents that makes people angry. It isn’t so much that there are any really interesting or unique software solutions being patented here. Instead, it seems to be more about applying standard solutions to situations that have been identified before anyone else has had the chance to evaluate them. At times, once the problem is identified, it is all too easy to arrive at the same solution as the person who addressed it years earlier. Do some software patents boil down to nothing more than a race to identify the problem first?

I know from my own experience of submitting and being granted a patent that you cannot simply patent ideas (no matter what the TV commercials may tell you). You have to patent methods or specific ways of implementing those ideas. When you’re evaluating someone else’s patent, the important part to pay attention to is the claims section. That’s what they’re really claiming the exclusive rights to.

How would I defend myself from the claims in this patent?

I know that I have to focus on the claims. I’ll work in a few pieces from my own Metaverse design to illustrate where I think the patent has holes. Do I have enough to work around IBM’s claims?

Basically, they’re describing the migration of a resource inside of a cluster.

The entire procedure which is documented in claim 1 is little more than the migration of a resource inside of a computing cluster. Freeze the resource to prevent it from being altered, find the best place to put the resource, copy the resource, disable the resource, and start it up on a different node.

The difference is that instead of migration a computer program or a computer resource (IP address, SAN storage, etc) between servers, they are migrating a record that is associated with a user’s avatar.

Even if I acknowledge that they were ahead of the time in putting some significance to the problem, I can award them no points for the novelty of their solution. “A cluster failover procedure, except, with an avatar resource.”

It is interesting that IBM specifically makes claims about teleportingavatars.

What if there is no avatar to teleport? If I am in my Virtual Home and I use a themed virtual interface to launch a local copy of Team Fortress 2 or Minecraft, there is no avatar transfer involved. I’m simply launching a local binary.

What if instead of teleporting, we create a shared space to migrate the users between applications? Program A creates a version of the holodeck. Once the user steps inside the holodeck, it transfers the relative position and orientation over to Program B. Program B then continues the simulation from the holodeck and into their own custom environment. Or perhaps we could simply simulate the remote environment closely enough to cut the user over.

Is there any importance in the definitions of the words used in their claims? I don’t see “teleporting” actually defined anywhere in their patent. What exactly does and doesn’t teleporting consist of? I don’t see it. On the other hand, they seem to clearly define what a disparate virtual environment is. “Each environment is disparate in that each may be instantiated by different service providers, utilize different proprietary systems, and require the creation of a unique account to participate.”

IBM’s claim is based, in part, on analyzing information in the received persona profile and automatically selecting a region.

…analyzing information in the received persona profile and automatically selecting a region in the first virtual world to locate the inbound avatar based on the analyzed information in the received persona profile;

If a user, inside a different application, wishes to open a JanusVR virtual room explicitly at the location http://www.reddit.com/r/VRsites, is any analysis needed? Is the intended destination even part of the “persona profile”? There is no need to automatically select a region on basis of the user’s profile if the destination is explicitly stated (or if the region is chosen by one another means).

[EDIT: May 16, 2014] This really is more about automatically putting your avatar with similar people, be they selected friends, others with like-minded interests, associations, or more. By inserting an extra step, perhaps where the user manually confirms (by pop-up GUI, by movement through a second doorway at the destination, or by some other means) that they wished to be placed with others based on their shared profile, an automatic selection would be avoided. Beyond avoiding a patent claim, identifying good destinations and giving the user the choice might create a better user experience.

IBM has a serious procedural error in their claim.

“…automatically selecting a region in the first virtual world to locate the inbound avatar…“

IBM’s claims involve migrating from a first virtual world to a destination virtual world. There is no value in selecting a region in the first virtual world to locate the inbound avatar. Instead, the obvious implementation would be to select a region in the destination virtual world to locate the inbound avatar. In the claims section (where it matters), they seem to have chosen the wrong destination.

[UPDATE: A continuation of the patent which was published in January 2014 changes the language in a way that seems to avoid this mistake. It is interesting to note that it completely reverses the role of the first virtual world and the disparate virtual world, as described in the rest of the application.

They have a second continuation, similar to the first, which slightly changes the preamble. I have since found a third continuation of the patent. It looks like they were trying to cover a number of challenges based on the specifics of the wording.]

The first claim contains multiple (A,B,C) requirements which must all be met.

The multiple steps in the first claim include: creating a persona profile, transferring the unchanged profile, disabling the avatar in the original virtual world, and granting or denying access to the first virtual world.

To avoid this claim, we need to avoid using every single one of the listed steps. Instead, we could change the avatar’s record (in the originating virtual world) after the transfer. We don’t have to disable the avatar (a process which isn’t clearly defined — did they mean logging out?) in the originating virtual world. We don’t have to be responsible for granting or denying access to the destination virtual world.

The remaining claims (2-7) are dependent on the conditions of first claim having been met.

In claim #2, IBM envisioned a remote shared database being used to transfer that information. I think that if Oculus were to use Facebook services to connect disparate virtual worlds, they’d be looking at a remote shared database as well. There might be a clever way around this claim, but my architecture didn’t involve this component so I’ll leave that to someone else to defend.

In claim #3, IBM envisioned that the user profile would be transferred directly between servers. I originally envisioned the client being responsible for transmitting the information necessary to coordinate the hand-off between two virtual worlds. The servers would communicate and synchronize through the client.

That’s one way around the problem. If I were Oculus, I’d use the APIs in the Oculus SDK to provide that service. But what about the audit logs and user reputation information? If it became necessary to transfer sensitive information between the servers, it can still be communicated between the servers, indirectly, through the client buy using a carefully chosen encryption protocol.

The remaining claims are very broad.

Claims 4-7 seem tough to counter. They basically claim the idea of sending virtual world information in a standardized format between virtual worlds. Perhaps the defense against claim #1 would be enough to knock these out? I really don’t know. Where is Pamela Jones from Groklaw when you need her?

Where to go from here?

I’d be interested in what others have to say about IBM’s patent (and the overall topic of virtual reality patents.) Perhaps related, I was excited to see the video of Michael Abrash and Dov Katz of Oculus VR talking about the great deal of R&D investment that Facebook is going to fund for virtual reality research for 5-10 years in the future. This also has me concerned. Corporate funded research will likely yield patents. Could VR become a terrible patent minefield (once again) in just a few years time?

In any case, in my next few posts, I hope to get back to the topic of specifying some specifics on how a live user transfer between disparate virtual worlds could be accomplished. If you’ve got some JanusVR virtual room coding skills, I might have a small job for you to create some illustrations.

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.

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)

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?

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.

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”

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.

“The Street.” That’s what Snow Crash calls it. The Street is a shared virtual environment that grew to be used by over a hundred million users. The author eases us into how avatars might interact in the Metaverse by describing a simple problem: how to reach the front door of a famous establishment.

If these avatars were real people in a real street, Hiro wouldn’t be able to reach the entrance. It’s way too crowded. But the computer system that operates the Street has better things to do than to monitor every single one of the millions of people there, trying to prevent them from running into each other. It doesn’t bother trying to solve this incredibly difficult problem. On the Street, avatars just walk right through each other.

You might remember that in a previous article, Griefing and the Metaverse, we touched on some of the issues involved when avatars collide. In an even earlier article, The sci-fi Metaverse is bad, we realized that the science fiction Metaverse is actually an unrealistic blueprint for what an actual Metaverse should be like.

When Snow Crash describes a high traffic public place, I think that they got it more right than wrong. When practical considerations need to come first, the Metaverse does not need to be a faithful simulation of reality. We could stop here and implement a public space with Snow Crash’s description of the Street, but there are additional practical considerations to deal with.

This really is a small piece on a larger discussion on how to handle scale. Let’s assume that we’ve solved the problem of scale on the back-end in a way that doesn’t split the client population into smaller segments. Everyone shares the same virtual space.

With the problem solved at the server side, how then, do we handle scale on the front end (the user’s client)? If we’re walking through a populated public area with only a thousand avatars, some just standing around, several hundred going one direction, and several hundred going the other, how do we even hope to faithfully reproduce that?

As our avatar travels, our Metaverse client will be assaulted by a stream of models and textures, as well as streaming data on position, and joint articulation (made worse with VR input devices). Even if we had Google Fiber to transmit all the data with very smooth updates, could our engine render a fast and consistent framerate that is suitable for a head mounted display? Unlikely.

Idea 1: Simplify the avatar (moderate feature reduction)

Nintendo Wiki: Mii Plaza

When I first selected the Mii Plaza image (above), I had originally intended to use it purely as a counter-example. But after some more consideration, it has kind of grown on me. If we’re in an area where we’re drenched in avatar data, we could dynamically choose to abstract the avatars into something less resource intensive (network, CPU, and graphics) for the client machines. For a client, dealing with the load from this kind of representation is less of a problem. Perhaps this could be the mobile experience? There are simple models, simple textures, and a limited number of joints to articulate.

We may still need a few circuit breakers, but the solutions are simple. As the client load increases, we could reduce the draw distance for avatars. Second Life uses another approach where it reduces the update rate (of movement, articulation) for avatars which are further away.

In such a solution, I’m not sure if the whole environment (beyond just the avatars) should dynamically abstract itself to handle a high-load condition. Artistically, that may work out very well. On the other hand, it could be a case of, “Wildhammer Plaza was an awesome place until the digerati told everyone about it. Now the place is derezzed and crowded with Miis.” (You know, I could probably use a cyberpunk writer to create vivid stories which illustrate the pros and cons of design choices.)

Of course, a version of the image above could be how avatars are always represented in your Multiverse. They won’t take advantage of the detailed limb articulation that something like PrioVR might provide. They won’t be as creative as Second Life avatars. But they’re going to be easier to deal with.

Idea 2: Throw away the textures (moderate feature reduction)

DeFo: Ghost Traffic Controller

Perhaps we want to prioritize avatar customization and articulation in our Metaverse. We’re still going with the Snow Crash idea that in a public space, unknown avatars are as transparent as ghosts. What if we literally represent them as ghosts? Do ghosts need textures?

We can still use some of the tricks we just talked about, like limited avatar articulation (a ghostly hand may not have individual fingers), limited draw distance for avatars, and a reduced stream of updates for avatars at a distance. The further a ghost is away from us, the more plausible it is that we’d need to process less information about it. At the far edge of our drawing range, perhaps only blurry form would suffice to simply indicate its presence.

Idea 3: Remove the individuals (heavy abstraction)

The first two ideas don’t address the issue of scale as much as they push back the number at which it starts to become a problem. That’s useful, but it doesn’t solve the underlying problem.

For this third design, I wasn’t able to find a singular artistic representation, but I do have two great inspiration pieces that are both animated. The idea here is that, at a certain number of avatars (or at a certain distance from them), you stop representing all the individual unknown avatars and you start representing a crowd.

The New York Times: Tracking Taxi Flow Across the City (click for animation and then press the play button on the next screen)

Click the image above and hit the play button on the next page. In this animated map, color represents a passenger being picked up in a taxi. As a design inspiration, I saw this as a great way to represent the presence of anonymous avatars in a high traffic public space. The more that are congregated in an area, the bigger or brighter the mass.

hint.fm wind map: March 13, 2012 (click for animation)

Click on the picture above to see the animated display. I hope you liked it as much as I did. I think this interactive wind pattern globe is even cooler. This represents something different. While the first animation represented events or existence, the second animation represents motion. The two abstractions give us mass and flow.

The problem that we’re trying to solve here is that if we try to represent every single avatar at all times, we’re going to be overloaded. But what if we represented them in bulk?

We can display the mass of avatars and the movements of avatars, but not the individual avatars themselves. The crowd of ghosts could be represented by a ghostly mist, fog, or cloud. (And a ghostly mist, upon close inspection, might resolve into the individual ghosts that were detailed in the previous idea.)

This idea plays very well with another aspect that we may be looking for: anonymity. In Griefing and the Metaverse, we touched on the problem of manual and automated data collection by third parties (whom wish to create dossiers on other users). A user that is lost in the crowd is not revealed to third parties. Further, a user who desires privacy and anonymity might even select that they don’t even want to be resolved as an individual ghost in a public space.

The problem we have to be careful about is creating a user which is invisible and has the ability to spy on and stalk other users. For this reason, a user who chooses to always remain in ghost form should resolve any other user (beyond selected friends or a public performer) as an anonymous crowd and ghost form. (In this idea as well as the other two, a user would be able to select if their avatar is fully materialized to known friends.)

I think that the crowd approach can reduce some potential griefing in a public space. (Be sure to check out Penny Arcade’s Greater Internet Fuckwad Theory if you are not already familiar with it.) Someone can be as outlandish as they want and actually attract their own audience if they’re entertaining enough. I might just want to see an avatar that is wildly gesticulating and contorting themselves into anatomically impossible positions as they play their speedcore music. But at the same time, their opportunity to be a public annoyance is limited if they are just as easily folded back into a crowd.

From a resource perspective, the crowd idea would scale extremely well. We paint a landscape with a forest and not all the individual trees. On the server side, we no longer have to stream individual anonymous avatar data to the client. The server would send high level crowd updates in their place. It could scale very nicely.

How would you tweak this idea? Do you have another great way of representing unknown avatars in a high traffic public space?