A bird’s-eye view of the Universal Asset framework
We’ve talked a lot about all the different components of our new framework, but now it’s time to get a more general overview. How will all these different pieces working together look like? Remember to check out our previous articles in this series, if you haven’t: The Universal Asset framework series.
The following image showcases the flow and general architecture of our potential UA framework:
As we can see in the above image, Universal Primitives (UPs) are at the heart of our framework. Everything dances around these UPs, they are what allow us to have true interoperability, and a high degree of customization flexibility, both on the end-user and world-builder sides. The framework is all about how these UPs and the resulting Universal Assets (UAs) are defined, created, stored, and used. For each of these tasks, we’re describing a tool that can facilitate this job.
These are namely: The Universal Primitive Creator (UPC), which is the tool we would use to create new UPs. The Universal Library (UL), which is where we would store and index all these UP blueprints. The Universal Asset Creator (UAC), which is the tool we would use to create the final form of an interoperable asset based on a selected UP, attaching to it things like the 3D files for representing that asset. And the Universal Primitive Translator (UPT), a piece of software that every world-engine would have, in order to digest/interpret the information contained in the UPs, and translate them into the correct language and code that a particular world-engine understands and can work with; resulting in the starting point for in-game asset creation, that respects all the specifications from the UP it’s based upon.
The Universal library is probably the only one of these pieces that would be truly unique and singular. We do not need to have many libraries, and it would probably be more efficient and effective to have just one. All the other tools however, don’t need to be exactly the same, as long as we can create a specification for them, so that all resulting UPs and their handling is consistent, they can be made in different ways, there can be multiple different versions of them. For example, UPTs necessarily have to be unique and tailored to each world-engine, it will be the job of each one of these world-engines, to create the necessary UPT so they can interpret and translate UPs into their worlds. Other tools like the UPC or the UAC, could go both ways. We might have some official versions or some variants that are more popular than others, but we don’t need to have just one.
This is just a view of what we’ve discussed so far in this series, in the future we might need to add more modules and components to our UA framework, or to expand what each one of these components does. But this current architecture gives us a nice view of how all these pieces will work together, and the flow of usage for both world-builders, UA creators, and end-users.
Final remarks
As we can see, true interoperability, composability, and customization flexibility for the Metaverse, will not be easy feats to achieve. In our case it requires the creation of a novel class of assets, the Universal Asset — and its blueprint, Universal Primitives; plus a whole ecosystem of tools to handle and utilize these new primitives. Perhaps we’ll find simpler solutions in the future, but so far I haven’t seen any real alternatives for achieving true openness, interoperability, customization flexibility for Metaverse assets, potentially interoperable functionality, and making the creation of virtual worlds easier for non-coders, all in one coherent and consistent framework.
