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?

Bit agressive on your phrasing there buddy lol..

Did you read what I actually said? I won't spend time developing a PLAYABLE DEMO to DISPLAY a concept or idea.

If my goal is to express my idea for a concept or mechanic, my writing or sketches more than suffice to complete the task coherently.

If I aim to construct a playable model of said mechanics I will:

-sit down with an engine
-load up basic functional graphic models of my own making
-establish the scripting for the controller input > model reply/reaction
-then tinker my ass off until I'm satisfied with the results.

See the difference between when I aim to design something and when I aim to develop it?

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.

Totally and 100% agreed Sir NoAdmiral.

The thing is, you have to take into account (as someone mentioned earlier, not sure who, I'll check and edit this when I get home) that up until now I haven't had to articulate my thoughts to anyone but myself. My notes and prototypes have all been for me to catalog in case I ever wanted to make things public. This way I'd have something to show or a staring point that's not from scratch for a prospective team if it ever came to it. If my personality has shown at all in the last couple of days it should be known that I can contribute as well as consider criticism/bounce ideas around without being self centered.

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.

I was en route to my second job from the first a few hours ago when something happened. I made an odd correlation between my jobs and the prominent political debate between those who are design oriented and those who are development oriented.

I work as a building superintendents' assistant and as a security guard. My job at the building entails maintenance and contracting work (generally hard physical physical labor). As a security guard I'm meant to take on the role of an observer, reporter and at times a deterrent.

The correlation I made is in between the different modes of thinking/action I require in each job. At the building I'm expected to think less and do more (I AM expected to think though). As a guard you're expected to observe and think to realize things before they occur or react as they're occurring (here my state of mind is almost opposite).

The reason I found this relevant is that either one of these states of mind are often default modes of procedure/thought for people.

Some are "Do-ers" and reacting impulsively/instinctively works for them. Others are thinkers and planning/organizing is their approach to almost everything.

I first made this correlation between the types of people in martial arts where the technical types and the impulsiveness/instinctive types stand out largely in contrast.

To wrap my point up , Game design and development seems to have the same contrast. 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. The prejudice that exists between the two types of people is a needless one. More often than not they're both capable of the same feats. They just go about it through different paths.

I'm still working on those replies (long work day :-\). They should be up tonight.

Sin ?§•??§?

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.

Kinda proved my point with your statement but *yawn* to exhausted argue the point.. Gnite ppk