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.

We can define a metaverse in a number of different ways. At a minimum, a metaverse must allow users to experience and perform actions with others in shared virtual spaces.

Years ago, we should have recognized and learned from the painful problems associated with a social metaverse platform which focused on user generated content. Today, a new crop of companies are gearing up to repeat those same mistakes.

As we look back, it was never really the user generated content that was the problem. It was the metaverse platform itself. It couldn’t live up to the hype. The platform was not capable of capturing a large audience, much less living up its roots in science fiction.

The concept of a metaverse (or even “The Metaverse”) is something that might yet deliver a compelling experience, but not in its current form. The design in use today needs to be shelved and replaced with something better.

I’m reminded of a quote from Chet Faliszek of Valve Software when he addressed Slush Play 2015 and spoke on the topic of VR development.

We’ve also seen a bunch of people following what others are doing. But don’t accept that. [….] There could be a fatal flaw in following what someone else is doing. They could be building on fundamental problems that they’re just not choosing to solve.

THE PROBLEM

These metaverse platforms have not just one, but seven major problems. Some of the problems are in building the platform, while others are in operating the platform. Let’s take a look.

A metaverse must keep pace with technology if it intends to remain relevant. Users and developers depend on the platform itself for their technological innovation. Additionally, the more complex and integrated a platform gets, the slower its innovation becomes.

How long did it take Second Life to support the Oculus Rift, which is arguably the most relevant piece of hardware ever to be developed in its existence? Where is Second Life when others are experimenting with hand and body tracking in virtual worlds? Why hasn’t it visually kept pace with the innovations in 3D game engines?

Games and other applications will continue to push the edge of new technology and innovation. Perhaps it is unfair, but they will be the measure by which users and developers will measure the technological innovation of a metaverse.

A rapidly evolving software and hardware ecosystem is extremely unfavorable to the development and operation of a metaverse.

Today’s rate of innovation creates an even more unfavorable environment for a metaverse platform. Technology is moving too rapidly (innovations in head mounted displays, inputs, drivers, performance, formats, standards, and more). It is difficult to build (or grow) a stable software platform on top of shifting sand.

Users (and therefore, developers) want a general-purpose machine of unlimited scope. It is a challenge that a metaverse platform engine cannot meet.

If users can do it in the real world, they want to do it in a metaverse. If they can’t do it in the real world but they can imagine it, then they want to do it in a metaverse. Millions of people will expect a metaverse to meet their own desires (even if their desires are in direct conflict with that of others). The desired feature set is not only incredibly large, it is also contradictory at times.

The real challenge isn’t technical. If it was, someone would have solved it by now, or we would have fixed someone else’s broken implementation.

Creating a metaverse is a large and complex problem with many interdependent variables, many of which are not technical. It is a systems engineering problem comprised of multiple domains. The real problem is in the human side of the equation.

Competition divides the experience. Content will be stranded and users will be fragmented, both of which diminish the overall experience.

Competition between metaverses already exists and is growing. While the increased competition creates innovation and choice for users and in-world developers, it also adds to the risk of commercial in-world developers, metaverse operators, and investors.

It is very risky to create a metaverse.

The barrier to entry is high, expectations are high, design is difficult, development period is long, ecosystem is evolving, competition already exists, and costs are high. Small teams are at a disadvantage. Big teams are financially pressured to deliver unrealistic results.

A metaverse continues to be a solution that is looking for a problem to solve.

In today’s environment, most people believe the problem is “social.” A more cynical view (and perhaps a more honest one) is that the problem is to “build something that will make money.” A clearly defined set of problems, not to mention an explanation of how a metaverse actually addresses those problems, is lacking.

A SYMPTOM OF MORE FUNDAMENTAL ISSUES

We have seven serious problems, none of which have found tractable solutions. Chet Faliszek’s admonishment is clearly just as relevant to metaverse developers as it is to VR developers. We’re building on fundamental problems that we either don’t recognize, or we’re choosing not to solve.

Is the concept of a metaverse simply unworkable? No, I think the concept has exceptional merit. What this tells us is that, behind these seven specific problems, we have some unrecognized flaws in our current understanding of what a real-world metaverse is and how it works.

Before we can begin to rework the metaverse problem, we need to identify and understand the core issues behind our current problems. Once identified, we can determine how a new metaverse concept might trade in our unworkable problems for more tractable ones.

SUMMARY

We reviewed existing metaverse platforms and found seven major problems in their implementation. These seven problems point to more fundamental issues which need to be identified so that we can improve our understanding of how to implement a metaverse.

The good news is that the metaverse concept can be reworked into a new model with tractable problems and practical benefits. We’ll explore this and more in future articles on this topic.

]]>https://metaversing.com/2015/05/31/fundamental-problems-with-todays-metaverse-implementations/feed/3jmccormThe Metaverse (image copyright 2015 by <a href="http://www.123rf.com/profile_michelangelus">michelangelus</a>)The Insanity of the Monolithic Metaversehttps://metaversing.com/2014/05/06/the-insanity-of-the-monolithic-metaverse/
https://metaversing.com/2014/05/06/the-insanity-of-the-monolithic-metaverse/#respondTue, 06 May 2014 06:45:51 +0000http://metaversing.com/?p=1039Lessons from the Past and Building the Future

Image Source: Future Virtual Reality (2011)

How can we help the next attempt at the Metaverse to be more successful? This article will present the idea that our attempts to directly build the large general-purpose virtual environments (“to build the Metaverse”) are, in itself, what have prevented a successful Metaverse from happening.

The Andromeda Blog warns us that virtual reality is doomed to repeat the failures of the past unless we recognize what those failures are, and start thinking in a new direction. They remind us that a popular definition of insanity is “Doing the same thing over and over again and expecting different results.” In the context of virtual reality, they’re right. We need to do something different than what has already been tried and failed.

What do people think is different this time around? “We have new technology!” “This time, we’re going to make virtual reality a platform!” “People are starting to take this seriously!” Those things are all important contributors, but are they at the heart of the problem? Only when we are able to recognize what we’re doing wrong are we able to figure out what needs to be different.

In previous articles, we’ve identified two easily overlooked but very substantial user needs which were neglected in previous implementations. First, there was a failure to maintain novelty (as the initial novelty decayed, large virtual worlds became boring). Second, there was a lack of utility (there was little real-world value which people obtained in virtual reality). A successful Metaverse has to continue to entertain its users. If and when that fails, it has to provide real-world value if it hopes to retain them.

What if there is another problem, more fundamental, that is baked right into the design?

Monolithic Worlds vs Modular Worlds

In this article, we’re going to explore the problem in different direction: monolithic worlds. This may not be a popular observation with some of the readers who find themselves invested in those designs. I understand; I happen to love a couple of them. But we need to illustrate a different approach.

Image Source: “Monolith of Lights” by James Everett

Over the years, there have been many discussions between programmers about the trade-offs between monolithic and modular applications. Each have their own advantages. Many people seem to preach an approach that is somewhere in between the two extremes. I bring this up only because I wanted to use some of the descriptions in Mike Schinkel’s post not to talk directly about the code, but to describe where we’ve been with virtual worlds.

Look at the two groups below. Which one of Mike’s groups best describe the virtual worlds that you’re familiar with?

GROUP 1

Grand Visions

[relatively] Significant Development Budgets

Requirement to Accommodate Infinite Future Scope

Minimum Utilization of External Components

Software Comprised of Complex and Highly-Coupled Components

GROUP 2

Modest Visions

[relatively] Little or No Development Budgets

Moderate Consideration of Future Scope

Cohesive and Focused Functionality

Maximum Utilization of External Components

When I think of Second Life, World of Warcraft, Gary’s Mod, or perhaps even the multi-user dungeons of the 80s and 90s, I think of the first group. That group is monolithic.

The Monolithic Virtual World

Image Source: Monolith Wallpaper by NickPerrotta on deviantART

The Andromeda Blog makes the distinction between a client-based virtual reality system and a browser-based VR system. For the purpose of this discussion, the underlying technology doesn’t matter so much. A monolithic virtual world envisions itself as an all-in-one solution that others will create their content inside of.

A monolithic virtual world generally begins with a moderately funded developer and a grand design. They create a general-purpose environment which runs within a tightly controlled specification. Yes, they might offer plug-ins or modules. They may offer you the ability to customize within their world, but the entirety of the world is under their control. You choose to build your own story inside of it. Not to the side. Not standing by itself.

When you build in someone else’s world, you are tied to their user base. You’re tied to their features. You’re tied to their upgrades and their innovation. You’re tied into their terms of service. You’re tied into their reputation. All of these can be positives and negatives. These alone are enough to keep developers at bay.

Does the engine for their virtual world lend itself to making a twitch-based shooter? A for-profit online movie theater? Secure chat? Real-world purchases? Telepresence? A hyper-realistic physics simulator? Low-latency communications? A monolithic virtual reality engine can’t be everything to everyone. It can’t be as good as a standalone application.

A previous article enumerated many of the choices in dealing with something as simple as load. Those are not fundamental decisions that you want someone else to make on your behalf. As an example, creating a twitch based first-person shooter inside of a virtual world simply doesn’t make any sense if that virtual world’s engine uses time dilation to handle load.

Are the faults of monolithic virtual worlds important? You better believe it. Innovation happens at the edges. Innovation is tied to novelty and utility. Novelty and utility are things that provide actual value to the end users. Trying to shoehorn many small developers into the same monolithic environment does not promote innovation.

When a well-funded company decides that they’re going to create “the Metaverse”, their design considerations will be shaped by the need for financial returns on a large scale. The natural tendency will be for them to go with a general-purpose monolithic approach. Do we have any reason to believe that “this time” they can use the same tried-and-failed approach and see different results? Does more money or newer technology cure the insanity?

A different approach is needed here.

The Modular Virtual World

If we see Second Life as an example of the monolithic approach, then what is an example of a modular approach? Something like Riftmax Theater would be part of a modular approach to a virtual world. Riftmax Theater stands alone and doesn’t require someone else’s virtual world to operate. It doesn’t try to be everything to everybody. It has a limited scope, and it concentrates on performing a core set of features very well.

The Opportunity to Do Something Different

Riftmax Theater succeeds, but it stands alone, unconnected to other worlds. How do we fit this and other well defined modules (with their unique code and focused advantages) into a larger universe? How does this form the Metaverse? This is the new problem that we need to solve.

While we recognize the value that monolithic designs provide, the design pendulum needs to swing back towards the middle. In a time of innovation and growth, we need the benefits of a modular virtual world. We need many developers working off of unique visions. We need competition.

Is there a way that we can build virtual worlds differently this time? Can we find a way to balance a general-purpose monolithic architecture with a specialized modular implementation? Can we unite stand-alone software? I think we can; it is just a matter of how. There are several ways to approach this, and an upcoming post may present one such solution.

“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?

If you’ve been following some of the posts here on Metaversing, you may have noticed a slant towards planning and design issues. This isn’t by accident. Many issues seem innocent or almost trivial, but need to be carefully considered before jumping into an implementation. A well thought-out design can save countless hours of trouble down the road in the systems development life cycle.

Today, I have an easy prediction: the Metaverse is going to be the stuff of legends for hackers, griefers, trolls, vigilantes, security researchers, and spy agencies. If you’re already familiar with the scene at the top of this article, then you know what we’re looking at: an in-world denial of service attack. Do you see it? Is it the guy in the pool with the antlers on his head? No? To explain, let’s go back to design.

One Metaverse might be be pinned to a basic concept such as, “You have a substantial presence in our world.” One way that concept might be implemented is for players to fully occupy a volume of space, and only one avatar or one object can be in any one space at a time. Let’s say that Alice is standing in a room. Bob comes along and tries to walk through Alice. What happens when two avatars try to occupy the same space?

Do you let Bob push Alice out of position? Does Bob teleport past Alice? Is Bob simply blocked by Alice and unable to move forward? Each of these sounds like a potential solution, but they each can result in unique problems. We’ll explore these three cases at a basic level.

This time, let’s imagine that Alice is standing in the middle of a doorway, and directly on the other side of the doorway is a pool. Again, we’re in a Metaverse where avatars have a unique physical presence. Do we let Bob push Alice into the pool? Does Bob teleport into the pool when he (intentionally or not) collides with Alice? Is Bob unable to move past Alice and denied access to the pool beyond?

The most simple design issues can have very large consequences in a virtual environment. (If you are looking for an exercise, imagine how the three potential solutions above would turn out if Bob is trying to traverse a crowded room.)

In the 2D world of Habbo Hotel, each avatar occupies a unique space, and your avatar cannot move through another avatar. You’re blocked. In the picture at the top of this article, you’ll see one character (with a large afro and gray suit) standing in front of the pool’s ladder. That’s an Afro Blocker. What is he doing? Just standing there. He’s also denying everyone access to and from the pool.

You might wonder if this kind of griefing is really possible in a 3D Metaverse? If that Metaverse uses a similar rule to exclude two avatars from sharing the same space, then yes, absolutely.

Let’s turn away from design for a bit, and look at what might happen in the operational phase.

When those Afro Blockers moved on from Habbo Hotel they then went to Second Life. Second Life didn’t fully enforce a unique physical presence for avatars, so their old denial of service trick didn’t work. They had to come up with new attacks.

One such attack, seen above, was to take advantage of particle effects to fill the environment with Marios falling from the sky. Because the effect was tied to their avatar’s appearance, it could even be performed inside of land where the player did not have permission to deploy objects.

The Wikipedia page for Patriotic Nigras seems surprisingly detailed for a griefer group. This may be attributable to academic interest in the group. It may be a good read to learn about some of the disruptive activities they were able to perform in a virtual environment, and the cat-and-mouse game they played with those trying to stop them.

…users of Second Life access the grid on the condition that they know that information like this is liable to be collected by automated scripted systems all over the grid and stored in off-world servers, with the blessing of Linden Lab itself.

This specific case to the side, what are your plans to react when griefers invade your Metaverse? Do you have an incident response policy ready, in advance of the situation, or are you going to wing it? Do you have a policy which would allow or deny your employees the ability to provide information to other users who are trying to counter the situation in-world? Do you know which operational controls might apply and how you plan to use them?

Consider this next example:

Minecraft Wiki: Griefing, “A massively destroyed castle.”

The Minecraft Wiki on griefing provides a good taxonomy of the methods used for in-world griefing. I’m not going to rehash their list, but it is far more complete than I would have imagined. Even better, they were thoughtful enough to include potential controls (solutions) which can be applied to existing servers to address these situations.

You may be designing a Metaverse right now, or maybe you’ve moved on to implementation. Regardless of what phase you are in, it is very good idea to review known vulnerabilities in these and other virtual environments to see how they might apply in your own Metaverse. Are these things that you can counter in your design, implementation, or operations? You need to be spending time on this now, not after deployment.

This is our introductory article on the topic of Metaverse security. Security is an issue we’re sure to hit again and from different angles. What else should we be thinking about when it comes to the security design?

In an earlier post, “The sci-fi Metaverse is bad (and you need to leave it behind)“, we talked about some of the notions we inherited from science fiction which shape our thoughts on how the Metaverse should exist. One such item is the open world concept. Another notion is of a single large contiguous (Euclidean) three dimensional space. These are romantic notions of the Metaverse, but do we really need them?

Second Life is an interesting example of both an open world and a contiguous Euclidean space. (This is the classical view of the Metaverse.) Land is a virtual resource in Second Life which is sold to players; it must be purchased in order to be used.

In Second Life, location can be important. The size to which your land can grow can be important. Sure, your avatar can teleport to almost anywhere on the map, but if you are so inclined, your can probably fly there as well. In 2011, almost 80% of the company’s revenue was from land fees. With revenue based on the constraints of real estate, Euclidean space makes a great deal of sense here. It is baked into the design, and with reason.

I find myself very attached to an open world. Sightseeing is a great Metaverse activity, even if Second Life has shown is that it isn’t enough to keep users engaged. I think the need here may be psychological. Without an open world, will we start to feel more trapped than empowered? Even though I can’t fly off the surface of Second Life and onto another planet, I don’t feel trapped. How open do we need? Perhaps there is a basic threshold which needs to be met.

WoWWiki, “Dimensional Gateway”

What about contiguous Euclidean space? In the countless virtual worlds of video games, we’ve been exposed to teleporters, portals, vehicles, and gateways which magically transfer us from one region to another. In many cases, they are the only way to travel to another region. Is this a problem for us? Not so much. An exception might be in those devices which only offer one-way travel. I think we instinctively want an open world, but as long as it is navigable, we don’t need contiguous space to get us there.

VirtuaView project on Indiegogo

Euclidean space may not be a real-world constraint that we need. For example, let’s visit a movie theater that you might manage in the Metaverse. If you are showing 50 different movies, do your really need 50 virtual floors to accomplish this? (I have to admit, one cool concept would be for a building to physically grow and shrink in height to dynamically create unique spaces as needed. In this scheme, a building’s height might represent its popularity. Navigation would have to be carefully considered, however.)

In Euclidean space, the number of seats inside each of the rooms would be limited. If you have a popular movie, do you need 20 theater rooms to seat all the avatars who want to watch that one title? Can you even manage the requirements of virtual space, and will your visitors accept that? If not, do you constrain yourself to only handle a fraction of the titles and a fraction of the people who might want to see them?

If you are selling movie tickets as content, you want to be able to sell as much as you can. You want convenience; your patrons go to the ticket counter, and they walk into the showing which is always on the first floor (or perhaps the grand theater on the second floor). You want them to always be in the same room as their friends (or perhaps consolidated with a large crowd of strangers to reinforce the idea that their decision to see this particular movie was a popular idea).

On the other hand, Euclidean space might be a real-world constraint that we conditionally want. If you are selling scarcity, you want Euclidean space. You might be an exclusive venue, and you want only the top movie to show in your establishment. You might want the theater to be sold out. You might want to use scarcity to support an image for your theater or to charge for the venue, not the content.

If you use non-Euclidean spaces in your design, be sure to keep in mind what kind of indirect message it sends to a user. If you deploy unique spaces nearly everywhere, then an area without one might read as common, or perhaps unimportant. An area that has a non-Euclidean space that doesn’t need one might read as personal, exclusive, or high-end — or it could just read as unpopular, lonely, abandoned or a one-off. Non-Euclidean spaces (or the lack of them) can be used to shape user impressions.

Surreal Adventures (canceled) on Kickstarter

How do you fit tens or hundreds of thousands of staterooms on a virtual cruise ship? Surreal Adventures planned to used non-Euclidean space to solve that problem.

The choice of where to use and not to use Euclidean space is going to be a core design factor in a Metaverse. We’ll revisit this issue later. In one such post, I’ll touch on this as one of the design choices dealing with complexity, scale, and back-end resources. Non-Euclidean spaces can also be a great way to handle some of these issues — if used thoughtfully.

What kind of metrics can we use to measure the success of a Metaverse?

We could measure the users. How many are there? How happy are they? How engaged? How long they stay? How much content they are consuming and creating? Something like like deviantART might measure and compare their success in these terms.

Conventional wisdom is that Second Life is a failure. But that all depends on how you measure success. Did Second Life take over the world? No. When it hit critical mass, was it able to capitalize on it? No. Is the business a going concern? Yes! They’re still in business, and they’re still bringing in new users, even if there is still an 80% churn rate in their new subscriber retention numbers. A publicly traded company that answers to shareholders might find that situation intolerable. For a private company, that might just be okay.

We can see that we can measure the success of a Metaverse is with business metrics. Do you have a reliable revenue stream? Are you able to capture revenue? Is the business growing? Are you going to be able to maximize your value and sell out to a larger concern?

When I look at Second Life, I see communication, self-expression, and exploration as three major goals that were strongly built into its design. But despite all of this, is there really much to do there? For most people, the answer is no. Why? The reason is that Second Life is too inwardly focused. How? Let me show you.

Activities in Second Life include sightseeing in Second Life, talking to people in Second Life, buying customizations for your avatar in Second Life, buying and populating property in Second Life, selling virtual goods and property in Second Life, playing simple games in Second Life. You see the connection that flows through all of these examples, right? They’re all inside of Second Life. They’re isolated from the real world.

What you do inside of Second Life has little impact on the real world (yes, there are exceptions). This isn’t just an issue of critical mass. When IBM set up shop in Second Life, could I go there to evaluate and then pay for a real laptop? Could I enter a technical support ticket for a device driver? Apply for a job? No, I couldn’t do any of those things in any plausible way beyond opening up an external web page. The reason for this was that Second Life is almost entirely divorced from the real-world, except for the people who inhabit it. It was like it was built with a meatspace firewall.

When American Apparel set up shop in Second Life, they got some publicity, sold some virtual t-shirts which only exist inside of Second life, and that’s about it. They weren’t able to directly translate their investment into sales. Is it any wonder that when the Second Life boom came in 2007, it went away as quickly as it came? What happens in Second Life stays in Second Life.

So here is my measure of a Metaverse: impact and influence; what you can actually accomplish. A Metaverse is successful in the degree that it is able to make an impact on the real world, be it material or influential. A Metaverse with a design goal of impact should be connected to real-world systems. I should be able to browse American Apparel t-shirts in the Metaverse and then actually buy them in real life from inside the Metaverse. I should be able to check on the status of my order. I should be able to make my voice heard to others and let them know how wonderful or how terrible those t-shirts were.

Source: Screenshot of pizzahut.com from 1994 via the adafruit blog

There was a time when the Internet didn’t have any significant real-world impact. Then, one day, ordering a pizza online was a very geeky yet amazing thing that you could do. In the novel Ready Player One, the author described a scene where two people in two different locations could sit in a virtual pizza parlor, order a pizza, and talk. They would order a real-world pizza which would be delivered, based on their preset preferences, to their front door. They would share a real-world pizza as they talked to each other online. Isn’t that where we should be heading?

I’m interested to hear what you think is important. What do you think? Should there be an ultimate goal and the ultimate measure of a Metaverse? What should we be baking into the design?

Second Life is a topic that is going to come up again and again, because it provides so many excellent concrete examples for a discussion on Metaverse design. Before it comes up for the first time, there is a thorny issue that we need to get out of the way.

In most cases, when I use Second Life as an example, I talk about the vanilla experience for an average user. One problem I’ve found in making observations about Second Life is that Second Life can actually be fairly tough to make general statements about it. For every general observation, there is likely to be one or more specific counter-examples. I don’t deny that these counter-examples exist, but I don’t believe that they fit the profile of the everyday experience.

I look at the image above and I tell myself, “This isn’t Second life.” It is, but it isn’t. It looks more like what I would expect to happen when Facebook collides with VR. While it is entirely possible for someone to make an avatar that so closely resembles and expresses themselves, this kind of representation seems more aspirational than typical.

As another example, I might make the observation that Second Life has a horrible user interface. What fresh hell is this?

Source: An exploded Second Life interface shot from Metaverse Tutorials.

If you managed to sit a non-technical family member in front of Second Life, they probably weren’t as curious as they were confused and frustrated. Movement? Awkward. Looking around? Awkward. Interaction? Awkward. The design pendulum swung way too far in favor of the minutia of virtual world management and away from simple usability.

I have no doubt that a defender of Second Life would tell us that it is actually quite easy to log in, explore, and interact. By setting certain options or using different viewers (software), the interface could be made more friendly for sightseeing and social engagement and still be functional.

The story of the user interface is similar to that of the avatar at the top of this post. An alternative interface that is simple and intuitive is Second Life, but at the same time, it isn’t Second Life. For the purpose of observation and comparison of virtual environments, we’re mostly going to stick with the vanilla user and the vanilla experience.

In the future, I may reference this post when a significant reference is made to Second Life. Is focusing on the general case a fair or unfair policy?