Rights & Duties Management System

830d3229-ec63-4961-aa7d-87fa3615ac69

Today I want to talk about one of the most central mechanism in Dual Universe: how to manage the rights and duties of players against other players and organizations. We want a generic system that will be able to handle as diverse things as: territory management, asset renting, organization functional structuring, delegations, etc. All this with the same core mechanism. In fact, we need some kind of theoretical framework for rights and duties management. Let’s see how we plan to do this in the game.

First let’s look at some basic definitions that we will use later. We call “Entity” anything that is either a Player or an Organization (see the devblog on Organizations). Entities can, among other things, own Assets: equipment, ships, buildings, etc. We are going to focus our attention on assets that can be used to do something, which is represented by the fact that there is a set of Powers that are attached to them. A power represents a capacity to do something. For example: I own a container C, which is an asset that has the “open” and “read” powers. These powers represent the possibility to respectively open it and check its content. Another example: a territory, which is also an asset, can have powers such as “the right to build on it”, “the right to mine it”, “the right to enter it”, etc. By default, the owner of an asset is granted all the powers attached to it. The problem we try to address is how can you grant one or several powers to somebody else, and how can you manage this when it gets complicated?

The central idea of the RDMS (Rights & Duties Management System) is the notion of “tag”. A tag is basically a string of characters that you can create. The owner of an asset can do two things: 1. assign some tags individually to each of its powers, 2. give tags to other players (or organizations). Thus, being granted a particular power is simply a matter of owning at least one tag that is assigned to that particular power. Example: I own my container C and I create a tag “friend” that I assign to the power “open” of C (this power might have already other tags assigned, it doesn’t matter). Then,I give the tag “friend” to Alice, my friend, so that she can access the container C.

So far, it’s simple, but it is already capable of doing quite interesting things: by using the same tag for several powers, I can grant a player with many powers in one shot, simply giving him/her this tag. Symmetrically, I can grant a particular power to several players at the same time, simply using a tag that I have already given to all these players and assigning it to the power I want to grant. Unlike simple hierarchies, tags can represent complex graphs of relationships between entities.

Now, you might think, it can be very tedious to have to manually assign tags to maybe hundreds of powers (one by asset?) or hundreds or players (all my friends!). The way to get around this is that tags can be organized into hierarchies. For example, we can define for tag “T” two “subtags” called “Ta” and “Tb”:


Schema-RDMS

In this case, whenever tag T is used (assigned to a power or given to someone), it implies Ta and Tb. If I own tag T, I am granted any power that is tagged with T, Ta or Tb. If tag T is assigned to a power, anyone with T, Ta or Tb can use it. Now, you can build a tree of tags to organize your partners in the game, put them into categories, group them, etc. At the same time, all powers are structured into a tree of powers (predefined by us), so that you have access to abstract categories of powers like “military”, “logistics”, “containers”, etc (we might actually provide several trees of powers, to reflect various ways to categorize them). So, if I want to give all powers related to military assets to someone, I can simply give him/her the military tag (NB: tag names are actually scoped, so that “military” here would in reality be “power/tree1/military”, which avoids name conflicts with your personal tag also called “military”, but which is in fact “mypseudo/military”).

So far, we have seen how to give rights to people, that is: how to grant them powers via tagging. The other side of the coin is about duties. When I assign a tag to a power, it can be attached to several duties. Duties are things like: a price to pay per month, per day or per use to be able to use the tag, a price to acquire it, a certain location that you must be in to be able to use it, etc.

Another important aspect is the notion of warranties: when I give a tag to someone, I can also take it back at any time. I may agree to provide a warranty attached to this tag, which says that the removal will be done after a 24h or 48h notice, or that I agree to pay a certain amount when I remove the tag, as a compensation. Depending on who is the stronger in a negotiation, the warranties can be more or less important. But for sure, if I am given a tag that grants me the power to fly a ship in space, I certainly don’t want to be stuck in the middle of nowhere, unable to fly the ship, simply because my tag has been removed.

Now, if you remember the way organizations work, members are assigned “functions” (used to be called “roles”, but this has been renamed). We said that functions are about rights and duties. In fact, functions are simply defined by a set of tags, with certain duties and warranties. Any member with a particular function will be granted these tags, as part of the function. The organization itself comes with many powers that are related to the ability to modify functions and set/remove tags inside them. There are some fairly advanced mechanisms to manage these rights of “tagging” within an organization, based on votes, but this would drive us too far for the moment.

The last notion I want to talk about is the notion of “power delegation”. It is crucial to understand how territories work, which I will explain in another post. I said at the beginning that, naturally, the owner of an asset has all powers on it, and in particular he or she is the only entity allowed to modify the set of tags associated to these powers. What if you would agree to give this “power of tagging” to somebody else? This is called delegation. If I delegate a power P to somebody S (like a clan or a guild, for example), I accept to lose the right to tag this power and I transfer this capability to S. I can remove the delegation at anytime (together maybe with some warranties), but while it holds, I’m not in charge anymore. S can administrate the power P, and can even remove the automatic “owner” tag that is always attached to it by default. The “owner” tag is a special tag that is used to say that the owner of an asset is granted all the powers of this asset. So, if somebody else administrates a power, I can even lose the right to use it. You know the drill: with great powers comes great responsibilities… Think about it: when you live in a country, there are a lot of powers that you have delegated to the government, sometimes losing the right to enjoy these powers. For example, the power to do your own justice. This is the basis of politics and, as we will see later, territorial management.

The RDMS is a very sophisticated system. There are many other things I did not mention, because it would be too long for this post (maybe I’ll do another one about “advanced RDMS”), like: power transitivity, roles, power management in organizations, tag composition, and more details about automatic tagging and hierarchies. What we try to do here is a system that can scale and adapt to many different situations, and that will “infiltrate” all aspects of the game, from flying a ship in a team, renting properties, scripting automatic defense based on who is showing up, and even the chat system. All those things will use the tagging system to be able to flexibly describe just about anything you want to say about a situation, while making the game “aware” of it and able to help and check. Emerging gameplay, emerging politics, emerging contracts system, what else? Let us know what you think about these!

JC Baillie,
Project Lead

Discuss-Now-evolved