Hi, hello, hey there. Not sure if we’ve met? This is Johan and David, we do scouting and DevRel at Raw Fury. We’ve been here for a while, quietly enjoying the pitches you’ve been sending, trying our best to make sure you get a reply in a reasonable amount of time, and signing a game or two. We travel a fair amount to conventions big and small throughout the year (we strongly believe that we should meet people where they’re at), so chances are we’ve had a beer, a cup of coffee, some mezcal, or all of those things (sometimes in rapid succession) while you showed us what you’re working on. One of the questions that tends to come up in these conversations is a deceptively simple one: “What should I put in our pitch to Raw Fury?” It’s not really simple, of course, but let’s talk about it!
So what should you put into a pitch to Raw Fury?
Let’s sort you out with a laundry list of items (tl;dr down below) and also delve a little bit into the logic behind that list.
tl;dr
· A playable PC build that you feel captures enough of the essence of what you want to build and conveys that in a way that makes sense for people outside of your team
· A budget that shows your development related costs for 1 PC build in USD. No need to add marketing, ports, and so on – we can figure that one out together later. Basically, what we want is your burn rate multiplied by the months left in your development cycle
· A deck that helps us understand who’s building this, why you are building this, when you think it will be done, and a high-level description of what you’re building
· Anything that helps flesh out the pitch including GIFs, videos, a GDD, concept art, story documents, and anything else that helps us better understand what you want to do and how you’re getting there
That’s about it, really. If you’re here for the laundry list, here you go!
A playable PC build
The reasoning behind this is fairly simple – if we don’t have a build, we can’t play it, and we can’t make any concrete decisions. The part that is slightly trickier, and something that gets brought up in conversations a lot, is the question “what do you want in a build?” We wish we could put together a bullet list of what we want to see in a build with concrete steps that are easy to follow to ensure success. However, it’s not that easy – what we want in a build is quite frankly impossible to tell. It’s what you want in that build that matters.
We want a build that _you_ feel conveys the essence of what you’re trying to make in a good way. That might be exceptionally tight movement mechanics in a white-boxed level, if you’re looking to capture the sense and weight and thrill of running down a street, trying to get away from someone. That could be one brilliant sequence of puzzles, dressed in art that is close to where you want the full game to be. It can be the core systems playing together so well that the fact that it’s represented by a red square and a blue ball in a grey room doesn’t matter at all. Or it might be something else entirely. The important part here is that you’re sharing what _you_ feel confidently shows off what you’re doing and where you want to go.
That said, there are a few concrete things that are good to see in a build:
· Skippable cutscenes/intro. If we get the chance to play a build more than once for further evaluation, rewatching or re-reading stuff is likely not why we decided to go back in
· Checkpoints you can load into in different parts of the build. If the build is +10 mins, having some checkpoints we can load into helps out a lot.
· English subtitles (if the spoken language isn’t in English)
· Control scheme (can be a separate doc as well)
While none of these are strictly necessary, they can be pretty helpful!
One thing to keep in mind when sending a build to a publisher/investor would be to send the build you’re most proud of, the one that you feel confident about, the one that really shows what you’re aiming for with your project. Seeing many pitches per month, we do our best to play through builds sent to us but can’t guarantee we’ll play any build more than once so a reasonable expectation is that we’ll only play the build the first time you send it—put your best effort forward!
A budget
When it comes to budgets, in relation to us at least, what we want is something that tells us your development costs for 1 PC build. This means that you don’t need to take into account marketing, events, PR, etc., only costs related to the actual development of what you’re building. It can be as simple as your months left of development multiplied by your monthly burn rate, and it can be more granular if you feel that it would explain your process better. The reason for this is that we structure our budgets into a few different pools—
Development, Marketing and Service budgets—so just let us know what the development costs are and we’ll figure out the Marketing and Service budgets.
Development is your studio, what you need to take this project to a releasable state. Marketing and Service budgets contain stuff like digital/physical advertising, external PR, external QA, events, localization, porting, VO talents, etc. We have a lot of good external folks and partners that we work with, and we can estimate what would be a reasonable amount of money to allocate for both the marketing budget and the service budget. Since we also don’t include internal work hours from our team into these budgets (our work is our risk to carry, only stuff that comes with an invoice from an external party goes into these budgets), it becomes really hard for you to estimate the budget outside of your development costs. Thus, we only really need a development budget that gives us an understanding of what you need to bring this to a full release, as we will discuss Marketing and Service budgets together later.
A deck
There are a ton of guides, hints, tips and lots of diametrically different opinions on what constitutes a good pitch deck. Is it a 10 pager, 20 pts Arial text, built to last about 30 mins (with questions) if you run it live? Or is it a 30 pager, filled to the brim of 12pts Times New Roman? Should you detail the length of every team member or the current amount of lines of code produced? Should there be any numbers in it at all? Suffice to say, there’s likely enough ideas of how to build decks out there for it to be a reasonable field of study if you’re heading down the PhD route. So let’s toss all that out and look at the basics Raw Fury wants to have in a deck and leave the rest of it for you to decide if you want to put it in or not. Personally, we subscribe to a very simple philosophy. There are six questions we want answered in any sort of pitch deck:
What are you doing, Why are you doing it, Who are you, Where do you want to go, What do you need to get there, When will you be there?
If all these questions are answered, we have a high-level understanding of what you’re building and why you think it’s worthwhile. We will have learned a little bit about your team and your background. Lastly, we will also know what your ambition is, what you need to fulfill that ambition, and approximately how long that will take. If you send a PowerPoint with 6 slides, and you answer one question per slide, that’s all good. If you then feel that you want to stretch out and add more things, that’s perfectly fine – you can add whatever you feel helps increase the likelihood of a total stranger grokking what you’re about to do. Just make sure you’ve answered the six questions above.
Anything that helps flesh out the pitch
If you have a GDD that you feel can help us estimate where the playable will be in 18 months, add it to the submission. If you have some snazzy gifs that can be used to explain mechanics, show off the mood/art, or just happen to be hilarious then add them. Do you have a video playthrough of the build? Get it in this here pitch (we try to play everything but it’s great to have something where we can fast-forward to a specific spot of cool stuff that you want to show off). Concept art, story docs, poems, recipes for good food, or recommendations for metal bars in your town – anything goes. As long as it helps us build a clearer picture of where you will be by the end of this project.
Submit your pitch!
We’ve put together a pitch submission form where you can show us what you’re creating and share all the materials referenced above. Please submit your project with us using the link below!
Raw Fury – Pitch Submission Form
And that’s about it! We hope this helps! And if you have any questions or feedback, feel free to reach out via email, at conferences/expos or on twitter! In the end, this is built to be useful to you, so if there’s something missing just give a shout.