//EDIT: See THIS POST (from page 4 of this topic when viewed with default settings) for the "results".

//EDIT: See THIS POST (from page 3 of this topic when viewed with default settings) for revised rules and links to the actual topics.

Possessed Inspired by this thread, I was curious as to what would be the outcome of a game developed collaboratively right here, with the main rule being You can only add new code, not alter or remove existing code. I'm not sure if this has been done before, while I am vaguely reminded of something gone before I cannot find any thing.

Here is how I see this "working" (or, as is perhaps more likely, going up in flames):

• I will post a basic skeleton program. I'm thinking C++, SDL 1.2.X or SFML
• Posts here will act as a kind of revision (un)control system, each post a "commit"
• You must attempt to amend the current version of the code (revision number?)
• The code change for a single "commit" should be relatively small and cohesive - add or change a single feature at most
• Posts should highlight what was changed (if possible using a diff?)
• Posts should include the full source of the program so far
• The program will be in a single file only
• Dependencies are limited to the standard library and the multimedia library only. No OS-specific calls
• Assets may be attached to your post, they should be free of copyright restrictions
• You can only add new code, not alter or remove existing code
• You may, however, alter numeric or string constants in existing code
• You may add code into existing lines:
  • Add a new clause to a condition
  • Add to an existing expression
  • Add parameters to existing function declaration/definition/call sites
  • Adding // at the start of a line is allowed by this rule (?)
  • You may also "insert" a newline after a //, thus uncommenting such code
• The code must compile on your platform of choice, and should strive to be cross platform
• The code must not crash, to the best of your ability
• Bad commits are ignorable under the "amend the current version" rule

I don't know whether there should be a theme. A theme might help focus the initial work, but I think lacking a theme could have some hilarious results.

Any thoughts? If there is sufficient interest, I could post the initial version sometime soon, perhaps at the weekend (Halloween seems topical). Of course if it has all been done before I will just slink away quietly...

The "code can't be altered" rule can be circumvented by duplicating the code and using version numbers in the function/variable names. But then again, on the other hand, if a bug is found in some existing piece of code, you want some kind of mechanism to be able to alter it...

Does commenting out lines count as "adding code"? Theoretically, the lines to gain in character count...

Well if the language is ruby, then you can add monkey patch code.

The "code can't be altered" rule can be circumvented by duplicating the code and using version numbers in the function/variable names.

Good point, but I think the intent here is more the spirit rather than the letter. The rules are just to give some structure.

But then again, on the other hand, if a bug is found in some existing piece of code, you want some kind of mechanism to be able to alter it...

Working around existing bugs is part of it!

Does commenting out lines count as "adding code"?

I'm not sure if commenting should be allowed or disallowed, or maybe just discouraged.

This is the coding equivalent of a Dwarf Fortress Succession game.

Doomed to failure. Bound for hilarious greatness.

I think a theme is a good idea, though.

Well if the language is ruby, then you can add monkey patch code.

I am open to suggestions on the language and libraries, but I was hoping for something reasonably popular, but not a "framework" like XNA or a full engine like Unity.

I like Ruby, but I don't feel it quite meets the popularity criteria around here.

Pity. Nothing quite a hard to follow as heavily monkey patched ruby. Especially if different versions of the same function get called at different times.

I'd vote for plain-old ANSI C. It's simple enough, everybody knows it, and it's got huge potential for creating an awful mess.