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.

I second this.

I'm still not sure how the "don't remove code" thing should work, because I can basically screw all of you by doing things like:

#define ( =

I think it should be acceptable to comment out lines that you want to remove.

No need to:

#if 0
#define ( =
#endif

...I have just been convinced to not use comments.

#define 0 1

Fortunately, you can only #define identifiers.

The program will be in a single file only
..
Assets may be attached to your post, they should be free of copyright restrictions

I have never used SDL or SFML, do they not require effect files like DX / OpenGL? or would they be considered as an asset

Why don't we use HTML5 and Canvas?

I have never used SDL or SFML, do they not require effect files like DX / OpenGL? or would they be considered as an asset

You can inline the effect files as std::string

I have never used SDL or SFML, do they not require effect files like DX / OpenGL? or would they be considered as an asset

You can inline the effect files as std::string

But that would make things bloated and difficult to work with, oh wait.. ;)

For the sake of added confusion, I think the use of goto should be encouraged

I have never used SDL or SFML, do they not require effect files like DX / OpenGL? or would they be considered as an asset

For simplicity, I was thinking the game would be 2D sprites. I was thinking the skeleton program might just be a bouncing ball or something.

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.

I was considering C, but I figured some people would probably end up using C++isms anyway, by accident. Including me, in the skeleton program (whoops!). I think that more people would be comfortable with C++, rather than pure C.

Why don't we use HTML5 and Canvas?

Again, I'm not sure that is quite as popular as C++ here. I think the experiment will live or die on the number of participants it could garner. I'm open to correction here, but I didn't really want to start a formal poll.

Nothing quite a hard to follow as heavily monkey patched ruby.

I'm still not sure how the "don't remove code" thing should work, because I can basically screw all of you by doing things like...

Well, my initial idea was that the code wouldn't be intentionally poor - but instead it would turn out that way over time due to the difficulty extending the game while adhering to that rule.

Now, if people prefer to treat this as a IOCCC entry where the code is intentionally crazy, then sure. In that case, the rule makes less sense, though I think it still has some value to preserve the collaborative nature, i.e. preventing someone replacing the whole program with something completely different.

I think it should be acceptable to comment out lines that you want to remove.

I think that would be OK. Then again:

For the sake of added confusion, I think the use of goto should be encouraged

Why not just jump over the offending code? >=D