Myst Online: URU Live Forums

Re: Code + Asset Management

veralun — Thu Dec 18, 2008 1:20 am

Author: veralun

Posted: Thu Dec 18, 2008 1:20 am

Sophia wrote:

I am a bit sad it is in Off Topic, it might be missed. ddfreyene's explanation is essential to a lot of us who are not familiar with OS teamwork and how to structure it (it's rather new for me so I am fascinated to learn more)

I think this is a valid point.
For now it is good to have as much as possible information in the same forum.
When the dust is settled down a bit we will see how we can get a better structure on this forum.
For now I will change Your favourite VCS? to General Discussion.

Re: Code + Asset Management

Sophia — Thu Dec 18, 2008 12:50 am

Author: Sophia

Posted: Thu Dec 18, 2008 12:50 am

Don't forget to read the discussion on what is your favourite VCS? too, I am a bit sad it is in Off Topic, it might be missed. ddfreyene's explanation is essential to a lot of us who are not familiar with OS teamwork and how to structure it (it's rather new for me so I am fascinated to learn more)

split from Code + Asset Management

DarK — Thu Dec 18, 2008 12:35 am

Author: DarK

Posted: Thu Dec 18, 2008 12:35 am

Thanks to all the people in this thread and the one mentioned by Sophia for getting the discussion going on this, The project seems in good hands for the moment.

Please remember...

Code:

Openness at all times



Everyone can/will take part, as a group/single individual and at every stage/role.



No elections!!!



People, who take a role, are not taking power/control, they are taking responsibility, and if you want to be involved you share responsibility.

Re: Regarding 'official' locks...

RW. — Thu Dec 18, 2008 12:10 am

Author: RW.

Posted: Thu Dec 18, 2008 12:10 am

thinkingman wrote:

OpenURU will do the same... I envision a project like Blender.org which is open, incredibly high-quality, with a really weird user interface (just kidding, I can do without the weird user interface part).[Emphasis added]

*sound of paper crumpling*

Well, out goes that idea for a new, novel, challenging, user interface puzzle.

Added note:

Sophia wrote:

...while leaving other people/groups free to choose their own path...

This may be and probably is, essential for reasons Gondar and J'on have already mentioned. Also, compatibility of content is one thing, but changes to the underlying architecture, again as already mentioned, may preclude maintaining compatibility of server and client code mods, due to the complexity of doing so. Such as mods to fix, again as already mentioned, some long existing issue(s), such as lag.

Re: Code + Asset Management

Sophia — Wed Dec 17, 2008 11:52 pm

Author: Sophia

Posted: Wed Dec 17, 2008 11:52 pm

Oh, I didn't have you in mind at all, thinkingman, I was just babbling away I noticed there seem to be some (not you! but this is as good a place to mention it as anywhere) who hammer on a "pure" Uru (not too sure what it means even), and if that is what they want, I'm sure they can have it. Just set up a server an invite a group of like minded avies.

Right after the announcement I noticed a lot of unbridled enthusiasm and wild energy floating around the forum, which is so nice to see. I don't think it is wise to try and stifle any of that yet, if ever. I think that the real challence will be to somehow channel such efforts, while leaving other people/groups free to choose their own path. Sometimes, that last bit seems to get forgotten in this settled communty, and once eager people might lose interest before the project is even started. Let us not determine what other people should want/do/say/feel/refrain from.

Re: Code + Asset Management

Anaerin — Wed Dec 17, 2008 11:13 pm

Author: Anaerin

Posted: Wed Dec 17, 2008 11:13 pm

And, of course, just because code is forked, doesn't mean the original branch can't take advantage of some of the new capabilities. I do think, however, that (after looking at the code for both server and client) we need to establish a firm protocol, so that all versions of server and client will work together equally.

Not to keep banging on about it, but IRC, Web (HTTP) and Jabber (XMPP) all do this, and do it well. There is an agreed standard, and no matter the changes to client(s) and server(s), it doesn't break the compatibility between them.

Re: Regarding 'official' locks...

thinkingman — Wed Dec 17, 2008 11:09 pm

Author: thinkingman

Posted: Wed Dec 17, 2008 11:09 pm

Sophia wrote:

...which can only be good for this dusty old community.

Hey, are you calling me "dusty"?? I don't mind being old, but "dusty"?! Just kidding. I agree, the amount of fresh perspective has been really invigorating and encouraging in the last week or so...

I think a lot of people misinterpreted my post, though, I had no intention of limiting ideas at all; but of course any time you keep software closed, it does tend to limit new ideas (a lot). I know there were a lot of suggestions I faxed/emailed to Adobe in the early years that were integrated into Photoshop where the extent of those ideas got seriously curtailed (BTW no credit for poor ole me ) but on the other hand, open source projects like ImageMagick, GIMP, etc., have really raised the bar for those Adobe folks.

OpenURU will do the same... I envision a project like Blender.org which is open, incredibly high-quality, with a really weird user interface (just kidding, I can do without the weird user interface part).

Re: Regarding 'official' locks...

Sophia — Wed Dec 17, 2008 10:32 pm

Author: Sophia

Posted: Wed Dec 17, 2008 10:32 pm

J'on wrote:

I'm not sure why so many are worried about forking.

Probably because most of us were brought up being told it is REALLY bad to use the word Fork

Just joking, I completely agree with your post, I don't see the need to be so rigid either, I am sure there will be deviations but that keeps everybody interested. I am already starting to see level headed discussions pop up, and less people throwing their toys out of the pram. Also, I am starting to see people who have never heard of Uru before perk up their ears and are already interested in dabbling with the code. To me, that means potential fresh blood, which can only be good for this dusty old community.

Gondar & J'on

thinkingman — Wed Dec 17, 2008 10:22 pm

Author: thinkingman

Posted: Wed Dec 17, 2008 10:22 pm

Gondar and J'on are completely right;

Client changes are necessary, however that doesn't reduce our need for compatibility, and the natural evolution of open source does mean people may flock to a central project - but doesn't guarantee that of course! I look forward to a Mac port -

Re: Regarding 'official' locks...

J'on — Wed Dec 17, 2008 12:36 pm

Author: J'on

Posted: Wed Dec 17, 2008 12:36 pm

thinkingman wrote:

Regarding 'official' locks...

This is how I look at the forking problem (hmm double entedre or what?) Cyan can make the Server app open source, but leave the Client closed-source. Prevent a lot of problems with incompatible servers... in other words, 'do whatever you want, just don't break the client architecture'. Apple did something like this by opening parts of OS X (a.k.a. Darwin). Although this effort is now officially over, it did spawn quite a bit of good while it was open, and much of that software is greatly in use today.

Do you realize that almost every time Cyan provided an update that a new client was part of that update? You can't make significant improvements to the game without being able to modify the client. And, as others have mentioned, you can't fix existing bugs in the client either.

Having worked for quite some time with open source projects, I'm not sure why so many are worried about forking. That's the nature of open source projects, and in my opinion, is a strength, not a weakness. Let the best ideas survive and let the bad ideas die a natural death. Instead of worrying about forks we should make it easier to accomplish, and at the same time making it automatic for players to be able to play on multiple shards with different clients, data, etc.

Some of this has to happen anyway, even if there is not a lot of forks happening. As long as there are multiple shards run by independent groups you probably don't want to make it mandatory that every shard updates at the same time. If a new client is required to play the newer version then you might have a problem if that new client does not work properly on the old version. The simple solution is multiple installs (and this may be the only solution at the start), but 1) that isn't very friendly, 2) may get out of control fast, 3) waste all kinds of disk space, etc. It would be better to modify the front end loader (which already handles version control and downloading of new clients) to find out from the data server what version and/or flavor of client and data are required to run on the shard in question, and have it download whatever is necessary into an install that can handle multiple versions of clients and multiple versions of data, sharing whatever can be shared. Give the player the ability to look at a high level how much of his disk space is being consumed in various versions along with the ability to remove versions corresponding to shards he/she may no longer desire to play on. Revision information would contain something like 1) flavor, 2) major number, 3) minor number. A flavor difference indicates a completely different client is required, i.e. the server is from a different fork with a different set of major/minor numbers. A minor number change means that the newer version can still be used to play an older version as long as the major number is the same. A major number change means that the new version is not compatible with older versions in the same flavor. An agreement at this level is the least binding, allows the most flexibility, and puts the control where it belongs (the player decides).

Data files present some interesting challenges also. Potentially translators can be written to translate various formats if people find reason to change data file formats in incompatible ways. Even if the format doesn't change, perhaps changes in prp files can be introduced at sub file levels -- something at a higher level than a binary diff, i.e. a prp diff that understands the prp format and can patch it, producing a cached version of a shard/flavor/revision specific prp before entering the game, somewhat similar to the ogg sound files being converted to wav format after they are downloaded. Speaking of sound files, in general they don't change, however new ones can be added. So potentially in most cases we might just have a superset of sounds, rather than having a lot of different versions of a particular sound file.

With this architecture the only "protocol" that has to be shared/agreed upon is the initial file loading protocol and file system layout of data files on the client side (even that can be abstracted). An example (although not perfect) might be to look at the linux boot loader vs. the linux kernel. There are lots of different forks of the linux kernel, but for the longest time there was only one boot loader (for the x86 architecture) called lilo. Now there are essentially two (lilo and grub).

There should probably be someone who assigns "flavor" numbers (perhaps automatically via a website). There should be a small range of "flavor" numbers reserved for experimentation/private use. Note that flavor numbers should not be a scarce resource, i.e. you shouldn't have to justify your need for a new flavor number, they should be handed out pretty much automatically (flavor numbers should not be used as a means of fork control).

Anyway, changes as outlined above won't be trivial to create (and work correctly!), but something like it should be an eventual goal in my opinion. Stop worrying about forking and embrace it instead. At the beginning things may be a little wild, but some consensus will probably emerge fairly quickly and evolve over time. Even if one "meta shard" eventually dominates you still want to allow for someone/or a group of people to make a huge change and give them the ability to have large numbers of people test it. Lets say someone figures out a way of allowing 500 people to be in the city with little or no lag, but it requires a complete change in the network protocol, client and server code. They probably won't really know if it actually works (even with a good simulation) without a good test, and it may take multiple tests over many months to get it right (Hopefully I'm not being too optimistic about getting 500 people to participate -- perhaps we'll have to bribe Rand to guarantee an appearance in the city when such a test is required. ) What if the data file formats didn't require any changes in this case? A system like I mentioned above would allow for completely different clients, sharing the same data (in reality there will probably be differences here, unless the developer constantly tracks the game related changes in the "meta shard" version), talking completely different protocols to completely different servers. This minimizes the pain for the players (i.e. not having to do multiple full installs, which can take a lot of time and consume a lot more disk space), which may be required for significant participation in such tests.

Finally, let the leaders be the ones who actually do great work, rather than people who just talk about it (and yes, that includes me -- I have intentions of working on this project, but I have no idea if I will actually find the time to do so).

Re: Code + Asset Management

Dot — Wed Dec 17, 2008 11:51 am

Author: Dot

Posted: Wed Dec 17, 2008 11:51 am

I'm wondering whether this would be a good project to set up and discuss over on the OpenUru site. It will facilitate work between interested individuals, whether they belong to a guild or not (not everyone wants to belong to a guild) and it may therefore be more acceptable to the wider community (since not everyone trusts the guilds ).

I've seen several names in this thread whose work has contributed greatly to the community during MOUL, and it would be great if they were on any team.

As has been mentioned, Chogon highlighted the possible use of Launchpad to ensure a good code basis. It would be interesting to see what people think about that. To that end, I've started a thread on OpenUru, Looking at Launchpad, where we can discuss its possibilities, hopefully without drama!

Re: Code + Asset Management

Gondar — Wed Dec 17, 2008 10:15 am

Author: Gondar

Posted: Wed Dec 17, 2008 10:15 am

Well, bugs are spread across all 3. Graphics errors and physics confusion is client-side. Various chat and SQL bugs and a lot of timeout crash stuff online is server. And of course netcode itself is spread between both. You need at BOTH to fix netcode. Otherwise you update server code and the client goes "buh?"

That and how can you port it properly to OSX and linux distros if you don't have the source? Wine isn't a port, just an emulation.

As it goes, I think the biggest problem is everyone is concerned about locks and governing instead of say a push-based guidance. Instead of saying "thou shalt not" to ideas, should instead be saying "Why doesn't thou do". Besides, it's going to be open source, it'll fit itself with some guidance under the structure when done. A person will take over a part and do something.. another thing will be someone saying "We need someone for x" and another will say "Sure!". Then you can have a pack of compilations that will more or less work together (just changing how the interface is drawn shouldn't break it for servers at all after all). So no need to really lock it down or anything.. it'll centralize on its own with no pressure.

You don't need to force something like this, the guilds don't need to take control, and certainly don't need to do pass "laws". Just provide a central group, and people will flock. If they get really bad and start swinging any power like a club, people will get pissed and take their work elsewhere.. and then the guilds will have to backpedal hard to fix the cracks they caused. Self-balancing, after all.

Re: Code + Asset Management

BlackRaven — Wed Dec 17, 2008 8:07 am

Author: BlackRaven

Posted: Wed Dec 17, 2008 8:07 am

Indeed. And I do think (speculation) that some of the problems that would need to be fixed exists within the client.

Re: Regarding 'official' locks...

hanse — Wed Dec 17, 2008 7:56 am

Author: hanse

Posted: Wed Dec 17, 2008 7:56 am

thinkingman wrote:

Regarding 'official' locks...

This is how I look at the forking problem (hmm double entedre or what?) Cyan can make the Server app open source, but leave the Client closed-source. Prevent a lot of problems with incompatible servers... in other words, 'do whatever you want, just don't break the client architecture'.

Then only Cyan can fix bugs and problems with the client or introduce new features. This would require resources from them and I don't know if they have enough resources.

Regarding 'official' locks...

thinkingman — Tue Dec 16, 2008 10:53 pm

Author: thinkingman

Posted: Tue Dec 16, 2008 10:53 pm

Regarding 'official' locks...

This is how I look at the forking problem (hmm double entedre or what?) Cyan can make the Server app open source, but leave the Client closed-source. Prevent a lot of problems with incompatible servers... in other words, 'do whatever you want, just don't break the client architecture'. Apple did something like this by opening parts of OS X (a.k.a. Darwin). Although this effort is now officially over, it did spawn quite a bit of good while it was open, and much of that software is greatly in use today.