Systemic Issues in Metaverse Implementations
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.
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.