Plug-and-play game mechanics for the Metaverse (Part 1)
If you haven’t, be sure to check out the prior articles in this series: The Universal Asset framework series.
In a previous article we talked in a general manner about Universal Functionality (UF), or how we could give functionality to interoperable virtual assets, that’s preserved across worlds. In this article we’re going to describe how our Universal Asset (UA) framework might help us create plug-and-play game mechanics. Here I’m going to use the example of a basic combat system, with mechanics around how weapons and armor may interact with each other. On further articles we’ll discuss other types of possible plug-and-play game mechanics.
We will also start defining in more detail the specifics of what constitutes a Universal Primitive (UP), and how they differ from one another. As a reminder, our framework requires us to have a public library of templates for any interoperable virtual asset. This library might look like a mix between Wikipedia (for classification and information) and GitHub (for hosting and updating the data associated to the UPs). Each template is a category/box for a type of virtual object (for example a sword). The UP is the data associated to this category, in our case here, we’ll talk about combat-related data.
This library lives independently of any virtual world and might allow us to define some types of interoperable functionality, like that relevant for a combat system, or other game mechanics, by relating any UP from the library in relation to another UP (like weapons and armor). In this sense, this interoperable functionality is very similar to a semantic network, but instead of using words, we use the primitives — more specifically, fields/parameters from these primitives — as nodes, and the “functionality” is described/encoded in terms of relationships or connections (edges) between these nodes. These semantic networks of functionality are what virtual world may choose to inject into their worlds, these networks would have to be translated/interpreted by the world-engine into actual functionality.
One thing to notice, is that we’re going to get rid of many of the known conventions and restrictions from the real world. We will define weapons and armor in a new way, we will let go of physicality all together and consider them intrinsically magical or digital. The Metaverse is a place where magic is real, and everything is not a mere imitation of an analog object, but a magical or digital object in its own right. These magical/digital weapons and armor are “formless”, users decide to give them whatever aesthetics they want (with some mild limits dictated by the underlying UP). “Realism”, where the looks of an armor or weapon reflect what type of stats or properties it has, is an optional approach some virtual worlds might decide to go for, but in general this type of realism is not inherent of the magical/digital Metaverse as a whole.
A simple plug-and-play combat system
The first combat parameter we’re going to define is a damage multiplier. Each type of weapon (UP) will have a bespoke damage multiplier. This parameter multiplies over a base damage value, for example, a damage multiplier of 1.5x over a base damage value of 100 would output a final damage value of 150. Now each weapon type/UP will have its own bespoke damage output, that differs from other weapon types/UPs. The way we justify introducing this parameter, is so that we can better balance the inherent differences between weapon types, like for example a knife and a greatsword. We will introduce the notion of risk and reward in combat, to arrive at the particular value the damage multiplier of each weapon type should have.
The concept is simple, weapons that on average are riskier to use (meaning the chance of landing a blow are lower), should in compensation get a damage boost. The risk/reward score will depend only on the parameters we’ll use to define any weapon UP. For the purpose of this article we’ll use these 3: range, swing-speed, and cross-section. The relation of each one of these parameters with risk is pretty straightforward. Longer-range weapons, weapons with a fast swing-speed, or weapons with a high cross-section are all harder to dodge or evade, therefore they are less risky to use, therefore they’ll have a lower damage multiplier than other weapon types that are riskier to use.
Each weapon type/UP will have a unique combination of values for these 3 parameters, and a single risk/reward score will be derived for each weapon. We could arrive at this score by several means of testing, either manual trial and error, or perhaps in the future in a automated way. As an example, a standardized combat simulator AI could run thousands of combat trials with a given weapon, and by statistical analysis of how well the AI-player performed, a score is given. This would allow us to create an arbitrary amount of new weapon types/UPs if needed, and assign to them a risk/reward score, from which we would derive our final damage multiplier.
By now, we’ve defined a characteristic parameter for every weapon type/UP, the damage multiplier. And luckily, the 3 parameters used to measure risk (range, swing-speed, cross-section) also give us a way to define the visual constraints each weapon type/UP should have, in terms of size/volume, since cross-section and range are inherently spatial parameters. So now we can define for example a weapon type/UP for a normal-sized straight sword, to be a volume of average size, range, and cross-section. But we can create other categories also, such as a different weapon type/UP for a knife, of short size and range. And another one for greatswords, with big size, long range, and big cross-section. And so on.
This way of defining a weapon type/UP gives us a simple volume. These volumes will likely be made of simple geometrical objects such as rectangular prisms, spheres, cylinders, or even a combination of them. From this volume we can define other properties for the UP, such as hitboxes, or the volume inside which our visual files for the asset need to fit in.
Types of attacks and their damage
One possible way to add more granularity to our combat system, would be for example to link the maximum amount of damage a melee attack can make in a given time-frame, with the time it takes to execute that attack animation. We can now define combat metrics, such as damage per second (dps). Let’s set for example a standard dps for all weapons, at 40 hp of damage or 40 dps. Let’s now define different types of attacks based on their attack animation duration.
A light attack animation might last 1s and therefore would deal 40 hit points (hp) of damage, a heavy attack animation might last 1,5s and deal 60 hp of damage, a charged attack might last 3s and deal 120 hp of damage. We can now even combo attacks together, and still, they’ll roughly deal an average of 120hp of damage in 3s, whether it’s 3 light attacks, or one single charge attack. These 40 dps or base damage per second would be the thing upon which we would apply the damage multiplier, so that each weapon type/UP would actually deal a slightly different dps.
What about armor?
Luckily, our UA framework works just as well with armor categories as with weapon categories, armor can also be defined in terms of universal primitives. Although they will have different parameters and values than weapons. One way to construct these armor types/UPs would be to divide types of possible armor, in terms of its bulkiness. We could have a base value for armor against physical damage, and a multiplier for each armor type/UP, analogous to the one we used for weapons. The value of this multiplier would be positive and proportional to armor bulkiness. If bulkier armor has a bigger hitbox, this implies more risk, therefore there should be a boost in armor protection to compensate. This also makes sense logically, as bulkier armor is natural to be thicker and therefore provide more protection.
We now have a clear way to define any weapon or armor universal asset (UA), we may want to introduce into our virtual worlds. But we’ve only discussed a few parameters for our hypothetical combat system, we can always introduce more, or tweak it. And since it’s entirely defined in relation to other UAs/UPs, it’s a consistent combat system that integrates with all UAs from the start, one any world builder could easily plug into a new virtual world. Leave it as is, or modify it.
Final remarks
The simple combat system mechanics described here are only an illustrative example of what could be done inside our UA framework. Arbitrarily more complex combat systems should be possible, as we create new categories/UPs for weapons and armor, new parameters, and new relationships between the parameters of one category with another one.
The key thing is that these combat systems are defined in terms of, and tied to, a public library of UPs, and therefore can act as a foundation for building standards and achieve universal functionality across the Metaverse. Or as a great starting point for world-builders to build their own combat systems, while preserving some amount of interoperability if they wish. If we can extend this concept of plug-and-play game mechanics even further, we might make the creation of complex virtual worlds much easier and user-driven.
Once we have our giant library of game mechanics and interoperable assets being built in the open, world-builders will be able to import these into world-engines (fancy extension to game-engines), and start using them as they are, or modifying them for their own needs. By making the design of virtual worlds more modular and composable, we can grow them bigger, make them have better quality, and save a lot on building time. It also sets the foundation for constructing new standards, which will undoubtedly help with interoperability.
