Tag Archive | Metaverse

Wrapping Up: A Novel Metaverse Architecture

We’re skipping ahead to the very last chapter in our Metaverse design story: the reveal of a brand new architecture.

By now, it is clear to me (as much as it is to everyone else) that my interests have moved on. So, no fancy pictures this time, and no more groundwork. I’m not going to walk you through how we arrived at this final architecture. If you’ve followed the many articles along the way, it shouldn’t be hard to determine the specific problems we were trying to solve, and to extract the many pieces of unique value which are embedded in the design.

In short, by focusing on the right thing, it isn’t hard at all to initiate a Metaverse. In fact, all things considered, it is shockingly easy. And not just “a” Metaverse but “The” Metaverse. Part of the secret is to give the community an incredibly simple core element, and to allow them to build something that is far greater than any of its individual parts. Let go. Don’t try to control everything. The tighter you try to control The Metaverse, the more you destroy its core value. Stop it!

Another part of it relies on letting go of the science-fiction definition of a Metaverse (and the Second Life defintion of a Metaverse). We have to build The Metaverse using what we already have on hand, and invent as little as possible. We can’t tell everyone that they’re wrong. We have to show them how they’re right!

Guess what? We’ve got a architecture that, among other things, nullifies that pesky issue of critical mass and chicken-or-the-egg. In fact, it tackles a host of other problems that you probably never even knew existed. So how do we get there?

We start by building a minimal Metaverse. What is the most basic element of our real-world Metaverse? Is it identity? Is it an avatar? A massively shared space? No. In fact, it is something much simpler. We define the most fundamental Metaverse (and the value that it provides) based on hyperlinked spaces. We transport the user from one experience to a completely different experience. At its most basic level, The Metaverse should exist to connect and transition users between between experiences, even if they come from completely diverse sources, using completely different programming techniques. The Metaverse links two or more isolated experiences in a way that creates new value.

We could climb the cosmological stack, and perhaps even call it a Hyperverse (a play on “hyperlinked experiences”) or even an Omniverse (the sum of all experiences). Okay, I should stop here because this is quickly becoming pretty abstract… maybe even a bit strange. I’ve got to pull this down to Earth and explain a bit more.

The difference between Metaverse VR applications and today’s VR applications is that in The Metaverse, applications are built for hyperlinking. So, this means two things. First, that from your application, it would be considered completely normal to pass the entire user experience from your application to some specific point in the next application. If you want to be literal about it, okay, we can do that. We could use a door as our metaphor. A user could open up a special door in your application and walk through it. Unimaginative, but fine. They cross the threshold and control is transferred to the outside application. Your application ends.

The other thing is that you should expect that other applications will want to link directly into YOUR application. Your application is called by other applications. Other applications are called by your application. The underlying model is actually somewhat old (in Internet terms) and well proven: the 1990s Internet Suite.

Beyond that, consider that most people don’t just want to link to the front door of your application. They might, but that’s pretty boring. They want to link to deep content inside of your application. As deep as you’ll allow. You should identify specific spaces or experiences which are deep inside of your own application for others to be able to link into, and then to provide an easy method for them to directly get there, such as with some specific command line arguments.

So your application should expect to be launched from any other application, and you should expect that people will want to reach a specific destination inside of your application by using whatever specific command line arguments you are comfortable with. The destination could be derived programmatically (with any necessary safety checks) or they could be hard-coded by you, the designer. The more choice, the better, but as much as you are comfortable with.

Hyperlinked experiences are the real future of VR. They will allow you to create the best possible experiences in virtual reality, blended together, without the restrictions and limitations of language and protocols and engines. You always choose the best engine and the best language and the best middleware for your own application, given the constraints of your project. Give yourself permission to build the best application of its class using the tools you want. As you find opportunities, you’ll hand off the user’s experience to others who have done the same. Or maybe you’re not a programmer, but you just want to design your experience inside of someone else’s application without fear of it being trapped inside of a limited bubble. The Metaverse can help pop those bubbles and open up your content to a larger audience.

Remember that critical mass issue? As long as an experience doesn’t do anything foolish, like start in a 2D window or with a ridiculous splash screen, even if it isn’t Metaverse aware, by default, it is capable as acting as a leaf node in The Metaverse. It may not be able to launch other experiences, but it is able to be launched (and by other applications) from within The Metaverse. “The Metaverse? It’s so easy to join!Any application. Any media. It is all part of The Metaverse.

Not every corner of the Metaverse needs to be massively multiplayer, or even an online experience. Who knows, one day my bank might want to create a virtual reality or a Metaverse banking application. Do I need to risk sharing my private transaction with millions of other people? Of course not. Each experience retains full control of its own boundaries. If it doesn’t want to be a fully shared space, it doesn’t have to be. If it has intellectual property or sensitive information that it needs to protect, it should be allowed to protect itself as it so chooses.

Some people will specifically create pure leaf nodes for The Metaverse. Build the best-in-class multiplayer “shrine” application and watch people build their shrines within your tool and then link to them from all sorts of other applications. You may be linked into by other applications that you did not know even existed! In the early days of the Internet, everyone started to build an email client into their application. One day, programmers learned to just let the user use their favorite email client, which was far higher quality than anything they could develop on their own. It’ll be the same for VR.

When we have hyperlinked experiences, we allow a whole new class of VR experiences to blossom that we don’t yet see today. Those are the experiences which aggregate people together, and the experiences from which people branch out from once again. A VR experience for, “I’m bored, what is there to do in VR right now?” A VR experience for searching other experiences. A clubhouse for like-minded people. These are the new experiences that will exist between today’s VR experiences. Do you like social spaces? Some might be social spaces. The opportunities are limitless.

The Metaverse isn’t a web. It isn’t a tree. It isn’t a central star configuration with a launcher application in the middle. It is a collection of nodes which can assemble in any which way their designers allow and the users choose. The nodes (the experiences, the applications) must assemble into the shape chosen by the users. Nodes launching other nodes launching other nodes. Nobody is in the center except for the user who acts to glue the Metaverse together, on demand, inside of their own PC, in real-time. The Metaverse is an amorphous blob, given shape by the user.

Once users see this in action, I don’t think they’ll have much trouble wrapping their heads around it. As this approach catches on, it will quickly become clear that some standardization is needed. People might want to use standard URIs which could represent a protocol (at first, they are more likely to represent specific programs). Early on, I had imagined a facility on your local machine that translates URIs such as vr://vrchat/room/900 into specific command line parameters used to launch a specific application (an application which may or may not be Metaverse aware). But still, a piece is missing.

It is easy to tell a programmer that their application might be called by another application. It happens today as a normal part of being available in SteamVR or Oculus Home, for example. It is another thing, however, to tell an application that they must call other applications. Now you have a whole new set of problems to juggle. Let’s avoid that. The same component that does the translation from URI to binaries with command line arguments will also serve another purpose: to be the parent process which launches, monitors, and kills VR applications. It is called The Matrix. (Don’t laugh! It actually manages to work out pretty well.)

The Matrix inherits its name from the fact that it manages the transition between two programs (from an application perspective as well as from a user’s VR perspective) by negotiating a match in the matrix of potential transition capabilities. Depending on what features the current experience and the new experience support (if any), the Matrix negotiates an appropriate application transition and visual transition between two applications.

A round photosphere that is smashed into the ground? A shared room between them, such as a rigidly defined white hallway or holodeck grid? Or maybe the lights go bright in one experience and then dim down to normal levels in the next experience? From a programming standpoint, the general method will be for the calling program to give the new destination URI to The Matrix, the Matrix to inform the program of which of its pre-approved methods of transition will be used, and then to use that method to transfer control.

Will this be a carefully negotiated shutdown or will it be a cut to black and a hard kill of the calling program? Will there be shared room contents and user positional and orientation data until the exact moment of transition? That is the job of The Matrix to coordinate or, at worst, to directly perform a minimal transition by itself.

The Matrix will be the compatibility layer that needs to be aware of what Metaverse applications are installed on the local platform, and how to launch them. Later down the road, it might be useful to have an installer functionality bundled into it so that it can install new rich applications on demand. But it’s not required.

There we have it. A new Metaverse architecture that is engineered to be simple yet packed with value. Any number of applications can launch and be launched with minimal effort. A simple hard-wired (“baked”) proof-of-concept would take minimal resources to create. A fully functioning system will take more.

Along this early road, there will be some wrinkles. For example, in the world of 2D applications, World of Warcraft doesn’t have the same display and control schema as Team Fortress 2, or as another title like FTL. This is by design, and users accept this. They realize that there is value in letting each experience have its own unique set of controls and its own unique way of displaying things. Will this be the same in The Metaverse? Maybe application designers will arrive at a commmon control schema? Or they might decide that inheriting a set of common controls is a feature that The Metaverse should provide for them.

Users also understand that they can’t bring their FTL starship into Azeroth, which is the intellectual property of Blizzard, or take their toon back into FTL. Hopefully they will find the same level of understanding when it comes to The Metaverse.

Once you have a very loose structure where VR experiences which can be linked together, we start to create a shared community of users, programmers, and experience builders. As the value of a Metaverse experience starts to prove itself, the participants begin to take their seat at the table. They see that it demonstrates real and unique value. It begs for enhancement. Above all, the ability of a minimal Metaverse to bring the interested parties together may be the most understated value of the entire design.

That community may decide that they want an even richer experience with more features. A single identity? A shared avatar? Services that persist through multiple services? On top of the thread that connects applications, they might look to build a rich new thread that runs between and through applications. One we bring all parties to the table based on the value of hyperlinked experiences, this and so much more is possible.

The first step in building The Metaverse isn’t to build something complex and crazy. It is to start with a minimal Metaverse experience based upon the value of hyperlinked experiences. Start the Metaverse by linking together diverse virtual reality experiences, demonstrate the value of connected content, and the rest unfolds from there.


As mentioned at the top of the article, I am moving on to other personal interests. If you have any questions, you may click on the title of this article and use the Reply feature at the bottom of the page. You may also email me privately at my Yahoo! account with a username of jmccorm and a subject of Metaversing. For a limited time, I’ll be happy to answer your questions, clarify or defend any aspect of this unique Metaverse architecture, or just bat around some ideas.

To my loyal readers over the years: thank you!


Defined and Explained: Creating the Metaverse in the Real World

Virtual world image. Copyright 2015 by kran77 / 123RF Stock Photo

Two years ago, I restarted my effort to make sense of the Metaverse. Today I can confidently tell you that I understand what the Metaverse is in the real world, and how it actually works. You’re about to understand it, too.

  • What is the Metaverse?
  • What purpose does it serve?
  • Where do we begin our efforts to build it?
  • What new applications can we make to take advantage of it?

Have we cracked the code? See for yourself if this article delivers those answers in a meaningful way.

What is the Metaverse? The real Metaverse?

No, not the one we’ve seen portrayed in science fiction. Also not the large software project which creates connected spaces for people to design their own worlds in. Not the intellectual notion which claims the sum of all media, yet offers no direction on how to get there.

So many of us say that we want the Metaverse, yet this decades long journey has been so frustrating. For the most part, we’re able to agree on something that is so clearly illustrated, yet we’re unable to say what it really is and how to implement it. Why? Read More…

Fundamental Problems with Metaverse Implementations

INTRODUCTION

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 Metaverse (image copyright 2015 by <a href="http://www.123rf.com/profile_michelangelus">michelangelus</a>)

The Metaverse (image copyright 2015 by michelangelus)

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. Read More…

IBM Patent Claims to Invent Group Travel, Except “in the Metaverse”

IBM is no stranger to virtual world patents.

Last year, we looked at how we would implement travel between unrelated virtual worlds, when we accidentally stumbled across an IBM patent from 2013 which touched on that very concept. IBM described a system that would read your personal profile (friends, interest, age, etc) and teleport you to a region in your destination that compliments your profile.

This month, the US Patent and Trademark Office published a new patent application from IBM, called System and Method for Group Control in a Metaverse Application. In short, it looks like a standard method for online group travel, except, “in the Metaverse”.

The concept is simple. The patent details an innovation where a “group link engine” allows users to be invited into a group. Once inside the group, a leader can control their actions. They then add in additional obvious claims, such as the ability to transfer leadership, to temporarily remove a member from the group, to send out invitations to the group, and to record movements.

Are we witnessing the start of patents which take an obvious concept and then claims that it is something new because it is “in the Metaverse”? One can only hope that the USPTO can see through such obviousness.

A Review of Portals in Virtual Worlds

BACKGROUND

A year ago, we started to look at how we might travel from one virtual world (anything from a simple program launcher to a more complex program like JanusVR) into a completely unrelated virtual environment.

As I searched for some consensus on how portal should look and operate, I wasn’t able to find any good guides which cover the topic. (The extensive use of the word portal by web-based companies has made it a particularly difficult topic to search.) This article is a (non-exhaustive) review of portals as a popular method used in virtual worlds today to transport the user to entirely different regions.

What are portals? Portals are typically objects or areas in the environment which advertise the ability for a user to approach and engage them in order to be teleported to a new location. Traditionally, they are placed vertically along a wall (and walked into), but they can be placed horizontally along the floor (and stepped onto). An additional action may be required, before or after moving an avatar into the aperture, to actually engage the portal.

Portals won’t be the exclusive means of long-distance travel within and between virtual worlds. What portals have going for them is that they’re already commonplace in virtual worlds, they can be visually integrated into many themes, and they’re easily understood by players.

In JanusVR, portals take center stage as the method used to connect otherwise unrelated virtual worlds.

In JanusVR, portals take center stage as the method used to connect otherwise unrelated virtual worlds.

Read More…

Metaverse Observations and Beliefs

This article contains a listing of some metaverse observations and beliefs.

There do not appear to be any similar lists to compare this to, so your feedback on this list (and what is missing) is appreciated. I know that many of you can be tough critics, but constructive criticism is welcome. On the other hand, if this list strikes you as boring and unchallenging, that’s welcome news for me.

Observations

VR hardware and software is evolving rapidly.

  • Hardware and software solutions are not stable
  • Large investments can quickly become irrelevant
  • Poor solutions are quickly replaced by better ones
  • Continued investment is needed to stay current

There are limited rules for deciding what a metaverse is or how it should behave.

  • Many definitions exist
  • Fundamental definition is the ability to experience and perform actions with others in shared virtual spaces
  • Guided by previous attempts at metaverse implementation
  • Guided by current metaverse implementations
  • Guided by existing virtual worlds
  • Guided by science fiction

It is difficult to create a metaverse.

  • Barrier to entry is high
  • Expectations are high
  • Investment period is long
  • Significant investment required in money, people, and resources
  • VR ecosystem is rapidly evolving, adding to risk
  • Return on investment is unproven and uncertain

Competition already exists. There will more than one metaverse.

  • Stranded content
  • Fragmented userbase
  • Increased innovation
  • Increases risk for metaverse providers, developers, investors
  • Increased choice for users, developers, advertisers, investors

There will be many different possible sources of revenue for a metaverse provider to choose from.

  • Transactional advertising (“click here for our store”)
  • Brand advertising (long-term exposure to brand “Nike!” “Nike!” “Nike!”)
  • Connection or usage fees by users
  • Connection or usage fees by commercial developers
  • Premium content (models, features, events)
  • Premium services
  • Special placement of content/locations/events
  • Rent, building or land ownership, and development
  • In-world currency and in-world transactions
  • Cloud storage services
  • Cloud hosting services
  • Consulting services

Beliefs

  • For most companies, the metaverse will be used as an opportunity to extend their existing business models.
  • In the short term, major metaverse platforms which intend to use surveillance or data mining of their clients are less likely to fully disclose that information for fear of backlash and reduced adoption rates.
  • In the long term, major companies which are currently engaging surveillance and data mining of their clients are expected to continue that practice on a metaverse platform.
  • A metaverse does not need to limit itself to real-world constraints just for the sake of closely simulating reality.
  • The more complex and integrated a platform is, the slower that innovation becomes.
  • Users and developers are dependent on platform providers for technological innovation.
  • While competition can result in waste, it still remains a net positive for metaverse development. A competitive market is good.
  • The choices made in the initial design of a metaverse are critical to its character and its success.
  • A general-purpose metaverse cannot succeed inside of a self-contained bubble. It must interface with the real world to be successful. (Novelty will bring the users in, but utility will keep them.)
  • A metaverse could be embodied in different forms which have yet to be demonstrated.
  • A metaverse is most likely to be created and maintained by a small team effort, web-based company, or gaming company (rather than the telco or an organzied non-profit model as given in science fiction).

How do you Solve the Metaverse Problem?

When you meet someone who has a metaverse or virtual world project, ask them what they’re creating. If their answer is something like, “I’m creating a engine in C++ that uses a distributed computing to present an interactive world that is defined by point clouds”, they’ve only described their solution. Do you fully understand the problem that they’re solving? More important: do they?

An artist's interpretation of the Systems Engineering process. Source: Penn State Lunar Lion Team

An artist’s interpretation of the Systems Engineering process. Source: Penn State Lunar Lion Team

I came across a great quote about systems engineering at Wikipedia. “The systems engineering process must begin by discovering the real problem that needs to be solved; the biggest failure that can be made in systems engineering is finding an elegant solution to the wrong problem.” When we’re making a Metaverse, what is it that we’re trying to solve?

When I read the quote above, it resonated with me. Why don’t we make a fresh attempt to start with needs and then work towards a technical solution? Who’s problems are we trying to solve, what are they, and how important at they?

We are going to try to understand the needs behind something that is very thorny: a metaverse project.


It is worth pointing out that even though we’ll start our focus with needs and we’ll end up at solutions, we’re still following the same path that has been made many times before us. We’re going into this by saying that our solution is a metaverse. The only uncertainty is what form that metaverse will take.

The mistake? We’re defining the problem in terms of a solution. At least this time we recognizing that fact up-front. Perhaps this illustrates yet another reason why the very attempt to intentionally create a metaverse can result in its failure.

Now, back to determining needs…


The Users

To understand the needs that drive a metaverse, we could start by asking people what they want or need in their everyday life. (Finding an expert summary would make more sense.) It might be hard to turn their answers into something useful, but I think there is a lot of insight into basic human needs and desires that shouldn’t be easily dismissed. Read More…

A Review of Earlier Articles… and a Return to Metaverse Issues

Nine months ago, I wrote my last article on the Metaverse.

It was a short piece, mostly referencing an email from Fabian Giesen, a demoscene coder (and more) who was doing some VR work at Valve as a contractor. I’ll be honest, his message was a real downer for me, and I had my own Notch moment. Why was I working towards something that, if successful, would ultimately be used just to provide value to Facebook?

Over the past nine months, a surprising number of you have told me how those early Metaverse articles had actually been very helpful to you. A few of you said that you had a Metaverse effort going, but most of you were creating multiplayer virtual environments. Thank you all for your feedback and support!

I think the moment that it all crystallized and brought me back to Metaversing was seeing the return of Valve with the HTC Vive. Suddenly, it seemed like there were possibilities once again. Thanks, Gabe. I’m looking forward to learning more about your shared entertainment universe… perhaps a non-traditional Metaverse? Read More…

The Wolves of Virtual Reality’s Eternal September


This is the second article (in a series) on issues that face the virtual reality community as it enters a period of rapid and sustained growth. If you need additional context, please begin with the first article in the series, “Before the Eternal September of Virtual Reality“.


Image Source: Wolf Quest (3D wildlife simulation)

Image Source: Wolf Quest (3D wildlife simulation)

The Wolves

Along with a massive influx of new users, how much thought have we given to malicious actors entering the fold?

Griefers aren’t anything new to virtual worlds. In last year’s article, Griefing and the Metaverse, we explored some of the problems that persistent virtual worlds have faced. In recent history, our new virtual reality applications have had precious little exposure to malicious actors. We can expect our isolation to end as more people begin to own VR hardware.

Developers, are you validating inputs on the client side and the server side? Are you hardening your multiuser code against those who would intercept and change their own network packets in-flight, or modify variables inside of application memory? Are you even creating an audit trail of anomalous events? Probably not. Very quickly, we’re going to attract the sort of crowd which will exploit such opportunities. Read More…

Competitors with Different Goals: Valve versus Oculus

The recently announced HTC Vive looks to be a strong technology competitor against the highly anticipated consumer release from Oculus in the PC space. While Oculus has long-ago stated that they are working to deliver their consumer VR headset at a lower margin, possibly even at cost, HTC/Valve has announced their entry of a premium VR experience.

A Different Focus

What is overlooked by many is that while these two companies compete in VR hardware and software, their focus couldn’t be any more different. Read More…