I have an idea!
This forum has a history of failed monday projects, I worked hard on and then dumped one rather interesting attempt myself a while ago...

How about we make it more of a game?

Someone starts a project. Lay the basics down like, C or C++, file organisation, source control etc. And you implement a first feature.

Then it's the next developers turn. Add whatever you want, submit and pass it on.

Motivation for this format. It was my impression that people in the monday thread had very different ideas about which type of game they wanted to make. If the development process itself is a game like this then each participant is the boss for his turn, there will be no debating about where to take the game.

For this thread I'd like to discuss how to best make such a game work with the least risk of breaking down.

I think a good platform to use for "passing" the project around would be to use github. A main repo is set up, each developer clones the repo, works on it for his turn and sends a pull request.
A maintainer moderates the main repo and whos turn it is.

I suggest the maintainer keeps a turn queue where people report their interest in taking a turn. Keep turn length flexible if some just wants to contribute some smaller feature and others bigger features but say the max time for a turn is one week.

If someone can't use his turn when it comes up, I don't know if he should be bumped to the next slot or to the end of the queue. This should be moderated with care as to not discourage people who show interest in the project.

Important! In order to make sure the game always moves forward, it is not allowed to remove or "replace" features. Basically, do not move backwards or sideways, only forward.

Yeah that's basically the idea here. I didn't intend to launch a project that had to be designed before implementation. So, just like the aforementioned monday project this isn't one noob with a vision.

The whole point of the game is that there is no planning. Instead there is a moderator that just keeps it clean and moving forward, but has no say in where this forward is going.

So it's just like the forum game where each guy posts the next sentence in the story and it just gets crazier.

Another thing I thought of to clarify the last point of my first post. The ban on moving "sideways" does not include refactoring the code if necessary. As long as the implemented features aren't severely crippled.

Of course if anyone starts to get grand visions along the way, they're free to branch off the project and go where ever he wants with it. But that branch will be a completely separate project. We can just hope such branchings doesn't make the game come to a halt.

Sound like fun, i'm in!
As for which language to use, i'd say to just allow a C\C++ mix, so each submitter can just use the dialect he prefers.

The guy who starts the project kind of sets the stage. If he begins by coding C++, others are of course most encouraged to continue in the same style. Though perhaps people could be allowed to code C style, if the result doesn't get too messy.

Anyone may of course add scripting support at any turn, at that point it's his own choice which scripting language the project will be using from then on.

As for the analogy with the writing game trick of waking from a dream. Anyone could make completely different graphics and add a level that goes off on a rather different path. I don't know what level of moderation would be best in these issues, I guess that's up to the guy handling the main repo.

Another rule I just thought of, mostly relevant to graphics, but might be good for some code issues too.

Placeholder: If you put in some crappy graphics or ugly code needed to make your feature do anything useful. You can mark it as being just a placeholder. Then the rule about replacing implemented features is ignored for that piece.

From a spectator's point of view, it'd be more hilarious if this were not followed.

On the maintainer\moderator\boss thinghy: I think the most reasonable thing is to do it the most anti-democratic possible way.

I mean, this is your idea, you get the burden and the staff of power, if things go well you get the credit, if they don't you'll simply get the blame

If you put such delicate questions up to vote and sindacation there will never be any progress.

No more bikesheding, just get with it

http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality
http://en.wiktionary.org/wiki/bikeshedding

Basically a bunch of people getting together to make a bike-shed haven't spent a moment on the bike-shed itself, and instead argue over the color to paint it.

Attached is the initial source code and a simple MSVS2008 solution file.

I added a few harmless comments.

Is the repository going to branch off for people whom wish to go a different direction?

i.e. The framework may begin and someone turns it into a platformer, then someone else disagrees and branches off that code to turn it into a space shooter. Other developers may choose to assist with one or more branches, or branch off themselves. The branches that become inactive could become disabled and deleted.

The branching idea sounds really great! Evolution! Think of it! On February 12th (guess whose birthday!) we could release a bunch of games, say 5 or 6 . They would look very different. After the games had gain popularity all over the world , we would reveal their true origin. All evolved from one single piece of code, that did nothing more than maybe opened a window. People would say "No, that's impossible! Someone must have created each game separately."

= optimist smiley.