Cleaning Up Instancing

[teedyo]

Hrmm.. I had forgotten about that little hiccup. whistles innocently. Definitely an issue that should be looked into. Have a relatively simple idea; it just has a little issue. Goes back to pretending to think.

[realXCV]

In MOUL the hoods were instanced along with instanced Ae'Gura's to their respective hood

The hoods were instanced from a OOC perspective.

[Marten]

In MOUL the hoods were instanced along with instanced Ae'Gura's to their respective hood

The hoods were instanced from a OOC perspective.

Most people feel that yes, 'hoods were instanced only OOCly, and each was supposed to be physically present in the real cavern. But, the changing of the word "Neighborhood" to "Bevin" in MOUL, when "Bevin" is not believed to be the D'ni word for "Neighborhood" but rather a proper noun and the name of a singular place, made some people question whether the instancing of neighborhoods was really meant to be OOC only. And as far as I know, Cyan has never answered that question to anyone's satisfaction.

I have a strong preference that the 'hoods be instanced only from an OOC perspective... and a strong preference that the word "Neighborhood" be restored to its proper place in Nexus listings.

[realXCV]

If each hood is in its own instance then we should have as many Kirel, Watcher's sanctuary and guild pubs.

[Mac_Fife]

I agree with Marten regarding the IC/OOC nature of the 'hoods. I suspect Cyan included the randomised setting of features like the clock, party lamps, etc., in an attempt to highlight that they were actually "different" places in roughly the same part of the cavern (although GZ co-ordinates blow that idea). Reading some of the original blurb Cyan produced for Uru Live, I suspect Bevin, Kirel and possibly other 'hood layouts would also have been part of the randomisation had Cyan had the time in the first iteration of UL. I'd hoped we'd get a Kirel option for 'hoods in MO:UL, but it got hijacked as a Guild recruiting centre

[Tweek]

Bevin, Seret and Kirel were specifically separate single hoods. Yes hoods weren't originally instanced (which is even stated on the old DRC site when it talks about the amount of work they put into fixing up hoods to accommodate new people arriving). The change to Bevin combined with the broken KI co-ords basically made everyone think it was instanced, and it has been a complete mess since.

Kirel was specifically the DRC's hood back in the day, they opened it up in Tpots then retooled it as a guild recruitment hood in MOUL.

I'd rather see the hoods returned to being multiple locations in D'ni, called hoods not Bevins and no longer under the illusion of being "instanced".

[Kenguin]

I just need to chime in here and voice my strong opposition to any system that makes it easy to get to a public version of a puzzle/journey age without having first solved the age yourself or with a group.

It's one thing to have spoilers and walkthroughs posted around the internet. It's an entirely different thing to have the game itself present you with a big "spoil me" button in the context of the game world itself.

And I'm not concerned about people who want to be spoiled. I'm concerned about newbies who don't know better, and end up having the single player puzzling experience ruined for them by accidentally clicking on the wrong thing and ending up in a solved age with a bunch of dancing, chatty people messing with all the levers. What if they don't even realize that wasn't the correct place to go, and go ahead and explore everything, thinking "hmm this is weird?" Think about it -- think about the first time you visited any uru age, and how you were struck by curiousity and wonder. Would you really like that experience taken away from you by the game itself?

But even if you're not a clueless newbie it can be a problem. Imagine getting the fireflies to follow you all the way to the Gira linking book, only to accidentally link to the public instance. D'oh! Quite frustrating and not-fun gameplay, there.

(Anyone whose answer to these problems is "they should have RTFM" or "they should have been more careful where they clicked" I would respectfully ask to recuse themselves from gameplay design )


A big problem is that Uru really has two equally important but opposing faces. Is Uru a game, with challenges (the puzzles) leading to rewards (new areas to explore/seeing game story unfold)? Or is it an online environment for people to socialize and hang out in? It seems to me that the bookmark mechanic is being proposed with the latter in mind, paying little attention to the former. It's great for veterans who know the game like the back of their hands and just want to jump around and organize group events as efficiently as possible, but it's not very good for new people still climbing the learning curve.

People have mentioned the conflict between gameplay and story consistency, and it's true that it's there, and that ultimately "gameplay is king." However, one must remember that Uru (and all myst games) are quite unique in that the story is a huge part of the gameplay. Most myst games start you out not knowing anything about where you are or the mechanics of the world, and you learn them by experimenting and exploring, and you're rewarded with more information and new places to explore. Uru is no different -- many of the mysteries of relto and bahro stones and linking books are a big part of the story of Uru, and just plastering over it with some new mechanic removes a huge chunk of the game IMHO. However, I will have to concede that mysterious behavior is a detriment to the multiplayer aspect, where you just want to get a group together and do something. So the ideal solution would somehow partition the "story" and "social" aspects and not allow them to interfere with each other.

It's obvious that cyan has struggled with this problem as well. The systems in Prologue were more consistent story-wise, and had a heavy focus on individual puzzle solving. But someone decided that was too boring/hard for someone who just wants to get in the game and see other people, and the whole thing changed for MOUL introducing a lot of the weird inconsistencies we are struggling with now.

Really, as has become apparent, this is a much huger issue than just "cleaning up instancing." We are touching things like how the game should introduce new players, how group dynamics operate, what the background story to MOOL should be, and what the core gameplay mechanics of the entire thing will ultimately feel like. There's no way that a solution to all of this that pleases everyone is going to be hashed out here in this forum. In fact, it's most likely that different solutions will be created, and different shards will pop up according to players' preferences. For example, one shard may let everyone get to public ages from the get-go, while another may stick to "pure" story progression. And that's fine! Variety can be a good thing. But with this in mind, I propose two guidelines:

• Keep changes modular
• Keep it simple, silly

Keep changes modular so that shard maintainers can "pick and choose" their favorite mechanics without having to install some major total conversion system that may conflict with other things they want to do. And keep it simple -- we're ultimately going to be open source programmers doing this on our free time, and we need to concentrate on fixing the most glaring issues ASAP without delving into complex total conversion systems that never get finished. Not to mention testing and ironing the bugs out of these things (if it was hard for Cyan, you can bet your asafoetida that it'll be hard for us).


ANYWAY, with that said, here are some additional thoughts I have on the instancing thing:

• As I said, I don't like the idea of going to public ages before solving them yourself (or with a group). However, I do like the idea of access to the public age being a reward for solving the age. I really believe that puzzle solving needs to have better rewards than decoration for your relto, and this would be a good way of doing that (I've thought of a few different mechanisms to achieve this, but I won't write them out here).
• When you have tightly-coupled ages (such as Kemo/Gira or Ahnonay/Cathedral), really the only place those linking books should go is between the two paired instances of those ages. Why would I be in a private Kemo with some friends and want to link to the public Gira? Or why would I be in someone else's Cathedral and want to link to my private Ahnonay? These books should be kept simple, and always link to the appropriate pair. Following people around in such situations shouldn't be a chore.
• A little bit off topic, but it's annoying to solve a puzzle with a group and then have to solve it by yourself again to get the prize. I think anyone involved with solving an age in a group expedition should be rewarded for entering the bahro cave (I don't remember if this worked properly in MOUL).
• It's obvious that grouping and inviting needs to be made easier than the current MOUL solution, but I don't like the idea of only allowing people to access all my ages. What if I just want some help with the Ahnonay multi-person puzzle? Or just want to throw a party in Kadish? I think fine grained "age-sharing" control is a good thing.
• I can't think of any good way to make the age sharing mechanic both story-consistent, and smooth. I think smooth should be the priority, and it can just be considered a short cut for manually sharing your relto book with people and letting them get to your age from there.
• Yes, neighbors-instanced ages bad. Weird instancing bugs or non-intuitive links bad. A key design element should be "this link will take you were you expect it to." Another one should be "don't make it any worse than MOUL was."
• However, I actually kind of liked the neighborhood-instanced mechanic. I liked the fact that the garden age for each neighborhood was "linked" to it, and you could go back and forth and see other people going back and forth. It contributed to a sense of "place" to the game. The OOC problem with instancing the gardens can be hand-waived away (if the dni had that many identical looking hoods, surely they could have that many identical looking gardens). Decoupling the gardens from the hoods would remove some unique gameplay experiences (being able to hang out in a hood and then just say "hey let's do the garden age" spontaneously, and not worry about inviting or sharing links -- or wandering into a garden age in the midst of being solved by a group and joining in).
• Yes, public city areas good. Also, some fan-made ages may become good "public hubs" as well. I think there are some ways of solving the lag problems that haven't been tried yet. But at worst, you could automatically spin off new instances when one gets full (instead of just locking people out).
• Whatever the linking rules and new background story are, I think there should be in-game documentation and explanations of everything in the form of journals and notes.

My random thoughts on some age-specific mechanics, in addition to the above:

• Pod ages: city links should be public, but create a private relto link for your own use if you want.
• Minkata: city links should be public, but create a private relto link for your own use. Additionally, when running around in the public instance, if you happen upon a bahro cave, touching the stone will link you to your private instance so your personal progress through the age can be recorded. Any further progress will continue in the private instance.
• Jalak: Need some sort of "jalak hub" (or through the nexus) that links you to various "arenas" (instances) of jalak in which different games can be going on, and "players/spectators/referees" can be defined. Maybe scores posted.
• Cleft: not sure how the game should start, but access to a public one at some point would be desireable.
• Player created ages: Public/private/hood instanced as best fits the age.

Great. I just added a long-winded post to an already over-long thread. Hope someone reads it

[Marten]

Good points, Kenguin. Yes, I did read through most of your post.

While it is still my preference that any book be able to link the player to the "real", public instance... perhaps the game mechanic could be defined that for puzzle Ages, you cannot link to the public instance until you've completed the Age in a private instance first. I think the bookmark approach could be adjusted with minimal change to enforce this as a "game rule." It does break the immersion of the world somewhat... but there are always going to be some things that do that. There is definitely a balance we need to maintain between "game" and "realistic environment." I'll have to think about a way to apply this concept consistently yet reasonably, especially with Ages like Eder Delin and Tsogal.

Regarding your point of what should happen by default when the player links from Kemo to Gira (or vice versa), it has been my feeling that the game needs to sense which bookmark is the correct one when a user opens a book. If the player is in a group and in Kemo, and goes to link to Gira... then the player should not have to activate the Group bookmark before clicking the panel. The Group bookmark should be active default in this situation. Though the player should be empowered to override that, and link to a private or public* instance if he or she so desires. (* perhaps with the limitation noted above about requiring the puzzle to have been previously solved.)

As for other concerns... We might all be blowing smoke around here - we don't yet know how Cyan will license the existing content of Uru Live, and I believe portions of that content include pieces that would need to change to support our wild ideas here. But, I like to think that if a sufficient number of participants here can reach a consensus on a model we feel is superior to the one Cyan used in MOUL, that we might have a slight chance of convincing them to permit us to implement it. That is why I am participating in this and other discussions here.

[realXCV]

I did read all of it.

My own preference is for the puzzle solving aspect. However, many players seem to like to all link to the same instance and explore the age as soon as it's released. It means that if there is to be a public instance, it should be available from the beginning and not just once the private age is solved. Yet, there are still thoses (like me) who don't want pre-solved ages because nobody would then be interested in the private ones. Starting from the "no journey cloths in public ages" idea from I-don't-remember-who, I expand it in my idea to "no reward at all in public ages" (a reward being a relto page, journey cloth or getting your own instance of an age through a public instance). It can be used on an open public age or on a limited public age.

Concerning bookmarks, a public/private one should suffice. (And a "share book" for books in shared ages that link to private instances). An option could be added in the option menu for the default behaviour of the books. Default being private.

[Marten]

Starting from the "no journey cloths in public ages" idea from I-don't-remember-who, I expand it in my idea to "no reward at all in public ages" (a reward being a relto page, journey cloth or getting your own instance of an age through a public instance).

Concerning bookmarks, a public/private one should suffice. (And a "share book" for books in shared ages that link to private instances).

Except for the last bit (which if I understand correctly, means you could not add the Eder Kemo book to your Relto by using the Eder Kemo book in a public Eder Gira), I've advocated this same approach - that public Ages shouldn't include the rewards. However, that doesn't seem to satisfy people who feel that accessing later parts of the Age - those hidden behind puzzles - is itself a reward.

Thus far, I see the following options:
* Don't let the puzzles be solved in public Ages - I am not fond of this solution, but it does have some precedence. In 'hood-instanced Gahreesen, players could not progress beyond getting their KI. The Age could not be solved.
* Don't let players visit the public Ages until the private Ages are solved. This is the approach I proposed above, but as realXCV observed, it does prevent groups from immediately visiting the public instance of an Age when a new Age is opened. Under my proposed model, however, players could still form groups quickly and easily and explore each others' private Ages as soon as each player has claimed his own copy of the Age.

My original proposal for bookmarks was to only use only a public and private bookmark, but 'private' led to a the instanced controlled by a group organizer when the player has joined a group. (I very strongly dislike the 'share book' system because someone must stand at the book and share, share, share, share to invite a large number of people to his or her private instance. Also remember that I do not want invitations to instances to be deliverable through the Nexus system because it breaks the separation of Yeesha magic and technology.) Alahmnat, I believe, felt that the benefits of adding a third bookmark for groups would outweigh the negative of adding complexity... and so that's how I landed on the "3 bookmarks" design.