Scaling the Metaverse. To infinity and beyond!
Check out previous articles from: The Universal Asset framework series.
The Universal Primitives (UPs) library is the backbone of our Universal Assets (UA) framework, and this library can be scaled as much as we want it to. Any person or company should be able to create a new instance of an already existing type of UP (like a new weapon category/box), by following a specification or blueprint defined for that type of UP. These blueprints will likely have some sort of governing structure that allows us to update them or modify them if necessary. People might even choose to create standardized blueprints for never before seen types of UPs.
In this way, UPs can be viewed as nodes or cells in our library, that over time multiply, differentiate, merge… New UPs can be created in minutes by humans, perhaps in fractions of a second by AI. Potentially billions of people helping grow a library, that not only benefits their creator, but the entire Metaverse ecosystem.
Connecting tissue
UPs may look like nodes of a network, but they are so far only loosely connected to each other (if they belong to the same UP family type), or not at all. It might be interesting to try and create further connections and relations between them, a sort of connecting tissue. Perhaps new types of UPs specially designed to be relationally dependent or connected to other UPs will arise. As we’ve discussed in previous articles, this might be a way to encode some gameplay dynamics in the form of connections or structure between a subset of different UPs in our library.
Each particular choice of nodes and set of connections/links — that might be represented as some sort of graph — is likely to provide us with different outcomes. We don’t need to connect all of them together, or even in a symmetrical or even manner. Different people might discover that different structures of nodes and links are more fun or interesting than others. We now have a new dimension of growth and complexity, not only the number of UPs or nodes in our library, but also the number of connections/links between them.
UPs are of course still very useful to us with minimal or null connection between them. These connections are additional information that might or might not be useful to any given virtual world, and as always, they should be able to discard or modify as much or as little of this information they want upon importation. Now would be a good time to make an important remark about the nature of these UPs, and their possible connections.
UPs are not new capabilities
So far we’ve described UPs and their possible interconnections merely as informational or structural data, this provides us with a couple of desirable properties. We do not want them to be big chunks of code in the form of extensions or plugins, that give new capabilities to our “world-engines” as we’ve been calling them. This would make them too different from one another and hurt the ease of their importation into any given world. Virtual worlds will likely be created with a series of different world-engines, that were built using different programming languages, conventions, restrictions…
We don’t want to impose any technical choices upon these different world-engines, which is why a technology-agnostic approach could prove much more beneficial. UPs and their connections should not be viewed as programs, but merely as inputs (imagine something like old punched cards). It should be up to each individual world-engine to develop the necessary capabilities to interpret and integrate this input of data into them. World-engines need only to preserve the definitions and structures of the data they are importing.
This also means technology shouldn’t become the limiting factor to scaling our library. UPs and their connections are well-defined data, and structure between this data, that shouldn’t have any external dependencies. We want our library to grow and scale independently of how the current technology at any given time is progressing. The process should be automated, so that upon importing the data from the UP belonging to a sword for example, the world-engine automatically creates a new object, uses the data imported to specify the parameters and values for that object, and hands it over to the world-builder. The same for any gameplay mechanics being imported.
Test servers
Given how adding new UPs and mechanics to an already live system might be problematic — but as we’ve discussed in other articles any given virtual world is likely to have many different servers or world-instances — it probably makes sense for virtual worlds to have a public test-world or “beta” world, where new additions can be tested and balanced with the help of players, in an environment separate from main or “stable” worlds.
Players that want to help play-test future upcoming capabilities can enjoy them in advance in the test world, and provide useful feedback. And new features can be tested ahead of time in a safe environment. Our virtual worlds need not stay the same as it launched on day one. They too evolve and become more complex and interesting as the Metaverse as a whole grows.
Final remarks
The older and bigger our UP library becomes, the more nodes and connections between them we have, the more interesting our Metaverse should get. We can hierarchically build more and more complex systems upon this foundation. Who knows what emergent behavior might arise? All being built in the open, by the people for the people. AI is likely to help us with the task of handling and even expanding this ever growing library…
“A system of cells interlinked, within cells interlinked, within cells interlinked within one stem...”
—Vladimir Nabokov, Pale Fire.
