Cooperation in Wesnoth development (?)

[SlowThinker]

As an outside observer I feel that the game development must be quite chaotic. It seems like the Wesnoth code is a pudding-stone which consists of the core (which suits needs of the original little game, but not needs of present Wesnoth), plastered by less or more random code made by individual developers who just went aroud and decided to change something, solo and without any deeper discussion.

Where these my feelings come from?

• there is no good system in the game architecture, implementation, WML ... :
  examples:
  a code that manages the gamestate is mixed together with a code that manages the player's interface, and so for example context menus can be invoked during player's turn only
  somewhere in the forums I have read that the code that manages insert_tag is spread in many parts of the Wesnoth's code (!)
  and example that shows a mess in WML: link
• It is not uncommon that the Wesnoth's code is changed / new code is added, but it is not thought over well.
  examples:
  the WML parser 'eats' spaces in 1.10; link
  [tunnel] has been added to 1.10 but its usefullness is very limited; link
  Combat outcome calculation is extremely slow in SX games; link

Sure the text above is somewhat unfair, it generalizes and I don't think it is true with every piece of Wesnoth.

______________________________________________________________
My questions are:
How is the game development organized? Is there any system of cooperation?
In case you can be concrete: for example ... how the algorithm of 'combat outcome calculation' (see link above) emerged? It is not a trivial thing, so was there any discussion about it?
Why there is not a central list of planned changes (not only for bugs - gna.org) so that anyone can comment them (in every detail if needed, e.g. non-trivial algorithms)? (sometimes the intention to change the code is published, (example), but still, most people will miss it because it is not in a central place)


______________________________________________________________
Wiki:
Similar situation is with wiki - with my bad english and only partial knowledge about game mechanics I would never venture to directly add/change any text there. I could propose changes or comment a candidate-text created by other people, but it would require a central place where editing of wiki might be discussed.

[Crendgrim]

I am not going to comment on the first parts, as I know nothing about it, but I'd like to say something to the Wiki thing.

You are asking for a central place to discuss changes in the Wiki. Did you already know that the MediaWiki software we are using for the wiki has a function called "Discussion"? In Wesnoth's wiki theme, if you scroll down to the very bottom, there is a link "Discussion" which leads to a discussion page for the article (note: you might need to be logged in to the wiki to see it). Each article can have its own discussion page, and this might be used for what you have in mind.
If you look for a central place to discuss big rewrites of the wiki, though, we have the forums (section "Website") as a place to discuss it. Alternatively, asking on IRC in #wesnoth or #wesnoth-dev (or even asking the people in charge of the wiki directly) can help discussing it. As of now, there are not that many active wiki authors, so it's not a big deal to organize what is going on.

[SlowThinker]

Thank you, I added wiki to my to-do list.

(note: you might need to be logged in to the wiki to see it)

Yes, log-in is required to read 'Discussions'

[zookeeper]

Unless I've missed something, the discussion feature in the wiki hasn't really been in use, so trying to start discussions there doesn't sound like a good idea. That's what the forums and irc channels are for.

[SlowThinker]

IRC has no structure, I don't think I would want to search through IRC before editing of any wiki page.

Forum seems to be suitable, but only if one thread corresponds to one wiki page. Also all wiki editors should know they are supposed to search for a corresponding thread before they edit wiki...

... and searching for a corresponding thread may be more laborious than just looking into a related 'Discussion' page. Also a positive point is Discussion pages are shown at http://wiki.wesnoth.org/Special:RecentChanges. But I see one potential problem: in case I add a wiki page to my watchlist, is a related Discussion page added too (even if it doesn't exist yet)?

[Crendgrim]

Unless I've missed something, the discussion feature in the wiki hasn't really been in use, so trying to start discussions there doesn't sound like a good idea. That's what the forums and irc channels are for.

Yes, I actually did not mean to suggest one should write there something like "this and that needs to be changed" (as the concerned developer most probably won't ever read it), but that one could use it for certain things.

IRC has no structure, I don't think I would want to search through IRC before editing of any wiki page.

Hm. You don't seem to understand what IRC is.
IRC is a client-server based live chat protocol, mainly used for conference talks. So, if you join Freenode on the #wesnoth channel, for example, you will read everything that is written in there while you are there.
Additionally, there are chat logs of IRC channels to be found in some places, such as on http://irclogs.wesnoth.org for the Wesnoth channels.
I don't understand where you see the "no structure" there...

Forum seems to be suitable, but only if one thread corresponds to one wiki page. Also all wiki editors should know they are supposed to search for a corresponding thread before they edit wiki...

This sounds as if it would make things way more complicated while granting almost no gain. If someone edits the wiki (to clarify things I'll focus on the WML documentation here), it's either to add/modify documentation of a new feature, or to reword certain things. There is not really the need of having some pool of suggestions which is to be searched, actually.

[Gambit]

We could start #wesnoth-wiki on freenode

[ancestral]

We could start #wesnoth-wiki on freenode

You laugh, but… that actually might be a good idea.

[fabi]

As an outside observer I feel that the game development must be quite chaotic.

Well, the first thing you can do is change the "outside observer" status and join (or at least watch at) the developers community.
Since we do nearly all of our discussions in public you can have a look and see how far your feelings match the real situation.

Wesnoth is a participant in gsoc since several years, and you need a certain level of organisation to make that happen,
thus we already have a first evidence of some form of "organisation".

It seems like the Wesnoth code is a pudding-stone which consists of the core (which suits needs of the original little game, but not needs of present Wesnoth), plastered by less or more random code made by individual developers who just went around and decided to change something, solo and without any deeper discussion.

Both true, at least sometimes.

Where these my feelings come from?

Why do you feel the need to discuss your feelings here without a deeper insight into the public available codebase?
If those stuff is what you are interested in, why don't you learn to read the code?
Reading code and getting a rough idea of its function isn't black magic,
remember that programming languages are made from humans for humans.
That is why you need compiling, the stuff the cpu eats is not human friendly anymore.

there is no good system in the game architecture, implementation, WML ... :
examples:

a code that manages the gamestate is mixed together with a code that manages the player's interface, and so for example context menus can be invoked during player's turn only

Really?
As far as I know gamestate and gui are not bound together at all.
This is more a problem of network and event synchronization than a gui/gamestate issue.
The [menu_entry] system is a little limited on the one side but it is also easy to use on the other.

An early design decision was to define that a player can only act in her turn.
That constraint (and others) enabled to simplify the implementation to a degree that made Wesnoth develop fast,
if you don't define such constraints your engine design will end up too complex and the Project fails.
We would not have Wesnoth at all if the sum of those constrains weren't well chosen.

somewhere in the forums I have read that the code that manages insert_tag is spread in many parts of the Wesnoth's code (!)

We have some issues with functionality spreading too much but I doubt that inert_tag is one of them. Searching the codebase for the String "insert_tag" gives only hits in one file, variable.cpp and a quick look there gives no hint about other code parts being involved much.

and example that shows a mess in WML: link[/indent]

That is an issue with growing codebases in general. You add more features the original designed core wasn't meant for.
But I think we are good in cleaning this things up, most WML is in a good state currently.

[*]It is not uncommon that the Wesnoth's code is changed / new code is added, but it is not thought over well.
examples:

the WML parser 'eats' spaces in 1.11; link

1.11 is a development version, it is full of bugs and untested new features, that is the purpose of it.
If the space eating parser won't suit our needs it will most likely be not part of 1.12.

Bug Reports are better filled in the bug tracker than discussed on the forums,
the developer in question might not even read your forum thread but the report will reach him sooner or later.
The bug tracker is some sort of organization structure which brings order in the chaos.

I do not see your point with this example, why is it evidence that a change was done without thinking?
It is more an example of a bug (if it is one) introduced by accident as a side effect.
Those things happen, software development is a complex business.

[tunnel] has been added to 1.11 but its usefulness is very limited; link

Hmmm, I do not know if [tunnel] is the best example for limited usefulness.
[tunnel] is a side product of the redesigned [teleport] feature. While previous version's [teleport] was hard coded to the "Silver Mage" use case you can now implement
all sort of unit bound teleportation abilities with [teleport] and more map/event bound ones with [tunnel].
I call that a huge jump forward in usefulness.
The vision limitation in question was in fact a feature of the "Silver Mage" use case since it makes pretty much sense there.
During the implementation of [tunnel] this "feature" was inherited from the old specialized code.
Having normal sight through a tunnel is in fact a very rare and limited phenomenon, not a common law of nature.
Its usefulness is not very limited in general, as you claim, it just doesn't suit your very special use case.
That you need that feature for your exotic purposes is in fact a sign of the [tunnel] being very versatile.

Combat outcome calculation is extremely slow in SX games; link

Again, one of the constraints I mentioned above, thus a problem of a special use case.
You have unusual units in your example, with huge amounts of hitpoints and special features.
Support for it is not needed for normal Wesnoth games, thus supporting them will have a low priority.
On the other hand, if you can come up with a good algorithm, please present it.

Sure the text above is somewhat unfair, it generalizes and I don't think it is true with every piece of Wesnoth.

The problem with this discussion is more that your examples are bad ones and that we discuss "feelings" not facts.

Wesnoth's code base is for sure not perfect and the amount of organization could be increased.
But still you have a bunch of volunteers being unpaid for their work.
Forcing them into a rough organized working environment might be a huge motivation killer.
Remember that most of the developers earn their living with coding, not having a boss as a Wesnoth developer is a nice relief.


______________________________________________________________

My questions are:
How is the game development organized? Is there any system of cooperation?

Most stuff happens on irc at #wesnoth-dev. We have also a mailing list, you know the forums and the wiki.
For most open source projects that is enough, for example is the development of the linux kernel mostly coordinated on a single mailing list.
We could use some sort of task management system but the group of developers is still small enough to go on without one.

In case you can be concrete: for example ... how the algorithm of 'combat outcome calculation' (see link above) emerged? It is not a trivial thing, so was there any discussion about it?

Sorry, I can't tell you. But you can find out yourself. Isolate with the help of svn who did the commit and ask that person on IRC about it.
The svn history is also a form of "organization".

Why there is not a central list of planned changes (not only for bugs - gna.org) so that anyone can comment them (in every detail if needed, e.g. non-trivial algorithms)? (sometimes the intention to change the code is published, (example), but still, most people will miss it because it is not in a central place)

That is because nobody is paid to do it and there is obviously no volunteer for the job.
Do you want to do it?

Wiki:
Similar situation is with wiki - with my bad english and only partial knowledge about game mechanics I would never venture to directly add/change any text there. I could propose changes or comment a candidate-text created by other people, but it would require a central place where editing of wiki might be discussed.

As mentioned by others, the wiki is not the best place for discussing features.

[SlowThinker]

wiki

If someone edits the wiki (to clarify things I'll focus on the WML documentation here), it's either to add/modify documentation of a new feature, or to reword certain things. There is not really the need of having some pool of suggestions which is to be searched, actually.

I don't think it is only about rewording, it is also about adding a missing stuff: I remind you our debate started around the fact that max_hitpoints= should be added to wiki.
Why a pool is not needed? Please tell me another mechanism how to involve people like me in improvement of wiki. I mean people who see a problem in wiki, but are not sure about it or don't know all related stuff, or don't know english adequately.

Hm. You don't seem to understand what IRC is.
...
I don't understand where you see the "no structure" there...

IRC (as a candidate for a pool) is not structured (hierarchically or by another way). If I want to focus on a concrete wiki page (for example I want to edit it) then I should read all IRC logs.

As mentioned by others, the wiki is not the best place for discussing features.

I didn't want to discuss Wesnoth features, but texts that should be added/edited.

cooperation

Wesnoth's code base is for sure not perfect and the amount of organization could be increased.
But still you have a bunch of volunteers being unpaid for their work.
Forcing them into a rough organized working environment might be a huge motivation killer.
Remember that most of the developers earn their living with coding, not having a boss as a Wesnoth developer is a nice relief.

Yes, but more cooperation and communication about changes in the code doesn't require any hierarchy among Wesnoth devs.
And I would expect more communication should be rather motivating for developers - a debate about problems and algorithms is entertaining (at least for me).

A minor idea:
About the hierarchy: I fully understand it would be demotivating. From other side it would solve situations like this one: gna: Debug mode can be used in Network multiplayer; there are different views on the issue among devs, and so the issue stays unresolved in the worst possible state (IMHO): the debug mode is possible in MP, but players are not warned that one of them uses it.
Therefore my idea is:

groups with led by a boss would be possible, but on a voluntary basis only. So if a group of devs feel their thinking/programming style is similar, they can choose a boss and focus one one (or more) part of Wesnoth code, let us say replays. Other devs can work on replays too, outside of the group; members of the group are not limited to work within the group only, they can work solo too.

But maybe such organization would be needlessly complicated, and next feature would be good enough.

Why there is not a central list of planned changes (not only for bugs - gna.org) so that anyone can comment them (in every detail if needed, e.g. non-trivial algorithms)?

That is because nobody is paid to do it and there is obviously no volunteer for the job.
Do you want to do it?

Yes and no. Of course I cannot do it without a discussion
I will start a thread about it, but where shall I place it? Ideas? Coder's corner? Developers’ Discussions (but I don't have an access there)?

...I do not see your point with this example, why is it evidence that a change was done without thinking?
It is more an example of a bug (if it is one) introduced by accident as a side effect.
Those things happen, software development is a complex business.

I didn't say that changes were done without thinking, I said the thinking was not good/complete enough, possibly because changes weren't not discussed enough.
Amount of bugs in software depends on the design, and a pudding-stone type of software will suffer bugs much more than software with a good conception.

my examples

fabi, thank you for detailed answers.

The problem with this discussion is more that your examples are bad ones and that we discuss "feelings" not facts.

The question whether my chosen examples were good or bad ones is not important for the main topic of this thread, but I will answer because I must defend my truth and (so far) I believe my feelings were supported by rather good examples:

a code that manages the gamestate is mixed together with a code that manages the player's interface, and so for example context menus can be invoked during player's turn only

Really?
As far as I know gamestate and gui are not bound together at all.
This is more a problem of network and event synchronization than a gui/gamestate issue.

I am sorry for an unclear wording. I didn't mean gui itself, but a higher level of abstraction: I meant the code that manages the player's interface with the game status - for example a WML code that retrieves an additional information about a unit via the context menu - this WML should not be synchronized.
WML doesn't distinguish a) code (and data) that must be synchronized and b) code (and private data) that may run on individual clients and shall not be synchronized.

An early design decision was to define that a player can only act in her turn.

you mean 'act'='change game state', in my post I rather meant 'act'='retrieve info about game state'

and example that shows a mess in WML: link[/indent]

That is an issue with growing codebases in general. You add more features the original designed core wasn't meant for.
But I think we are good in cleaning this things up, most WML is in a good state currently.

I don't think WML is in a good state. WML has too many exceptions, the WML syntax doesn't reflect the implementation ... some problems are listed in the end of this post (see "Summary")

[*]the WML parser 'eats' spaces in 1.11; link

1.11 is a development version, it is full of bugs and untested new features, that is the purpose of it.
...
Bug Reports are better filled in the bug tracker than discussed on the forums,
the developer in question might not even read your forum thread but the report will reach him sooner or later.

I am sorry, I wanted to write "the WML parser 'eats' spaces in 1.10".
I usually prefer to start a thread before I report to gna.org, because I may be mistaken, and in this case it is possible the bug "has been considered negligible" by devs (according to this Anonymissimus' post)

Having normal sight through a tunnel is in fact a very rare and limited phenomenon, not a common law of nature.
Its usefulness is not very limited in general, as you claim, it just doesn't suit your very special use case.
That you need that feature for your exotic purposes is in fact a sign of the [tunnel] being very versatile.

This is a scenario that happens with the simplest kind of a tunnel (1 source hex, 1 target hex) in fog, blocked by an enemy unit on the target hex:
a player tries to move through the tunnel, but his move ends on the source hex, all movepoints are lost, no explanation, no way how to find out what happens on the other end of the tunnel, no way how to kill the blocking unit. So tunnel usefulness is rather limited to map areas where only allied units are supposed to move.
To allow a different topology of a map (to add a single hole that ends in another part of the map, or to have a cylindric map) is not a very special use case but a natural desideration. In fact I would expect such a desideration was the primary point that led to the implementation of [tunnel].

Combat outcome calculation is extremely slow in SX games; link

Again, one of the constraints I mentioned above, thus a problem of a special use case.
You have unusual units in your example, with huge amounts of hitpoints and special features.
Support for it is not needed for normal Wesnoth games, thus supporting them will have a low priority.
On the other hand, if you can come up with a good algorithm, please present it.

I presented an algorithm in the thread I referred to (see 'link' inside the quote). It works with berserk attack only, but similar principle may be used for a general algorithm (excluding situations where WML applies random effects to units involved in the combat)

This might be a history of the algorithm (it needn't to be accurate, and also I neglected some complications, but it serves well as an example what happens / might happen if there is no coordination among developers):
The original author wanted the calculation worked in very general situation (i.e. also with any crazy user-made WML that affects the combat). So he applied a brute-force (2^n) algorithm. Later people noticed the calculation was very slow in SX games, and so another developer imposed these limits to attack: max. 4 specials (berserk, drain ...) can take effect for any attack.
So finally the algorithm is neither fast nor it handles a general situation.

[Crendgrim]

The discussion indeed started about the addition of max_hitpoints=. However, adding / updating the documentation of a WML tag / attribute should be done by the developer introducing / changing it right after the commit, so in most cases this situation won't happen at all. If a developer forgets about it, though, it is very unlikely that he will see it when it is posted somewhere in a "pool" of some sort. In this case, it is better to either add the information to the wiki, or (in case of doubt how the tag/attribute works exactly) ask the developer directly to add it. Having a pool of random thoughts will not help here as it needs someone to structure it, and to keep track of what was already changed in the wiki and what wasn't. This requires a lot of work from a single person which could better be used to find out who changed something and talk to this person about how to document the changes.
Actually, I do not believe a mechanism like a shared information pool is even needed. There are very few people interested in improving the wiki who are not developers themselves (be it either engine developers or UMC authors*). The ones of these who are not necessarily able to find out who changed stuff are UMC authors; and there are not many of them who regularly spot mistakes in the documentation. Most of those who do are either engine developers themselves, or are in touch with them. Maintaining a pool then for only a handful of people sounds like too much.
Also, if someone wants to edit a wiki page, he cannot be forced to read all random thoughts of different people on that page before editing it. Introducing a method like the one you're proposing doesn't offer many advantages IMHO, but rather complicates things for contributors.

* I will use the terms "developer" and "author" here to express the difference between those working on the program, and those only using the powers of the WML interpreter.

[SlowThinker]

wiki

Maintaining a pool then for only a handful of people sounds like too much.
...
Having a pool of random thoughts will not help here as it needs someone to structure it, and to keep track of what was already changed in the wiki and what wasn't.

But there is a structure already, that copies the structure of wiki: each wiki page has its own "Discussion" page.
Only few people are interested in wiki improvement, and so it is very likely 'Discussions' would be rather empty than full of random thoughts.

In this case, it is better to either add the information to the wiki, or (in case of doubt how the tag/attribute works exactly) ask the developer directly to add it.

It is not so easy to browse a page history and to find out who inserted a specific text. Also some paragraphs were edited by 5 or more people - so whom should I contact?
Also I believe one-to-one communication is not so effective as many-to-many communication: it is always possible a third person has something to say; or somebody else than the person I contacted would be willing to do the editing.

Also, if someone wants to edit a wiki page, he cannot be forced to read all random thoughts of different people on that page before editing it.

Who says anybody would be forced to read the 'Discussion' page? A wiki contributor could skip it (then he would be in an identical situation like now) or use it.

[Crendgrim]

Only few people are interested in wiki improvement, and so it is very likely 'Discussions' would be rather empty than full of random thoughts.

And that's why nobody will ever look at it. Especially since in Wesnoth's wiki layout the link is rather hidden.

It is not so easy to browse a page history and to find out who inserted a specific text. Also some paragraphs were edited by 5 or more people - so whom should I contact?

Well, the developer who introduced the change. And yes, I know that this is not easy at all, but it is the only way to do it, as nobody else will know how exactly it works now. Or ask on the forums, and somebody else (read: a developer roughly knowing who works on what) who sees the thread might look for the developer.

Who says anybody would be forced to read the 'Discussion' page? A wiki contributor could skip it (then he would be in an identical situation like now) or use it.[/section]

Then nobody will look at it. Especially not the developer who introduced a feature but forgot to document it (for whatever reason that might happen). And getting this developer's attention is the important part here, which just cannot be solved by using the semi-hidden discussion page.

[SlowThinker]

wiki:

And that's why nobody will ever look at it. Especially since in Wesnoth's wiki layout the link is rather hidden.

Discussions are shown also at Recent changes, and that page is frequently visited. See SingleUnitWML‎ there.

Well, the developer who introduced the change. And yes, I know that this is not easy at all, but it is the only way to do it, as nobody else will know how exactly it works now. Or ask on the forums, and somebody else (read: a developer roughly knowing who works on what) who sees the thread might look for the developer.

The developer should have his pages in his watchlist ... hmmm ... there is no way how to add an e-mail notification?

[Crendgrim]

Well, the developer who introduced the change. And yes, I know that this is not easy at all, but it is the only way to do it, as nobody else will know how exactly it works now. Or ask on the forums, and somebody else (read: a developer roughly knowing who works on what) who sees the thread might look for the developer.

The developer should have his pages in his watchlist ... hmmm ... there is no way how to add an e-mail notification?

What? There are no specific pages for a certain developer. If a developer changes something in InternalActionsWML, he can as well change something in EventWML or wherever. So, he would have to watch all changes to the whole documentation, and that cannot be enforced.