Jump to content
  • Advertisement
Sign in to follow this  
Jouke1988

When to greenlight a GDD

This topic is 1587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi!

 

As a game designer, next to being a beginner programmer and a experienced artist. I wondered how other designers feel about there concepts, when do you re-evaluate your design document and deem it to be to complicated.

 

Please share your thoughts, I'd think its quite an interesting topic.

Share this post


Link to post
Share on other sites
Advertisement

A GDD isn't always the best course of action altogether. As Acharis pointed out, prototyping is better.

 

In a AAA, one needs to have a bunch of info before architecture of the work can begin, but even they start with prototyping. 

For anything lesser than a AAA, I would recommend writing the shortest possible GDD and discuss with the team about end cases.

Based on their questions, detail the end cases in the GDD so that it is a bit more exhaustive and reflects the agreed upon behavior.

 

So, in essence, a GDD is too complicated when it contains more info than it needs, and it is not complicated enough when it does not contain agreed upon behaviors.

It is normal for a GDD to be a living document as end cases are being determined along the way, and trying to predict everything at concept stage would be a gross misunderstanding of the software development process. As a game designer, it is not your job to try to guess what limitations/issues will arise and how to handle them. You are a owner of the vision and common goal, and must be willing to adjust as needed to remain true to that.

Share this post


Link to post
Share on other sites

when do you re-evaluate your design document and deem it to be [too] complicated.


The subject line of your post was "When to greenlight a GDD," which didn't make sense to me. Curiosity as to what the subject line meant is what prompted me to open the thread. The reason the subject line didn't make sense to me is that greenlighting a project is not something a designer does himself. Now that I've read your real question (quoted above), I understand what you're asking. There are three questions: when is a design ready, when to re-evaluate it, and when are its flaws recognized.

The way you used it in your subject line, "greenlighting" seems to be the decision that work can begin on the game. That is a judgment call, and there is no clear "when." I suppose one can deem a GDD ready when the key gameplay is determined, so one can build a demo.

Re-evaluation is something that should happen multiple times. If using Scrum, it should happen after every sprint. It should also happen once a playable demo is built.

Lastly, the realization that it's "too complicated" usually comes after working on building the game for a while and the process is bogging down.

Share this post


Link to post
Share on other sites

I generally don't work with a game design document fully, but write a little and keep the rest in my head. Assuming this counts...

 

I deemed my game too complicated when I realized I didn't have the money and manpower to do it in a good way.

 

Also, as an afterthought, in the future I might just post my GDD here and ask people what they think. The information you get can outweighs the risk of people stealing your idea, as oftentimes the ideas aren't worth much anyway.

Edited by Shane C

Share this post


Link to post
Share on other sites

I recommend not writing GDDs and just prototyping core gameplay loops with squares/circles/etc. There was a great video on the making of Journey, and it showed all the prototypes they created before it evolved into the game everyone loves

Share this post


Link to post
Share on other sites

 

when do you re-evaluate your design document and deem it to be [too] complicated.


The subject line of your post was "When to greenlight a GDD," which didn't make sense to me. Curiosity as to what the subject line meant is what prompted me to open the thread. The reason the subject line didn't make sense to me is that greenlighting a project is not something a designer does himself. Now that I've read your real question (quoted above), I understand what you're asking. There are three questions: when is a design ready, when to re-evaluate it, and when are its flaws recognized.

The way you used it in your subject line, "greenlighting" seems to be the decision that work can begin on the game. That is a judgment call, and there is no clear "when." I suppose one can deem a GDD ready when the key gameplay is determined, so one can build a demo.

Re-evaluation is something that should happen multiple times. If using Scrum, it should happen after every sprint. It should also happen once a playable demo is built.

Lastly, the realization that it's "too complicated" usually comes after working on building the game for a while and the process is bogging down.

 

Ah, i see what you mean. I think the simpler explanation would be, at which stage of the 'prototype' could you be turned down by your vision. Since your vision is an abstract idea of a technical formulation i presume.

 

However, in certain post-mortems you can read the developers stating something along the lines 'i never imagined it work out like this'. Which is quite an interesting statement for the holder of the vision. So where do you draw the line?

Edited by Jouke1988

Share this post


Link to post
Share on other sites

Ah, i see what you mean. I think the simpler explanation would be, at which stage of the 'prototype' could you be turned down by your vision. Since your vision is an abstract idea of a technical formulation i presume.
However, in certain post-mortems you can read the developers stating something along the lines 'i never imagined it work out like this'. Which is quite an interesting statement for the holder of the vision. So where do you draw the line?


There is no magic answer to that extremely subjective question. The team has to figure this out for themselves (multiple heads are better than one).

Share this post


Link to post
Share on other sites

 

Ah, i see what you mean. I think the simpler explanation would be, at which stage of the 'prototype' could you be turned down by your vision. Since your vision is an abstract idea of a technical formulation i presume.
However, in certain post-mortems you can read the developers stating something along the lines 'i never imagined it work out like this'. Which is quite an interesting statement for the holder of the vision. So where do you draw the line?


There is no magic answer to that extremely subjective question. The team has to figure this out for themselves (multiple heads are better than one).

 

Yes, i do understand getting to such an extend would make it seemingly subjective. However, its quite unsatisfactory to merely deem such actions a trial&error method. One look at the Apple or Android store and you can clearly see the lack of vision in my opinion. To much replicas and to little invention. But i guess in the end, those who re-invent will get payed off. Having a solid design standard is perhaps to idealistic?

Share this post


Link to post
Share on other sites


Yes, i do understand getting to such an extend would make it seemingly subjective. However, its quite unsatisfactory to merely deem such actions a trial&error method. One look at the Apple or Android store and you can clearly see the lack of vision in my opinion. To much replicas and to little invention. But i guess in the end, those who re-invent will get payed off. Having a solid design standard is perhaps to idealistic?
I think it becomes more clear when you lay down some goals/rules.

 

The rules of a healthy development:

1) It's all about making a game and releasing it. Everything not leading to this result is an excessive fluff and can (and should) be cut down. All methodologies, theories, ideals, documents, techniques are to be judged against this premise.

2) A game needs to be fun to play and/or bring money to the developer (it can be argued which is more important, also just one of these condition being met is sometimes perfectly sufficient - but not meeting at least one of these means a failure of the development process).

3) There are no exceptions to the two rules above :)

 

 

So, to answer some of your questions:

 

"its quite unsatisfactory to merely deem such actions a trial&error method" - does trial & error allow you to finish a fun & playable game? If the answer is yes, it's perfectly satisfactory.

 

"Having a solid design standard is perhaps to idealistic" - does solid design allow you to finish a fun & playable game or is it just some artificial ideal you imposed on yourself? If it's an ideal discard it. If it's a tool to meet your goal follow it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!