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.
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.
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.)
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.)
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:
Every instance has the following general controls. You can modify them if you meet the access requirements set above:
(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".
(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.
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 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.)
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.)
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.
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.
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.
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.
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:
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.
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.)
(But you can invite other players to visit. I never saw any reason to disallow that.)
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.)
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.