It's a nice GDD. I can see that you put a lot of thought and effort into this
However, if you plan to use it in a team as a definitive guide during production, it's not gonna be feasible for a couple of reasons:
-
Nobody wants to read a 69-page design document. It's too long; no one can digest that much information in one, or even multiple sittings. Reducing wordiness is going to be crucial. Also, important information can get buried somewhere in the middle and be not very easily accessible because of that. A Table of Contents in the beginning would really help with that. There's also a bunch of visual references, but I still have no idea what the intended art style is due to the references being far too diverse. You also don't need 13 images to convey what the settings menu is going to look like.
-
It's a bit rigid. And at the same time, very unspecific. Using the Environmental Hazards/Obstacles section as an example. Instead of 4 paragraphs of how you intend the players to to interact with these hypothetical obstacles, it would actually give a clearer picture to the designers and programmers to give a few specific examples, like an itemized list of potential obstacles and what they're going to do to the player. So instead of "...electrified puddles and similar obstacles, Poppy must time her movement properly or find the right object to interact with if she’d rather spare herself the hassle of...", you do something like:
"Electric puddles: when Poppy overlaps with them, does damage and briefly paralyzes Poppy. Tripwire: deals massive impact damage to Poppy if triggered."
You can't predict how the players are going to interact with the game. All you can do is design the interactions, observe, draw conclusions, and make adjustments. After that, you can adjust the doc to append some interesting obstacles that you wouldn't have otherwise considered before playtesting. This is where having a more fluid structure for the GDD could really come in clutch.
modern zenith
novel cedar
