Joined: Mon Mar 01, 2010 8:37 pm
Posts: 3
|
Background:
So as I am reading though this forum, there seems to be a very common theme: People worrying about URU splitting up into a huge number of different distributions, and it turning into a massive "second life" due to the tendency for the few weird ages that will most likely be made. I've compiled a few of my opinions and suggestions on the matter in this post. Before you read them, please read this short background.
Keep in mind, I have only played the first myst and URU, I've yet to get Riven to work, and I've only played part way through Myst III. I didn't know IV and V existed until yesterday (from this posts time). Sorry if my suggestions create continuality issues.
Please read this entire post before commenting, as I've had to revise it many times and put a lot of thought into it. Some portions may have incomplete ideas, I did not mean for this to happen... but if you read the entire post, it should also all become clear. Also, please understand that some ideas may have already been suggested in other posts (reading everything would be time consuming), so consider this one a repository if you see these re-posts. (( )) will be used to dictate out of character chat where necessary to make sure the messages are clear, explaining why it would be done this way, and to solve any issues or prevent misinterpretations. [[ ]] would be used to dictate when text is meant to be read from a role playing perspective, where necessary.I've had my fair share of managing projects, and I've even done an open source project too.
Anyways, here are my opinions and suggestions on the matter:
A New Beginning.
I agree with RAWA's rules about continuality for OFFICIAL ages, and required approvals before they can be added to the Cyan servers. This keeps a core focus in URU. However, this severely limits creativity too. So, here is my proposition for this:
Some explorers have attempted to write new ages, where some were dangerous and threatening to vistors. The DRC initially forbade this practice, until they discovered yet another secret. It seems Yeesha foresaw this problem, and wrote an age just for this. ((we will call this age "A Short Story" for lack of a better name at the moment)). This age will teach explorers how new Writers and Maintainers could SAFELY store their ages for revising and maintainance: Creating their own private city neighborhood ages. She explained that they could be kept private, shared with a friend, or shared with the world through the nexus ((this would make linking to people's neighborhoods more useful)). There, they can display their ((unoffical and unapproved fan made)) ages.
The DRC greatly approves of this, as it will encourage the rebirth of D'ni by bringing back the lost art, and at the same time, this will discourage inexperienced visitors from accidentally linking to experimental ages without invites, and also reinforces their understanding that anything they see or hear in these new explorer created ages may not have actually been a part of D'ni history ((eliminating continuality issues)). They are, rather are a fantasy caused by the rebirth of the lost arts, and skilled writers can use illusion to make things seem real ((this resolves continuality issues arising from people writing ages outside of common D'ni ability, and can be further be quelled by stressing a reference to Ahnonay, and how Kadish made it seem like the age was controlling time)).
Explorers who wish to debut their neighborhoods on the nexus must go through a DRC approval process through the new Guild of Maintainers ((reasons and process is described throughout the Real Life Side section)).
Now on the real life side:
Legal Issues:
When a person links to a private neighborhood, instruct them they are leaving the Cyan servers (explained later), and they are doing so at their own risk. Opinions, art, and ages found there are NOT their responsibility, and that explorers venture there at their own risks. Also, once again, remind them the content found is not officialy part of URU Canon.
Fan Ages and Neighborhoods:
Allowing unapproved fan created ages on the Cyan servers would be silly. It's reckless and dangerous. Next thing you know, you will have some adult themed D'ni strip club age (you KNOW its going to happen) and everyone will be visiting it; bringing all that foul language and other trash back to the public city places and turning URU into a pile of crap. So, in order for these people's neighborhoods to be displayed publically, first the writer must have written at least one complete age that is actually Myst/URU oriented, before they can make their neighborhood public for everyone to visit (they can invite people and allow buddy access however regardless if it's public). Any ages which are not Myst/URU oriented cannot be displayed in the public neighborhood or their neighborhood will be striked from the nexus by the DRC.
For consistancy reasons and to help avoid confusion, the word "shard" should become synonymous for these player neighborhood instances in which custom ages are being hosted.
Fan ages do not all have to be displayed in the neighborhood. The player may embed ages within ages as they wish (Eder Gira and Eder Kemo come to mind). They can also choose to allow or deny certain books and stones from being "bookmarked," all of which will be described in more detail later in this post.
Servers and bandwidth:
There is always the issue of bandwidth. Bandwidth is very expensive. I wouldn't ask Cyan to host fan created ages unless it's integrated into the actual game. Therefore, there is a second requirement to create a public neighborhood: the owner must host a shard from which their ages will be distributed from and linked to. This server is where the ages and intereactions will be coordinated from, leaving the Cyan servers to focus on authentication and the main storyline.
Authentication issues:
People can either directly connect to the fan neighborhoods by putting in the DNS or IP of the shard, or by linking through the official nexus. Under no circumstance should Myst Online usernames or passwords EVER be sent to a shard! To identify a person and ensure they are who they say they are, instead, the client will give the shard their User ID and a Private Key. The shard will then attempt to connect to the Cyan authentication servers, provide the private key, and if successful, download character data.
If the key is leaked, a person merely requests that a new key is generated.
Cyan Auth Servers offline?
It is not a requirement to be authed by the Cyan Auth servers. Here are the following modes:
- Shard owners can decide to use their own username and password system (they cannot be listed as a public neighborhood using this method). When linking, the user will be provided with a user:pw login window, complete with an auto-login checkbox. If they do not have an account, they can click a register button, and either fill in information in game, or be provided with a hyperlink to a web page where they can register. Users will also be warned they are passing authentication data to a third party, so they should NOT use their Myst Online login or password.
- Use a fallback method by accessing stored authentication data if the Cyan Auth Servers are offline, and the user had played previously.
- Allow the client to supply data about the player's character. Note that this is only when joining the shard. There is no reason important enough as to allow a third party to have any write access to the cyan character database. (i briefly touch on third party character databases in "Multiplayer Ages without hosts" to account for third party character tracking)
In the cases where the Cyan Auth server is offline, the KI will specify so, reminding the player that the Auth Servers are currently inaccessable from the shard they are playing on, as to prevent people from taking advantage of the offline status and trying to impersonate others. As a roleplay sense, it could be a blinking cursor of the Great Zero, stating that the KI cannot establish a link, and are therefore currently confined to their Shard.
How would they be "bookmarked" like in the Relto Shelf?
Yeesha placed two things in her Short Story age: a KI dispenser, and a Relto page. The dispenser gives explorers the ability to access the Nexus's new functionality. The new Relto page will allow other players to link others and themselves directly to their nexus, allowing them to access the hidden bookshelf described below (and allows them a method of accessing the nexus bookshelf if the main Cyan servers are down). Note players visiting other's nexus cannot use the nexus terminal, as it would not respond to their KI.
When a player is in the Nexus, it will have a link in the display screen to the secret panel which has the Guild of Maintainers Symbol. When the player selects this link, the nexus screen will display only the shards in which they visited or were invited to, AND which the owner is allowing to be displayed in the nexus (some owners might prefer people visiting their neighborhoods or only allowing invites in order to access their ages). When the player selects one of the shards, they will get two buttons: Link to shard, or display bookmarks. Linking to the shard is like being invited or finding it in the public list; linking will send you to their neighborhood. If they chose display bookmarks, a bunch of mechanical whirlygigs will happen, opening hidden booksheves in the nexus. These booksheves are much like the Relto bookshelf, keeping track of a player's progress through that shard's ages.
Note that pressing EITHER of those buttons will display the legal warning, as in order for this to function properly, control must then be passed to the shard (otherwise where would bookmarks be saved? Would be a lot of stress on Cyan's database if they were saved there)
If the shard is down, the player will be notified and an error animation will display on the nexus panel.
Alternative to above:
Place another special book slot in Relto, where it links them to a grand Relto Library. When they link in, they will be standing on a platform in a very dark library (they can only make out the faint silouettes of the shelves and the millions of books on them). They get a KI slot where it does the same thing as the nexus, displaying neighborhood/shards. The relto page will instead link to this "Great Realto Library." When the player selects "display bookmarks" it will the legal warning, and if accepted, they will have an animation where they are being taken to the appropriate row and bookshelf while their client authenticates to the shard. (reminds me of that underground train thing in Myst). They can then select the appropriate books and allow certain ones to be shared if they desire.
If they cannot connect to the shard, the platform will stop and display an error, along with a pop-up just as in the suggested nexus changes.
Custom URU Clients:
As long as client's agree on certain communication standards, there shouldn't be an issue with using a custom URU client on the official servers or the shards. For shards and ages which require more than just the standards, clients should be able to support scripts which change the way the clients communicate. CRC and hash checking can be built into the client to ensure the clients are using compatible builds. The checks are ONLY for compatibility checking.
This isn't a shooter or anything, so cheating should not be a concern. However, in any timed trial games, custom clients should have the ability to fall back on official builds only, as this is the only area I can think of in which cheating would be a concern.
Offline Mode
Players should be able to download stand-alone plugins of these ages at the creators choosing. This allows those people to play on metered internet, or if the creators cannot host those ages in a multiplayer neighborhood.
Multiplayer Ages without hosts
For those people who make group ages, but cannot host a neighborhood, they could ask another person if they would be able to host the age. Nothing dictates here that multiple people cannot host an age, but progress cannot be tracked unless these shards allow character data to be shared with each other, or store said data in a shared database (the age can dictate what shard or database the character data should be stored in, but the shard itself can override these settings on a per-age basis). Unfortunately, this all introduces a very technical setup which can't really be explained to players in a role-play sense when they ask about why their age in one neighborhood isn't being saved to another, but this might be something that should be explained by a DRC book or by the guild of greeters. This shouldn't be a problem for the reputable neighborhoods, and those smaller neighborhoods which DO override these settings will probably have people visiting who know and understand this already.
If the shard owner wishes for simplicity reasons, the player's client can instruct the shard on how far along the player is in any particular age. This can cause a lot of cheating, but seriously, this isn't a shooter, so why should you care? 
Private shared ages
If individuals wish to make a private age as a simple click-and-go, the URU client will have listen server capability built in. When someone invites a friend to an age they are testing, the clients will directly connect (don't forget the legal warning!) and the inviter will be the host.
Unfortunately, this setup would not be designed to hold multiple instances of an age (meaning Bill and Jill cannot both save progress of the same age), so either Bill or Jill need to provide a download for the other to get if they want to save their progress through the age. In fact, I cannot think of a reason why a listen server setup should ever save someone elses progress.
Credits for the ages
Credits for age creation can go onto a panel at the beginning/end of the age, or somewhere in the linking book (A credits page in the back of the book?)
Why all the effort for custom ages?...
Why? Three words: Tsogal and Delin. When I first arrived in the Guild of Greeters, Tsogal was all the rage. I heard a lot of talk about it. I got the impression that it was this epic multiplayer age with crazy puzzles requiring coordination with many people. When I did my first run, I was kind of disappointed...
Now, imagine creating ages where that was just the first part..... but where will you find the people to run it with you? You can post to all the forums and mailing lists that you want, setting up events and synchronizing timezones is as big of a challenge as the ages themselves could be. People not making their promises, or unexpected events coming up... eventually people will give up and stop trying.
However, this system would be quite easy to fill replacements, just like in Tsogal and Delin. Just have someone link back to the greeters bevin and recruit some more.
There is also a second part of this: The more effort required to obtain ages, the less willing people would be to get them. By providing an automated distribution method, simply by linking to the neighborhood and/or age, you eliminate two major factors: Lazyness and technical illiteracy.
Finally, it allows large congregation hubs as MOUL does right now. Overhearing conversations as you run past, talking about the age that someone just ran and how much fun it is, will peak curiosity (as it did with me and Tsogal). This translates to a wider audience exposure, and much more easily keeps interest in the game since it requires very little effort to explore new places. This keeps MOUL alive. You just can't get this on a forum unless people stumble across your topics, because people have to be searching for those topics or something related.
On a less obvious note, this also encourages the open source URU builds to keep in touch with the Cyan's version. It keeps a focus on the Cyan build, and many client's won't deviate too much from it. Client programmers can still do as they please, this by no means prevents them from writing a whole new client for their own servers. Without a focal point, open source systems tend to drift apart, eventually developing into entirely new systems.
As an example, a couple of focal points in Linux are the kernel and the Free Software Foundation philosophy. Everyone makes their own distributions, and nothing is stopping them from making complete rewrites. But thanks to the kernel and the FSF, it helps to remind people when it's still linux, and when it is it's own entirely new operating system altogether. It gives them a point of reference, something consistent they can base on. This creates a comradeship among the distros, and even though some have rivalries, if and when a change to the kernel would benefit ALL of them, they tend to all contribute.
Credits:
I will reference posts that I've taken suggestions or ideas from. If you aren't on this list and feel you should, PM me.
http://mystonline.com/forums/viewtopic.php?t=20070 Had some interesting concerns, many should be resolved by everything I've talked about above.
If you like this idea, or don't, please leave feedback, and come up with any other issues that may arise from this build.
Revision History
03/02/10: 1.2.1: Revised Custom URU Client section so it is more clear what the goal is.
03/02/10: 1.2: Added a "Why" section.
03/01/10: 1.1: Clarified the username:pw shard section slightly.
03/01/10: 1.1: Added information on how to handle single or multi-player ages, and simple listen server functionality.
03/01/10: 1.0.1: Minor edits for formatting, clarified some statements. Added this version section to help keep track of edits.
03/01/10: 1.0: First Post.
_________________
Signature.
Last edited by Anticept on Tue Mar 02, 2010 10:07 pm, edited 9 times in total.
|
|
Login
FAQ
Search
