I'm blogging Matthew Ball’s must-read, nine part metaverse primer over the Summer; my take on Part 1 is here, my coverage of Part 2 is here, with Part 3 coverage here and Part 4 coverage here.
In Virtual Platforms and the Metaverse, Matthew Ball gets into potential ontological territory by making a distinction between virtual platforms, virtual worlds/online games, and what it takes for a given product to have essential Metaverse features.
In Matthew’s view, a virtual world — and his definition of ”virtual world” is broad enough to include the online versions of Animal Crossing and Call of Duty — can sometimes be a virtual platform, but that’s not always the case. A virtual platform with Metaverse qualities, as he defines it, must have this:
[T]he technical ability for (relatively-unbound) creation (engine + studio + tools), services to support it (prefabs and asset marketplaces, voice chat, player accounts, payment services), and operate a multifaceted economy (i.e. consumer spending that’s shared with on-platform creators/developers, as well as creator/developer-to-creator/developer revenues). In success, these platforms generate a virtuous circle. Better technology and tools lead to better experiences, which brings in more users and more per-user spending, which means more platform profits through which better technologies and tools can be produced, as well as greater creator/developer profits through which better experiences can be produced, which attracts more developers and more users, etc.
The comic irony, as he notes, is that all attempts to explicitly create The Metaverse have failed or fallen short (hello, Facebook Horizons), while fun online games like ROBLOX and Fortnite have, as they become vertiginously popular, evolved to become more and more like virtual Metaverse platforms.
As that happens, the underlying technology that makes both virtual worlds and platforms possible — specifically, the 3D graphics engines Unreal and Unity — have become robust enough to enable powerful enterprise applications:
Hong Kong International Airport was famously designed in Unity, a leading game engine. Unity wasn’t used because it’s the best tool to design an airport — that’s typically rendering software purpose-built for the architecture industry. Instead, Unity was used because it was superior at simulation. As a game engine, Unity could not only render a not-yet-real environment, but realistically stress-test it for fire, a flood, a power outage, backed-up runway, and for the flow of humans in an emergency. This was, itself, an enormous leap. And it’s one now being used in countless other areas, from industrial engineering to film. Cars are being designed using simulation/game engines, then this same software is being deployed in the end-product. Hummer’s dashboard UI is now based on the Unreal Engine and can simulate the vehicle live.
He points to Nvidia’s Omniverse as a potential means of connecting enterprise use cases like these together into a prototype-ready mirror world, enabling us to simulate entire systems, to better improve the ones we have, and design new ones.
This all looks roughly right to me — except for a single point of unresolved mystery:
(more…)
