Plug-and-play game mechanics for the Metaverse (Part 2: Electric Boogaloo)

Checkout the previous articles from: The Universal Asset framework series.

In our previous articles we’ve discussed how our Universal Asset (UA) framework could allow us to build some of the basics needed for a combat system. Now we’re going to expand upon the previous article by introducing status effects, and explain a bit more the bigger vision we have for this Universal Asset framework.

Status effects as Universal Primitives

You guessed it, status effect can also be universal primitives (UPs). Our goal throughout this series has been to lay down the framework for how we can achieve true interoperability of assets, and empower user-generated content (UGC). The way we’re trying to achieve this is by building many of the components needed to construct a virtual world and its gameplay mechanics in an open and decentralized way, also favoring modularity and compatibility of all these pieces, so that people can pick and choose—just like in cooking—the ingredients they want to use for their particular needs.

These Status effects UPs we’ll talk about describe many ways in which we can temporarily alter the stats and behavior of the player’s character. They are triggered from the environment or incoming attacks, and are typically accompanied by their own bar or meter, that triggers the status effect when the bar is completely filled or drained. Some typical status effects in games can be poisoned, burning, electrified… But we can also use them, without having an associated bar and letting them be triggered instantaneously, for casting spells, upon the player themselves or their enemies. Spells that can alter the stats of players, such as buffs or debuffs of certain types of damages or resistances, or stats like fall damage, poise, noise…

The data these status effects UPs need to contain are things like:

• Whether they’ll affect some of the already existing bars/meters of the player, such as the hp bar (for damage), or have a new septate bar (for like example the burning status effect).
• The specifics of what stats/parameters of the player they will modify upon activation of the status effect.
• Visual assets, or other additional data/information.

Character UPs?

I want to focus on the second bullet point. This is the most important part of the status effect UP. In order to make any status effect UP importable and compatible with any given virtual world, we need to make sure that the stats or parameters the status effect UP wants to modify are present in the player’s character. This could be done via a simple check upon importation, or perhaps we might even see UPs for character stats and attributes. This would allow us to check which set of status effects UPs are compatible with what set of character UPs.

One of the great things about turning most things into UPs, is that we might eventually link them to one another, not only the UPs themselves have usefulness, but we can create different types of connections, and build different game systems via these connections, but we’ll leave that for future articles. One of the reasons we go through all this trouble of taking components of gameplay and world-building and turning them into UPs, is that once we have a set of specifications or standards on how these UPs sounds be created, with the help of blueprints, any person should be able to create a new UP.

Any person can decide to create a new spell or status effect, upload it to the public library of UPs, and now any virtual world can decide to import and implement it into their world. The UP library is like a buffet of gameplay mechanics, you can pick and choose what you want, potentially among hundreds, thousands of choices.

Ideally in such a way that all importable UPs are compatible and composable, at least with all other UPs present in the library. Entire game systems, such as magic systems, might be built by simply defining a series of connections between a certain set of UPs, these systems of objects (UPs) plus how they’re connected — with the use of modifiers for example—can become their own meta-UP, also importable into worlds. The game rock, paper, scissors is an example of a type of “system” between 3 objects. In a magic system these 3 objects could be magic types, and the relations indicate that certain types of spells do more or less damage against certain characters belonging to one of these 3 types of magic (imagine Pokémon).

As always, all these UPs and game mechanics that are importable into any virtual world, are not imposing on us how we should build virtual worlds. They act as a starting point, from which each world-builder can tweak or modify as they wish, but with strong interoperability already built into the system, it comes with many things for free.

Is Magic really just state?

We can generalize the notion of state/status and how it changes, to define magic in a more formal way. Magic is the representation of this “thing” objects can carry. In fact, objects don’t only hold this state, they may use it to transform other objects, or pass it along. Videogames like The Legend of Zelda: Breathe of the Wild (LoZ:BotW) showcase this beautifully. The way this game treats elements of nature, like fire, ice, lightning is just as if these were types of magic. Almost every object in that world can interact with other object of the world, under a well-defined set of rules on how state and state-changes are calculated (the creators of LoZ:BotW called this a “chemical” engine, but we could alternatively call this a “magical” engine). This type of interactions define what is usually called “systemic games”.

Magic would be then the abstracted notion of state, and how it can transform other things around it, multiply, or interact with other types of magic/state. This means we may not only create building blocks with our UA framework for status effects, but as a way to make it much easier to create whole systemic games! Each type of state/magic could become its own UP. World-builders could then apply to any object, some properties associated to a certain set of magic/state UPs they’ve decided to import into their worlds. For example, a fire UP could be defined by its ability to burn things. We could create an optional dual state for any set of objects we want to be affected by this type of “magic”, the states of: burnable — burning.

Objects that are susceptible to fire damage (burnable), upon interacting with natural fire or magical fire, would change their state to burning. These burning objects might even gain the property to burn neighboring objects themselves, so that the fire can spread. Objects carrying different states (we can view them as being imbued with or carrying magic) could interact with other objects carrying a different state/magic, and cancel each other out or produce other types of effects. It might even take imbuing an object with more than one type of magic to trigger certain special effects. The sky is the limit.

Also, since magic is the abstract notion of state and changes in state, it can apply to apparently non-magical things also. For example, in LoZ:BotW, a tree may have the “choppable” property, and be in the unchopped state. And the player might be wielding a weapon like an axe, with the “chops” property. When the player hits the tree with the weapon, a collision occurs between the weapon and the tree, that triggers the state transition of the tree from unchopped to chopped, which triggers an animation that makes the tree fall down.

At this moment the tree could even become a new object as a consequence of this interaction, and become a log, a different object with a different set of properties than the tree, for example, logs may float because they all have the “floats” property. So if the chopped tree falls on a body of water, there’s a floating log the player can now hop on to. “Chops” could be seen as a form of “magic”, in the sense defined above. Or a sort of physical stimulus. So it might be helpful to describe all forms of magic as a type of stimulus of some kind.

Final remarks

Now we can start to see where all of this is going, an ever growing library of user generated game assets and mechanics, following a simple standard or specification for compatibility, but with almost absolute freedom on what can be created. From which any given world can borrow as much or as little as they want. The hope is that by having such a system, we achieve interoperability, make it easy for any individual to create their own world, and contribute to building a more rich and flexible Metaverse ecosystem.

The UA framework doesn’t set a single giant standard for the Metaverse and how to build worlds, but instead sets a flexible and modular foundation upon which these can be constructed. But these bigger standards will not be decided by any single individual or company, but by the collective of Metaverse inhabitants, that will organically grow this potential public library. Creating new primitives, deleting them, merging them, creating new ways to connect them. Natural selection and survival of the fittest, a way for our Metaverse infrastructure to evolve over time, getting better, and better, and better…