Christian Simmers

I don’t do a full doc but have started getting into the practice of making mockups, to work through interface layout and communicate with the team. All the pitches I’ve made have mockups in them just as a visual aid

I do like having design docs even if the team ends up deviating from them and tracking the project changes and progression/iterations elsewhere. It's a nice way to give new project members a quick overview if you know the major features and requirements in advance.

As for the format the, I like a design doc that's mainly a combo of pitch/proposal doc, scope statement, and a list of features/requirements. It's not too far from a project charter in more agile project teams?

The important part though, for me as a project manager at least, is having something that can help me pretty quickly convey the concept of a game and the general scope of work that'll go into it to team members. You can do that a lot of ways and a game design doc is kind of just my own habit.

Unfortunately my college didn't even show us what one looked like let alone make one. So I took it open myself to design a format for a Discord Server to create GDDs and to freely organize them in the Discord Server format. Imo it helps with the organization of information and allows for easy updating of said information as well as a great catalog of post mortems.

But if you wouldnt mind showing me what kind of format you use for your GDDs I want to understand the design of traditional documents to understand them better!

Monolithic docs aren't really useful in my experience. However a well maintained wiki with per-feature pages can help wonders.
Essentially a page can then serve as a brief for someone implementing the feature as well as a discussion mechanism for the team.

Well, this ended up turning into a bit more of a ramble than I intended it to...

I never use them! I learned pretty early in my career that I HATE putting design in a "document" format. But in addition to that I think it's not helpful for my design process and communicates the wrong information for my team.

High level information I prefer to use slideshow as outline, even if it isn't a live presentation. It's way more important people on my team understand why we're designing something in a particular way. Because when a particular piece of design doesn't work out, I find it's often more frustrating for people to have to redo something that they did, in fact, do perfectly "correctly" the first time. And then deviating from that spec, or having to rewrite it to match new design experiments adds a lot of friction and confusion. Way more helpful to have everyone see what the goal is, and understand why the attempt didn't reach the goal.

Not without it's disadvantages for sure. Not having the big GDD means you have to spend a lot of time building that understanding and buy in. It's harder to communicate the game to external partners (eg publishers, contractors). It's easy to be very underdocumented since you're not just updating some single central thing often. It's easy to desync with team members, especially remotely, when design shifts. It requires a lot of time from vision holders to just be communicating with everyone. And it absolutely does not scale well because it's hard to keep larger groups on the same page.

But I go without them because it's more true to the game process, and process is everything! Design isn't real until it survives contact with playtesting, and once you hit that point you already have the design. And if instead it dies in playtest, you can iterate faster. You can't always avoid writing specs, but when you can, you saved time, work, and kept your team doing what they're good at instead of generating documents.

So yeah, I hate them, not just because they're never true, but because putting it down concretely on paper gives it weight it should not have! Games never go to plan! That's not a flaw, that's the process of creating art. And while having "the big plan" might be useful for some people, I find it more confusing! I think game developers, designers, and production teams should be building process that reflects reality!

I really love a living wiki style document. I don't care if it's in google docs, notion, confluence, or a folder full of html files in dropbox, but I want cross-linked sections organized with a directory for easy reference. I expect it to grow and change. It might continue to stay relevant in a live service game but in the kind of one-off projects I've done, it's usually discarded after a point when the game is real and most of the work to be done is iterative and polish.

I want a vision of the game laid out with at least vague descriptions of setting, characters, story, tone, aesthetic, audience, design pillars, mechanics, progression, and goals of the game. The scope might not be readily apparent but I should be able to understand the vision and start writing tasks and features to put in the team's project management board.

I don't want to see stuff like "The fishing is like in Stardew Valley. Go play that and copy it." It's not helpful and it's embarrassing. Yes, I've seen this more than once. Points of reference are fine but "clone this" sucks.

Some of the most effective direction I've received from game designers has involved literal MS-Paint doodles. Quick, low-fidelity, napkin quality drawings are wonderful at conveying exactly the right amount of information without any distracting concerns like "is it really going to look like this?" because it's painfully obvious that it's not.

If possible, I think it's great to work with concept artists/art directors and get them involved in the pre-production stage. I think a great GDD has many contributors but is guided and curated by a deft designer.

I've worked with designers who left way too many questions and weren't really interrogating how the game works. Like "The character can fly." HOW does the character fly??? What actions does the player take to fly???? Really picturing the experience of the game and transmitting that to the team through documentation so they can build it is the goal.

I have so many opinions on this that I wrote a blog on GameDeveloper about it a while ago!

https://www.gamedeveloper.com/design/you-don-t-have-too-much-documentation---how-to-write-useable-documentation

I think docs being usable, searchable and scannable is paramount - if your docs aren't designed to be actually used and read then no one will use them.

In solo dev contexts my docs are mostly to communicate with external contributors or gather ideas, but for the most part I typically don't design in-doc unless it's necessary for some kind of archival or communication purpose.

In my studio work living docs and wikis are paramount, and the classic "here's just a literal document that tells you what the game is" is very outdated at this point. I think a good doc also needs to have core pillars very rigidly defined explainers for them for folks to reference too, so devs are on the same page about what they're building.

the unhelpful answer i have is that it depends. i often see people getting hung up on hitting a particular format, filling things out in a certain way, etc. but really it's just trying to solve two problems:

• helping you, as the designer, think through the design. so often writing docs I'll be like "yep yep, like this, easy" and then I'll come to actually detail out bits and suddenly it gets more tricky and I realise there's stuff that's underspecified.
• communicating the design to everyone else who's working on it. this is partly "here's how this thing works", but what is just as important is that everyone agrees what the problems are that the design is trying to solve, and is aligned on the general approach for how we're planning on solving it.

ultimately, if your job is being a "game designer" (as opposed to making a game by yourself) then the easy part of the job is designing the game, and the hard part is getting everyone to agree on what the game is and building something that connects up. and different teams, different projects, they'll all have different reasons that that is hard. your job is to think seriously and deeply about how to solve that problem - and one tool might be writing a GDD, and including stuff in a particular structure, but honestly if you're thinking hard enough about that problem, the details of how you structure docs should be pretty straightforward to figure out.

I'm coming at this from a pretty different place, I'm a freelance board game designer that works mostly solo or with a co-designer.

I don't do traditional GDDs. I find it's most helpful to do an initial brainstorm and create a document that contains all of the considerations and restrictions, all the initial ideas including 1-2 sentence descriptions of potential games, and the final decision on what to do for the first prototype.

After that I keep a journal of all the notes I take during development and testing, and also use it to track changes from version to version. Having this continuous chain of reasoning from inception to current version makes it a lot easier to know why a change was made, and to know what else to try if something isn't working.