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!
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 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.
@@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
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.
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 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.
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.
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.
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.
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 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.
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.
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 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.
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!
Start with the written out idea.. then prototype, then develop a GDD
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.
Ey! Thats super interesting. Do you care about visuals when prototyping or its all white boxes??
@@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.
@@CollinPatrick Thanks for the tips :3
I hope he's fine, last video posted during covid :|
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.
Whatever happened to Tim Ruswick? The man just stopped posting one day and I just noticed it in 2024. I hope all is well, Tim.
Hope his well
@@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
You good bro? It's been two years...
Life's tough
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.
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 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.
What happened ? This is your last video ? What happened with Mon-Fri videos ?
1 year since last upload rip
A lot of those micro decisions are made iteratively. Agile development says your design document WILL change
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.
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.
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.
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 Trello for this kind of stuff, I can write down my ideas immediately anywhere and organize everything there.
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.
Welcome back bro , hope u had a gd vacation
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!
Did u stop making videos?
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 agree. I always do design docs. but not to decide the speed of bullets and damage. this is for maybe a balance sheet that comes later down the line.
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.
Yeah, I've got a few dead projects already becuase I started implementing stuff without proper prototype first. Listen to Tim and prototype! :D
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.
awesome
Where are you at Tim? I hope you're fine.
He passed away...
@@shroomy__rxcks Are you serious?
@@shroomy__rxcks he's still active on his discord, lol
Heyo Tim. Nice vid
Checked out your game. Looks neat! But man, why don't you have a trailer yet?
That's an interesting view point! Thanks, I learned something today!
Important topic, the coverage is nice and eloquent!
good tips tim, I change my visualization of the game all the damn time
Why cant I post anything in the discord? I cant interact at all and Idk what to do
Is anybody here? Tim?
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!
Where are you my guy, Game dev industry is not complete without your vids
where he is?
😂
@@martinandani what
"There are no secrets to success. It is the result of preparation, hard work, and learning from failure."
-- Colin Powell,,,,
ty
@Tim any update on Murder Bunnies?
Yessir, we locked orders a few days ago, charging cards for shipping shortly. Still on track for March!! Possibly earlier.
@Tim Ruswick | Game Dev Underground Amazing! Thank you
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.
100%
Where is Tim? We miss you! Hope you're happily married and moving on with your life
where’s tim?
I am disappointed that one of the examples for hook shot was not the legend of zelda, but I guess that's the point lol.
What about New Videos?
Better topic of this discussion should be "When should you use GDD"
I need a game developer for for a first person shooter game
Paid?
Not many updates from TR these days...
This dude is thinking... this dude is thinking lol...
I was thinking Indiana jones. 😆
I hate real world card games.
And I hate computer card-based games.
smooth brain detected
man, it's been a while jeeesus, he ded lulw
I hate design document, they are an obstacle to iteration.
First
Where are you bro
Indie dev is a cruel world. Very few make it and Tim wasnt one of those😔
@@gijane2cantwaittoseeyou203 he's still making his game though, I saw him post screenshots on Discord
@@Volian0so he's still active on discord? If so that's good
A lot of those micro decisions are made iteratively. Agile development says your design document WILL change