You've (hopefully) all seen this quote.. OpenQuake volunteered its facilities for the discussion necessary to cull and thoughfully compile suggestions. Notice that the says, "from designers," and in his later .plan mentions that they don't design games by committee. There's a difference here, the one that you ( general ) have been arguing about. Something like the quaternion proposal is a good proposal. ( Note: it *was* a suggestion. Now it's a proposal; while I don't tend to stand on nomenclature, the work done on the psuedo-coding and research evident in the prosposal distinguishs it from a suggestion.) This is the kind of thing we want to send to id: while perhaps underdiscussed, it will probably ( has? -- I'll check tonight ) gotten by unvetoed by the list; it's apparently technically sound, sums up the advantages and disadvantages, suggests an implementation; and most importantly, requests something from id that NOT ONLY could improve gameplay ( better support for rolls; more freedom in terms of rotating entities on the map ) but is something that is not exposed to our manipulations.

Any proposal that could be implemented by the designer can be considered alongside those that cannot, but BEAR IN MIND: any proposal sufficiently detailed to have a good chance is a proposal sufficently detailed to form a design document for a mod. And the process is designed to cull out those proposals people are unwilling to work for. Personally, I think an autodownload proposal with an attatched URL to the ModSpy beta homepage ( and attatched source ) would get a lot more attention than any other proposal. "It's doable -- we've done it. It's ugly -- you could make it pretty. It's popular -- you could make it famous." If you don't think a front-end should be included with a game, include either console options ( i.e. telnet ftp vs CuteFTP / WS-FTP ) or suggest that it be incorporated ( graphically ) into the 'Network' menu.

Anything we can do, they can probably do better, but we ( collectively ) have a whole lot more time. I want them to concentrate on things we can't change; most of the gameplay features won't make it in under their 'committee' defense anyway, unless they already have the idea and are looking for a means. I think that id will go over the final list with an eye towards things that developers can't already do. If this includes problems of scale, consider that id probably doesn't have more time than you coming up to work on it, on top of the work they have already committed to for Quake 3.

The wishlist idea is in direct response to the Carmack quote: we know these idea are not perhaps as thoughtful as these others that have made it through our culling process; we know most of them are outside of our domain ( i.e. committee defense ), but we thought you should have a look at them anyway. Right now, the wishlist has no formal or informal existence; I have yet to see a compiled list, and I will not compile one; just keeping up with the proposals eats my time. However, the autodownload thread(s) are still right now at least half-wishlist; whatever resemblance to the original proposal ( go look it up on the web :)) they used to have have disappeared almost entirely. Bielby ( so far as I know ) has not modified his original suggestion yet, because the discussion on it ( or about its idea ) is still so fervent. Being on the 'new suggestions' page is not an indication that the suggestion is off the wishlist; that culling is reserved for making it to 'under discussion' ( as a proposal ). Being put on the suggestion page basically means that you put enough time into the suggestion to write it up in the proper format and are willing to submit it to the scrutiny of the world. The culling process is, in part, designed to make sure that time is spent on the proposals, that they really are thoughtful.

Summary:

The point I'm trying (and probably failing) to make, is that unless id are wanting to concentrate on just creating a game engine for coders and designers like us to hack away with, the kind of opinion of "those that aren't happy can change it themselves" doesn't work.

It doesn't matter if it works or not. id knows what they want to do for the GAME; that's the whole point of the committee comment. What they're asking the DEVELOPERS ( read the quote ) for is ways to code the game that they've decided on making so that the small but influential minority who make the game so great by modifying it are happier.

I hope I made sense here.

What constitutes an acceptably culled and thought out list? I think any suggestion that makes it through the process we've outlined will be a thoughtful one; whether or not id will pay any attention to it depends on its content and if it's the kind of suggestion they're looking for: that is, code-based. That is the issue of culling. Do we allow gameplay suggestions through?

I a say a modified yes: the wishlist will exist in parellel, and only wishes that make it through without veto will be compiled into the wishlist OpenQuake sends id along with the 'Hopefully Final' proposals. Until then, the wishlist will not exist in seperation from the proposal list. The topic 'q3wish: xxxx' should be used for gameplay suggestions, especially ones that are not expected to be example coded.

For example: the current 'new suggestion' "Autodownload" could end up on either list. If the author took the time and thought and effort to code up a solution -- wrote the console-based half of ModSpy ( but say, only for skins ), the part that id would drop into every copy of Quake 3 ( with or without the ModSpy hooks ); if that happened, Autodownload ( assuming it passes both vetoes ) would be sent to id on our final list of proposals; otherwise, ( assuming it passes both vetoes ) it would be sent on the wishlist.