First we talked about clients and servers; then we talked about maps. Now we are finally at the hardest part of virtual worlds to wrap your head around – not coincidentally, also the aspect that gets people the most excited.
Things. Stuff. Bits and bobs. Widgets. You know: objects.
A lot of folks think a digital object is something like this:
Objects might seem simple, but they are actually very complicated. The subtleties lead to confusion about what is possible in online worlds or metaverses – and the answer is both more and less than people tend to think.
Digital paradoxes
Let’s start by hitting on some of the core dichotomies that exist with virtual objects:
Appearance versus the thing itself. A digital object’s appearance is not the object. In fact, in a well-architected online world, the object can change appearance willy-nilly because the visuals representing the object and the object itself are decoupled.
Ownership versus possession. There is quite a lot of interest today in digital object ownership, of course. But every digital object is, by definition, stored on a server. Someone owns that server, and can turn it off or wipe the hard drive. Separating the control of the object from the ownership is the main project of NFTs, for example; and yet even NFTs mostly don’t manage it, partly because of…
Data versus code. Typically, a digital object consists of a set of data. Statistics about the thing that describe the functionality it is supposed to have. But that functionality is not generally part of the object. It’s like sheet music, not an MP3 player. It takes code to read the data, and code to make the object do anything at all. Otherwise, it’s just rows in a spreadsheet.
Container versus content. We’ve all run into a movie that our computer’s movie player has trouble with. Those rows in the spreadsheet are set up with specific headers on the columns. Even if you have the code that can theoretically interpret the rows on the spreadsheet, if your movie player expects them in a different order, the movie won’t work. This is a data format question, which I touched on back in the first article in this series. It doesn’t help to have a BluRay player if all the songs in the world are in VHS format only.
The structure of digital objects
In the real world, when you go to buy a car, you probably have a particular model of car in mind. Virtual objects work the same way. There’s a cookie cutter that defines the object, and there’s the cookie you get when you use the cookie cutter. You can make as many cookies as you like, and they will have basically the same shape.
There are many names for this distinction, but I will use the terms template and instance. The cookie cutter is the template: it defines the shape. An individual cookie is an instance.
If you’ve ever played Dungeons & Dragons, this concept is familiar to you. The Monster Manual defines what orcs are. But you fight a specific orc. And when that orc falls victim to your mighty blade, the “master copy” orc remains in the book, ready to spawn more orcs for future encounters.
The “shape” of that orc is therefore the list of specific bits of data that make an orc different from a dragon. The name is one of those bits, how many hit points it has is another, and so on.
In many virtual worlds, the instance is actually a carbon copy of the template. This means that all instances of a given template are exactly the same. This is done to save on computer storage and memory; the fields that don’t change on an instance don’t need to be on the instance at all! You don’t need to store the name “orc” on every orc – you can just use the name from the template.
On the other hand, if the data or fields can change or vary, then you do need to store it with the instance. Data on templates is immutable by players; data on instances is modifiable. An orc named Fred and an orc named Betty need to store their names individually, and it takes up space. A wounded orc needs to know how hurt it is, because the template only stores what a healthy orc is like.
How many databases?
Because of this concept, pretty much every virtual world maintains a minimum of two databases.
- One of them is read-only, and is the source of templates. The only people who get to populate this template database are the developers of the virtual world.
- The other is read-write, and whatever you change is persisted. This runtime database is the one that saves instances.
(Even this is a massive simplification. Back in the late 1980s, a virtual world architecture approach was developed in which there were no templates. Every object was unique, and therefore each instance tracked all its data. Instead of templates, you could clone an object from another object, which gave you the functionality of a template. One cost to this approach is that the economy of looking back at the template for information was lost – this style of server was far less efficient to run. What we gained was the ability to create new kinds of objects on the fly. Over time, this evolved into architectures in which the template database can be altered while the world is running, but which do not require every object to know every piece of data about itself. There are lots of more subtle variations, such as the notion of object types which are classifications of sets of object templates… this is a deep rabbit hole).
When people speak of decentralizing virtual worlds, this distinction is often one of the things omitted. Which database are you decentralizing? It’s not hard to share template data – text MUDs have been doing it for decades! It gave rise to a phenomenon called “stock mud syndrome,” where MUDs used so much shared template data that it was hard to tell two games apart!
The precedent is even older: the Monster Manual actually is a decentralized template database. Every game table has their own copy of the book. In fact, every adventure module sold is an optional add-on to the template database, because that static DB often holds maps, treasure items, and everything else.
On the other hand, what people seem to want to decentralize is actually the runtime database. That’s the hope for things like NFTs, which are all about instances. And in particular, those people want to decentralize just one field: who owns the instance. We’ll have to come back to that topic later.
Fields aren’t just text
Let’s go back up to those paradoxes at the top of the article. We’ve already established that a given field might be immutable, in which case it lives in the template; or mutable, in which case it has to live in an instance.
A given field doesn’t just store stats, though. It can store entries that point to another database. The most common use for this is to link a set of stats (such as “orc”) with its appearance (“a 3d model of an orc”).
Back in the first article in the series, I pointed out why this is challenging already – there are many formats for art. But there’s also the question of whether the art lives in the template or the instance – this determines whether it can change or not! Modern character customization systems store the basic avatar in the template, and a set of fields lives in the instance for all those sliders, letting you adjust the height and cheekbones and hair color and whatnot.
You can’t carry runtime customization data like that over to another world unless the template matches. And this is true not just for art-related fields, but for all fields. You can’t carry over your current health to another game if the template for players in that game doesn’t handle health.
So now, our little diagram for what objects look like is kind of like this:
Something worth pointing out: this diagram has an assumption that all the art is in the same database. And indeed, in most games it is, and most online worlds it is. But it doesn’t have to be. If the art field pointed at a URL instead of a database entry, it might be anywhere on the Internet – and in fact, things like web browsers, NFTs, and our platform here at Playable Worlds all rely on that idea.
But we’re not even half done. After all, the lamps in our diagram can’t be turned on and off. In fact, they do nothing at all. Dealing with functionality will introduce a whole new level of complexity… next week.
Check out the other articles in the series
How Virtual Worlds Work – Part 1
How Virtual Worlds Work – Part 2
How Virtual Worlds Work – Part 3
How Virtual Worlds Work – Part 4
How Virtual Worlds Work – Part 5