I thought you disappeared from youtube, I haven't been seeing your videos in my feed. I had to search you to make sure you were still doing videos. Glad to see you're still here.
It depends on design experience. At the studio I work at (~20 people), we often make the GDD before the prototype if it's a type of game we are familiar with. This is often the case when we're shopping around for brand deals since most brand games take mechanics we are already use to seeing. After seeing the GDD, we may be asked to create a prototype before a publishing deal is made. If it's a type of game the studio is not use to or an original IP we may write a short document to outline the core concepts of the game to provide direction and a goal for the prototype. Those are no more than 5 pages. Once we have the prototype and made a few more design passes, we would the write a more detailed GDD and begin shopping around for a publisher. Another thing is, at least in my experience, GDDs are supposed to be constantly changing to reflect the current and future state of a game throughout the development process. If the GDD never changes, then the designers are either perfect or something is wrong internally. Of course, I am speaking in terms of how an indie studio may handle it. Some of this may or may not apply depending on the scope of a game.
@@jorgevelasco-theartofgames8687 It depends on the game and the goal of the prototype. If it's a complex game, we may not have much of an art pass in the prototype and just leave it as grey boxing with free assets. We will have concept art on the side to help people imagine the visuals. If the game is mostly mechanics everyone knows, we may push for more developed art in the prototype since that is what we are really trying to sell.
I have both experiences (starting from a doc without any type of prototype and start with a prototype and then document). If you start with a document, you have to accept that in some moment, the document will be deprecated beyond what is useful to update, so don't fall in love with the document. If you start with a prototype, I usually document along the way, just to have a clear goal, a basic loop and the mechanics used in the prototype to get to that goal. Either way, have documentation is pretty useful as the 2 reasons why you should are so important. Great video Tim!
So basically: design a prototype first (core gameloop mechanics), thinker with it until its fun to play. THEN design the main game, long term gameplay, levels, progression, extra features, artstyle.
I like to make a crappy GDD for the prototype, just to make sure I don't wander off and forget the point I was trying to prove. And the key word here is small, Sometimes its just a paragraph or even a frase or a couple of topics. Like so: Hookshot game - Platformer 2D - Vertical Level design - hookshot (propels you up) - Fall damege and thats it. BTW I still use a custom version of that GDD (for when it gets serious) you made to this day. great stuff! thanks.
To me a design document is a tool you don't always need. Times you might need it are: when the team grows/changes it's quicker to bring new people on; if you're talking to people who might want to fund your game before it's finished, a DD is helpful to make your argument; for complex games, it helps to have a full list of features before you arrange alpha testing; it can be used to contain scope creep and define the MVP; if you're solo and you're going to take 2 years, you might only touch a feature once every 8 months, it's useful to know what the intent is. My DD look like Miro boards with pictures, maths and feature lists - not a 2000 word essay.
Spot on. I've spent ages trying to keep everything down in a document, after following advice like "you have to have everything planned before writing a line of code!". But after getting work as a software engineer, I found out that this is pretty much undoable -- unless you're reinventing the wheel. Software, and especially games, are bound to change because real feedback is critical. So have a rough plan, brainstorm, discuss, prototype, and correct accordingly.
I prefer design pillars to design documents. There can definitely be value in making some basic core decisions up-front, along the lines of, "Hey, this is meant to be a non-stop action game, so minimize time spent on puzzles, exploring, etc." Not only does it help maintain focus, but if the design pillar repeatedly conflicts with emergent designs that test well with players, it suggests the pillar is actually not a good fit and should adapt to what people like. Pillars act more like a filter for ideas than a detailed spec sheet.
You make excellent points here, but I would say it's better to not do too much of a design doc upfront rather than not do one at all. A design doc, even working alone, will help you organize your thoughts while you're getting to work on a prototype. For me, inspiration hits fast and hard and I can crank out a 1,000 word design doc in a day or two (for a complex game; I made a shmup where the design doc was a few pages of notes scribbled in a notebook as I was working on the game). I can't program those 1,000 words of ideas in a day or two. Worst case scenario, the prototype doesn't work out and you "wasted" a day or two focusing on game design for a failed project, which, in my opinion, is not time wasted. There definitely needs to be a limit, though.
I use design docs for 'possibilities', whether it's getting a simplified version of a game that I should make later instead of right now (if its too complicated or I should be working on something else) or putting multiple potential directions a design could end up going. Considering something from multiple angles and putting incompatible ideas on the same doc is good to make sure I don't get locked on a course too early and forget other things, but also makes it easier to break from the doc, since it's actually impossible to follow all of it.
@@martinandani He's still posting on Twitter every once in a while so he seems to be fine. Still is odd that he just dropped his channel over night literally. No goodbye, no farewell, just gone into the night. True man of mistery =D
Great video. Personally, I think writing a design document is imperative, regardless of whether your game will change or not. The fact that you've documented the basis of the game allows you to easily make changes later. If the idea is just in your head, its slightly difficult. I spent almost 2 months writing my game design document. I'm 3 months into development and some parts have changed, but the underlying foundation has not. I dunno, having a design document written just makes the potential of building the game much more realistic, possibly a placebo.
I feel like your advise is pretty good spot on for what I decided to do. I'm almost done with my first game ever and I haven't documented much of anything. I really free balled it. I've decided to do a make a general game design doc and track my time for the second game. Before I do that I'm going to make a basic prototype though.
Glad to see you back Tim! I've tried using design docs before and yeah, I usually never end up following them cuz like you mentioned, things change along the way. But a short one definitely does serve as a nice starting point!
Solid video bro! I was considering making a design doc for one of my game ideas and this video was very timely. I'll still make one, but not as in depth as I originally planned (for the time being, at least). I'm confident in my programming and have some business & marketing experience, but I know to make the types of games I want to make, I'll need to find an artist to work with. So it'd definitely be useful to have at least some of the basics written down so when I'm ready & find the artist I'm looking for, it would aid me in explaining to them a lot of the ideas that are in my head. I'll keep it to 0.5-2 pages just for a very rough outline, then start the prototype and add to/tweak the design doc as I go. Writing also helps me organize my thoughts and think of new ones.
good to see you Tim. I was never a fan of design docs especially since my games never went beyond prototyping, lol I do think like you said when your game is near the end of alpha or into beta and you got a vertical slice going then design docs will become very helpful especially level design stuff.
I don’t have a computer graphics card programs basically nothing to make a game, but was recently inspired to finally try. And this just completely inspired me further thanks a lot man.
Hey Tim, it would be really cool if you played some video games with game design perspective in your commentary. I'd suggest starting with Beginner's Guide!
Any tips: What do you do if you become a millionaire on your first indie game? Do you buy house, car or open an office? Not sure which direction to go to.
