What I should have said is that I am not willing to spend time developing a playable demo in order to display a concept or idea.
In your case, your design is a specialized form of control for movement and attacking; it would really benefit from a rough playable prototype. It could get your idea across. I don't understand why this doesn't seem worth the time to you? If it's not worth the time to you, why should it be to anybody else?
SinisterPride:
I think, though, that the process of prototyping (or constructing a playable model of a mechanic) may not only give you something to show people who may be interested in being a part of the development team, but it could also change the way you look at your mechanic.
For example: Maybe you have an idea of exactly how your control scheme will work (as you laid out in one of your other threads), and it really might work very well, but when you explain it, without showing it, all I think of is QWOP, and I no longer want to have anything to do with the project.
I think a big part of why people seem to be resistant to the idea of a pure "Designer", is because everyone on the team is part of the design process. Maybe one of the graphics programmers develops a really cool shader or figures out a way to include some graphical flourish that was dismissed as being beyond scope before... that person just influenced the design. Maybe only aesthetically, but that's part of design.
So, when someone comes along who doesn't want to show how a mechanic should behave or present a few concept sketches to get a feel for the aesthetic of the game, one really starts to wonder how integral their role in the development is.
I very much agree with NoAdmiral.
SinisterPride, you said the following yourself in an earlier post:
I believe in purpose in all my actions (even the menial ones) and shy away from waste of energy and time
When designing a complex system you will inevitably reach a point where accurately reasoning about the design and all of its implications in your head / on paper becomes practically impossible due to fundamental limitations of the human mind (such as a limited working memory). In programming we appreciate that all of the intricacies of a sufficiently large project cannot possibly be kept in one's head at any one time. The same could be said for any sufficiently complex system of rules, such as a game design.
Unexpected emergent properties arise in games frequently. If your design has reached a certain threshold of detail/complexity, and you are still working on paper, then making a change to the design is going to take a long time (as you have to back-track through the various connected elements of your design, and anticipate the implications of the change). The change will probably introduce other problems as well (as due to the design's complexity it is unlikely that your reasoning will be correct, let alone exhaustive).
The time/energy cost of reasoning about the effect of a change to the design on paper increases as the design's complexity grows, and the accuracy of your reasoning decreases. When you finally do begin implementation, you will likely have to tear out parts of the design as you realize that they don't work quite as expected. This can be extremely expensive. On the other hand, if you have a basic prototype then you can make a change and immediately test the implications. You can also get an early warning of any game-breaking design decisions - potentially saving you huge amounts of wasted effort. This allows you to know, rather than just think, that the design you have laid out behaves as expected in the real world. It allows you to empirically test the validity of your ideas, and reveals their true implications.
At some point it becomes more efficient to stop thinking/writing and instead create a functional prototype. It seems to me that the only question is where exactly this line is drawn.
As an aside, prototypes have frequently served as sources of inspiration - I'm sure many games (or at least major features) have been born from some quirky behavior in a prototype which turned out to be fun.
For some business applications, where requirements are very rigid and the general type of problem is pretty familiar, then a waterfall / non-iterative approach can make sense.
But for game design, at least for me personally, an iterative approach has been useful enough that I can't imagine using a non-iterative approach, from a practical basis.
To take just one example, I had initially imagined/planned/designed that the movement UI would be heavily accelerometer based. But, before I settled on my current movement AI, I quickly prototyped 3 different UI's: accelerometer, traditional buttons, and swipe. Over the course of a few weeks, myself and 2 others tested all 3 prototypes, and I made quick coding tweaks to fix bugs / fine-tune. We found that what I envisioned (the accelerometer), was absolutely terrible and so got scrapped completely and ended up going with swipe.
I'm very glad that I (or anyone else) did not spend dozens of hours making extensive, detailed plans based on using the accelerometer, as all that design work would of been wasted.
This isn't to say a nice design or an "ideas guy" is bad, I think they can be extremely useful in some situations. Specifically, where they are not set in stone but willing to rapidly iterate, and you already have enough programmers and artists.
For a small hobbyist team, an ideas guy even without programming or art skill could still be extremely useful to the team, as long as they are able and willing to do a lot of non-design tasks and grunt work the team needs too, as opposed to spending 90% of their time on ideas. If they spend 25% of their time or less on idea generation / design documentation, and 75% or more on other useful tasks, it could work out.
I'm talking about things like:
- recruit additional members: go to arts colleges and compsci colleges, hand out business cards, tack on your posters, go to game boards
- community outreach - go to web boards and chats and try to find new alpha testers
- find and purchase things like server hardware as needed
- schedule interviews with prospective new team members
- book meeting rooms / library room time / videochat and coordinate schedules for team meetings
- grunt work to relieve the artist: sometimes the concept artist needs 100 images to be resized in a way you can't automatically batch it, this is an area the ideas guy can help out, getting the artist back to working on the aspects of concept art creation only they have the skillset to do
- update the team's game website with content / blog posts
- research cost-effective marketing plans
If someone is the "ideas guy" and refuses to help out with these kinds of things, when the programmer(s) and artists are overloaded with work, that is probably what people are objecting to.
Now, if the team is big enough, say 10? 20 people? At a certain point, I think a full-time purist ideas guy / game designer or even several could make sense, depending on the situation. I haven't worked on game development teams that large, but hypothetically I could see a lot of value at that point in a true purist ideas guy, for some scenarios.
My keyboard finally gave out on me 2 days ago. I guess the poor thing deserves to R.I.P. after all the hardcore gaming and intense writing I put it through 
I responded through my phone for the last few replies. I'll post up the draft responses I have mostly written up on my phone. Won't get around to fully replying to all my threads till tomorrow, had a long day at both jobs 
I read everything though, good valid points which will pose tough responses. Thanks for the input/contributions guys, keep up the good work
People who are development oriented are hands on learners and perform better while having a creation to tinker with. Design oriented people are more comfortable envisioning and planning (extensively at times) before enacting said plans.
Most decent computer scientists spend days of architectural and design planning before writing a single line of code. Most decent game designers implement prototypes early, and tinker with them constantly in order to hone in on the desired behaviours.
Corollary: generalisations are generally worthless.
