Dachannien wrote:

The biggest issue with forking is incompatibility. If lots of people start creating ages that require various special experimental features of a custom version of the server or client, and those special features are either not pushed to a trunk version of the software (or, worse yet, can't be reconciled into the same trunk for some reason), then the end user may have to install multiple versions of the client in order to play, or the age creator may put in many hours of work centered around the experimental feature only to realize in the end that they'll have to set it up on some non-mainstream shard because the most popular shards are running incompatible server software.

I'm not saying don't fork, though - I'm saying either fork and keep it private, or fork with the full intention of re-merging your improvements in the near future.

Rusty_Russell wrote:

Quote:

then the end user may have to install multiple versions of the client in order to play,

I'd say that multiple versions of the client are a no-no from the outset - servers yes, client no.

Finally people who see the problem of multiple clients.

Whilyam wrote:

Yes, the client should be designed so it could connect to a variety of servers with a variety of content. Like a web browser to some extent. I don't have to get a new browser to look at CNN after looking at the DRC site.

"Yes, the client should be designed so it could connect to a variety of servers with a variety of content. Like a web browser to some extent".

Look, if someone does massive changes to the client to introduce "cool new feature X" in their fork of Myst Online, that may very well (depending on if the feature requires server responses or not, which they often will) require a NEW feature on the SERVER-SIDE as well, to handle that client request, which leads to multiple server&client-versions.

So, as I said from the get-go, if you allow multiple forks to all bear the name "Myst Online", with each then having to create their own modified server software to add support for their custom features, you'll immediately fracture the userbase among X different incompatible versions of Myst Online, instead of keeping all users meeting in one compatible, continuously improving "Myst Online" umbrella where ages can be added and everyone has ONE advanced client to play with, without scaring people away with a need to research what client&server-software they want to run, with each client claiming to be the best.

Multiple client&server-combinations bearing the Myst Online brand:

• Alienating a large portion of the userbase who do not have the energy and tech savvyness to choose a client, alienating the people who just want to get into "Myst Online" with ONE easy client, check
  
• Creating client and server incompatiblities and project fracturing due to specific server features for different clients, check
  
• Fracturing the userbase by dividing them into branch camps, check
  
• Allowing fork projects to bear the Myst brand may hurt your trademark, which Cyan lawyers have to look into
  

Solution:
My proposed solution has all along been to bar forks from calling themselves "Myst Online". Solving all problems above AND creating the inclination to contribute fork code improvements to the official "Myst Online" since there's no fighting to be "the best version of Myst Online". This would still allow anyone to use the Myst Online codebase for their own virtual community games, under Open Source license, and everyone wins.

Last edited by Jones on Tue Jan 06, 2009 10:56 pm; edited 3 times in total

I think Whilyam is in the multiple client bad camp. He's talking about the same client doing many things.

Rusty_Russell wrote:

I think Whilyam is in the multiple client bad camp. He's talking about the same client doing many things.

Trying to make an "uberclient" that understands ALL alternative project's changes is a coders nightmare, being forced to keep track of what each alternative project's client and server software is doing in terms of new features and new client-server communication changes, AND writing a client that understands and responds to ALL server differences, AND implementing proper , accurate responses to ALL of them, that's a LOT of work. There's no magic way to have "one client" for all of these projects, that is not how implementation of new features work, you don't have one without the other, server and client goes hand in hand which is why there would be differences for each project when they create new features and in turn an (ever increasing) incompatibility between each project (again, each project having their own client and server which is necessary to support their custom features).

This in turn forces existing and new, potential users to research what version of "Myst Online" they're going to get (do they want the one with an improved chat system or the one with new shaders? and more importantly; do they want to have to do research in the first place? of course not), since there will be multiple versions of Myst Online to choose from, each with different features and therefore different client&server-combinations, something that may be difficult to understand if you've never written software:

Whilyam wrote:

Yes, the client should be designed so it could connect to a variety of servers with a variety of content. Like a web browser to some extent. I don't have to get a new browser to look at CNN after looking at the DRC site.

From a non-coders viewpoint it probably sounds as easy as "making a web browser that can visit all websites" to unite all projects, but a web browser just has to follow the HTTP transport protocol standard, which is set in stone and VERY easy to implement (I've written a bunch of browsers in my days). It's an entirely different beast having to monitor source code changes both client-and-serverwise for each project to make an "uberclient" that understands each version of Myst Online and all their feature differences. That is an incredibly difficult job since it wouldn't be done once you've made v1.0, you'd have to change EVERY TIME the alternative versions release an update. Having this kind of "master project" that tries to be all other projects is not going to work.

Which is why it just takes one simple requirement: Forks being required to have their own unique project names, which frees them to develop in ANY way they want, do ANY crazy thing they want (there wouldn't be any limitation on what they can do!), and contribute the best and most groundbreaking features back to help THE "Myst Online" universe by helping improve the game engine (read my post at the top of this page, page 2, for a bit more expansion on what this entails and how it keeps from fractioning the userbase and helps users and coders alike (no fighting to be the best client, no worries about compatibility, and no problems designing Ages that work for all users), while protecting the Myst brand name).

Thanks for the chat Russell, I'm heading off for today.

It is very simple to implement multiple features that may not be available in all clients/servers. When the connection begins, the client and server negotiate the features each supports, which features are mandatory, and acts accordingly. Web browsers do this (HTTP1.0 vs. HTTP1.1), BitTorrent does this (DHT, Peer Exchange, Encryption), SSH does this (X forwarding, local echo, XTerm, Mouse support). It's essentially trivial to implement, and merely requires an agreement established that modifications will be backwards compatible in this way.

If the server has functionality the client doesn't, then depending on if that functionality is mandatory or not (Optional extra dances would not be, new KI functionality would be), the server either disconnects with a message ("Sorry, but your client does not support the required functionality to use this server. Please install the KI_Upgrade plugin version 3.2 or higher") or allows with a warning ("Welcome to Some_Server. Some advanced functionality is available on this server, but not recognised by your client. To experience this advanced functionality, please install the New_Dance_Moves plugin version 1.0").

If the client supports features that are not supported on the server, the client merely turns off those features and runs without them.

Please stop feeding the troll.

_________________
Avatar: Anaerin
Ki: 118686

Barring anything in an open source project is inadvisable as well as impossible. If you want to bar something from your server, go right ahead. There is absolutely no reason there can't be multiple versions of both the client and server.

The HTTP/Web browser analogy DOES work because they (browsers/servers) have the same feature in common: the protocol.

I say we "bar" demanding rules.

_________________
Can you withstand the gaze of the Eye of Eternity?

Quote:

It is very simple to implement multiple features that may not be available in all clients/servers. When the connection begins, the client and server negotiate the features each supports, which features are mandatory, and acts accordingly.

This acts under the following assumptions:

-That the feature set is known and well established.

-There are no unannounced features, and there are no unannounced bugfixes that introduce incompatibilities. All feature changes and bug fixes are announced in the protocol.

I doubt the assumptions are reasonable. If this is going to be open source, then I'd say the likelihood of a developer creating features without announcing them in the protocol is likely to be very high.

How can a client realistically 'create features without announcing them' that breaks the gameplay? If it sends a packet to the server that is not expected, it is simply rejected. Anything in the realm of successfully exploiting malformed packets or undocumented features to exploit security holes is an issue that is properly the responsibility of the server developers.

Likewise it is up to the server maintainers to give their users reasonable accommodation in selecting or configuring a client, or else they won't be getting any visits.

A client can play card games with itself and waste its own cycles as much as it wants without harming the server. If it starts sending illegal packets to the server, the packets get ignored. This is all relatively straightforward.

Of course, I have no expertise on the subject outside my second-hand knowledge from a few years studying such things as a hobby - nothing first-hand. That's why I'm deferring to the people who have first-hand experience.

My own posting history here serves as a salutary example of why it's sometimes good to hold back on those "common sense" critiques from inexperience, for example, some of my contributions in the UI thread...

Quote:

How can a client realistically 'create features without announcing them' that breaks the gameplay?

I'm not familiar with how the current protocol works, but you are assuming all created features also create malformed packets.

There are several ways to create new "features" without changing the packet structure. Bots, for example, do not need to change the way the client communicates with the server; they simply need to access the keyboard and mouse so they pretend to be a human. UI changes are also another way to add "features" to a game that it didn't have before without having to affect the packets. In World of Warcraft, there are mods that will disable the fog that covers unexplored areas on the map, for example.

In addition, it may create confusion if the new "feature" doesn't work with a server: Somebody with a modified client may wonder why the feature is not working, and may think it's a bug or that the game is not working. Hopefully, the developer will create proper messages informing the user that the client is not intended to work with servers not modified in the same way.

CobraA1 wrote:

you are assuming all created features also create malformed packets.

Quite specifically not. I would ask you to re-read some posts on the subject, but I'd suggest reading posts from somebody who actually will be developing the software - SCGreyWolf, ddfreyne, whoever else is talking.

Rusty, as much as we love him, wasn't aware of the difference between data and code, calling the client a multi-gigabyte download.

CobraA1 wrote:

There are several ways to create new "features" without changing the packet structure. Bots, for example, do not need to change the way the client communicates with the server; they simply need to access the keyboard and mouse so they pretend to be a human.

You will not need to worry about wallhax in Uru. This analogy to online FPS game cheating is a waste of our time.

CobraA1 wrote:

UI changes are also another way to add "features" to a game that it didn't have before without having to affect the packets. In World of Warcraft, there are mods that will disable the fog that covers unexplored areas on the map, for example.

Again, this is irrelevant to the question of preventing "cheating" in Uru.

You could "mod" sparklies (to go back to a GameTap beta feature) into your own Relto without earning them; you could put XXX content on surfaces, and...well, the worst that can likely happen on a properly configured client is you'd send or upload a disallowed KI image to somebody else or their Bevin picture server, but that's it. The sparklies and modified content will all be client-side; it doesn't change what's happening on other people's machines or the server, and that is the critical distinction.

Aside from the previous rather unusual possibility, cheating and griefing in Uru would probably consist of exploits like:

-Updating your position more often than is legal (a server side problem)
-Updating the position of explorers and items in the world illegally (again server-side), like creating or removing barriers, pushing people off cliffs, stealing objects
-Throttling other players with a terrible ping (I guess; that's probably / hopefully not an issue)

The one attractive feature I'm sure would be very troublesome to deal with would be the ability for scripted objects that can spawn themselves, or for players doing something similar, which could lead to consequences similar to the "grey goo" attacks on Second Life. But, once again, this needs to be implemented server-side.

As I've stated in other threads, the network packets are really just an internal Plasma message wrapped in TCP or UDP headers (UU used UDP, MOUL used TCP). To add a new part of the protocol, you simply add a new message class. Cyan has done this a number of times in MOUL, for adding things such as the Jalak pillars and the BlueSpiralGame (Delin & Tsogal). Plasma's network classes are all based on the same Messaging system that the rest of the engine uses.

I think I can say with some certainty, Paradox knows what he's talking about. I personally would listen to someone with 4+ years of actually dealing with Plasma's internals rather than some programmers who have just recently come out of the wood-work because of the UruLiveOpenSource thing.

The fact is that he's not making guesses about this stuff.

I'm really just starting to somewhat fully understand the workings of Plasma. I've found that Plasma isn't something you can make assumptions about. Guessing isn't enough. Unless you actually have some form of code in front of you, you probably have got the wrong idea.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

It would be great if we could avoid forking! But realistically, we need to plan a strategy to compensate for it.

In a clean development model, with just one repository:
* There is a core branch, or "trunk," in a code repository, containing the "stable" version of the software. The code base is at least unit-tested, and should compile without difficulty.
* Additional branches are used for projects that are not yet ready to be accepted into the trunk. Software built from these branches may be incompatible with software built from the core branch. Software in these branches is essentially unfinished work. When the changes are finally tested with sufficient confidence, the trunk is updated.

The repository manager is responsible for ensuring that a surprise protocol change doesn't bite everyone in the behinds; updates don't get merged into the trunk without some sort of review, and no-one except developers should be building from the non-trunk branch. That should resolve CobraA1's concern, but there is a bigger problem, and that is how the repository co-ordinates updates with everyone that uses it.

If a change breaks backwards compatibility (if a new server version requires a client update), you'll need a way to update all servers at the same time. If half of the servers update on Thursday, and half of the servers on Friday, then in the interim anyone running the old client would theoretically receive their update when connecting to an updated server, but then they will have problems connecting to the servers that aren't yet updated.

I'm not confident that Cyan's protocol will lend itself easily to keeping backwards compatibility, because when Cyan controlled the server and the client distribution, they were able to enforce that the two stay in sync; release client connected only to release server, rehearsal client connected only to rehearsal server. The Open Source Myst Online community will not have that luxury if multiple shards are running the same server release. To compensate, we should probably try to be as backwards compatible as we can. But there may be times where that won't be an option.

The above problem is made thornier by the addition of multiple repositories which may act independently of each other, but I do have a suggestion for resolving that. The client and server system should be engineered so that clients obtain a qualified server list from the repository from which the client was built. Under this model, if a player wants to connect to Shard Betelguese built from the Orion repository, and also wants to connect to Shard Cinnabon from the Pastry repository, then he or she would need two client installs. This is painful on the prolific shard-hopper's disk space, but it would reduce the likelihood of incompatibility problems arising between forks. This same model could also be extended to branches within a repository, to ensure that development branches don't accidentally connect to non-development servers.

_________________

MOULa 26838 | Prologue Video Project: On Hold pending Minkata support
Visit rel.to to explore Myst, Uru, and D'ni communities!

Last edited by Marten on Thu Jan 08, 2009 12:40 am; edited 1 time in total

The people who write all the "fear" posts about forks have obviously never ever worked on a real open source project. If the community process works the reason to fork is very very small. Even if it does not work it usually takes a serious amount of pain before the community decides to do a fork. A good example was the egcs fork of gcc that happened after many developers felt that gcc did not move forward. And it has been since merged back / replaced the original gcc.

As with all living things growth (and therefore the possibility to fork and explore new territory) is fundamental. But there is no need to fear that the main branch will suffer. Linux, too benefits much from some of it's "forks" like the realtime branch and much of the work developed out of the main tree comes back and gets integrated into the main tree.

_________________
"Never attribute to malice that which can be adequately explained by stupidity."

elektrolott wrote:

The people who write all the "fear" posts about forks have obviously never ever worked on a real open source project. If the community process works the reason to fork is very very small.

If the people who write all the "fear" posts are planning to work on the Uru open source, then we're going to have a bunch of amateurs who don't know much about community processes trying to work together. Or against each other. If some developers who _have_ worked on open source are able to act as gurus to the learning process, things might go OK... it might depend on how badly the number of new participants outstrips the experienced participants.

There are a lot of community members who are very passionate about Uru, who have dreams of how it should be, and these dreams are not all compatible. Looking at past discussions, this community doesn't have the greatest track record of reconciling its differences.

But I think we can mitigate the fork problem, as I've stated earlier. Planning for it really isn't that difficult.

_________________

MOULa 26838 | Prologue Video Project: On Hold pending Minkata support
Visit rel.to to explore Myst, Uru, and D'ni communities!

Quote:

You will not need to worry about wallhax in Uru. This analogy to online FPS game cheating is a waste of our time.

Bots exist for all types of multiplayer games, including large scale games such as MMORPGs.

. . . and unless you've somehow gained the ability to watch my editing in real time, I made no analogy to wall hacks when I submitted my post. WoW is a MMORPG, not a FPS.

The principle is basically the same regardless of the game style, so your complaint about my analogy is moot: Use whatever information and forms of communication that are already available to add advantages to the client that others may not normally have.

. . . and correct me if I'm wrong, Jones was concerned about changing the game in general, not just about cheats specifically. The point is that such things are possible, not about the particular form they may take.