I go in-depth into my thoughts about a 'game designer' position here.

The entire post is important in my opinion (says the person who wrote it), but here is one snippet amidst many:

I'd love for someone to adequately explain in detail why changing the reload time of the sniper rifle in Halo 3 from 0.5 seconds to 0.7 seconds was beneficial. That is a game designer. Someone who constantly has in the back of his mind that it takes exactly 2.4 seconds for the player to do a complete 180 degree turn around in whatever specific FPS he's working on, and the effect it has on competitive play. This is the science of game design. It should be called "gameplay mechanic engineer", IMO.

@Servant of the Lord: Thank you for linking your article It was indeed important and I thoroughly enjoyed reading it as well as wholeheartedly believe it to be true as it is necessary.

This goes in line with what I had just posted on being grounded in my role. It would allow me to contribute to other disciplines either through my own or through understanding/knowledge of other said disciplines. Thank you for your input Sir

The nature of your 'idea' will significantly effect any answer you can get.

Is it a paradigm shift that noone in the industry will seriously consider (maybe even for 10 years)...

(I have BIG ideas that a whole generation of tools would need to be developed to make happen)

Is it some nifty game mechanic that any company would want demonstrated before they will understand it is doable...

(someone mentioned using mods of existing games to short circuit prototyping your idea)

Is it something that could be put on an APP (and thus rarely make a single buck of profit, thus cutting out all but hobbyist development).

DO you know it will work ? Thats sometimes the hardest of all -- to realize an idea just wont work (or rather work in the right way so players would actually want to play it).

---

Ideas ARE a dime a dozen, but demonstratable ideas cost alot more...

Design is really not the same kind of activity as development. There are many people who enjoy one activity and not the other, in both directions.

I don't know... maybe... but still I find it suspicious, this whole divison to design and development. I think I could agree to some people liking only development without design (like coders who like to code, whatever it is), but someone who likes designing and not liking developing? That does not make sense to me...

Architects may not construct the final building, but they don't just have ideas of what they want

I think architecture is a very bad example. Builders precisely follow the given blueprints, they are not allowed to change almost anything (even materials used or thickness of the walls), it's required by law. On the other hand development process stray so far from the original design document that... What the designers envisioned and what was delivered is so different that if it was a building it would surely crumble :D

Game designers are not like architects. They are not even remotely similar.

Game design is in fact more about daydreaming and spewing ideas.

No, it's not! http://sloperama.com/advice/lesson14.htm

Architects may not construct the final building, but they don't just have ideas of what they want

I think architecture is a very bad example. Builders precisely follow the given blueprints, they are not allowed to change almost anything (even materials used or thickness of the walls), it's required by law. On the other hand development process stray so far from the original design document that... What the designers envisioned and what was delivered is so different that if it was a building it would surely crumble

Game designers are not like architects. They are not even remotely similar.

Hmm, I disagree. All you are really saying is that game designers have not learned how to be very good at their job yet. This is because we don't really understand games very well. If people truly understood games fully, it would be possible to produce a precise design that a programmer could turn into a completely functional and playable game.

It is rather beside the point though - the point was that anybody who is truly involved in the design process is also truly involved in the implementation process.

If people truly understood games fully, it would be possible to produce a precise design that a programmer could turn into a completely functional and playable game.

What makes you think that game design is a fully deterministic process? All the evidence I see suggests that works best as an iterative process between designer, artist and developer.

We don't build a house with 12ft ceilings, make a beta tester live there for a month, and then rip the building apart to make 14ft ceilings. In game design, this sort of thing is a daily occurrence...

It's pretty much a tautological fact. The only reason you ever need to iterate is because you didn't have enough information originally, because the act of iteration X is done to get you information for iteration X+1. It stands to reason that if you already had that knowledge and the same resources, you wouldn't need previous iterations. You could always have written the final version first, had you known that's what was needed.

On a more practical and less idealistic level, better understanding of games and software could seriously reduce the amount of iterating, waste, and trial-and-error that currently takes place. We're learning to iterate faster because it's easier than learning to understand better.

It's pretty much a tautological fact. The only reason you ever need to iterate is because you didn't have enough information originally

That once again assumes that the problem space is fully deterministic.

It's not clear to me that abstract concepts like "aesthetics" and "fun" adhere to determinism in the same way as does the ability of a bridge to withstand 10,000 newtons of lateral shear...

If the problem space is deterministic, then iteration is not strictly necessary. And if the problem space is not deterministic, then iteration is not strictly sufficient. The fact that we embrace the iterative process shows that we presume there is important information to be found about our designs, and I agree - I just think that we shouldn't think iteration is the only way to find it.

(As an aside, it's not strictly an architect's job to ensure a bridge withstands 10000 newtons of lateral shear - that's what civil engineers are for. Information is passed up and down the chain to facilitate the optimal design. This is quite relevant because I gave the example of an architect just to show that even someone who works mostly on the aesthetic and functional side rather than the low level implementation details still has to draw up detailed artefacts to show what they want constructing. Any iteration is confined to the higher level parts of the process.)