Discussion Organising Your Project

[Marin]

It's just turned Sunday for me, which I plan on being the standard Weekly Discussion day from now on.

I skipped last week due to jam stuff and generally being super busy.

Without further delay, I've got some more interesting topics.

• Do you have a Game Design Document for your project?
• Should projects have a GDD? Why or why not?
• What should be included in a GDD?
• How is your GDD set up, if you have one?
• How extensive is your GDD? Do you plan out every single event, or kind of freeball it from a certain degree?

 

[MegaMew47]

Well first post so let's go!

- Do you have a Game Design Document for your project?
I do.

- Should projects have a GDD? Why or why not?
For a long period of time, mostly while I was solo deving, I honestly didn't. I would have various papers and documents with ideas written down; things I wanted to accomplish, areas I wanted to include. But it wasn't this super fancy paper that was shared to the world. I would say that not having one is fine, as long as you are by yourself. Working with a team, and not having one, however, can make you see, unorganized, not giving a good look to other members. And it just makes it harder on them.

- What should be included in a GDD?
Well, I would say pretty much the basics; some of your characters, including attributes and looks, as well as personality and backstory. Write down events you'd like to have, areas, most likely in order. Possibly your custom dex, if you have one, sidequest ideas. Essentially make it your diary to your game.

- How is your GDD set up, if you have one?
First I have a To-Do list. This is pretty self-explanatory. Second I have a section of my characters, in order of appearance. I briefly describe them, including anything I believe to be necessary. Next up I have a brief synopsis of my main, overarching plot. Secondly I describe plot in between gyms. Separating them, almost like chapters, I write down what I want to happen. I'll explain more about this in the final question, since it fits better there.

- How extensive is your GDD? Do you plan out every single event, or kind of freeball it from a certain degree?
I write down a brief summary of what happens in each gym. The main gist of what happens, such as raid this enemy base, go through this forest, meet this person. I don't think it's good to plan out every single event. Things are most likely to change in the time you actually get around to developing that part. Give yourself more freedom in the future and not to confine yourself to having to make a specific event, or writing a line of dialogue exactly the way you wrote it a while back. You may get a new idea, but can't implement it, because of how extensive your plot is.

Typically as I get to an area, about to start an event, is when I'll look closer. I know what's going to happen, now I just have to get there. And I have the creative room to do so.

thank u for coming to my ted talk

 

[Radical Raptr]

Personally, game development is very difficult, it is easy to get lost or confused with what is going on.

A design doc forces you to put your thoughts down to paper(or text) in a real way rather than just ideas floating around.
Having an outline, imo, is essential to continuing and finishing a game because it keeps you on track and helps you realize what exactly is left to be done vs what is finished.

 

[Maruno]

Essentials isn't a game. Technically it's a project, and technically it needs to be coherent, but it doesn't have a plot or anything. The only things to plan out are individual features and modifications.

To that end, I have at least six "To Do" Word files, plus one with outlines of the major projects that can/will be done in the future (e.g. rewrite map rendering, switch to some better form of Ruby/RGSS, put Essentials onto GitLab). I also have a bunch of txt files with bits of code in that may or may not ever be used. There are folders for resources and backups and concept art and my attempt at a TCG mod and a copy of all wiki pages, and several spreadsheets containing copies of items.txt and moves.txt, and meme pictures, and a file called "LOOK AT ME" which I haven't looked at in over six years.

A design document is definitely not just one document. Okay, some of my files and folders wouldn't count as content that would go into a design document (they're just work), but quite a few would. And it's fine to keep them in multiple files. You can organise them better like that.

 

[TechSkylander1518]

• Do you have a Game Design Document for your project?

• Should projects have a GDD? Why or why not?

Oh God yes. Do people not always do a doc? How do you survive like that????

• How is your GDD set up, if you have one?

For a short game, I always start the doc with the initial brainstorming/premise. I think it's always helpful to have that somewhere you can see it, to put you in the mood you had when you got into the idea in the first place.

From there, I make a few sections for specific elements- plot, characters, code, graphics, music- in no particular order. I also make a section for credits, so I can keep that updated when I find a new resource to use.


I kind of think in wiki formatting for my full-scale project, so I've actually got multiple game docs in one folder. (It helps me keep things sorted that way, too) That one goes like this:
Abilities- A document listing new abilities in alphabetical order, their intended purpose, what kinds of Pokemon get it (is it signature, mega, etc), and the code for them. I also have a section in here listing different functions an ability can have, to get some inspiration.
Characters- A document listing characters split up into sections based on their role; rival, antagonist, etc. Each character has their character concept, sprites, Pokemon team, and code for their trainer class, if applicable. (Note- I put the sprites there just to keep track of who has a sprite and who doesn't, but you definitely should not use the sprites from your doc, I'm almost positive the quality will get screwed up)
Credits- Just so I don't lose them in any other doc.
Items- Like abilities, it lists new items, intended purpose, and their code. (Both for items.txt and if any item has a new effect) I do try to sort these a bit more, though, putting them in sections like Key Items, Mega Stones, etc)
Locations- I do name, name origin if I want to remember it, what other locations it connects to, what the player does here, the concept of the town, an idea of the map, and the theme.
Moves- Just like abilities. Define names, purpose, etc.
PokeDex- Is actually its own subfolder, with a doc for each Pokemon line. I pretty much write it like a Bulbapedia article, except I start at the top with the concept and some visual inspiration. I also start writing the PBS code at the bottom of the page, so I can readily update any changes.
Plot- A plot outline. I write dialogue if I think of it, but I mostly focus on getting the whole idea out.
TMs- Just what it seems like, start planning your TM order and moves. I also put the PBS code here when I think of a TM a Pokemon should learn.
And finally, a Various Code doc to hold any code that doesn't easily fit into the others.


Obviously that's a lot of work, and most games won't need this at all, but I think if you're doing a full-scale, new Fakemon kind of game, this would definitely be really useful.

• What should be included in a GDD?

I would say 1000% you should at least be keeping your credits there and any new code you wrote, because it would really suck to misplace either of them.

• How extensive is your GDD? Do you plan out every single event, or kind of freeball it from a certain degree?

Okay so obviously the fact that I have like ten docs for my planning shows that I am extremely extensive with it lol. But in with dialogue, I kind of do plan out every event! For flavor text and minor trainers, I just figure that out as I go, but for major story dialogue, I do go ahead and write it out. It can be a little annoying with some characters (' ... and " might all get formatted weird, so make sure you run a quick find and replace so you don't get those squares in your text), but you also have that spelling/grammar check right there, which I think is a better positive. Plus, having to click "Show text" or "edit" every time you write a new line interrupts the flow of things IMO- I prefer to just do that when I'm actually doing the coding part.

 

[VanillaSunshine]

Oh, this is a good topic! I feel like this is an underappreciated aspect of game dev!

I've been fussing with Pokémon Fan Games for about 3 years now (wow!) but I've only recently made proper progress on a project. I think a big defining factor behind that is the fact that I didn't have a "Game Design Document" for my first two projects, instead only relying on a vague idea of what I wanted. (The bigger defining factors are things like my health and the scope of my projects being too large.)

Before I actually started on my current project, the first thing I did was create a GDD to collect my ideas. It went through a bit of a revamp after I properly settled on the core idea I wanted, but for the most part it's just been my dumping ground for notes...

I have one big one that has so far has been organized into chunks such as:

• Characters, where I list the core NPCs and their role in the story.
• Gameplay elements, such as side-quests, how I want to handle HM/gyms, core flow for dungeons, and various little ideas I've pulled from friends and other projects I've played.
• Planning trackers, where I organize my thoughts for non-gameplay things. For example, I have all of my towns & routes laid out, including the meaning behind their names, and I also have a list for when I was brainstorming names for the region itself.
• Miscellaneous, where I just drop little ideas like "put a Box Dev somewhere!" and "make a decoration for this thing!"

And I really wish I did this for my original projects! They might've actually gone somewhere if I had, or at least I would have realized how unreasonable they were a little sooner. Better late than never, I suppose!

I also have a Changelog, where I keep track of my development by date. I'm extremely forgetful, and I already mark all of my script changes with a game-specific comment so I can find them with a search, but having every change and its date in one place has been wonders. Debugging is a breeze when I can open the TXT file and see that the only thing I did the previous day was edit a specific PBS file, so the error that keeps pointing me to a script isn't a fault in the script, but a fault in the PBS file. (I also like the Changelog because it helps me track how long I've been working on this project, and helps me notice when I ignored the project for a few days.)

Less importantly, I have a TXT copy of my Regional Pokédex, leftover from when I was planning it, but it's always good to keep around so I don't have to go fussing with opening my project just to see all the Pokémon in my region.
I also have my Credits TXT file, which is exactly what it sounds like. I think it's quite well organized and cutely decorated, which I'm proud of!

When I reach a bit further into development, I suspect I'll want to create a new file dedicated to the story elements, so those points aren't getting mixed in with the more technical points like gameplay loops and such.

I don't know what I was doing before I kept track of all this type of stuff! It really turned game dev into something fun and focused, as opposed to tentative and confused. As a writer, I have a bit of experience planning out stories and their beats and features, and I don't know why I didn't translate that into game dev until this current project. I don't think I could get anything done without some semblance of GDDs, and I can't imagine how devs could work if they don't make at least one!

 

[Foxowl]

I do think coming up with details/ideas on the fly is nice but planning is super super important! Having one document is okay but honestly I prefer having multiple in a folder, makes it much more organized for me. Now I haven’t made any full scale/large games, but for my jams:
Hunt for the Yeti had two documents, a main planning one for areas and progression as well as my credits.
A Slice of Life had a big credits document I constantly added to and it made it very easy to copy/paste at the end of the project. I also made a planning document similar to what I had with HFTY but this time I decided to do it on paper by hand (idk why, I like taking notes). I find that after a while I don’t really add to my documents other than the credits, they’re really just for getting my ideas and general plans down initially. I’ve tried writing out my dialogue and scenes in documents before but I find it tedious to copy/paste that every time and I prefer writing as I go.
If I made a larger game I would almost certainly have documents for plans, characters, a to-do list, and most importantly credits.
In addition, I think documents are incredibly important for collaboration because while you can talk in a discord server or in DMs it’s going to be so much easier and more organized if it’s written out in its own place.

 

[Evan]

Ah yes, I love using google docs for design documentation. I generally keep folders with several documents in it, to keep track of things but to also feel a freedom to just write things down and keep them in a folder.

THEFT on the MAGNET TRAIN EXPRESS only had one google doc for just about everything, and I kept track of progress in the credits.txt file while working, actually. It was hectic, but the scope was small enough that it didn't hinder any progress.

SEA and SKY has a WILDLY LARGE design documentation apparatus, which is in a google drive folder, as I mentioned. The crowning achievement of that folder is the "Final Planning Doc" which is a google spreadsheet and contains pretty much everything worked on--whether it's tiles, Pokémon stats, Pokémon movesets, egg moves, egg groups, rival teams, gym leader teams, trainer types, region population (Pokémon & people), new moves, new abilities, keeping track of new mechanics, UI, our list of items--we have like 25 tabs in it, and it's the master doc. Any time anything gets changed, it gets changed in-game AND in the spreadsheet.

I have a separate document that writes out the story in detail, along with comments the whole time for folks who read it to see more on, or to participate in discussion of something i'm unsure about. And I also have one where I script out larger events. These are less set-in-stone, as they generally change a bit while eventing them in.

 

[Ekat]

Do you have a Game Design Document for your project?

My planning process has really varied from project-to-project. I've done solo, small team (just Michael and I), and large team. Whether I work alone or with Michael, my GDD is very bare bones. Meanwhile, the largest dev team I worked with, Pokémon Umbra, was elaborate with the organization.

My preferred way of organizing my games is best described as o̰̺͈͠r̵͙̳̭̻͓̥g̩͓̥̹̪͟a̞̙͕͡ǹ̜i̟͈̘͙͖̜̭͢z͉̺̳ę̳̘̘d͖͍̟͚͉ ͓̯̞͘ͅch̸a̘̪̙o̺͓̝͓͎̻̭s̘̖͕.

How is your GDD set up, if you have one? How extensive is your GDD? Do you plan out every single event, or kind of freeball it from a certain degree?

I'll use Apathy as my example. It's a short project, and my documentation for it is still easily retrievable. That, and Ashen Frost is a monster of a project now. I don't think I'd be able to even cover the tip of the iceberg if I used that as my example.

Spoiler: This is long so it's going in a spoiler

I have two kinds of notes/documentation. Permanent and temporary. Apathy only had two pages of permanent notes. This first one covered the technicalities of the game, especially the aesthetics. The other side is an indecipherable mess of my plans for gameplay and mechanics, so I decided to show this page.

Spoiler: Picture and transcript of my notes

[Top Left Corner]

Meowth, clefairy, sandyghast fam, sedra fam, wingull fam, skrelp fam, deoxys, snorlax, empoleon, torterra, tentacruel fam, corsola fam, luvdisc, finneon

These are the Pokémon overworlds I planned to include in the game. Out of the list, only four actually made it in. My selection seriously changed up.

[Top Center]

Undella Town (Winter)
Can You Feel the Sunshine (Instrumental)
Wave BGS
Summers
Perry's Dream (Super Pr. P)
Wavy Beach 1
Welcome to Ladida Plains
Radio Static
Work it out (instrumental)
Deoxys' theme
Slimy Spring Galaxy

These were music tracks I felt would be fitting. Unlike the Pokémon overworlds, all but Deoxys' theme made it in. One of my personal pet peeves with fangames is when people use the default midi tracks. Adding music... isn't that hard. (Thinking of good songs can be, though.)

[Top Right]

-Space Tileset (Or Panorama)
-Indoor tileset
-Outdoor tileset

One of my goals going into Apathy was to make an appealing resource pack. These were the three tilesets I originally planned on making. As the game expanded, though, I wound up making seven.

[Center Right]

-Indoor battle
-Outdoor battlex3 (day, eve, night)
-1 MC
-Protag (NPC)
-1 rival
-2 unique women
-2 unique men
-1 girl
-1 boy
-1 tuberf
-1tuberm
-oldf
-oldm
-grunt f
-grunt m
-teacher
-mayor
17 x 2 = 32

This was a list of the planned battlebacks and overworld sprites I needed for the game. Nothing too notable here, but all integral to Apathy's visuals.

[Bottom Center to Bottom Right]

-Zero weather
-Overworld shadows
-Terrain sounds
-Window names
-Custom locations windows
-Exp all
-Reflection on/officially
-No heal w/partner
-reborn animations
data, graphics, sfx
-gif titlescreen

-load screen bgm
-reborn battlers
-gen 7 data/pbs (castaway)/graphics-pkmn overworld sprites

-get rid of random cry
-custom text colours
-maybe summary screen EV/IVs

This list was the remainder of utilities I wanted to include in the game. There were some plug-n-place scripts, and some quality of life additions. I'm very picky about this kind of stuff.

My permanent notes are just that, permanent. They're the broad outlines and long term goals I set for the game. My permanent notes are basically my fallback, the references I refer to as I worked. But, in this case, I also jotted down some of the specifics if they came to mind. The limited timeframe encouraged me to do that.

My temporary notes are the specifics. Typically, they're linear goals. Make X tileset, map Y, do the battle UI, etc. Usually, I throw together a list of quick tasks into Notepad++. I keep the file open, and delete each task from the list once it's done. Then, I write out a new list of tasks to complete. After creating a solid foundation for the game (UI, tilesets, etc) comes mapping. Then comes eventing. During eventing comes more mapping, tilesets, overworlds, etc. I try to be flexible, because many of my ideas come as I work, and I try to do a lot of refining.

Overall, I find myself best suited to flexibility. While I do make plans, the degree to which I'll wind up following them varies. In the case of something like Apathy, where I was on a hard deadline, I needed to be ruthless. I had to know right from the start what I needed, when I needed it by, and when to cut the bloat. If this meant changing my plans in the middle of what I was doing, then so be it.

Spoiler: Finished product versions of the map sketches

What should be included in a GDD?
1. Credits
2. Every other random dev thought that comes to mind
3. Page margins filled with hyper-specific ideas

Should projects have a GDD? Why or why not?
The chaotic part of me wants to say no, and encourage devs to go with the flow. (Assuming that style works best for them.) Again, I prefer flexibility. But, too much of that is going to leave you directionless. Much like deadlines, I believe that a solid plan is the first step to completing your project. Even if that plan is just, "Learn how to use Pokémon Essentials and RGP Maker XP."

Documentation comes with a number of benefits:
1. You can more easily recognize your limits as a dev. (Time, coding/eventing/composing skills, etc.)
2. You can edit your ideas, and more easily ask for feedback. (Assuming your plans aren't written in gibberish like mine.)
3. You can recognize how much progress you've made, or what areas you need to focus on.
4. It can help you overcome creative blocks. (When I come to a creative block, my first response is to go back to my notes. I revise everything, even the stuff I've discarded. It definitely helps.)

Outlines are absolutely valuable grounding tool. I'm just an agent of chaos.

 

[Atomic Reactor]

• Do you have a Game Design Document for your project?

I do not keep any sort of written documentation on my projects, I just kinda keep it in my head I guess. The closest thing to design documents I have are a bunch of different image files of tiles and sprites that I work on. Usually a new biome will warrant a new set of tiles to work with, thus a new image file, so I keep them separated like that. Otherwise I have compilations saved like character sprites and overworlds. But yeah, all the story and stuff just stays in my head till I make it. I do have a checklist on my phones of random things I don't want to forget to do, and I keep a ReadMe updated with credits and stuff so I guess that kind of counts.

• Should projects have a GDD? Why or why not?

Yeah probably, if you're doing a big project, it would be better to have documentation than to not. Obviously everyone's documentation is gonna look different though. Whatever works for the individual is fine, there are no strict rules on process of development, only advice.

• How extensive is your GDD? Do you plan out every single event, or kind of free-ball it from a certain degree?

My process is :
1] Drafting, sketching, general brainstorming. With my current project it started to just culminate in my head until I was able to visualize a realistic path forward. I have a general idea of how/where the story and events will go, but fine details and lore get developed as I map out the world itself.

2] Mapping. I go on week long bursts of mapping and tiling. In the brainstorming phase, I come up with the world map, which helps immensely for my organization, because the world map works as a skeletal outline of what the world will look like. I will start the next area with a biome/mood/ design in mind, but start with a very crude map, especially if I don't have all the tiles I need. As I continue mapping, I polish and refine areas little by little, making tiles or adjustments as I see fit until the map is both functional and aesthetically pleasing to me.

3] Once all the mapping is done, I kind of jump around to different things. Fakemon, animations, UI, QoL updates and stuff. NPCs are for the most part made up on the fly, unless it's a significant event like a gym leader or important story event. For longer dialogue cut scenes, I'll write it all out on a separate word document just so I can efficiently proof read and junk, then I copy/paste it over and delete the word doc.

4] Though I am testing everything as I map/event it, the final part of the process is to play through the entire thing, probably more than once. Take notes of all the things that need fixing or adjusting, make sure it flows well and has enough variety, basically just making sure I like everything about it. Then I'll let friends play it so I can get final feedback before letting everyone else play it! Through out the entire process though, I'm always making tweaks and minor adjustments to different areas, a lot of stuff people would probably never notice.

That's kinda all I got to say. It seems like a lot of other users DO have development documentation, which makes sense, and I admire, but being I do not really document anything, I thought I'd throw a post out there to somewhat contrast the others. Kudos to all of you who have documentation, and even more important, organized documentation!

A lot of you detailed your rationale on how you organize your different documents, so my question is for @Maruno, since his work is building an engine vs building a game. You said that you have about 6 different "to do" documents, I was just curious what's your rationale for separating them? If it's not too spoilery for v18 or anything, can you elaborate on your 6 to do lists? Or give an example?

 

[ranko]

This is the first time I ever had a document for my project and interestingly enough, this is also the first project I ever finished. Usually, I only plan out the script intro and a handful of character quotes.

So yes, I think a GDD for planning is pretty invaluable to me, but I don't rely on it extensively as much as I use it to keep track of the vital details and roadmap a bit. A lot of details are made up on the fly from a solid concept written down on the document. It's almost sort of like, playing DnD with myself in my head. One thing in the GDD is basically the minimum amount of things I must have to consider it a complete game, and subtract from there if needed (but I take care to at least start on every single one). Things like Checkpoints, maps, number of items in a feature, etc. I originally had 10 maps per area in this jam, but cut it down to 5. I originally had 5 Puzzle Houses, but cut it down to 4. I originally had 4 Zones to explore, but I cut it down to 3. By putting the broken pieces together something was still able to happen!

Shouuuuld people have one? It depends on what your brain can handle I guess. I definitely have some disorders in the attention area and I need something kicking my ass to get me to work constantly to get things done, and a document helps me remember that. A lot of people are really good at keeping things in their head and coming up with things on the fly!

In addition to a 2 page document, I actually keep a second document for quotes/characters. I have a big butts text document full of quotes I find on the internet and try to find a way to define characters in quotes. It also has a few misc likes and dislikes and I just sort of formulate something from there.

In terms of planning and throwing stuff into the game itself, I absolutely feel the need to map out the first few events in the game, down to every move route and word of dialogue, and then add/subtract accordingly. I come up with a script, and convert it into eventing, and just keep it there as a rough draft (i learned its better not to go for perfection and rather come up with something shitty and cut out the fat later). I do the same with actual features in the game, but those things come along as they see fit. If I've DnD'd my way to a point where a feature would be weird to shoehorn in, it pretty much dies (the Journal feature died in this recent jam, but I basically gave a nod to it by mentioning the MC forget their pen.)

basically i make something shitty and bloated and cut out the fat

 

[Aki]

Oh I love game design docs; reading or making! I have a lot of design docs for games that aren't being made...I find that when I have an idea stuck in my head it helps to write it down and try to plan out how it could be made into a full game, then I can finally get it off my mind, phew!

Most GDDs I write start off as a stream of consciousness just broken up with bullet points, so it's pretty messy. But I like going back over them later anyway, there's been quite a few times where I read back and found I'd already planned around a problem, or designed the game way further than I remembered. It also helps answer questions about, "Why did I design it like that?" There's usually a reason.
When I'm actually devving I make it up as I go, so the rough GDDs will get into some of the unique mechanics or overall design of the game, but there's not really anything about specific characters or locations.

Spoiler: big images

Design docs for two different games here; both pretty rough because I haven't made enough actual development progress to go back over them and make a clean draft.

Without notes like this I'd probably put the worldbuilding details in the game and then not know which parts I made up.

Since it's typically just me reading the documents I don't stress about how disorganized they are, but after a playable release I go back and clean them up! A postmortem draft helps me reflect, and when a game's gotten big enough to release I wanna be able to keep track of the mess I've unleashed...So the GDDs start looking a lot cleaner! At this point my goal for the GDD is to document anything that a normal game might have in a wiki, so tons of character details and any references or secrets that are included the game, but that maybe aren't spelled out directly in the game's files. So stuff like any Pokemon details, the changelog, or game credits? Not in my GDD, they're documented clearly in the game's files already. In my GDD I want to write about the character relationships or motivations, and important details that could create plot holes later if I forgot about them.

Spoiler: more big images

Are there actual game spoilers in this, I tried to not include stuff but IDK

One thing I never organize though is my scraps folder for any game...Like AR said, I keep a folder of WIPs and references, notes and everything else. Scraps are important to be because uh, otherwise I'd dump everything on my Desktop and it can't even handle one project's worth of files. Where a GDD is something that I'd share with any teammember who needed to see it, the rest of the scraps are a mess just for me to work with.

Spoiler: yes they're big again

If that Macargo looks cool it's because I didn't make it, it's from a public resource.

 

[Rashi]

• Do you have a Game Design Document for your project?

Of course! Why not? I'm really serious at it. I even write a journal lol.

• Should projects have a GDD? Why or why not?

If it's fan game, I think depends on developers because it's a hobby and they have their own choice. And some people doesn't have good skill on writing so they may not like doing it. But personally I love it! It's fun and also makes the development more easier.

• What should be included in a GDD?

Well, it's depends too on whether the project is small or big. For a small game, I mostly focus on events and small ideas. Few notes including gameplays ideas, events, hidden items and characters. When it comes to big games, I think it should be focused on... almost everything lol but I will mention important ones - Story, main events, characters personality, PokeDex,, place information, forms or fakemons ideas and forms.

• How is your GDD set up, if you have one?

My way of creating documents is really weird. First I would create a folder named on my game. Then I have multiple folders in it for different sections like graphics, scripts, etc and including one folder of main project with Pokemon Essentials. And a section for notes which I mostly focus on. I would have multiple note files in it including story, pokedex, moves, maps, fakemon/forms ideas etc.

• How extensive is your GDD? Do you plan out every single event, or kind of freeball it from a certain degree?

I don't spend too much time on it.. Only few big things I like to type names of every towns, city or village based on the place. Also, few notes on rivals encounters and villain moments. Not really everything.

 

[Marin]

With the various projects I've taken on in the past, I've always intended to document everything well and to start by breaking the idea that's formed in my head apart into smaller bits and pieces, and start writing them down in a document. That works well for about the first, well, 2 days, and then I'll forget about it.

The great part about having a GDD is that if your team changes, new contributors will be able to look through the concept of the entire game, see what's planned and worked on and done, generally get a feel for the game, and decide if it's good or not. It's also what will or will not spark motivation and dedication in that contributor for your project, because they'll know the ins and outs of your project.

As a relevant example, I do not have any type of document for my MK Project, and as such, I'm unable to provide a good overview of what the project is about. Maruno and Aaron, the two other major supporters of the project who commonly provide feedback, voice their opinions and make suggestions know the project through and through, and exactly what's best for the project, despite me not having a document. That's because they've been around since just about the start of the project, and it's great. But their role could never be easily replaced because of all the knowledge they have that is inaccessible (i.e. in the past, though still available through Discord by scrolling up). A GDD would completely solve that issue, which makes it a great tool if your team is expected to change over time.

Furthermore, GDDs also just provide you with a way to organise your thoughts and reflect on them like Aki said, whether that's before, during or after development. You can be as detailed as you want, and break your idea down into pieces as small as you want: I've seen people write down entire events and dialogues in their documents, but also ones with just a story description.

For the one project I've released (together with Maruno), Pokémon Mobius, we did create a pretty thorough GDD that went over the entire story, included and put thought into all backstory (i.e. how the game would have progressed up until the point where it starts, as you pick up the game at the third gym and play between gym 3 and 4), different scenarios and the major plot points, and listed all things that would need changing to suit our aesthetic and new features.
In this document, we also proposed game and region names, kept an exhaustive to-do list (which we recreated and assigned to me, Maruno, or "Don't bother, not enough time" in the last few days) and essentially crafted the concept of the region through reactions and comments inside the document itself (as well as on Discord, obviously). We also had a separate document that was dedicated to our very own Pokédex, all items available and all items and Pokémon the player'd start with.

All in all, I'd highly recommend a GDD, regardless of how big your game or team is. Being able to look back and get a clear overview of what your project is about at a glance is worth more than a thousand images - whether for yourself in two years time, when you might have lost sight of your project's roots, or for someone who's potentially interested in joining your team.

 

[aiyinsi]

I have four documents.

• Credits: It's such a pain to have to search for credits after you finished a project. It can be circumvented by a little effort every time you download a new ressource. (I also include the credits of not yet used assets and then delete those I didn't actually use when I delete them out of the project folder) It's not that I use that file while I work ... it's just so I don't lose the credits or stuff.
• Ideas: Well I tend to write my ideas out there. Just whatever I think might be cool. What is in there doesn't need to be in the game. It's just lterally a brainstorm file. It's split into 5 subcategories: Story/Lore, Places, Pokémon, Items and Gameplay/scripts.
• TODO: If I deem a feature from the idea file as good enough that I want to encorparate it into the TODO file I plan it out and move it to there. It's sorted by priotity of it getting done. It doesn't necessairily mean that I always do the first task on that list. I'll do the second or third if I feel like it. But it does mean, that I always got the priority tasks of my project in mind and I also reflect on the priority from time to time.
• DONE: Once a task is done it's moved from the TODO list to the done list. This does not include any of the work done like actual scripts/dialouge/art/... . It only includes a short description of every task done. It's a great documentation of what's done. When I was working with a team and didn't just have txt files flying around in my project folder the done was actually incorparated in the ooge spreadsheets TODO list together with a part that showed who was working on what.
• Additionally: I have folders where I store assets I made, a seperate project that is a clean install of essentials 16.2 that I develop scripts in and then save them as txt in a different folder. They are not strictly part of the GDD though. They all go into a library of assets that I ever made that's not just bound to one project.

Are GDDs needed?
No, but they help you keeping a grasp on where your project is standing, how much work still needs and has been done. In general they relieve your brain of needing to remember all the ideas/plot/lore/whatever is necessairy for your project. Also if you're working with teammembers GDDs are a very straight forward and easy to understand to make everyone aware of everyones tasks and what is done in the project right now. Conveying that through chats is a lot harder in my experience.

 

[Maruno]

A lot of you detailed your rationale on how you organize your different documents, so my question is for @Maruno, since his work is building an engine vs building a game. You said that you have about 6 different "to do" documents, I was just curious what's your rationale for separating them? If it's not too spoilery for v18 or anything, can you elaborate on your 6 to do lists? Or give an example?

They cover different aspects. They're long-standing documents that contain all the things I've thought of over the years (well, all the things I've bothered to write down). They're called:

• To Do - Animation Editor (lots of ideas for a major overhaul of the Animation Editor, half of which are redundant as I want to move over to a different animation system instead now)
• To Do - battle (lots of notes about things to implement/things that could be implemented/things that need researching to ensure they work as they should... all related to battles)
• To Do - lag (ideas about what kinds of things can cause lag, not super fleshed out)
• To Do - other (anything that doesn't fit into the other To Do documents)
• To Do - screens (anything that is contained within a GUI)
• To Do - v18 (things I've done or wanted to do for v18, so that I had them in one place. Not all of the things in here have been done after all, and will be redistributed into the other To Do documents in time)
• Essentials projects (headings and brief notes on the larger projects that could be done with Essentials)

I think everything other than Essentials projects is really stretching the definition of "game design document", though, since they list specific features, bugs that need fixing and research that needs doing. The more general documents are over 20 pages each, so splitting them up is just about being able to manage it all.

 

[AdoreNotFound]

- Do you have a Game Design Document for your project?
Honestly can't live without one.

- Should projects have a GDD? Why or why not?

I think a GDD is really good to have, it gives you and your team (if you have one) a clear vision of what your aims and goals are. It helps getting people on the same line but also for outsiders who read the GDD, it should give them a clear vision about what type of game they're getting in to.

- What should be included in a GDD?

To be honest a must are your plans and what you're trying to create. Putting that in your gdd gives you and others a good vision about your ideas and your plans. It could also hold the red line of your game. Just generalise it. It should be easily readable and understandable for someone who has never heard of the game before.

- How is your GDD set up, if you have one?

I have a folder dedicated to my GDD, having a one-pager. As well as a fully written out Game Design Document. I also personally like to use a scrum board (Even though it's not really GDD) Since it helps me get a better view of what needs to be done and also a better overview of what I want the game to be.

- How extensive is your GDD? Do you plan out every single event, or kind of freeball it from a certain degree?

My GDD is kind of the summary of the game so to speak. I don't write every little step the player takes but if I'd ever take a break from the project I should be able to read the GDD and get a good idea of my plans once again.