Ongoing Uru Review: Better Instancing

Like most MMO games, Uru Live doesn't try to cram every player and every game scene into the same persistent world. Instead, nearly every game area is cloned many times over, into "instances". This is in essence a scaling mechanism; it allows the play experience to remain consistent as more players join the game. In concrete terms: you have a home area which feels private -- nobody intrudes on your domain, so it feels like yours (even though every player has a nearly-identical home). And you can explore and solve puzzles without interference. If you want company, you invite people in.

However, the current instancing system is not great. It's overly complicated and laden down with historical cruft. In the year of Uru Live's operation, we've seen people (Cyan and players) try to do a lot of different things in the game, and many of them have been tripped up by the instancing model.

This is my replacement scheme. It is rather reactive: I am not inventing a new MMO adventure game, just trying to solve the problems that I've seen in Uru. I'm probably creating new problems in the process. But what the heck, it's better than standing still.

I also include a scheme for "history instances", which let you go back in time and see story events that you missed. (What? It fits in nicely, and Uru needs it, right?)

Mind you, I have no illusions that Cyan will adopt this scheme, even if Uru Live comes back someday. It would require a massive rewrite. This is an exercise in game design.

What Needs Changing in Uru

The notion that some Ages are common, some are private, and some are for neighborhood groups.

This gives a nice sense of differentiation to game areas. But each of these categories causes problems; some were eventually circumvented, and the rest ought to have been. For example: Aegura is a common area, but they had to allow private Aegura instances to cut down on crowding. The Pub is a common area with no clones, but the opening of Ercana and Ahnonay caused hour-long traffic jams there. The puzzle Ages are private by default, which makes it very difficult to hold mass gatherings there. (Players like holding parties everywhere, it turns out.)

Live events.

Cyan stuck hard to the notion that an Uru story event was something that happened in a particular Age, at a particular time, to whoever was logged in there and then. Some events were spread across all the instances of an Age, but most occurred in a single instance.

This is a lovely idea which needs to be shot dead. Players want to experience stuff themselves. This means that game events must be repeatable, or clonable -- that is, "instanced". I propose to tie event instancing into Age instancing. Both systems have to be pervasive through Uru, so we might as well connect them.

Neighborhoods as the unit of player association.

It wasn't a bad plan, but it was too limiting. You can only belong to one neighborhood. There wound up being other kinds of player groups; Guilds, for example, have a completely separate affiliation system. And there is no support for ad-hoc groups like "the bunch of people I'm exploring this Age with today."

Linking books as simple "touch it and go" artifacts.

This was broken from the get-go in a bunch of ways. Books have multiple pages; books have "share" icons. The rules for which instance a given book send you to are ludicrously complicated, and still don't work right. I think we have to bite down and put a complete instance-selection UI right on the book page. Every book page, consistently.

As a side effect, we can scrap the Nexus. Its only real purpose is to host all the UI that linking books don't have. Kill it and save everybody a dozen links per day.

We're also throwing away the book latches and reset buttons on the Relto shelf. Those are nice physical manifestations of game mechanics, and I understand why Cyan put them in. But they're awkward and they don't fit with the rest of my instancing UI.

(So how does one reset Ages? I shall explain later on.)

Impossibility of linking from one part of the Cavern to another.

This rule was broken months ago. Let's not bring it back. It'll only cause headaches.

Whatever else I feel like.

I am blithely assuming a bunch of other game improvements. Notably, the KI interface has to be a lot more comfortable to use. (But we knew that.)

Okay, Let's Hear This Plan Already

Right, sorry.


All Ages follow the same instancing rules; all books follow the same linking rules. That includes books on your bookshelf and books you find.

Okay, not absolute consistency. There will be some special cases. But let's get the system up first, and then put in particular restrictions where justified.

(Certain Ages will have different default behavior, though.)

All Ages also follow the same membership/invitation rules. I will go into detail farther down, but here's the overview: An Age has a list of managers (owners) and a list of members. (Managers are always members.) An Age can be public (accessible to everybody) or private. A private Age has a list of invitees. (Members and managers can always get in, they don't need invitations.)

When you create a new Age instance, it's private, you are the sole manager (and member), and nobody else is invited. You can then start adding people at the various access levels. There are no special privileges for the original creator -- if you make someone else a manager, then you both "own" the instance equally. (You can even resign from managership, and then you're just a plain member.)

The instance control UI:

When you're in an instance, your KI has a control panel for it. What you can do with the panel depends on whether you're a manager of the instance, a member, or just some guy.

You can also bring up the control panel of any instance you're a manager or member of. (If you're not a manager or member of an instance, you have to travel there in order to access the "anybody" controls, assuming there are any to access.)

The instance control panel has three tabs: Permissions, General Settings, Age Settings.

Every instance has the following Permissions controls. The settings are visible to everybody, but you can only modify them if you're a manager:

We take for granted that you must be a manager to add new managers, boot members, or change the access controls. There is no booting of managers, but you can resign from managership. (You can also resign from membership, and from being invited to an instance.)

Every instance has the following general controls. You can modify them if you meet the access requirements set above:

Instances will also have Age-specific settings. For example, Neighborhoods will have controls like "Who can post to the image? Who can download from the imager? Who can open the book-room door?" The options for all of these questions are "managers", "members", or "everybody".

(DRC Neighborhoods would be set up in the familiar way: only members can post, only members can open the book-room doors. New avatars are members of a DRC Hood, but not managers. DRC Hoods have no managers. Their names and access controls are unchangeable. When you join a player-created Hood instance, however, the rules are whatever the managers decide.)

Other Ages would have other controls. Jalak might have a "Who can adjust the columns?" control. A puzzle Age might have a "Who can work the puzzles?" control; the default would be "everybody". If you wanted to (say) have a Kadish party without anybody closing the tree door, you would set this to "only managers can work puzzles".

How books work:

To go to an instance of Age X, you must find an X linking book. There is no magic Nexus-style "go anywhere" interface. But, as today, books that you find generally collect on your Relto bookshelf. So you can depart for most places from Relto.

(By the way, I'm referring to Cavern areas as Ages here. They work the same as "real" Ages. But a City linking book can still have pages leading to several areas; that's handy.)

(Also note: I'm not worrying about Bahro tablets. Either they go away, or they have the same UI as books.)

We may have to scatter some more books around to support popular linking patterns. For example, put a Neighborhood linking book in the Neighborhood (replacing the Nexus book); this lets people hood-hop. Put Aegura and Neighborhood books in the Pub, the Great Zero, etc.

The book UI:

You open a book, and see the usual linking panel on the right. On the left are a Nexus-style list of categories: Personal, Bookmarked, Member, Public, History.

When the Personal tab is selected, you see a list of the instances (of that Age) for which you are a manager. This is less confusing than it sounds, because until you start messing around with instance creation, there will be just one -- your private instance. Yes, every single Age has private instances.

When the Member tab is selected, you see a list of the instances which you are a member of, and those you are invited to. (But not the ones you're a manager of; those appeared under Personal. It's clearer if the Personal and Member lists don't overlap.)

When the Public tab is selected, you get a list of public instances. It's pretty much like today's public-neighborhood list. Recently-used instances appear, but not limited to fifty -- you can scroll down to see more. (Scrolling might be slow, as more data is downloaded.) Sorted by population, by default.

When the Bookmarked tab is selected, you are browsing the instances you have access to -- everything in the first three tabs. But it doesn't show all of them; just the ones you've selected as favorites. This lets you return to a place even when it's hard to find in the Public tab.

The History tab is used to create new instances. I will describe it later.

(It seems weird to hide the "create" functionality under History. Actually, it is weird. We might want to put a "create new instance" button on the Personal tab, too. Or maybe History just needs a better label.)

Note that any instance can be marked public (see above). So the Public and Bookmarked lists will include many players' "personal" instances. Contrariwise, if you lose access to an instance, it disappears from your lists, even if you have it bookmarked. Bookmarks don't grant access, they just make it convenient.

(Oh, yeah: all of these tabs show the current population of each listed instance. I know, that's a big implementation headache. But it's too important to skimp on.)


When you're in an instance (that doesn't belong to you personally), your KI interface has a button for "bookmark this instance".

When you call up a player screen (friend/recent/neighbor), and it says "Steve is in instance X of Age Y", there's a button for "bookmark that instance". (This makes it easy to go meet someone, assuming he's in an instance that's accessible to you.)

Matching Ages:

There are a few cases where two Ages form a puzzle set. You want to be able to jump back and forth without worrying about which instance you're going to. (For example, Ercana and the Silo. Or the Cathedral and Ahnonay.)

In these cases, the instances will come in matched pairs. If you create a new Cathedral instance, a matching Ahnonay is created at the same time. And the books leading back and forth don't have all the fancy book UI I've described. They just have a linking panel.

(This doesn't mean that every Cathedral and Ahnonay linking book is simple. Just the pair that you use in the course of solving Ahnonay. The Ahnonay and Cathedral books that appear on your Relto shelf have the full UI. So from Relto, you can create new Ahnonay instances, find friends' instances, etc.)

Examples so far:

I've thrown a lot of rules at you, and you're probably wondering whether the result is even slightly usable. Let me go through some examples.

- Neighborhoods:

A new avatar is assigned as a member of some DRC Hood. It's also bookmarked for you. When you open a Hood book (the one in your Relto, or any other) it displays the Member tab, with your bookmarked Hood instance selected. So that's the easiest one to get to; it's your "home", in that sense.

But you can become a member of other Hoods, too; you're not limited to one. Most hoods will be set to "members can add new members", so it's just a matter of finding somebody and asking. You don't have to go through a Relto-book dance.

To create a new Hood, you don't have to leave your old one (much less create a new avatar, which is what people typically do today). Just open a Hood book, push the "create new instance" button, and then start adding members. Since you're the initial manager, you can set the name and make it public from the instance control panel.

- Aegura:

When you open a City book, it displays the Public tab, sorted by population.

The DRC will of course have a public Aegura instance. That will be popular simply by its name and nature, which means it will stay on top of the list.

But if it gets too crowded, the DRC can easily create a second Aegura. In fact, anybody can. The Public tab will wind up with a long tail of less-used Aegura instances. (Just like we currently have a long list of public but unpopular Hood instances.) That's fine; it means you can select one which is exactly as crowded or empty as you want.

Or you can create a private Aegura. Or create an instance and make your friends members, so that you can all hang out there regularly. Remember, all the stuff you can do with Hood membership, you can also do with Aegura membership; they follow the same rules.

- Gahreesen, Kadish, etc:

When you open one of these books, it displays the Personal tab. Initially, this means you see just one instance, your private one.

But if you want to go creating more, fine. (This is the replacement for book resetting. See below.)

You can also create public puzzle Ages. Lots of people will probably jump in and start solving puzzles, which is messy, but it's what you asked for. (Alternatively, set the control panel to "only members can work puzzles".)

You can even make a "neighborhood" -- a social group -- based in a puzzle Age instead of a Neighborhood instance. Again, the rules work the same.

- Group solving:

Say ten people are hanging out, and someone says "Let's go speed-solve Minkata!" Here's what you do.

First, everybody goes to a Minkata book. (You could line up at one in an Aegura instance, or go to your Relto shelves -- doesn't matter.) One person creates a new instance. He then adds everyone else as a member. (I'm assuming that the KI interface has improved enough to make this easy; he can go down the list of friends and mark people, click click click. Not the annoying tab-flipping dance you have to do today.)

Everyone can then open their Minkata books and link in. If you are a member of several Minkatas already, you can bookmark the instance that the leader is in -- that makes it easy to select the right one.

Age history:

In order to talk about replaying events, we need a coherent model of history.

Each Age has a history. It goes through a series of states, separated by state transitions. A transition might be set off by player action (you solve a puzzle), or by a story event (Laxman activates the GZ on June 24th, 2007.) Players will want to hop back in time to replay puzzles, or to re-watch story events. The History tab of a book permits this.

For the purposes of the history system, we're not going to mark every state change of an Age; only the ones that are interesting, or have interesting transitions. So Aegura might have the following list of states:

None of these states are associated with puzzles. Not all of them are associated with transitions; you can't watch the Great Stair barriers coming down. (Or, I don't know, maybe you can. Could work either way.) Some states have several replayable events. (For example, each stage of Episode 5 contains several dramatic dialogues.)

When you create a new instance, you can decide where it starts on its state list. That is, you go to the History tab in the Aegura book, and you see the list above -- from the beginning up until the present. (Whenever that is.) Select a stage, hit the "create" button, and you enter a brand-new private Aegura instance at that point in its history.

Say you create a new Aegura instance at the beginning of episode 9. You find the whole city open, all books present (as it was in Ep9). The first event is, let's say, Laxman appearing in Tokotah and giving a speech about the war. If you go to Tokotah, you see a Laxman avatar standing there quietly; in front of him is a special "dialogue" marker. When you hit this marker, Laxman begins running through his speech. (And maybe pacing around and emoting, too. It's all recorded.)

At the end of this, Laxman leaves, and a new marker appears elsewhere. It triggers, I don't remember, probably Cate giving a different speech.

(Finding these event triggers shouldn't be difficult, so there will be some hint directing you to the next one. Could be just the line "Dr. Laxman is about to speak in Tokotah" in your KI chat pane.)

When you've gotten up to the event where the Bahro appear around the Arch, the Aegura instance is at the next history state. In this way, you can play through the rest of Ep9, and so on up to the present.

Note the trick here: an instance doesn't advance through history unless a player is present. The trigger doesn't have to be a dialogue marker; it could be a player touching some object, or coming near a waiting character, or taking some action with a puzzle or machine. But a state transition always requires at least one player present to see it. If you create a private instance, nothing there happens behind your back; you will be present for every event.

Of course, in the public Aegura instances, events will occur in real time, just as they did in season 1. As soon as an event becomes available, somebody will trigger it. And this is true in every popular Aegura instance -- all of them will see the same event more or less simultaneously.

But nobody has to miss out. Say a bunch of your friends are hanging out in your Neighborhood, and you learn that Laxman just gave a speech. You immediately create a private instance -- selecting the previous state, before the speech -- and invite everybody in. You all run up to Tokotah, and when you've all arrived, someone hits the trigger. Bam, speech. You're seeing it a few minutes after the lucky folks in the public Aeguras, but that's fine.

What about puzzle Ages? Areas like Kadish or Teledahn won't have a long history list, because story events don't happen there. The only state listed in the History tab is "Beginning". That's important, though -- that's how you "reset" your puzzle Age! It's not a true reset; you create a new instance in the beginning state. Go there, and you'll find all the puzzles fresh and ready for solving.

Resource limitations:

Since there's this "create new instance" button, people will push it. What happens if you push it, like, seventy times? If everybody does that? Does the database choke?

The current Uru system forces you to leave an instance before you create a new one. (This is how "resetting" actually works; you are removed from your old private instance and attached to a new one.) Then the left-over, unused instances are deleted. This puts a simple limit on the number of instances that exist per avatar.

In my scheme, we'll need some similar limit. First, a short-term limit on creating instances: say you can create ten per day. That's plenty for any normal use.

Second, we'll need to garbage-collect unused instances. Certainly, any instance with no members and no invitees can be deleted. But we need to go farther. If you create ten private instances, you'll be a member of all of them. So they're not totally unused.

I figure that in your Personal tab, you'll have exactly one instance marked as "keep this one". (This doesn't apply to group instances, only to instances in which you are the sole member.) The non-keeper instances will be deleted after 24 hours. If you don't explicitly mark an instance, the keeper is just the one you most recently visited.

(This plan also cleans up private history instances that you create. That's good. Really, you're not going to keep history instances around; you're going to go through them and watch the events. Which will probably take less than 24 hours. Once you finish doing that, the instance is caught up to the present, as it were, so there's no reason to keep it. You can always create another one if you want.)

So sure, you can create ten instances of an Age. The next day, you can create ten more. The next day, you can create ten more, but the first ten will be gone. It's a bit of database clutter, but you have to work hard to stay in the same place, and most players won't.

Again, once you get other people as members, it's a group instance and you don't have to explicitly mark it as a keeper. So if you create a lot of popular instances, they will all stay around forever. That's fine.

(This leaves a bit of a hole: you can create instances, and then induct random strangers as members to keep the instance alive. The current Uru Live has the same hole, though, if you think about it. It doesn't seem to be a fatal flaw.)

Other issues:

- Relto:

Is it an exception? I guess it can be. Lock out creation of new Relto instances; don't let the player set his Relto to be public, or add new members. Then Relto behaves basically the same as it does today.

(But you can invite other players to visit. I never saw any reason to disallow that.)

- Shared membership:

My scheme lets you choose the membership of an instance, or even of a set of matched instances. But there's no way to create unrelated instances with the same membership. (For example, if you want an Aegura instance for your Neighborhood, you have to go down your Hood member list and add each person to the Aegura member list.)

We might want a better way to handle this. Maybe when you create an instance, you can select an existing instance and say "use the same membership list" (and manager list, invite list, etc.)

- Personal history events:

In a sense there are story events in puzzle Ages: for example, Yeesha's appearances in the Cleft. And, more crucially, Yeesha's appearance in Kveer -- which is not a puzzle Age, but which is reached by solving puzzles. It's possible we need a distinction between "global history" -- the story that happens in public -- and "personal history", which would be the things that happen to your avatar. Designing a system to cover both of these is tricky, and I'm not going to attempt it here. I don't think it's impossible, though.

- Guild pubs:

I don't have a way of doing exactly what Cyan did with Guilds. You can certainly create a Watcher's Pub instance, add some members, and declare it the "Association of Cheese-Eaters Pub." The DRC can do that too, for that matter. But that doesn't get you the nice banners and decorations.

We could allow an instance to have special decoration properties, settable only by the ResEngs. But then you're back to the scaling problems we have today. None of our Guilds ever got big enough to make Guild Pub crowding a serious issue -- but if Uru had continued, we'd have gotten there.

You really want Writers to be able to make new Writer's Pub instances. But then there isn't really any exclusivity; everybody will do it, just to collect the full set. In my scheme, it's easy for players to create social groups, but it's hard for the ResEngs to make special social groups.

But maybe that's the way it should be.

Last updated February 23, 2008.

More of the Ongoing Uru Review

Other Uru Stuff