Imagine making your way through a crowd, thousands of people donning anything from casual wear to the most over-the-top dresses. Even though the place is absolutely packed, you don’t have to use your elbows to shrug past. Like a ghost, you pass through anyone you encounter, and they go through one another as well, turning the regular Brownian dynamics of the crowd into something truly phantasmagorical.
That’s how crowds worked in “Snow Crash,” the 1992 novel by Neal Stephenson that introduced the world to the metaverse. But how will Meta’s version handle them?
This question is not nearly as trivial as early impressions might suggest. Even though we are yet to witness this all-encompassing digital reality, pundits are already breaking spears over just how amazing or dystopian it can be. Ironically, the answer in both cases greatly depends on the code and the data infrastructure that will power every interaction in the realm.
When you make your way through the proverbial crowd in a metaverse, your VR headset has to render every other avatar next to you according to your perspective and spatial location. When you bump into someone, the back-end servers have to calculate the physics of your interaction, ideally with a full account of the vector and momentum of your movement.
Then, optionally, they must send the appropriate signal to your haptic gloves, suit or any other device you’re wearing, which would translate into the actual impact you feel.
The metaverse that today’s data infrastructure can handle is a very segregated one — a network of small digital spaces for tight groups.
Our example here requires a lot of computation, even when it involves just two avatars running into one another. The task of processing a multitude of such interactions in a crowd of even a few hundred avatars is probably enough to send a weak back-end server into a meltdown.
And let’s not forget that inputs guiding the motion of every avatar are beamed in through optic cables, with different latencies, with lags, which makes running the entire thing without shattering the suspension of disbelief that much more challenging.
From a stage dive at a virtual rave to a digital beach volleyball game, this holds true for any other interaction involving many digital personas operating through precise motion controls.
The idea of bringing thousands of people together in a virtual space is not exactly new: Online multiplayer games have been doing that for a long time already. In fact, Fortnite has already hosted metaverse-style concerts with as many as 27 million people tuning in. So surely it should be a piece of cake for Meta to do as much?
Well, not really. As always, the devil lurks in the details.
Divide and render
While the gaming industry can indeed teach Meta a thing or two about online interactions, even the vastest and most ambitious multiplayer realms rely on clever tricks to avoid back-end overload. The general rule of thumb here is to actually avoid cluttering too many users together in one digital location at the same time.
In other words, they avoid the very thing the metaverse, with its live event ambitions, wants to achieve.
Staying with the Fortnite example, let’s quickly note that the game is running on state-of-the-art infrastructure that processes 92 million events per minute. With millions of active players, Fortnite’s back end has to be ready for some very heavy traffic while also performing all the player data analytics it needs for marketing. Quite simply, the data piping the company has built deserves applause.
Now, when handling its massive live events, the game doesn’t clump all of its millions of attendees into one place. Instead, it splits players into 50-strong clusters, or shards, to which it streams individual simultaneous instances of the live event in real time. This shard-based approach is generally shared across such projects, with players split across multiple servers and digital localities to keep everything running smoothly.
More layers of complexity
While there’s no telling how detailed Facebook’s metaverse will become, its apparent focus on VR and AR does make things more complicated on the back-end side, as it gives computers more inputs to track.
At the very base level, we need to track a metaverse-dweller’s hands and head, at all times, to get their line of sight and process their interactions with the world through a physics engine. This requires way more precision than, for instance, what Fortnite is doing. As an example, the game handles dancing as a predefined animation that a player triggers with a button. Sure, you can do it with VR/AR, too, but it surely would be more engaging — and computation-heavy — with actual motion tracking.
In other words, even baseline metaverse functionality, like a VR chat with simplistic physics, is already quite a workload for the servers. If you want to add more sci-fi features, like an algorithm that will have avatars display the users’ emotions with facial recognition, you can have the client-side devices do the number-crunching. But it’s still data that has to be processed, analyzed and rendered in real time, adding stress to servers.
The phantasmal crowds from “Snow Crash” may be a good workaround, and there are many other ways to tackle this problem. Nevertheless, all this points to the larger challenge the metaverse is facing — a world made up of data has to rely on efficient, dynamic, flexible and robust infrastructure that can handle a lot of number-crunching and deliver all the relevant signals quickly. So far, it does not look like we’re quite there yet.
Taking this one step further, what about the scenarios where the metaverse itself works as infrastructure, with Meta and other companies writing new apps on top of it?
Let’s say we want to add an app that will allow users to access Google Docs with a gesture: turning the right palm upside down. Once the user sets off this event, the app will need to link with Google’s API, pull in the data, process it and render it for display. When editing a document, we will need to convert the user’s inputs, whether it’s motions or keystrokes on a virtual keyboard, into a format the Google API can understand while continuing to process the incoming stream to display the edits live.
Just this quick example makes for a whole new challenge for the metaverse backbone. To enable handy little things like that, it will need an architecture that supports dynamic changes to both its data piping and logical architecture in line with the apps’ requirements. Furthermore, this has to happen without significant performance dips, so that our app does not annoy the user with lags every time they want to check a new edit on a shared presentation.
The metaverse that today’s data infrastructure can handle is a very segregated one — a network of small digital spaces for tight groups. Its growth and adoption across industries will largely be driven by the development of the underlying hardware and infrastructure.
The bad news is that we’ll have to wait for all that’s promised for a while. The good news is that even if the metaverse ends up being a boring VR amusement park, the technological legacy it may leave us with will be immense enough to make it worth trying anyway.