High visuals are probably better for a pitch where you can communicate the words by speaking, while for ACTUALLY planning words are probably a lot better to explain things. Of course, you should have some concept art in there if it helps the reader understand
I love writing game design documents. i love writing scripts for games as well so writing a game design document was easy. I think some game dev need to now learn how to game write for their games. I might make a tutorial about game writing or something. Nice video!
I think the difference in presentation shows what the game designer has, or at least has confidence in. The mostly text document shows that they have a good idea what they're going to do (or they at least have a writer), but maybe not an artist. The other shows the opposite, of course. As for technical documents, in the process of making a game, writing things down definitely helps. Until you start writing, the game is just an idea in your head. Writing down those ideas is the first step in making that game real.
gonna link your video to my clients...all they come up with is a short version of the pitch, usually not longer then a tweet, then expect me to fill it for them. Tired of it.
@@thefckgd great. subbed. Try to mention on the technical side, multiplayer online, local coop and single player are different beasts and changing that mid production is idiotic and makes us freelance devs lose our shit. I started including that into the contracts, because clients dont understand what an undertaking it is to change a singleplayer game into multiplayer can be. In some cases you have to recreate the whole project.
I took a look at that "The Flame In The Flood" document cause it did look very nice and it intrigued me from your clip there, but I would say as a pitch document it's not very helpful. It gives a very clear mood / art style for the game, but despite a handful of terms in the opening page, it's doesn't explain very much about what kind of game it is, what you'll be doing more precisely in the game and what makes it stand out and unique. That said, I think the question comes down to who the document is for: a publisher might have a hard time accepting this game without a solid vertical slice (or at the least a prototype), but to help onboard new team members or to set the tone for the game, I think it's totally valid. This game was a Kickstarter success so I guess they had different priorities. Anyway, you asked for an opinion so I gave it! Great video and definitely gonna be tuning in for more.
Hey, thanks for pointing that out, I think you're right about that. I hope this comment helps others to understand all of this. Thanks again, including the "Great video and definitely gonna be tuning in for more." Means a lot to me. :)
@@thefckgd oh well I hope it's useful to others then. Actually the pitch document is a large part of my work, and it really does depend on its purpose (audience, I guess) as to its overall form. It's a whole topic in itself honestly! Anyway, thanks for the response!
@@TimmyShire Oh, do you think you could give me examples of pitches from your work? Or give some advice for me and the folks? That would be really cool of you. :)
@@thefckgd ha, this is gonna seem like such an obvious evasion but I can't really share any examples - not my property to share. But I've basically done pitches for internal purposes (i.e. pitches for the next project to producer / founder type folk), for publishers, and for onboarding / overview purposes. I've also recently done a high concept document, which was a first for me and is essentially a 1-2 pager overview of the game at a glance, I gather it's popular with publisher-side producers to share with higher-ups and anyone else interested who don't need the full scope and details. I think the easiest is those created as overviews or for onboarding team members. Usually at this point the concept is nailed down and you're not trying (as much) to persuade anyone with it, so you can generally have a bit more fun with it. Be more visual than informative. From there the internal pitch needs to be a bit more serious, though that obviously depends on the team you're in. A small indie team of 20 might not be so focused on having everything answered since there can be more targeted questions internally to see if it's an avenue worth exploring. As a rule of thumb though you're trying to get your idea off the ground, and so a lot of what you mention in the video is relevant. For this version you can probably get away with a less visually led pitch deck since the state of the game is likely just an idea in your head. For this you can rely more on reference images from other games (if you can compare your game easily to them), and even diagrams, sketches, fakes if you have the skills. I find it's still beneficial to be visual with these things, so even if you don't have any art to show you can still help persuade people with some visual content. For most teams you'll likely know the people you're pitching to, so most likely you can afford to be a bit hack-y about it. The point really is to get the idea out there. I might get lynched for saying so, but even a couple of AI images can go a long way for setting at least a vibe or tone for the game - though of course this shouldn't go into any "official" document, it only tells people that your team can't make anything of artistic integrity. The publisher side one is (unsurprisingly) harder, since there you're essentially asking for money. There are a lot of good templates out there but you're basically trying to prove three things: - your game is interesting / unique / valuable - there is a potential demand for it (either existing games prove it, or there is a gap in the market that only you have discovered) - your team are the only ones able to achieve it For this there are a few things you generally need, something about your team, overview of the core game pillars and gameplay loop, and some attempt at what you want to achieve with the art style. Typical concept art will be enough, or some high quality fakes, but these days a lot of smaller teams won't really find success with publisher funding unless there's at least something in-engine to show, a prototype or (ideally) a vertical slice. If you're already at stage you can probably show off a bit of it too - video clips would be perfect. Outside of that, a lot of the content comes down to the game in question, but the focus should be on highlighting what is new or compelling about your game. Worry less about the basics (i.e. if you're making a 2D platformer, you don't need to mention the movement mechanics unless they're particularly important to the experience), and focus instead on highlighting what's going to get players intrigued. Competitor analysis can be super helpful, it shows you've done your homework and if done properly you can really highlight easily to the publisher how "safe" they should be betting on your game. It's important to use this as a metric to measure your game against: it's worthless to say "it's a popular genre" if you can't point to why your game will benefit from that popularity. It should be about comparison, and obviously putting you in a good light. Another thing that can help is a budget and a timeframe, again to help answer the publisher's questions about their payoff before they need to ask it themselves. In all cases, don't be afraid of references. These things should always be about making the strongest, most compelling argument with as little information as possible. Don't fill the document with minute details or little things you think are neat: be concise, precise and generate intrigue. References will help with that, since you can say more with less. "Balatro but in space" says more than if you were trying to find complicated ways of explaining Balatro to the reader without actually using that name. Btw, I really like your idea of using voice alongside a design document. I can really see a short video of someone going through their document to be a big advantage - especially if you can share footage, audio, etc at the same time
@@TimmyShire There's a lot to learn here :) thank you. Do you mind if I use everything you just said in my video? I think it could be really useful for a lot of people.
