The GDD's Not Dead: Tips & Tricks for Agile Design Documents

Well, hello. Hello everyone. It's great to see so many people interested in design documentation. I'm very passionate about it. So, welcome to my talk. Uh it's called GDD's not dead, tips and tricks for agile design documents. First of all, hi. So, my name's Jay. I'm a game designer. I've been doing this for about 12 years now. Uh this is just some of the things that I've done. Um I started out working on the Buzz quiz games way back uh 12 years ago. And then I moved on to doing variety of stuff, lots of children's games, and then a real mixture, kind of

mobile and console. And this is what I do now. I work for company called Snapfinger Click. We're an indie company. We make games that people can play in the living room and online over streaming platforms like Twitch. So, you can type commands into Twitch and kind of play along at home. Um so, anyway, GDDs um I think to get sort of an understanding of where we're at with the GDD, it's good to do a little bit of history. So, software development used to work under the system or well, still does in some cases, but it's not used in game development very often anymore. But, this was the kind of standard up until about 15 years ago. 15 years ago. So, the idea was that you would do each segment of the development, complete it before you moved on. So, for doing design, the whole design would be complete. There would be a document that was written very detailed. Then that was your whole design process before any line of code was ever written. So, that's kind of where the GDD came from.

We're still kind of using that system under a system that came the system that it came from we don't use anymore. So, moving into Agile, which is what almost everybody uses now, it doesn't quite work anymore because we're starting the implementation while the design is still in progress. We're still figuring stuff out. Stuff's happening at the same time. So, you don't have that time to create a whole document up front describing absolutely everything in the game. So, we've got a lot of complaints about the GDD and I'm sure some of you have heard these or said these yourselves. That, you know, there's no time to write it. When when do we do it? We're too busy play testing. We're too busy prototyping and reacting to how people are playing the game. We haven't got time to sit down and write a huge document. Um it's almost impossible to keep it up-to-date because things change very quickly. You've written something a week later it's completely changed. It's too rigid. You know, in a in an Agile team you've got departments that

now all talk with one another all the time. So, there's definitely a move towards people contributing to the design outside of the design team. So, if it's written down in a big document, does that mean that you know, you're sort of setting in stone and you're not being very welcoming to other people having ideas. Uh documents are boring, right? Nobody likes documents. Um it's much more fun to just get on with the game and not spend time writing a document. And the old classic, nobody reads it anyway. Who ever sits down and reads a GDD from cover to cover? Just doesn't happen, right? So, should we throw the GDD away? Uh I don't think so. Um I think it's a very valuable tool still. We just need to learn how to adapt it to the way that we work now. Um GDDs are very good for figuring things out. You know, they are like the first prototype. When you sit down, work your way through a problem, you ask yourself a lot of questions. Just the very act of forcing yourself through this process of writing it down

can flush out lots of issues before you get to involving other teams and other people. So, it has a really huge benefit on that side. Uh it's also just good to write stuff down because you forget things. Even the designer will forget things. Every time you make a decision, if you know you've written it down somewhere, you don't have to go through this process again. And of course, it's great for the team. Having somewhere to actually look at a design document, answer their questions, always have something on hand. If it's possible to do that, though. So, moving into Agile, I think what a lot of people do is separate docs. I used to do this myself. Um it's it kind of feels like the obvious thing because, you know, you're working in an Agile way, a problem comes up, you solve it there and then you write a document for it. You just deal with it as it arises. Which makes sense if things flow nicely like that, but game development never does. Um at the time it works, but of course, you don't always implement everything in one

go. You might do a first pass. You might just do the key features. When you try and go back and revisit something to fill in the gaps, sometimes it can be quite hard to find the document that describes it correctly. There can be lots of smaller sub features that touch on these bigger features, and you can find yourself sifting through lots of different documents, trying to find the thing that you actually need. Uh it's a lot harder to maintain separate documents because there's a tendency to write it and then you're done with it. You don't really want to go back to it. And how do you kind of manage it? You know, is there a sort of central one document that's linking out to all these documents? There's not really this feeling of wanting to revisit them. They're just done in that moment. And it also this system means that things do tend to fall through the cracks a lot because when you're starting a separate document, you tend to do that for bigger features, kind of headline things. So, when it comes to smaller features, they just tend to get forgotten about because they're not worthy of a separate

document, so they can kind of sneak up on you at the end. So, I still think one big document is the right way to go about it. Um it is actually, you know, assuming you've got a good contents page and that you've got the right terminology, it can actually be easier to find things because if all else fails, you can just kind of control F your way through the document, just keep skipping through until you find the bit you need. It is in the sense easier to maintain. I mean, maintaining documents is always tough, but when it's in one big document, you're constantly scrolling through this document, this document is in use every single day, you're going to be going past sections all the time where you think, "Oh yeah, that's out of date now. I need to do something with that." It's always in your face and and you care more about it because it is an ongoing project, if you like. It's not just a throwaway thing that you wrote once and that you don't want to go back to. This is the this is something that stays with you for the whole project, so you care more about keeping it up to date. And it just makes it easier to cover

everything because with a big document, it doesn't matter if something's big or small, you can kind of slip it in anywhere. If something comes to mind, a smaller feature that you want to get in the game, you don't have to go through this process of starting a brand new document, you can just put it in kind of where it belongs and it's not such a big deal. What we need to sort of move away from is thinking of the GDD as a complete document that you're going to print out and you when you start writing it, you need to try and finish it. We need to think about it as an actual living document. It doesn't it doesn't ever really end. You're always updating it, you're always improving it. And it will never truly be finished until the game is. So, you need to kind of be at peace with having parts of the document that aren't complete, that they are work in progress, that they are marked as TBD, there's comments everywhere. This is all fine. I think it's even fine

to have just to explain different ways you want to try things cuz you might not be able to decide until you've got it in code, you've prototyped it. So, you can say, you know, I want to try these three methods. Later on, you can update it to the one that you've gone with. You should always keep a change log though because when this is changing all the time, it's useful for people who are interested in it to see if there's anything that's changed that that affects them. So, keeping a good tidy change log is important. Um there's a lot of tools out there for documents and I haven't used them all so I can't really talk about the benefits of everything. I can only really talk about the one that I use. But for me, I use Google Docs and it it kind of does 95% of what I want it to do. Uh the main benefit of it is the collaboration, the fact that multiple people can work on the same document at once. So, you can have a team of designers all contributing to the same document. There's not this sense of emailing different documents around.

And you know, as a team, there's always just the one version in one place. You haven't got version two, three, four. It's always the live version, it's always up to date because that's just how Google works. It's always on the network and it keeps its own version history so you don't need to worry about archiving versions off and things like that. Um it's very good at linking. You can you know, designers have a bad habit sometimes of talking about one feature and then it touches another feature and then they kind of want to go off and talk about that feature, especially if they haven't written about it yet. But, you should try and keep things in their right places and using a linking system, you know, click here to read more about that feature. Google Docs is really good at that to sort of jump around the document quite quickly. Um the comment system I also think is really good. Um the comments are great for everything really, for you to leave little notes about parts that haven't been fully fleshed out and you need to revisit

them, unanswered questions, concerns, or suggestions. Um also we talked about at the beginning about this idea of a document being very rigid and not being great for people to suggest things. Well, the comment section is good for that, too, because it's one thing to kind of go up to a designer with a suggestion. Being able to just drop it in as a comment, that's quite easy for most people to do. It doesn't feel like a big deal. Um and also for the designer, it makes their process a bit easier because they don't get put on the spot. They don't have to come up with an answer straight away. They can work through these comments, think about them, have a conversation as well, have a discussion, and you can always take it face-to-face if if it's going that way. And most importantly, animated GIFs. Um this comes back to thinking about the document more as something that you don't print off, that you look at on the screen. Um you know, in the past it was so challenging to describe how you you wanted something to move, you know, the the path of

something or a transition. So, being able to put sort of animated version of what you're trying to describe is actually really useful. So, this is a method that I use for writing documents. Um and I think not only does it work really well for agile development, but it's also good to bear in mind that the GDD is read by a lot of different people and it's a challenge for designers because they've got to write something that's read by the development team, uh management within the company, the client if there is one, a publisher, um QA, maybe the license holder. There's a lot of different people with a lot of different interests and different things they want to get out of the GDD. And you kind of have to cover all of this in one document that works for everyone. And that can be quite tough. So, I use the system called the three headers method. The idea being that literally document headers, you start kind of in an overview and you gradually build on the detail as you go down.

So, if we think about your sort of header one, this would be your chapter title. Um this would be, for example, this might be something like core gameplay. And this is a collection of features that belongs together within a chapter. And before you get to any of the features, you just have a section that you've written a couple of paragraphs that gives a really strong overview of what's coming up in this chapter. Excuse me. And when you're writing this section, this is where you should picture the people who aren't directly working on the game but have an interest in the game and are key stakeholders in the game. So, that might be your internal management, that might be executives on the client side, people who want to know the cool stuff about the game. They want to know the headline features, but they haven't got the time or inclination to discover all the ins

and outs of the game. They just want to know broadly what it's about and they want to get excited about it. So, this section, I think can and should be quite salesy, quite emotive, um full of, you know, concept art, stuff that gets people really excited, basically. And this is really kind of selling what this whole section of your GDD is going to be about. Nothing that you say here is actually going to be useful in terms of implementation. You're going to go into detail later on, but you can touch upon things just to get people excited. When we move to header two, this is our actual feature within the chapter. So, if your chapter was core gameplay, for example, your feature could be something like sliding block puzzles or combat system or something like that. Something that belongs within that chapter. And you kind of do the same thing again here. You do another overview, but this time it's for the feature. And this is a bit more focused on what

you're doing. It can still be a little bit salesy and a little bit exciting, but we're starting to drill down a little bit more on the facts. We're going into a little bit more detail now. And when you think about this section, this is for perhaps someone who's on your development team, but isn't actually implementing this feature. So, this might be, say, the lead programmer who has delegated the implementation of this feature to another programmer. They want to know kind of roughly how it works. They want to know the most important things, but they don't need to go through step-by-step exactly how it works. So, it's a bit more information. It's useful, but it's it's not like every detail at this point. We're just explaining it in a kind of summary. And now we get to heading three, which is This is kind of the meat of the GDD. This is like 90% of the GDD. This is where you're actually explaining how everything works. I say header three is kind of header three and beyond because you probably will go deeper with more subsections within sections, but the point is at this point we're not doing overviews. We're not doing summaries anymore.

We're just talking exactly about what we're doing. And this is all the information that you need to know about the feature laid out very clearly in whatever way, you know, works for you. If that's a flowchart, storyboard, walkthrough, but this is this is for the person who's implementing the feature. So, they've got all the information that they need to know. Um also for QA as well who would be testing the feature and want to know the ins and outs of it and everything there is to know about it. This should all be very factual, by the way. I don't think that This isn't the place to talk about the whys, um, you know, how cool it's going to be. This is really to focus on what it actually does. This is information. And I think what's good about the system is that Well, first of all, for your audience, they can kind of skip to the part they care about. It's the different people I talked about before. If they get used to this format, they know they can just jump to the part that they're interested in. Um, you can also very quickly transform your GDD into

an overview document if someone wants to just get a sense of the game, you've got it ready to go. You don't need to create something. You can just bring up the GDD, delete the bits that you don't want. It's all ready to go. But, in terms of Agile, it really allows the design to grow naturally when it's ready to, without the document becoming unwieldy or untidy or feeling like it's a huge mess. Because when you first set up that GDD, the first thing you'll do is do all the heading ones and twos. You'll do your chapter headers. You'll do your features. Then, you'll start filling them all out and giving a really strong overview of what the game's going to be all about. And that is enough for people to get going with it. It's enough to start prototyping. It's enough to start planning. And you can have features for many, many months into development where you haven't gone beyond your overview, your heading two description. You haven't got to the detail yet. But, you can read that document. It doesn't feel like things are missing. It doesn't feel like things are half done. It's very still a very readable format that works really nicely.

So, few other things that you can do, um, if you do have a big team of designers, I think it's really useful to put one person responsible for the maintenance of the GDD. This is something which is really good to give a junior or someone who hasn't got a lot of experience writing documents because this will give them the opportunity to kind of cut their teeth a bit on what's going on. It will get them used to how to write documents and eventually they can progress into doing that. Um I think it's also really important to encourage programmers to tell you about edge cases because um noting down edge cases can be really useful for the future. Um but also, you know, sometimes when edge cases get solved without going through the designer, it can have knock-ons. So encouraging them to talk to you about that so that you can just make sure that it makes sense is is always good. But having that written down in the GDD is good for QA as well because they want to know about the edge cases. They want to know what they're going to be testing.

Um and leading into my next point, you should keep updating it during QA. I mean, obviously now games games are made in different ways now and a lot of games kind of continue on and have QA happenings you know, almost throughout their their lifetime, but there are bad habits where people kind of switch off from the design once we're in the QA phase. Things get just discussed outside of of the normal process. Things happen very quickly to fix bugs, but it is useful to keep track of those things. Again, for the future because when the game is finally sunset, I think it is good to take some time to properly archive the GDD, to actually go through it to make sure that it that it matches the final product. That you know, if someone was to revisit this game, which people do, games are brought back by different teams in the future, um that it makes their life easier because we do we do this process with with code, so we should do it with design as well. And I think you're you're making life easier for your

future self or someone else who takes over your work to be able to come back to that GDD and they'll know that everything in it makes sense and reflects the final product. Um yeah, so that's that's that's it. Um, I haven't actually a longer slightly longer version of this talk that I'm going to put on my Twitter later. So, if you do want to see some more information, please have a look out for that. But, other than that, um, if anyone has any questions, I'd love to answer them. Thank you very much. I do I love that tear structure you've got cuz I think there's something I I used to call it well, have a slightly different variation which is like cell structure. So, you have a core idea and then you expand on that in detail. But, this is like a little cleaner because at least you can deal with a sort of high-level concept in a very simple way. Yeah, it's really good for clients actually. I forgot to say, um, if you are working with a client and a requirement is to send your GDD to them at milestones, um,

it feels like it's it's complete. It doesn't feel like there's any obvious gaps. It just looks like you're done even if you haven't branched out to any detail of a certain feature yet. You just read through it and you think, "Oh, there's nothing missing. I feel like I read about everything." So, it works nicely for that, too. I mean, one thing I look at is a one of the things I'm working on things like PlayStation Home where I was the product owner effectively, it was a contract between me and the dev team. So, I was saying, "This is the requirements. This is what the different regions are expecting." And then they would come back to me with their responses to how they would solve that problem. And the way that we dealt with that was when you went to testing, if it didn't match what was agreed, it got rejected. Yeah. How do you make sure that happens in this particular kind of flow? Is there a kind of cuz you talk about keeping the GDD up and alive even through QA? But, is there a kind of how do you make sure the responsibility is clearly on the team to deliver what's needed, not necessarily what they think is needed if that makes sense?

As in, um, do I expect QA to flag up when the game doesn't match the design? Yes, exactly. I would do, yeah. But, I think in the what happens a lot at the moment is that design tends to slip towards the end of a project and so it can be very challenging for QA to know when to do that because they don't want to be disruptive, they don't want to be flagging up things that they, you know, 99% suspect is okay, but the design says otherwise. I personally think it's always worthwhile of QA flagging up where there are discrepancies. I think I spoke to someone at Unity a long time ago that works on documents and I think they actually treat issues in the documentation as bugs. Yeah. I think I've got that right. that's right. Yeah, I think Yeah, and I think that's really interesting because it's a good point. It's, you know, for someone like Unity documentation is so important because they've got all these people around the world reading the documents. They don't want to spend time having one-to-one support. They want people to be able to resolve their problems as much as possible through the documentation. So

when you have an issue with the documentation and treat it quite seriously, I think there's something in that. You know, I don't think we're quite there in game development yet, but I think it's important to flag up these issues and if you want to treat them as a bug as QA, I have no issue with that. I think that that's worth doing cuz I mean I don't find it a huge use. Well, quite often it was okay, but it was normally like you said, you know, someone decided to fix something but we didn't understand the consequences of that fix because they're not the designer. They haven't got that overall picture and it's often you end up particularly with games as services, you end up with that consequence lasting for a very very long time. Yeah, and it's a problem. It is a bit of a hole because you know, luckily I think a lot of QA people are quite design-minded and they use their common sense to flag things up, but it doesn't always happen and things do slip through, which is why I do think it's important that you maintain that interest even in these bug fixing and and things that, you know, only happen to a very small number of

your users. It still matters and you should still care about it and you should still be involved in what that fixes and and kind of sign it off and be okay with it because there could be unintended consequences. Exactly. So, I'm naturally on. I've got plenty more I can talk about. We have quite a lot of time. There's a guy at the back there and he's a microphone with a hat. Hats are good, by the way. I have quite a few thoughts on documentation, but we'll skip those for now. And I would be remiss if I didn't ask, what are your thoughts on wiki solutions such as Confluence? We would literally talk about this at lunchtime. Mixed feelings. I kind of see wikis a bit like separate docs. They are a challenge um because the problem with a wiki is that you don't know what's there unless you go looking for it. There are ways that you can try and point people to the different sections, but it it suffers from the similar problem of it can slip out of of sync very easily

and and no one really knows until they stumble across the page. I think what works best for a wiki a franchises. So, games where you you know, you you do a sequel and you bring over a lot of features into that sequel because perhaps a feature changes only you know, in in minor ways. It's interesting cuz when I started on Buzz, that being a franchise, the process was we we actually tried to move towards a wiki in the end, but we never kind of got round to it, but the process was a bit of a mess when I started working on it because we we would start a new GDD for the next game and any features that were carried over from the previous game, we just didn't write a design for cuz we didn't see the point. So, we would just say, you know, see previous game. But of course, there were little tweaks and little things that would happen to those features over time that weren't really tracked anywhere. So, I do feel like a wiki might be useful for that for for those kind of

situations, but I think it is really like a long-term, long-running franchise. Um for other games, um one-off games, I I don't I'm I'm not convinced they're the best way. I have tried it and I think it it it's just a lot of the problems I mentioned with the separate documents crop up with a wiki as well. I mean, I had a lot more luck with a wiki with PlayStation Home uh because it was um stakeholders around the globe because we had to sort of satisfy each of their requirements and I was able to have a single definitive space which could easily be tracked. That worked really well. The trouble was it was Confluence and I'm not very big fan of that particular wiki personally, but it Remember, this is a while ago. It's It's got a lot better since, I'm sure. Well, okay. Yeah, see you know what I'm talking about exactly. The issue is not, I don't think, the process. Well, there's two issues, I think, if there are. It's very, very useful way to work.

But it's high maintenance. And you spend as much time making sure the wiki is still working as you do writing the stuff. The Sorry, go on. Well, the other thing I was going to add to that, the other problem with it is that that you lose the definitive original source. So, you can't track what decision processes were. And that actually, that's probably the biggest problem I had. There is another problem, actually, I forgot to say. If you are working with a client and they want to see the design, a wiki is a nightmare format to deliver to them. I know there are tools that can kind of spit it out, but um without being able to um you know, put things in a logical order, it's not great for the client if you are working with one to to receive it in that format. So, that's another issue that you you can have, but you know, your mileage may vary. The There's no right or wrong answer. Um it it can suit certain projects. I think what I didn't kind of say at the beginning is this the way I work, cuz I've worked on

big games and small games and everything in between, I I feel like this particular method works well for kind of anything. It can work for a small game. It can work for a big game. It can work for a client publisher relationship. But, you might find that something like a wiki works better when you're a smaller independent team, for example. Um but, if you're wanting to use a process that you can bring from project to project without ever having to change it, then this this feels like the you know, the one big document to me feels like the best one-size-fits-all solution. I mean, Google Docs is amazing because of the collaborative nature of it. Uh the only problem I have is that people changing things that I'm currently writing in. Which can happen. It's really annoying. Puts you off as well. You think, "Oh, someone's watching me. I've got to got to get it right. Can't make a spelling mistake." Can be Oh, boy, I can make spelling mistakes. Um sorry, any more questions? I So, you got one? Anyone No, no, no. I I'm going to check one out of you. So, what One of the things I like doing when I write requirements is use cases.

Where does the use case sit in the formula that you're doing with these three tiers? How do you Is it a separate thing? Is it a like a tier four or How do you How do you fit that in? Are you talking about um establishing the user's requirements with No, I mean, so there's a particular form of writing requirements where you write a use case. So, you say use does Mhm. uh what they see, what they do, what dependencies there are, what other systems are affected. Uh and I find that really useful to do in a tabular form. Yeah. Because it's really clear to a coder exactly what behaviors I expect to see coming out of the end process. Yeah, I would think that was Yeah, I I don't I don't go through the process in that way, personally. But, I I see that as as the the questions that you're answering when you start to flesh it out into that level of detail. And I I I think that part of the process is very personal, and that's why I didn't talk too much about it because I don't want to say, "You should do it this way or that way or whatever." because like personally I hate flowcharts. I'm really

I can't stand them because they're so I find them so unwieldy. I always forget some case. I have to go back and I'm fiddling around with little lines and I just I just don't like working with them, but I know a lot of designers love them and a lot of programmers love them because they they they lay everything out in a very logical way. So, I personally like working with storyboards. That's my sort of method of choice, but I when I get to that level and I'm fleshing things out and I'm really working through the the detail, that's when I'm asking all those questions and I'm trying to think, you know, if this happens, what then? If that happens, what then? And going through it in a storyboard, I find that you tend to naturally bump into those things because you you get to a point this is why I think it's really good to write stuff down because it will flush things out. You know, something that seems so simple as pressing a button for example, when you step through it bit by bit kind of frame by frame, you think, "Right, what happens next? User presses button." But it's not as simple as that, you know, what what prompts them to do it

and what hap- what's the feedback that's going on while they're doing it? Are they holding it down? Are they are they tapping it? Does it make a sound? Does it vibrate? Can they always press this button? Are there's situations where they can't? You know, that it can it can bring out lots and lots of questions, but with design, you know, you are always revisiting things. You never you never think of everything all the time, but as you go over it again and again and as you play test and as things come up through QA, you will eventually flush everything out, but you're just trying to catch the big things. You're trying to ask yourself the most important questions to try and get as much out as you possibly can in that sort of phase. I went through a phase where I tried to do UML, so that's like a formal structure for kind of writing out requirements, which um it's almost like HTML, but for writing out requirement processes. Um and it turned out to be a completely waste of time. Because it meant that I was writing what the coders needed to think through, not what the requirement

of the experience needed to be. And realizing there's a trust there, you need to have a kind of almost like I said earlier, a contract between me and the and the development team is I should not be trying to solve the problem. I should be trying to define the problem. Is that fair? Yeah, I think you are Yeah, there's sort of when you are going through the process of designing, um you know, that old we need solutions, not problems. You actually want the problems, not the solutions. Because um you might not have an answer to all those problems, but you need to know about all the problems, and then you can work your way through figuring out those solutions in whatever way that that sort of takes shape. Cool. Sorry, we're just trying to work out the next speaker's going to need a little time to get themselves set up. Um oh, it's it's just guys. Um so, we'll just carry on talking, but uh when they're ready, we'll get them to come up on on use the podium. So, I mean, any any more questions from the audience? Cuz I I This is one of my favorite topics. The reason is I think if we get

the documentation right at the right level for the right audience, then I think what I think Joe's brilliantly explained by having this three-tier system is that effectively, we've got a series of stories that we're telling at different levels of depth. Yeah. And uh so, the way I work is rather than the three stories, which I actually might start using, I I typically work on a high-concept document first. And what I'm writing with the high-concept document is is something that does not that that never changes. This is what we are going to build. This is agreed at the beginning. This is This doesn't vary. But that means it's not got any detail. It just tells you what exactly it is the game is supposed to be. Then the GDD is the living document and at that point I've broken down the elements that are in the high concept which are features and effectively I've got a one I I take a one-pager per feature viewpoint. They're almost never one page. I try but they're almost never one page and in that one pager I'm trying to define what it is that's the problem,

how it's solving and then these user stories about what the user sees, what the user does, what's going on in the background, etc. That's a personal take. Yeah, I think the the trouble with my approach is I can't usually show clients the GDD. I have to rely on them trusting me that the high-level concept and the GDD match. And when technical problems happen I have to come up with solutions that communicate to the dev team why it's important not to go off the rails. At the same time when I have to go off the rails, I have to explain to the client why this is still the same game. That's non-trivial. And so this seems to me a much simpler way in some ways because you can communicate the high, middle, and low tier. So but how I mean am I right? Am I am I interpreting your description correctly cuz um you know, what happens when things go off the rails? Does it matter so much because you can readjust every tier?

No, it doesn't really. Yeah, because you can exactly you can always adjust any part of the document. You know, you you everything goes into that one document. You don't need to flip around between between them. So if something does need to fundamentally change or you're removing a feature or you know, something doesn't work or whatever, then yeah, it doesn't really matter because it's just just just a general update to the document. So that's all fine. Quick question here. Do you have example documents that we could see? Oh, you know, I really want to. I've had this conversation with it's really difficult because nobody wants to let me. Um yeah, no, I I I actually I I mentioned I loaded a longer version of this talk in the summer and I wanted to put up a a design doc to go with it. But I was told no because um yeah, just NDAs and and things like that. Um it's really difficult though and I really I kind of almost just want

to write like a fake one just to get it out there, but I just never have have the time really, but take so much time to write that. I mean, it probably take longer than Yeah, it's it's a big it's a big challenge to to commit to, but um it's ongoing. I keep asking about it. I keep trying to get that and I'm hoping that enough time will pass for some of the projects where no one really cares anymore, but it's it's very difficult people especially when you're working with a client no one is motivated to say yes to that unfortunately, so Well, we did try we actually have a template Genie I think on our website, but um it's not as interesting as this one. Uh but the problem is that it's blank. So, it's just like here's the questions to ask. And that's not what you're after. You're after how do you answer those questions? And what I found is cuz every piece of documentation we do is commercially confidential, we can't give our clients material out. So, I end up in the same position you're describing. Yeah, it's really difficult and I'm I'm very pro knowledge sharing, but it it's

challenging when you when you've you're working with other parties unfortunately. And it's challenge of being a freelance in general which is that you know, sometimes I can't even tell you what projects I'm working on. And sometimes I'm on projects that last years and they're out of date and I'll change the template by that point. Cuz they're I think I don't know about you, but for me the template is an evolving process anyway. Uh slightly less so I I here. Yeah, I mean, I we spoke about this a little bit over lunch, but I'm I I'm not a I don't believe it's possible to have a template in the kind of I know a lot of people want to see a document with headers and things mapped out for you. I think that's very difficult with games because the games are so different and you can't you know, if one game's got guns and one game's got puzzles, you just can't bring that over. It's not that easy. The key features of a game will vary depending on what it is. So, I think it might be possible in terms of genres,

but I don't feel it's possible as like a really high-level thing, but I do copy-paste my GDDs a lot when I'm working on a new project because there are certain elements that you can copy over very easily. You know, things like the pause menu or something. Are you going to design the same pause menu 10 times? No. So, you might as well bring things like that over and and it reminds you that you are going to need them at some point. So, you can definitely cut corners that way and I I do a lot. I still find myself adding to that because some client wants slightly different thing on the pause menu. I've got client currently wants us to put an extra help page and I'm trying to dissuade him of that process cuz it's just going to get in the way of people's use and the only way I can think of putting it is on the pause menu. Yeah. But it's not a not great solution, but it means I've just had to change the way we normally write that feature. So, that's just challenging. Anyway, uh are we nearly ready at the back? No, not yet. Apparently, I've got to keep going.

Question over here. Sorry, Joe. Uh Joe's being a very kind sport at keeping us giving you extra time. Um first, thanks. It This is going real nice, especially for me. Um I'm a lead game designer in a uh casual mid-core online PvP sports company and most of the time I'm also a big defender of uh rule them all, big one game design documents, and we maintain it. Just like you do in uh Google Docs. Um but our most like 90% of the time our documents are highly mathematical. Like we don't just like and it has to be both open to product managers, understandable by product managers, but also understandable understandable by the game developers. Because it's sometimes not mutually exclusive, sometimes it is. Um I most of the time had to find myself

uh kindly dictate some syntax rules. Like if this is a um variable, use it in bold blue. It can be changed by players' actions. Or is this a value that we may change? Like 15 was unbalanced, like let's make it 10. Then bold red. And then uh write everything you can, if it's possible, in pseudocodes and stuff like that. But of course, there's although once the new game designers get it, it shortens the time, but it has an investment time. Mhm. And gets things clunky and not everyone has to be mathematically, you know, understand it so well. Um if you had such challenges, uh what did you do or what would you suggest both everyone do? Well, I think when you find something that particularly if your your programmers get along with and and the design team enjoy doing like pseudocode,

um there's no reason not to do it because um if if that's working for you. But I think yeah, it's in terms of how you put that in your document, that that's a challenge that you have to figure out how you're going to represent it. And I think what I I mean, I don't have I don't have that particular issue, but there are sometimes where you've got formulas and things that you need to talk about. Um I do break off into separate documents for particularly technical details. So, if there is, you know, a big table of numbers, for example, um I would break that out into a separate document and and kind of keep things clean, but it it you know, pseudo code doesn't seem to me to be something that you would have to keep out of the document. I think it's just perhaps good to do an overview for your producer project manager person, you know, what it's doing, uh like a couple of paragraphs or, you know, paragraph about it, but clearly, you know, define what it is. Like, here's the overview, here's the pseudo

code, you can jump straight to the pseudo code if you want to. Make it clear in your write-up that you're not um missing out on any information, you know, so you've you've said you've covered the things you need to know in your little paragraph. Um and there's nothing that's, you know, in there that you need to read if you just want to jump to the pseudo code and you can read that and you're comfortable with that. I would probably do something like that, just making it very easy to jump to the bit you care about, basically. Yeah, I think it's lots of strength in having a secondary set of documents around the technical response to the GDD, which could possibly avoid some of that stuff as well. Uh but it all it's been what works for the situation. Yeah, it's very dependent on on your team and and what what works for you. So, yeah, if you want to break it out into another document, you should. Obviously, you've got to remember to keep on top of it, but you don't have to. It it's what works best for you, I think. And unfortunately, on that note, I'm going to say thank you very much. Thank you very much, yeah. Thank you very much.

Uh Mhm.