The team working with the game designer doesn't have to trust him.. They have to understand him.

... That's... It... It made me speechless

...

If you don't like the game design.. Find another game designer who has something of your interest.
You could become a game designer yourself.. but I haven't seen any programmers who are good game designers.
Programmers have a bad habit of just going with the flow since they can code instantly whatever ideas pop into their head.
And they only make mediocre GDD's because of this.. if they make one at all.

I think you're too hung up on the importance of a GDD. If you'd studied software development you would know about agile development methods, a fairly new way of structuring development. An emphasis is made on evolving requirements and producing code that can be quickly modified as a result. Unit tests and good (software) design patterns are used to help ensure code quality and maintainability.

Agile methods typically dispose of the monolithic design document, as they are often outdated by changes during development. The substitute used varies between specific methods, but typically a looser collection of requirements are used that can be easily rearranged and modified.

I frankly don't care if a game designer can write a GDD. I care if they can effectively organize and communicate an idea using whatever medium is best suited to the task at hand.


I can give a personal example of evolving design from my own project. (a 2D space trading game for context)

When I started I wrote out 5 or so pages of design, not comprehensive but enough to communicate the idea. I then started work. A few weeks in I hit a roadblock. My design called for large systems where the player could fly freely around. This didn't work (the engine I was using couldn't handle the large images for planets, and they took too long to procedurally generate).

So I changed the design, split off the navigation and battle into separate parts. This gave my an opportunity to try Newtonian physics in combat, since it wouldn't complicate the navigation.

A few weeks later I had Newtonian combat. Turns out, it wasn't very fun, and I spent a lot of time writing helpers for the player (leading targets, missile tracking, etc) to make the game playable.

So I redesigned it to a more stylized combat. Ships now flew about like it was the 18th century and broadsides were all the rage. This turned out to be quite fun, but a little limiting. The player only controlled one ship and sometimes you could get swarmed by enemies if your AI team-mates abandoned you.

So I redesigned it. When I'm done with the current prototype the player will control his entire fleet directly. Essentially a 2D space RTS with ships pretending it's the 1700s. Hopefully it will be fun, if it isn't I'll redesign it again.


I'm not claiming to be a great designer, just showing that unforeseen roadblocks (the technical issue, or combat not being fun) can force a redesign, and you shouldn't be afraid of it. Embrace it as a chance to experiment and learn.

(sorry if that rambled a little off topic)

[quote name='glhf' timestamp='1334935798' post='4933244']
...

If you don't like the game design.. Find another game designer who has something of your interest.
You could become a game designer yourself.. but I haven't seen any programmers who are good game designers.
Programmers have a bad habit of just going with the flow since they can code instantly whatever ideas pop into their head.
And they only make mediocre GDD's because of this.. if they make one at all.

I think you're too hung up on the importance of a GDD. If you'd studied software development you would know about agile development methods, a fairly new way of structuring development. An emphasis is made on evolving requirements and producing code that can be quickly modified as a result. Unit tests and good (software) design patterns are used to help ensure code quality and maintainability.

Agile methods typically dispose of the monolithic design document, as they are often outdated by changes during development. The substitute used varies between specific methods, but typically a looser collection of requirements are used that can be easily rearranged and modified.

I frankly don't care if a game designer can write a GDD. I care if they can effectively organize and communicate an idea using whatever medium is best suited to the task at hand.


I can give a personal example of evolving design from my own project. (a 2D space trading game for context)

When I started I wrote out 5 or so pages of design, not comprehensive but enough to communicate the idea. I then started work. A few weeks in I hit a roadblock. My design called for large systems where the player could fly freely around. This didn't work (the engine I was using couldn't handle the large images for planets, and they took too long to procedurally generate).

So I changed the design, split off the navigation and battle into separate parts. This gave my an opportunity to try Newtonian physics in combat, since it wouldn't complicate the navigation.

A few weeks later I had Newtonian combat. Turns out, it wasn't very fun, and I spent a lot of time writing helpers for the player (leading targets, missile tracking, etc) to make the game playable.

So I redesigned it to a more stylized combat. Ships now flew about like it was the 18th century and broadsides were all the rage. This turned out to be quite fun, but a little limiting. The player only controlled one ship and sometimes you could get swarmed by enemies if your AI team-mates abandoned you.

So I redesigned it. When I'm done with the current prototype the player will control his entire fleet directly. Essentially a 2D space RTS with ships pretending it's the 1700s. Hopefully it will be fun, if it isn't I'll redesign it again.


I'm not claiming to be a great designer, just showing that unforeseen roadblocks (the technical issue, or combat not being fun) can force a redesign, and you shouldn't be afraid of it. Embrace it as a chance to experiment and learn.

(sorry if that rambled a little off topic)
[/quote]

So basically you had a concept only of a game that sounds good but you don't know for sure since you don't have a complete GDD.
That was the first mistake.. This is the same thing as creating a game without a game designer.. An idea is just an idea.. you have to make a GDD too.

But lets pretend that you had a great GDD.
Then you run into problems coding the game.. but it's not the game designers fault.
It's the programmers fault.. And the game designer gets punished for it?
The programmer should have made a code design and chosen the correct engine that can create the GDD.

It sure sounds like you had a lot of trouble though in that project... you had to redo huge parts of the game several times and the game isn't anything what your idea was.
Doesn't that ring a bell?
Don't you see now how amazing it is having a game designer on your team?
All that trouble wouldn't ever have appeared if there was a good designer with a good GDD from the start.. and ofcourse a good programmer as well.

[quote name='ShawnCowles' timestamp='1334937382' post='4933260']
[quote name='glhf' timestamp='1334935798' post='4933244']
...

If you don't like the game design.. Find another game designer who has something of your interest.
You could become a game designer yourself.. but I haven't seen any programmers who are good game designers.
Programmers have a bad habit of just going with the flow since they can code instantly whatever ideas pop into their head.
And they only make mediocre GDD's because of this.. if they make one at all.

I think you're too hung up on the importance of a GDD. If you'd studied software development you would know about agile development methods, a fairly new way of structuring development. An emphasis is made on evolving requirements and producing code that can be quickly modified as a result. Unit tests and good (software) design patterns are used to help ensure code quality and maintainability.

Agile methods typically dispose of the monolithic design document, as they are often outdated by changes during development. The substitute used varies between specific methods, but typically a looser collection of requirements are used that can be easily rearranged and modified.

I frankly don't care if a game designer can write a GDD. I care if they can effectively organize and communicate an idea using whatever medium is best suited to the task at hand.


I can give a personal example of evolving design from my own project. (a 2D space trading game for context)

When I started I wrote out 5 or so pages of design, not comprehensive but enough to communicate the idea. I then started work. A few weeks in I hit a roadblock. My design called for large systems where the player could fly freely around. This didn't work (the engine I was using couldn't handle the large images for planets, and they took too long to procedurally generate).

So I changed the design, split off the navigation and battle into separate parts. This gave my an opportunity to try Newtonian physics in combat, since it wouldn't complicate the navigation.

A few weeks later I had Newtonian combat. Turns out, it wasn't very fun, and I spent a lot of time writing helpers for the player (leading targets, missile tracking, etc) to make the game playable.

So I redesigned it to a more stylized combat. Ships now flew about like it was the 18th century and broadsides were all the rage. This turned out to be quite fun, but a little limiting. The player only controlled one ship and sometimes you could get swarmed by enemies if your AI team-mates abandoned you.

So I redesigned it. When I'm done with the current prototype the player will control his entire fleet directly. Essentially a 2D space RTS with ships pretending it's the 1700s. Hopefully it will be fun, if it isn't I'll redesign it again.


I'm not claiming to be a great designer, just showing that unforeseen roadblocks (the technical issue, or combat not being fun) can force a redesign, and you shouldn't be afraid of it. Embrace it as a chance to experiment and learn.

(sorry if that rambled a little off topic)
[/quote]

So basically you had a concept only of a game that sounds good but you don't know for sure since you don't have a complete GDD.
That was the first mistake.. This is the same thing as creating a game without a game designer.. An idea is just an idea.. you have to make a GDD too.

But lets pretend that you had a great GDD.
Then you run into problems coding the game.. but it's not the game designers fault.
It's the programmers fault.. And the game designer gets punished for it?
The programmer should have made a code design and chosen the correct engine that can create the GDD.

It sure sounds like you had a lot of trouble though in that project... you had to redo huge parts of the game several times and the game isn't anything what your idea was.
Doesn't that ring a bell?
Don't you see now how amazing it is having a game designer on your team?
All that trouble wouldn't ever have appeared if there was a good designer with a good GDD from the start.. and ofcourse a good programmer as well.
[/quote]

You're arguing both sides of the same coin and you can't even decide which one you're supposed to be in favour of.

The programmer is supposed to know everything he is supposed to know from the GDD, but it's the programmer's fault if the wrong engine is used? Either the programmer has the choice of what engine to use, or he doesn't. Which means either, you say in your GDD "You will use this engine." - and the designer needs to be a top notch programmer, or you're allowing the programmer to choose something which isn't stated in the GDD.

Throughout the entire thread you've said that the GDD is the most important part, everything is in the GDD, if you gave the same GDD to two different teams you should get the exact same game out at the end. This simply is not possible. If it was, then the designer isn't needed at all during the development process, since everything should be done before the game starts being made.

You need to figure out which side of the fence you're on.

[quote name='ShawnCowles' timestamp='1334937382' post='4933260']
snip

So basically you had a concept only of a game that sounds good but you don't know for sure since you don't have a complete GDD.
That was the first mistake.. This is the same thing as creating a game without a game designer.. An idea is just an idea.. you have to make a GDD too.

But lets pretend that you had a great GDD.
Then you run into problems coding the game.. but it's not the game designers fault.
It's the programmers fault.. And the game designer gets punished for it?
The programmer should have made a code design and chosen the correct engine that can create the GDD.

It sure sounds like you had a lot of trouble though in that project... you had to redo huge parts of the game several times and the game isn't anything what your idea was.
Doesn't that ring a bell?
Don't you see now how amazing it is having a game designer on your team?
All that trouble wouldn't ever have appeared if there was a good designer with a good GDD from the start.. and ofcourse a good programmer as well.
[/quote]

What I was attempting to illustrate was that a good designer should realize that change is inevitable. For example the Newtonian combat seemed really fun on paper. It didn't turn out that way so it had to be changed.

As for the veiled personal attack, I consider it a point of pride that the game could be changed so rapidly to suite the changing design. It is a sign of a well engineered system.

EDIT: Decided to not feed the flame war by removing veiled personal attack of my own.

[quote name='glhf' timestamp='1334938346' post='4933269']
[quote name='ShawnCowles' timestamp='1334937382' post='4933260']
[quote name='glhf' timestamp='1334935798' post='4933244']
...

If you don't like the game design.. Find another game designer who has something of your interest.
You could become a game designer yourself.. but I haven't seen any programmers who are good game designers.
Programmers have a bad habit of just going with the flow since they can code instantly whatever ideas pop into their head.
And they only make mediocre GDD's because of this.. if they make one at all.

I think you're too hung up on the importance of a GDD. If you'd studied software development you would know about agile development methods, a fairly new way of structuring development. An emphasis is made on evolving requirements and producing code that can be quickly modified as a result. Unit tests and good (software) design patterns are used to help ensure code quality and maintainability.

Agile methods typically dispose of the monolithic design document, as they are often outdated by changes during development. The substitute used varies between specific methods, but typically a looser collection of requirements are used that can be easily rearranged and modified.

I frankly don't care if a game designer can write a GDD. I care if they can effectively organize and communicate an idea using whatever medium is best suited to the task at hand.


I can give a personal example of evolving design from my own project. (a 2D space trading game for context)

When I started I wrote out 5 or so pages of design, not comprehensive but enough to communicate the idea. I then started work. A few weeks in I hit a roadblock. My design called for large systems where the player could fly freely around. This didn't work (the engine I was using couldn't handle the large images for planets, and they took too long to procedurally generate).

So I changed the design, split off the navigation and battle into separate parts. This gave my an opportunity to try Newtonian physics in combat, since it wouldn't complicate the navigation.

A few weeks later I had Newtonian combat. Turns out, it wasn't very fun, and I spent a lot of time writing helpers for the player (leading targets, missile tracking, etc) to make the game playable.

So I redesigned it to a more stylized combat. Ships now flew about like it was the 18th century and broadsides were all the rage. This turned out to be quite fun, but a little limiting. The player only controlled one ship and sometimes you could get swarmed by enemies if your AI team-mates abandoned you.

So I redesigned it. When I'm done with the current prototype the player will control his entire fleet directly. Essentially a 2D space RTS with ships pretending it's the 1700s. Hopefully it will be fun, if it isn't I'll redesign it again.


I'm not claiming to be a great designer, just showing that unforeseen roadblocks (the technical issue, or combat not being fun) can force a redesign, and you shouldn't be afraid of it. Embrace it as a chance to experiment and learn.

(sorry if that rambled a little off topic)
[/quote]

So basically you had a concept only of a game that sounds good but you don't know for sure since you don't have a complete GDD.
That was the first mistake.. This is the same thing as creating a game without a game designer.. An idea is just an idea.. you have to make a GDD too.

But lets pretend that you had a great GDD.
Then you run into problems coding the game.. but it's not the game designers fault.
It's the programmers fault.. And the game designer gets punished for it?
The programmer should have made a code design and chosen the correct engine that can create the GDD.

It sure sounds like you had a lot of trouble though in that project... you had to redo huge parts of the game several times and the game isn't anything what your idea was.
Doesn't that ring a bell?
Don't you see now how amazing it is having a game designer on your team?
All that trouble wouldn't ever have appeared if there was a good designer with a good GDD from the start.. and ofcourse a good programmer as well.
[/quote]

You're arguing both sides of the same coin and you can't even decide which one you're supposed to be in favour of.

The programmer is supposed to know everything he is supposed to know from the GDD, but it's the programmer's fault if the wrong engine is used? Either the programmer has the choice of what engine to use, or he doesn't. Which means either, you say in your GDD "You will use this engine." - and the designer needs to be a top notch programmer, or you're allowing the programmer to choose something which isn't stated in the GDD.

Throughout the entire thread you've said that the GDD is the most important part, everything is in the GDD, if you gave the same GDD to two different teams you should get the exact same game out at the end. This simply is not possible. If it was, then the designer isn't needed at all during the development process, since everything should be done before the game starts being made.

You need to figure out which side of the fence you're on.
[/quote]

Game design should include everything that is about how the game is played and what the player can see.
Engine is behind the scenes.. It's something that imo at least falls into coding design.. the programmers job.. He has to chose a engine that can create the game in the GDD.. which is the programmers job.. creating the game (the GDD).. while the designers job is designing the game.
The programmer could even chose to create a new engine if he thinks it's more efficient.. but that's something he would have to discuss with the director.

Game design.. is for designing the game..
Engine is for creating the game.

But lets pretend that you had a great GDD.
Then you run into problems coding the game.. but it's not the game designers fault.
It's the programmers fault.. And the game designer gets punished for it?
The programmer should have made a code design and chosen the correct engine that can create the GDD.

Yes, programmers are the main source of problems during the development of a game. Regardless of professionalism level. That's the way it is, that's how it always was and that's how it will always be. And the job of the designer is to fix it. Actually, any decent designer should take it into account when making GDD and provide some alternatives in case an unproved experimental technology will not work.

Also, passing "fault" around is a childish thing. You are making the game together, it does not matter even the slightest tiniest bit whose fault it was. That's also why the trust part is absolutely critical.

Anyway, this all is not important because you already know how to make a good game and how to be a good game designer way better than we do so you don't need our advices.

glhf, you should read Code Complete by Steve McConnell. You should also brush up on a few concepts, notably the concept of a Wicked Problem. McConnell levels some criticism toward the top-down waterfall approach in his book, describing waterfall design as one of those Wicked Problems that can not be fully solved up front. I promise you, there has never, never, never, never, never, never, never, never, never, ever been a perfect up front design for anything non-trivial, since the human race began. Ever. No matter how good a designer is, the project will change. If you think otherwise, you are just fooling yourself.

Every single post you make only reinforces my knowledge that you have no idea about real world software development. None whatsoever. And yet you continue to prate and prattle like you have a single clue what you are talking about. You do not.

Engine decisions absolutely must inform game design decisions. Design must compromise around what is and is not possible given available engine tech and budget/time considerations. Design can say, "We need a fully featured, 100% scale simulation of the entire universe." That's pretty easy to say, design-wise. Engine-wise, it's not so easy, and if your answer is "The programmer could even chose to create a new engine if he thinks it's more efficient." then your project will fail.

If you try to build a game 100% up front, you will fail. If you try to build a game as a dictator would, telling the staff to make your vision come true with no consideration to their input, telling them that design is god and king, then you will fail. Failure is written all over every single one of your posts. Take that as a personal attack if you wish. People have been arguing and discussing with you, trying to help you, but you refuse to accept any criticism or any viewpoint that is counter to your own.

Now, prove us wrong. Go away for awhile and come back with a completed game. Give us an (honest) post-mortem. Give us evidence that what you say is the One True Way, and then maybe we'll start showing you a bit more respect. Until then, you are just a babbling poseur.

[quote name='glhf' timestamp='1334938346' post='4933269']
But lets pretend that you had a great GDD.
Then you run into problems coding the game.. but it's not the game designers fault.
It's the programmers fault.. And the game designer gets punished for it?
The programmer should have made a code design and chosen the correct engine that can create the GDD.

Yes, programmers are the main source of problems during the development of a game. Regardless of professionalism level. That's the way it is, that's how it always was and that's how it will always be. And the job of the designer is to fix it. Actually, any decent designer should take it into account when making GDD and provide some alternatives in case an unproved experimental technology will not work.

Also, passing "fault" around is a childish thing. You are making the game together, it does not matter even the slightest tiniest bit whose fault it was. That's also why the trust part is absolutely critical.

Anyway, this all is not important because you already know how to make a good game and how to be a good game designer way better than we do so you don't need our advices.
[/quote]

I'm not here for advice..

And I'm not passing blame around but if I drop a glass of coffee on the floor in the office... Should I yell for a game designer to run over here and clean it up?

You don't understand how important the game design is still.
It's something that should be changed as little as possible.. if anything at all.

If a programmer messes up he has to go back and fix what he messed up.
It's much much better instead of altering the games design.. It might be easier to change the game design.. but then you have destroyed the game you got the team together for in the first place. Now it's like you got a team without a game design, All you have now is a game designer without a game design... you want him to start creating a new game design on the fly while everyone is waiting on him. That doesn't sound like a good environment for creating a good game design... more like creating a stressed poorly detailed game design to fix a problem that the programmer caused. Now it's completely luck if the game becomes any good.

*Deleted. Sorry.*