Design Land: Creating Great Design Docs - Extra Credits Video Games

Oh, this was such a good idea, Zoey. Sometimes it really helps to get out of the office, you know? I mean, I can actually feel my mind clearing up just from being away from work stuff. Woah. Um hi. Um what what's this? Quiet, you. Hey, looks like another message from Design Land. Dearest Matthew, today I find myself lost, clamoring up the design document dunes just to slide back down again, facing mirages that I once thought were good ideas, blinded by sandstorms of possible designs. This, I fear, is one of the most treacherous legs of our journey through the region known as the pre-production plateau. In fact, just yesterday, one of our junior designers wandered off when we weren't looking and got themselves mired in quicksand. Thankfully, we found them in the nick of time just moments before they got dragged under by minutia. But, you know what they say, you have to walk without rhythm. Thanks so much to HelloFresh for helping us figure out what's for dinner. Today, we begin our first two steps in

Design Land. For today, we start doing the thing which both excites and terrifies me about this series, turning Design Land into a ride-along. To the degree that my publisher will let us, I'll now begin using real examples from the game we're building as we're building it, so you can see the process as we go. So, with that, let's talk about design documents and the three purposes that they serve. One, design documents retain information. Now, this may seem odd as most people think of design documents as tools to convey information. But, you have no idea how many meetings I've seen go by, especially in pre-production, where people say all sorts of awesome design ideas and some problems are solved, but then no one documents any of it. All that great stuff is left, at best, as meeting notes no one can parse a month later, or at worst, with whatever parts of the discussion stick in people's heads. So, it's good practice to document new systems and features that come up right after the discussion. It'll show you the holes in your thinking and give you something to reference the next time someone asks, "Wait, how did we say the upkeep system was supposed to work again?" Think of it

as the rope that will help you keep the quicksand from sucking you under. Two, design documents convey information. Now, this is the way most people think of design documents as something to hand the rest of your team to build. Prototypes are better for this, but design docs are still useful here, especially where UI is concerned. And three, design docs as the first place to fail faster. In design, there's no harm in being wrong, there's only harm in staying wrong. And the first place you can make sure you fully thought something out and that all the pieces work together is in your documents. You'd be surprised how many ideas you can dismiss and how many systems you'll find still have aspects you need to flesh out just by trying to document them. So, now that we've outlined the three purposes of a design doc, what are the practical steps to make them the most efficient? Well, first, use a wiki, not a pile of Word documents or the like. Why? Well, things are far less likely to get lost for one, helping with the data retention. Second, everyone will be working off the same version of your documents, cutting down on confusion. And third, it makes it very easy to hyperlink other documents, which

you absolutely should do. After all, you can't expect your whole team to read every document. And when an artist or engineer pulls up a document to do whatever task they have at hand, you don't want them wasting 20 minutes desperately searching for everything that the first doc references. Or worse still, just making assumptions about the things that you very carefully documented elsewhere without even being able to look at those docs. Also, wikis encourage people to make short design documents. This sounds silly, but it's actually critical to good design doc hygiene. Your design doc should, for the most part, be around 1,000 words or less. If something's running a lot over, you should probably break it down into more digestible pieces. And if you keep your design doc short, so long as you have good internal linking, people are more likely to read them, designers are more likely to write them immediately following meetings, they're easier to keep updated, and everyone spends less time scrolling through walls of text to find what they're you're for. And so you can see what I'm about, I've enclosed this example of one of our design documents. Remember, long documents don't make better documents. Don't fall into that trap. You know what does

generally make for better documents though? Pictures. Everybody loves pictures. If something's really important, a picture is a great way for getting people to stop and read the section about it. Along with that, examples are great too. Abstract designs can be hard to parse. So if you can walk people through how things, especially systems, should play out, then you'll do a better job of communicating what you're actually going for. And writing examples is often how you'll discover edge cases you didn't account for, or places where your design doesn't play out exactly how you want it. From there, you'll want to make sure your language is consistent and specific. Initially, our doc referenced territories, lands, and regions when they were all in fact the same thing. We also used character and hero interchangeably. Don't do this. These are the mirages that can lead you astray. Be specific wherever you can, and make sure that your terms are defined. If you write, "Heroes entering another faction's territory without a declaration of war are trespassing," then you better define what trespassing is somewhere else. And if it's how your game works, you'd better write, "Heroes entering another faction's territory

without a declaration of war or a military access treaty are trespassing." Because you need to spell out everything. No one's going to code what's in your mind. Another great way to get specific is to put formulas in your documents. And don't worry, as first pass formulas, they don't have to be right. You can use pseudo code to help define what you're going for and give you a place to iterate from. Simply saying, "Monsters drop gold when killed," means that an engineer is going to either end up gated while they try to get in touch with you to ask how much gold, or they'll just make up the value themselves. It also means other designers won't be able to give you feedback and help you fail faster before it's in the game. Whereas writing something like, "Monsters drop gold value equal open paren open paren two times attack value plus three times defense value plus HP close paren forward slash 100 close paren," gives your engineers something to plug in right away and allows your other designers to ask, "Wait, is defense really the most valuable stat for a monster? Do we want it to be?" Lastly, remember to deprecate documents. Sometimes something you write early

might get utterly changed or even completely removed from the game. Don't let those documents sit around because 6 months from now an engineer might spend an entire week trying to build them. Though I do recommend having a wiki section called deprecated documents where you move them rather than delete them because who knows when you'll want to pull something back in or mine them for an idea you had a year ago. And with that, fellow ventures in design land, I will leave you for the time being. But before I do, here are two formulas I grabbed from one of our design documents. In the comments below, see if you can parse them in plain English and figure out what I'm trying to do as if you were a fellow designer on this project. For the next time we meet, we'll be talking about how to impart meaning into math. Design boldly, my friends. James Portnow. P.S. Put on sunblock or you're going to get burnt. Oh, thanks, bud. Wait, how did he know we were at the beach? Oh, but it's hard to talk about game design on an empty stomach. Oh, talk about a tasty loot drop. Thanks, HelloFresh. HelloFresh is a tasty meal kit delivery service that's been saving me a ton of time this summer

while also helping me avoid stressful meal planning and expensive trips to the grocery store while I'm hangry. That never ends well. Instead, I get everything I need to prepare awesome home-cooked meals delivered right to my door and I'm eating in a half hour or less. And now with more than 55 different meal options available each week, finding your favorite is super easy. Want to go for vegetarian, pescetarian, or fit and wholesome meals? Oh, they got you covered. Myself, however, I went a more meaty route and cooked up their delicious one-pan pork carnita tacos, which Zoe and I devoured quite quickly while we hid inside from the day star. But since it's cookout season, Jeff grilled up their firehouse cheeseburgers, which of course looked too good for Zoe and I not to slap on sunscreen and make an appearance for. You shut up, pal. Oh, and another thing HelloFresh gets right is their continued work on the sustainability and freshness fronts. Their produce goes from farm to your front door in under a week. The ingredients are pre-portioned, meaning less food waste when compared to grocery shopping. And HelloFresh is the first carbon neutral meal kit company, which we love to see. And with the summer in full swing, now's a great time to try

HelloFresh for yourself with this delectable deal. All you got to do is go to hellofresh.com and use the code Extra Credit 16 for 16 free meals across seven boxes, three free gifts, and free shipping. Oh, you heard me right, hungry peoples. You can get free food while supporting the content you love, the environment, and your grumbly tummy. Again, that's 16 free meals across seven boxes and three free gifts at hellofresh.com using the code Extra Credit 16. Your time and taste buds will thank you, and once again, so will we. Thanks so much for the support. I believe that was Kat for thanking Ahmet Ziyad Turk, Alicia Bramble, Angela Valenciana, Arclight Games, Casey Muscha, Dominic Valenciana, and Joseph Blaine for being legendary patrons.