KrilltheKill
|
|
« on: June 22, 2016, 07:38:57 AM » |
|
How and when do you start making your game's GDD? How do you organize it and why?
I'm not new to the concept but I still didn't come with many ideas on how to do it myself, I'd like to know how you do it and what's the reasoning behind it.
Also is there any golden rules or guideline that those starting to make their GDD should follow?
|
|
|
Logged
|
|
|
|
Polly
Level 6
|
|
« Reply #1 on: June 22, 2016, 07:54:31 AM » |
|
I'd like to know how you do it and what's the reasoning behind it. The reasoning behind it is so that everybody on your team has all the information they need to do their job / bring their A-game .. without having to consult the director / designer(s) all the time. If you're working alone or in a small team you probably don't need a ( extensive ) GDD.
|
|
|
Logged
|
|
|
|
KrilltheKill
|
|
« Reply #2 on: June 22, 2016, 08:15:13 AM » |
|
I'd like to know how you do it and what's the reasoning behind it. The reasoning behind it is so that everybody on your team has all the information they need to do their job / bring their A-game .. without having to consult the director / designer(s) all the time. If you're working alone or in a small team you probably don't need a ( extensive ) GDD. I meant the reasoning behind the organization decisions in the GDD itself, I'm very aware of what purpose it serves
|
|
|
Logged
|
|
|
|
KrilltheKill
|
|
« Reply #3 on: June 22, 2016, 08:24:18 AM » |
|
Gdd at the indie level is wasted time under the illusion of productivity
I still think it's good for those who are not so organized with their ideas, just so they have somewhere they can write them on in a somewhat more formulated fashion.
|
|
|
Logged
|
|
|
|
ProgramGamer
|
|
« Reply #4 on: June 22, 2016, 08:26:19 AM » |
|
just write down all your ideas on paper and stockpile them somewhere. Then, when you want to implement that idea, pull out the appropriate piece of paper. Not all pieces of paper are worth keeping, and in time you'll learn to know which papers to eventually discard.
|
|
|
Logged
|
|
|
|
Polly
Level 6
|
|
« Reply #5 on: June 22, 2016, 12:01:48 PM » |
|
I meant the reasoning behind the organization decisions in the GDD itself, I'm very aware of what purpose it serves Ah, in that case ( i'd ) organize it in a way so that it's easy for each discipline to find the information they need + Make things as visual as possible. For instance, here's a example of a flowchart describing "ranged melee" enemy behavior.
|
|
« Last Edit: June 23, 2016, 12:50:44 AM by Polly »
|
Logged
|
|
|
|
readyplaygames
|
|
« Reply #6 on: June 22, 2016, 12:17:23 PM » |
|
I have heard that using a wiki is actually a really great way to organize your GDD, especially with multiple people working on the project.
|
|
|
Logged
|
|
|
|
Wilson Saunders
|
|
« Reply #7 on: June 22, 2016, 01:44:22 PM » |
|
A GDD at the hobbyist level is a great way of preventing a game idea from keeping you up all night without actually having to implement everything. Writing down your ideas will prevent your brain from dredging the idea back from your subconscious every 15 minutes to remind you how awesome it is and how you should totally not forget it. Or is this just me?
|
|
|
Logged
|
|
|
|
voidSkipper
|
|
« Reply #8 on: June 22, 2016, 03:29:09 PM » |
|
A GDD at the hobbyist level is a great way of preventing a game idea from keeping you up all night without actually having to implement everything. Writing down your ideas will prevent your brain from dredging the idea back from your subconscious every 15 minutes to remind you how awesome it is and how you should totally not forget it. Or is this just me? For me it's more that it helps to clear up which ideas are only awesome because they're in my brain. Some things are not as great on paper as they were in your head.
|
|
|
Logged
|
|
|
|
halk3n
Level 1
|
|
« Reply #9 on: June 25, 2016, 07:21:29 AM » |
|
Gdd at the indie level is wasted time under the illusion of productivity
Bullshit. GDD's have a bad wrap because of how they're written from yore. An illustrator who has a mathematical mind and can clearly illustrate the design process with little words and mostly images is someone who can get anyone to implement anything into actual code.
|
|
|
Logged
|
|
|
|
Dylan Moon
|
|
« Reply #10 on: June 28, 2016, 12:30:40 AM » |
|
If your working solo - keeping tabs on ideas, tasks and so on in a notebook is always helpful - as previous posters mentioned; it keeps you focused and helps from needing to constantly remind yourself of a good idea until you implement it.
That said - if your working in a team - a GDD is helpful. Similar to iterative design - I would say you should build the GDD as you go - any ideas you have put them in a section as a Design Backlog, focus on nailing down things such as the player experience goals and other elements that you can agree on. I wouldn't say sit down for 5 hours and just create a fully fledged design document - because either you will have to deviate from it eventually or you may end up locking yourself from creating a much needed change. Just keep your GDD organic in it's content - but at the same time make sure you nail down on certain very important points depending on where you are with your game. For example, if your nearing the end of the game's development - don't suddenly change everything unless you think its necessary. On that note - if your just starting off the project, experiment and keep the GDD as organic as possible and build on it iteratively.
|
|
|
Logged
|
|
|
|
voidSkipper
|
|
« Reply #11 on: June 28, 2016, 03:39:48 AM » |
|
If your working solo - keeping tabs on ideas, tasks and so on in a notebook is always helpful - as previous posters mentioned; it keeps you focused and helps from needing to constantly remind yourself of a good idea until you implement it.
That said - if your working in a team - a GDD is helpful. Similar to iterative design - I would say you should build the GDD as you go - any ideas you have put them in a section as a Design Backlog, focus on nailing down things such as the player experience goals and other elements that you can agree on. I wouldn't say sit down for 5 hours and just create a fully fledged design document - because either you will have to deviate from it eventually or you may end up locking yourself from creating a much needed change. Just keep your GDD organic in it's content - but at the same time make sure you nail down on certain very important points depending on where you are with your game. For example, if your nearing the end of the game's development - don't suddenly change everything unless you think its necessary. On that note - if your just starting off the project, experiment and keep the GDD as organic as possible and build on it iteratively.
If you're anything like me, even just keeping a checklist of milestones and essentially gamifying your game development is a great motivator.
|
|
|
Logged
|
|
|
|
hmm
|
|
« Reply #12 on: June 28, 2016, 04:45:02 AM » |
|
My experience with GDDs: Team size = 20 Designers = 3 Purpose of GDDA starting point for further discussion with the rest of the team, and a great place to put down in writing the outcome of any quick design discussions. Also, a crucial point of reference for designers communicating with each other - its hard to just talk about design and all end up on the same page. How and when do you start making your game's GDD?Preproduction/prototyping phase. Getting ideas down on paper before any code or art is produced. Refined repeatedly as prototypes are built to test ideas out. How do you organize it and why?We used a lot of different Google Slides and Google Spreadsheets because the Google software allows for realtime collaboration, and makes it dead simple to share updates to a GDD with the rest of the team. Its done in real-time. We used Slides instead of Docs because the slide format forces you to keep it simple and to the point. The idea isn't to explain every detail exhaustively, but to give the team enough to understand the basic idea - they shouldn't be expected to make the game based on the GDD alone, there should be a lot of working directly with designers to flesh out the idea (in my opinion). For organisation, we kept every subsystem in a separate GDD. Made it easier for programmers to navigate. Subsystems included, for example, the overall UI flow and game structure, the Reward Systems, Each level had its own GDD, and our Adaptive Difficulty System had one too. Other thoughts on GDDsI think GDDs tend to get a bad rap because of the dreaded Design Bibles of old - monolithic stacks of paper that contain every last detail of the game as envisioned by some designer, that quickly becomes outdated as the team faces the realities of production. These days, its much much easier to keep a 'living' document that a designer keeps up to date. That way, the GDD remains a relevant source of information, even if its just there to keep track of all the hundreds of little design decisions that are made throughout the course of development. Daniel Cook, of Spry Fox, has put forth the idea of using Design Logs for this very purpose.
|
|
|
Logged
|
|
|
|
Dylan Moon
|
|
« Reply #13 on: June 28, 2016, 10:27:22 AM » |
|
If you're anything like me, even just keeping a checklist of milestones and essentially gamifying your game development is a great motivator.
Definitely - a checklist of milestones is highly motivating, especially as you see items being ticked off and you look back to see how far you've progressed!
|
|
|
Logged
|
|
|
|
halk3n
Level 1
|
|
« Reply #14 on: June 28, 2016, 11:38:02 PM » |
|
Also, a crucial point of reference for designers communicating with each other - its hard to just talk about design and all end up on the same page. Yea, this is why using mostly imagery for design is crucial; an image speaks a thousand words.
|
|
|
Logged
|
|
|
|
DifferentName
|
|
« Reply #15 on: June 29, 2016, 10:53:22 AM » |
|
My game has several systems that need to fit together, and the ideas for them were scattered around through multiple notebooks. I just made a GDD to keep my ideas more organized, and to make sure each of the systems fit together around a core idea. With a better idea of how all the systems will interact, I hope this will help me code more effectively and efficiently. If I need to change an idea later, I think it will be easier to make sure the change fits well with the rest of the design when I have it all organized in one place.
|
|
|
Logged
|
|
|
|
KrilltheKill
|
|
« Reply #16 on: June 29, 2016, 06:10:06 PM » |
|
Say if I had a small team with me, would a GDD be a good idea?
|
|
|
Logged
|
|
|
|
{VeTeR}
|
|
« Reply #17 on: July 01, 2016, 06:10:14 AM » |
|
For The Crypt we have team of 3 and we have GDD. Not because we don't talk to each other about the game and ideas but it keeps your design in place, and what is most important GDD is a consequence that you need to keep while making a game. If you won't use this rules your final game can be blurry because you will miss your basic idea for it. GDD also helps to point the vision of the game and answer some questions you won't answer. I wrote an article about GDD here: http://thealchemyofgameplay.tk/2014/03/23/the-recipe-aka-game-design-doc-gdd/
|
|
|
Logged
|
|
|
|
halk3n
Level 1
|
|
« Reply #18 on: July 01, 2016, 07:27:18 AM » |
|
^Holy shit dude. You (and your site) are one of my inspirations to become more of an "analogue" game designer. Thanks for all the effort you've done to breathe life into the GDD approach.
I'd never thought you'd be a member here, but hey, why not and AWESOME!
|
|
|
Logged
|
|
|
|
{VeTeR}
|
|
« Reply #19 on: July 02, 2016, 08:28:14 AM » |
|
^Holy shit dude. You (and your site) are one of my inspirations to become more of an "analogue" game designer. Thanks for all the effort you've done to breathe life into the GDD approach.
I'd never thought you'd be a member here, but hey, why not and AWESOME!
Thank you! It means a lot!
|
|
|
Logged
|
|
|
|
|