Submitting changes to Cyan

Bellerophon · **Joined:** Wed Apr 14, 2010 2:46 am **Posts:** 34

kaelisebonrai wrote:

except that's probably the main thing happening. you're ignoring the facts, here =P

Sorry, what's the main thing happening?

kaelisebonrai · **Joined:** Sun Jan 20, 2008 2:14 pm **Posts:** 902

tool development.

also, "main codebase" doesn't really exist, so you can't restrict any point of view to it. =P

Bellerophon · **Joined:** Wed Apr 14, 2010 2:46 am **Posts:** 34

kaelisebonrai wrote:

tool development.

also, "main codebase" doesn't really exist, so you can't restrict any point of view to it. =P

Yeah, but like I said, the biggest challenge will be presented by the sheer number of contributors to the single trunk.

And it doesn't exist yet, but it will, that's the whole point of this thread.

In any case, development will probably be taking place on a linked project repository+bug tracker (hopefully something like Bazaar repo and lanchpad enviroment, if it gets a compatable licence) so it'll be standing alone on there anyway, guilds irrelevant except for defining the people involved.

Keiya · **Joined:** Mon Feb 08, 2010 3:08 pm **Posts:** 66

Personally, I'm inclined to just sit back and see what happens. It's somewhat surprising when you first see it, but people are actually pretty good at 'spontaneously' organizing when it helps them reach a common goal.

What I see as likely is a loose 'collective' of people working on it, swapping code, ideas, and tips. Probably, it'll be a growth off the GoW because that's where the talent and knowledge is, but over time it'll probably become a distinct, but overlapping and closely cooperating group.

In short: don't sweat it, and it'll almost certainly work out fine

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

and if Cyan says the GoW is going to be the semi-official forum for development, then the GoW contributor base will naturally grow to match, with new fans heading over to try their hand at poking into the guts of Uru.

andylegate · **Posted:** Thu Apr 15, 2010 5:24 pm

I've seen a lot of:

"Game Engine Code dev is completely different from Making Fan Ages"

in many different ways in several posts here. And then used as an argument why Dev discussions, etc, should not be hosted say by the GoW.

I've also seen:

"Coding developed by the GoW for making Ages is not the same as code developing for the Game Engine"

It's been pointed out that were it not for the VERY good understanding by the many coders that are currently and in the past at the GoW, the plugin for Blender that gives people the ability to create Fan Ages would not even exist.

The 2 are NOT exclusive of each other, and in fact have a VERY intimate relationship.

Code changes to the engine can have possible affects of how things are done in Ages. If those things change, then the plugin (and I'm talking about Cyan's plugin) will have to change too.

A large chunk of "Bugs" that get fixed, or things that might be changed will be done by people that do programing of course. However, those same "chunks" will also need to be tested by those that do work on creating Fan Ages, as they have a very good understanding of how Plasma works.

Not all Age Creators have that understanding, no. Anyone that wants to, can download Blender, and the GoW's plugin, install them, read some tutorials, and make a simple "Box Age" and say they have done it. People that have Max can also download Cyan's Plugin now, and do the same thing.

However, to create a really GOOD Age that would be close to on par with Cyan's Ages (and they're out there), including puzzles, interaction animations, etc, requires the Age Creator to be VERY familiar with Plasma and Python.

I don't just model things, throw some textures on it, export and walk around. I also make things like Journals, Linking books. Working doors, Levers, Buttons, GUI pop ups, how X event MUST happen before Y takes place.

All of those things will have me using a Python editor more than sitting in Blender and Max. If you think that Cyan's Plugin made Age Creation simple, you all are in for a very rude awakening. I've been making tutorials for them over at the GoMa, and I can tell you right now, while point and click is much easier than typing in ALCScripting code, you have to understand WHAT to point and click, and WHY you need that, and understanding the "why" means understanding how Plasma works.....

So please don't think that Fan Age Creation is something that has nothing to do with changes being made, or fixes being done to Plasma, they are linked very close together. As such, those doing the changes will need to be in very close contact with those making Ages (yes, I know, many changes can be tested with existing Ages, but at the same time, will you, a person who may not have created Ages before, be able to tell me WHY the avatar slid 4 feet and then stopped at one place, instead of stopping immediately? Was it because something has changed with the Terrain physics? The Friction? Was it set to 0.5?).

So keep that in mind while discussing this, while I'm not saying "YES" this should go to the GoW, what I AM saying is that you can't just through Age Creators out the window......won't work.

Bellerophon · **Joined:** Wed Apr 14, 2010 2:46 am **Posts:** 34

andylegate wrote:

So please don't think that Fan Age Creation is something that has nothing to do with changes being made, or fixes being done to Plasma, they are linked very close together. As such, those doing the changes will need to be in very close contact with those making Ages (yes, I know, many changes can be tested with existing Ages, but at the same time, will you, a person who may not have created Ages before, be able to tell me WHY the avatar slid 4 feet and then stopped at one place, instead of stopping immediately? Was it because something has changed with the Terrain physics? The Friction? Was it set to 0.5?).

So keep that in mind while discussing this, while I'm not saying "YES" this should go to the GoW, what I AM saying is that you can't just through Age Creators out the window......won't work.

Oh, I'm not saying that in the least. I'd imagine that the GoW and a seperate engine programming guild would comprise many of the same people and leaders with their existing knowledge and skills, as well as new people and that the Agemakers would make requests of the Engine-eers. It's just that I think it'd be organisationally easier to have it a seperate standalone setup keyed specifically to this one thing, since it's such a huge undertaking and the current GoW has a very broad spectrum of focus. I mean, there's crossover between the Maintainers and the Writers but that distinction is still convenient.

In any case, like I said before, I'm not sure that it's actually that relevant, since dev discussion should be taking place on a project-specific bugtracker hooked into the repo anyway.

PaladinOfKaos · **Joined:** Thu Aug 03, 2006 10:55 pm **Posts:** 625

Discussion about bugs and feature requests that have been put into the tracker will happen on a bug tracker.

More general discussion about development, vision, new ideas, and coding help will occur in IRC, mailinglists, or forums. A bug tracker isn't designed for that sort of talk, and it makes it harder to find real bugs. So where that discussion ends up does sorta matter, though if no place is defined the devs will make one (or gravitate towards OpenURU or the GoW).

DarK · **Joined:** Sun May 21, 2006 11:51 am **Posts:** 510

Montgomery wrote:

But the structure is still there -- having been developed when the guild was popular and active -- and should the guild be needed to do the job Cyan had in mind for it, we could start it all up again in relative short order. Including elections of officers, etc., by the community.

Structured Guilds are bad news to me...

Re-Building the guilds as "Ivory Towers" is one of the worst things we can do and will tend to block people out of development.

If we restrict development to those already involved, and trap source behind a social structure which you have to convince to include your work, there is a barrier to people starting development.

Its total ignorance to place development behind a screen such as traditional guild structures, it is those elected people that decide the view of Uru.

This can also apply to cyan picking a team to manage the patch process, but I would be more willing to accept a picked team from cyan. Uru is after all their product.

I would not accept some one else’s vision coming from a group of self electing players, Just because they have more friends than someone else, thus allowing them to be elected into a position in control of consensus.

I recall been sat in an IRC chat room one night and watched a well known player at the time, spout off that they had more right to develop and be in control of Uru than a person who was just starting out. I will never forget that, because the performance also showed why that player should not be in control through a lack of respect for others and their work.

These people do exist, and they usually spout off against such directions that devolve control.

(Please Note: this is not a slamming of guilds, many people in guilds have said they are loose associations without leadership, if they maintain that structure there is nothing wrong with the guilds been used to support development)

PaladinOfKaos wrote:

More general discussion about development, vision, new ideas, and coding help will occur in IRC, mailinglists, or forums.

What this forum, GoW, GoMa, Uru Obsession ... any other Uru communication channel are about really.

PaladinOfKaos wrote:

A bug tracker isn't designed for that sort of talk

On a tracker, I would expect to see details of the bug, discussion about the bug, code to fix the bug, reports of the fixed bug.

Look on a bug tracker as a very specific topic thread on a forum; I would not expect the level of diversion in this thread on a tracker.

If the diversion does happen for a particular reason (e.g. bug turns out to be multiple bugs), I would expect the original to be closed, and several more bugs appear in its place.

With feature planning, I would expect an entry on the tracker with discussion done on forums and links placed on the tracker for reference, with technical implementation issues done on the tracker.

BUT ... and here is the good stuff, if you are working in a group already and have everything you need, you don’t have to work on the main tracker.

Keep working until you are ready to release. Then place an entry on the main tracker with the final work when it is ready to be included.

A bug tracker is self documenting (and is documentation for a system), a forum thread is not self documenting and therefore practically useless in development.

Bugzilla comes with a vote system, and there are things on launchpad that allows “popularity contests”, ideally this would be the only way non developers interact with developer’s workloads. However as a developer yourself, you can decide to ignore the "popularity contest" as you personally see fit.

Personally I don’t want to have to browse 10 forums/10 individual trackers to decide what to work on. If it’s all in one place, I can see what needs doing.

Moderation of the tracker can be done similar to the forums, cyan picked the moderators for the forums, I don’t see it been an issue for cyan to do the same for the tracker?

Additionally as we’ve already seen recently, if we collectively as a community don’t generally like something done by a person cyan gave authority to. We tend to rebel and make our collective thoughts known.

Whilyam wrote:

Two questions people would ask themselves during any review.

Does this violate the Terms of Service?
Does this crash the game for a person who meets the system requirements?

Anything more than that is only there to create drama and nonsense.

Don’t ever say that if you work for a software house, you would be thrown from a 5 story tower block for wasting people’s time.

To build a straw man...

“I want Uru to become the operating system of all players that play Uru, I will force you all to uninstall windows and Uru will be your instant messenger, your internet browser, your word processor, everything on your computer will be done via the game Uru live”

Suddenly the idea of forming consensus does not seem that bad of an idea. We can add little flicks of other things here and there, but actually allowing a single person to totally move the goal posts is a bad idea.

I want to be developing a game not a twitter client, facebook client etc... “Popularity contests” on trackers tend to help prevent waste on things that are utterly useless to the overall product, as people don’t want them.

More discussion is needed from people on the end points of development - How to get code and how to submit code.

What happens in between, is not really the issue here.

Edits: Spelling and format

Keikoku · **Posted:** Thu Apr 15, 2010 7:00 pm

Eat_My_Shortz wrote:

Whilyam wrote:

There are only two criteria which any serious evaluation should use: Legality and Stability. Not "best of" not "consensus." Two questions people would ask themselves during any review.

Does this violate the Terms of Service? (obviously to be changed to allow code modification)
Does this crash the game for a person who meets the system requirements?

Anything more than that is only there to create drama and nonsense.

Whoa ... you're suggesting that every single change which is legal and doesn't crash the game should be accepted outright? So I could write a patch which immediately unlocks all Relto pages, or make star-wipe transitions on all Ki screens, and we shouldn't have a debate about whether those changes are worthwhile? (Someone in another thread suggested we add Facebook and Twitter integration into the Ki ... surely we should think twice before we make such a feature!!)

From a technical perspective, it's better to have a single code-base with everything in it than a hundred different forks and dozens of modified client executables, each with some arbitrary set of features. Otherwise, whenever someone adds a feature, they either have to figure out how to add it to each variant, or you end up with a matrix of "feature X is/is-not compatible with feature Y".

It's preferable to have a single code-base where individual features can be enabled or disabled either at compile time (#ifdef) or at run-time (config file). Then, anyone adding a feature only has to consider a single code-base (although they may need to explicitly handle the different configurations).

Better still if you can create a sufficiently flexible extension architecture so that as many features as possible can be implemented as add-ons.

However, there's a limit to this. Features which require interface changes require updating everything which uses that interface. As the number of extensions and features grows, interface changes become more expensive. So apart from needing "stability" in the sense that the program doesn't crash, you also need a degree of interface stability (and sanity).

So a third reason to reject changes is "this change will make life harder for everyone else". This is where it gets tricky. Unlike legality and reliability, this isn't an objective question, but a judgement call: is it worth the cost? This issue is, in large part, why successful software projects often gravitate toward the "benevolent dictator" model (e.g. Linus for the Linux kernel, Guido for Python, etc). There will inevitably be choices which require a degree of judgement, and it all comes down to whose judgement.

If people can't agree, then you may end up with a fork. Unlike a branch, which is just work which hasn't made it into the mainline yet, a fork tends to constitute a separate development target. I.e. developers can write code for one fork or another, or if they have time on their hands, can write multiple versions of the code for multiple forks. Usually, one fork wins out, in that most developers write for that fork primarily or exclusively. Occasionally, multiple forks persist (e.g. XEmacs has been around for 15 years and shows no sign of either dying off or re-unifying with GNU Emacs).

In the early stages, it may even be beneficial to have forks, so that design decisions can be solved by a "bake-off" (i.e. which forks attract developers and which ones get ignored). If nothing else, this will help people understand that "you can't have everything" is a law of nature and not just The Man keeping them down.

EowynCarter · **Joined:** Wed Dec 20, 2006 4:19 pm **Posts:** 1161

First point, we need a place to centralize everything, preferably cyan maintained.It's nice a have groups, but we need to reference, and a way for said groups to communicate. And communicate with the rest of the community too. We're not going to go anywhere if everyone do it's stuff in their own corner.
A place to find info on coding, a ticket system, a way for developers to say "looking for help in doing this or that", or "did that fix, don't bother doing it again".
Unless that is done, everything will pretty much break.

Then, that be different changes.
Pure bug fix (Ok, accepted)
Technical accept is easily done with, either it works, either it don't.
Adding clothes / ages -> Some system is needed to activate / deactivate stuff, if only to avoid hard drive overflow. So people will get what they want and voilà.
Changes that will affect the while game : some will be so small no one will really care. > For the rest, use good old democracy. If the votes are to close, Cyan have the veto.
It's also a question of accepting that not every change will be what you yourself want. But I think that, overall, we'll find ourselves going the same way.
Forks are unavoidable, they need to be to have some variety, but hopefully, there won't be that many of them.

We don't need one procedure, we need multiple ones depending the size and impact of the changes that where made.

We're diffrants people with differants ideas, but we still need to work together.

Frisky Badger · **Joined:** Tue Mar 20, 2007 6:48 pm **Posts:** 746

DarK wrote:

Montgomery wrote:

But the structure is still there -- having been developed when the guild was popular and active -- and should the guild be needed to do the job Cyan had in mind for it, we could start it all up again in relative short order. Including elections of officers, etc., by the community.
If we restrict development to those already involved, and trap source behind a social structure which you have to convince to include your work, there is a barrier to people starting development.

Its total ignorance to place development behind a screen such as traditional guild structures, it is those elected people that decide the view of Uru.

Structured Guilds are bad news to me...

Re-Building the guilds as "Ivory Towers" is one of the worst things we can do and will tend to block people out of development.

I'm sorry, but where has anyone suggested that the Guilds be used to "block people out of development"? The 2 Guilds getting the most attention in this discussion, GoW and GoMa, have open enrollment. All you have to do to join is say you are in the Guild. There are no restrictions whatsoever and as far as I can remember, there never have been. I thought "Ivory Towers" were supposed to be exlusive.

Neither of these Guilds is demanding that we be given control of this process and we certainly aren't going to, but I guarantee that whether Cyan decides to officially involve the Guilds in this process or not, there will be Writers (a lot of them) digging into the code and there will be Maintainers (a lot of them) inspecting new additions for bugs/glitches.

DarK wrote:

(Please Note: this is not a slamming of guilds, many people in guilds have said they are loose associations without leadership, if they maintain that structure there is nothing wrong with the guilds been used to support development)

I understand. You are trying to protect everyone's opportunity to help with Uru. All I'm asking is that you give the Guilds the same opportunity. In the end, whether you're in a Guild (or any group) or not, we're all just fans trying to keep Uru moving.

Christian Walther · **Posted:** Thu Apr 15, 2010 9:19 pm

Eat_My_Shortz wrote:

My only remaining concern is this reputation thing. You rightly argue that I should be taken seriously only if I am actively submitting code. My concern was just that even if I did submit code, I might not be taken seriously because I'm not well known in, say, the GoW community. Not sure how to solve this.

I think it was me who introduced the word “reputation” in this thread, so I feel compelled to clarify what I meant. Perhaps it wasn’t the best choice of words.

Submitting code is not required at all to build the kind of reputation I am talking about. There are many other ways to contribute – artwork, user feedback, organization, even well-written forum posts about completely unrelated topics. Also, building a reputation need not take a long time. There is no complex hierarchy that you have to slowly make your way through until you are deemed worthy. For a start, all it takes is a few forum posts. Case in point, I haven’t had enough to do with you to have an opinion of you before, but you have already earned a lot of trust from me by your thoughtful posts in this thread.

Any fears that being taken seriously in the GoW would require one to gain access to an exclusive elite of ancient wizard hackers are unfounded. The atmosphere I see is that everyone is welcome, and respect is given to those who get things done, no matter where they come from.

I wouldn’t say you are not well known in the GoW community. Many of the people who make up that community read this forum too and see what you post here.

But enough of this tangent, and back on topic. Where I like what you are saying very much.

Whilyam · **Joined:** Tue May 09, 2006 1:04 am **Posts:** 4134

Bellerophon wrote:

I mean, think about what you're asking with your turn on/off source code thing here. You're basically asking that when someone wants to download MOUL that they'll download a massive amount of code with thousands of different patches to the same files, go through a codebase assembling a completed version, run a compiler and compile, and then connect to the server. Which promptly crashes because there are dozens of different codesets connecting to it. Mister Blue, you see, decided he liked kicking to be less strong than Mister Red, and now they have incompatable physics engines.

No, that is not what I'm suggesting. You're extrapolating that out beyond what I explained. Firefox, again:
When you install Firefox, do you download every add-on ever made? No. Same with Uru. Understood?
As for your crashing strawman, that isn't stable, that thus is not allowed. Still with me here?

Quote:

No, there needs to be a primary trunk and compiled version that is peer-reviewed with a coherent view to the future and engine development, and a server based on that reviewed version.

No, there needs to be the base game with code that players can install on their own.

Montgomery wrote:

One must also consider canon. This is hge, becuase it it the depth, subtlety and internal consistancey of the canon that makes Uru (and all of Myst) the place the community enjoys exloring.

Drama or not, I personally feel there needs to be some kind of filter to avoid material that simply does not belong in the Uru universe. There should be strict guidelines for how the process is handled, and the pool of individuals who make those decisions should be open to any who want to vote. The Guild of Maintainers may be the natural choice for this.

Stop with the scary "material that doesn't belong in Uru" nonsense. There are two instances of material that doesn't belong in Uru and only two. 1: Material that is illegal/forbidden by the ToS (this covers pornography, malware, impersonation, and other areas). 2: Material that crashes users who meet the system requirements (this covers material that conflicts with other material, incomplete material, material that triggers another action that crashes the game, etc.).
Canon is subjective, open to interpretation, and able to be disregarded by anyone, including Cyan. It is a useless criteria, plain and simple and it has no place in a workable code/content approval process.

DarK wrote:

Whilyam wrote:

Two questions people would ask themselves during any review.

Does this violate the Terms of Service?
Does this crash the game for a person who meets the system requirements?

Anything more than that is only there to create drama and nonsense.

Don’t ever say that if you work for a software house, you would be thrown from a 5 story tower block for wasting people’s time.

Fallacious nonsense. We are not a software house, we are a diverse group of people who have never reached consensus. We either need a credible source of authority (Cyan) managing the game (impossible) or we need to allow individuals to choose their own path.

Quote:

To build a straw man...

“I want Uru to become the operating system of all players that play Uru, I will force you all to uninstall windows and Uru will be your instant messenger, your internet browser, your word processor, everything on your computer will be done via the game Uru live”

Suddenly the idea of forming consensus does not seem that bad of an idea. We can add little flicks of other things here and there, but actually allowing a single person to totally move the goal posts is a bad idea.

I want to be developing a game not a twitter client, facebook client etc... “Popularity contests” on trackers tend to help prevent waste on things that are utterly useless to the overall product, as people don’t want them.

More discussion is needed from people on the end points of development - How to get code and how to submit code.

What happens in between, is not really the issue here.

Edits: Spelling and format

If someone can do something like your example, more power to them. The fact is, it's practically impossible. You would be developing a game. If people want to add code to allow connections to Twitter, etc. why not? Before you say "that's not Uru" ask yourself how Uru's done being essentially stagnant? We need optional add-ons, not mandated golden-ness. Code add-ons need to be searchable, optional, and openly-developed. Allowing people to find and install (or not find and begin development) of features they personally want to see.

In short, none of these are rational responses to my common sense suggestions. Until the community at-large rejects this paranoid knee-jerk response, the "golden" branch will not be the cauldron of creativity it must be for Uru to thrive.

Marten · **Posted:** Thu Apr 15, 2010 11:12 pm

Optional add-ons would be great. There is little to no structure in place at the moment to permit such a thing. The first patches submitted are most likely to be like Pavitra's hash words patch - it changes the system in a way that is not designed to be backwards compatible or optional. If the point of the patch is to make the censored words into a non-cleartext format, then also allowing the words to remain in a cleartext format is orthogonal to the point of the patch.

Fundamentally, though, Whil is correct, and the above observation does not create a roadblock.

To cut down on the number of patches that Cyan has to review, folks will need to discuss and share their work. Participants should be encouraged to integrate their patches together. If 5 different people submit 5 different KI patches, Cyan is not going to be able to integrate all 5 because the patches will likely conflict with each other. In such a case, Cyan's going to pick 1 change or no changes at all. So, if contributors all want a chance to get their work into MOULa, they are going to need to work together, integrate their work before it goes to Cyan, and provide a patch that each of the contributing participants can live with. The scope of this sort of thing is going to be determined by the number of people contributing conflicting patches or ideas.

Sometimes a person is going to not want to merge their idea with another person's. That's fine. That patch can go to Cyan solo. While Cyan's ability to review patches remains limited, this may make such "solo projects" less likely to get integrated. However, that is up to the developer and Cyan, and is not a concern of the peer review, which should exist to foster collaboration and smooth over differences.

Submitting changes to Cyan

Who is online