coder wrote : About the clickable areas: I presume that graphics and story progress together. So there's a picture with some options and the contributor wants to add a choice. Or take Arianeb, let's say you want to invite the girl in the gas station. You enter development mode, make the girl a clickable area, and offer a new branch. A graphic artist would then need to create a picture and the story continues. In this case you could also continue with the same picture.
Well, I suppose that up to a certain point it is true that they will follow eachother. I could imagine that if we did follow through with this idea we'd probably start with writing one linear story and then convincing one or more artists to join and create the graphics for it (creating a baseline in the techniques and models used for the graphics).
But on the other hand I can also imagine that if it becomes 'a hit' we'd end up with way more writers than artists. And then the story would continue to stay ahead of the graphics (provided the artists work in a 'first in, first out' fashion).
Concerning the consistency: In development mode you should see the history. So if you threw a glass wine over the girls dress, stole a camera or bought her a new dress, you should see that info. If a new branch depends on one of those things you should add a dependency to the branch. You can only take pictures if you have a camera. So to enter that branch you would need a camera.
It's funny that you mention a 'history'. I've been playing in my head with rather the same idea, being that a 'page' in the story should not only contain text and actions (and side-effects, if you include variables), but also some form of notes which can contain details about events that are important to know when expanding the branch. In development mode you could simply append these notes into a log, creating the history you mention.
However, there could be some overlap with variables, assuming they are available (I'm beginning to think there should be variables, but very basic (only booleans?), to keep real 'design issues' away from contributors). If we take the spilling of the wine as an example, this could be entered into the notes or could set a variable like 'dress ruined' to true. The first would assume that the issue is going to be resolved before the branch merges back into the main storyline (without lasting side-effects, also not graphical (!)), or that the branch never merges back (i.e. there will probably not be a good ending after that event).
Using a variable instead will pretty much open up any option you want, as long as the main storyline has dependencies on 'dress ruined' the branch can merge back after setting the variable. The great danger is that adding too many variables can cause a 2nd type of combinatorical explosion. While the number of pages can remain lower, each page will get more and more difficult to create when you have to account for a lot of variables. Considering that we are thinking about the premise of having a lot of writers it will probably become inevitable that some page ends up inconsistent with respect to some variable (but then again, anyone can fix it if he comes across it). It would make me think that variables should not be allowed to be created freely, but rather have it in the hands of the maintainers (I suppose).
Your idea to hide the unfinished branches for the player until they lead somewhere is also a good idea. Otherwise a player would always feel he's playing an unfinished game. Well maybe you could add an alpha mode. Maybe it could be integrated in the development mode.
I would just keep it limited to development mode. Although I just thought of another form of pruning and that would be graphically: only show branches that are both leading to 'proper ends' AND also contain images all along the way (although initially you'd probably end up with an empty story this way :P).
[cut]I also think it's a good idea to limit the possible choices. I don't think there should be more than 4 choices under the picture. In the picture there could be more choices.[/cut]
Considering that having a lot of choices will create a story exponential in size, I'd say this limitation is pretty much implicit. In addition you'd probably want to formulate a rule something to the effect that a choice must have some logical effect on the story. Consider a choice where the date asks the protagonist (i.e. the player) what his job is. I can imagine that someone might view the current choices and could think "well, I don't wanna have job X, so I'll add job Y!", but where the difference between X and Y has no effect. (Of course in this situation we could also consider having the protagonist included in the background details, so the job is static and your choices could instead be 'tell the truth' or 'lie')
But pixel hunting is not nice, so the area should be big enough.
I've been experimenting with a simple raster and it's pretty workable for creating a story. 3x3 works quite okay, maybe we should use 4x4 or 5x5 but I don't think it's necessary to make it any bigger.
Pro: A raster would be easy to edit.
Con: Having some freedom in the size might allow some more 'obscure' options, for example Date Ariane's stargazing game.
The big remaining question is how to handle the cooperation on the part of the graphics. I guess the idea with a downloadable project file should work. This would also mean contributor should be able to upload. In first instance you could use rapidshare for that. Later you could add an upload option to the site.
I just don't know how big the chances are, you would get graphic contributions. It's a lot more work, than just adding an option and a few lines of text.
Support for uploading is not that hard, but should have some limits, of course. Beside that, I'm afraid this really is a 'try it and see' issue. Maybe there are some motivated artists out there, maybe there aren't... (but if you are and you are reading this, drop a line!

)