GDC T&T 001: “30 Things I Hate About Your Game Pitch”
This blog includes my takeaways & thoughts on the GDC Talk “30 Things I Hate About Your Game Pitch.” by Brain Upton.
[8 Minute Read]
Game pitch is such a crucial stage in game development; a good/bad pitch could likely decide the game's fate. The landscape of game publishing has evolved significantly, and game pitches aren't exclusively about landing a publisher anymore. Game pitch is still an essential skill that all game designers and developers should master, as it’s now often about selling your vision to collaborators, communities, funding, or even platforms that will help elevate your game’s reach. Additionally, the tips this talk has given can also be applied to areas from how to design your game store page to design a game in general.
This blog will not only cover all the critical advice in a clean and organized manner but also include my thoughts on many points he provided. Let’s jump right in.
Right at the beginning, Brain shares that we need to look at the Game Pitch from the audience’s perspective and everything in your pitch should answer those two questions:
Is the game worth making?
Can this team make it?
The latter one is obvious as it points to the feasibility of your game (with your team). The first one does feel a bit vague in terms of the definition of “worth making,” as the talk didn’t give any further explanation. It can be something like “Will this game sell well?” or “Does the game have potential to grow?” or maybe the idea has a strong connection to a specific culture or audience, then “Is it really meaningful and special?” However, this implies we should always figure out the hook of our game pitch, find out which direction the pitch should lean to and make the audience believe it is worth making for that reason.
Now let’s talk about the things that often go wrong in a game pitch and how to avoid them. I conclude 21 points that are very valuable to me and I add my reflections on some of them.
Pre-Pitch: Mindset, Personal and Tech Preparation
We always tend to put all effort into the content of the pitch, which sometimes leads us to ignore getting prepared for other things, such as mindset, personal and tech preparation. This section is about getting into the right mindset and preparing yourself personally and professionally before the pitch.
Don’t:
1. Don’t be hungover, but be ready and serious | Be mentally and physically prepared for the pitch. Take a shower :)
2. Don’t expect them to know you | Enter the room assuming the audience has no prior knowledge of you or your game.
3. Don’t trash others & don’t be an asshole | Criticizing others reflects poorly on you. Your attitude matters as much as your game; show respect and professionalism as you’re showing the publishers who they are going to work with.
Be more humble, I will say, especially if we get inspired by some existing games and the goal is to improve the player experience with some new twists or features. Keep in mind how challenging it is to design anything from 0 to 1. Instead of criticizing why those existing games are bad, try using “Yes, and” to emphasize that you not only acknowledge their work but focus on bringing the player experience to the next level rather than just “My design is better than theirs.” This could also be applied to the F&Q section if the audience asks you the difference between your game and existing titles. So, it is a mindset rather than some fixed content.
4. Don’t be annoyed if getting questions during the pitch. Be fine to go off script | Stay flexible and ready to engage in a natural conversation, even if it means leaving your script.
In the talk, he mentioned that even if they interrupt the pitch, you shouldn’t be annoyed, as that behaviour shows their interest. This is a really interesting point to me. I can’t even imagine being interrupted during the pitch, as it is a disrespectful, rude, and uncommon manner to the speaker. So this, to me, can be expanded to be a mindset that is mentally prepared for something unexpected.
5. Have no idea how many people/how much time/money it needs (your scope) | Be prepared with realistic estimates for time, budget, and team size.
I put this in the Pre-Pitch category rather than in Pitch Content because sometimes we might not include all that information on our slides. We are likely to introduce our team members at the very beginning if we have one. But this point can still be broken down into how much a specific feature requires (and we likely won’t include this for every feature, but we do need to be prepared if they ask about our estimation on any feature.) And if we don’t have a team at all at that point, this becomes more crucial as it shows we have a realistic plan and estimation for the future.
Do:
6. Bring a big enough screen to show your content | Ensure your tech setup is appropriate for the space and audience.
7. Bring headphones (Not earbuds) | Use proper equipment to present high-quality audio.
I have the exact experience of this point because one of my developed games is really about listening. We prepared both earbuds and headphones, and in our session, all the testers chose headphones over earbuds. Additionally, if the testing area is noisy, try to prepare closed-end headphones that have noise-cancelling. Lastly, another good practice is to have headphones spitters or possibly make speakers and headphones both enabling at the same time so that the audience who are behind the tester watching could get a similar experience.
Now, how do you make your pitch effective and efficient?
Pitch Content: How to Design and What to Present in Your Pitch
This section focuses on the actual content of your pitch—what should be included, how it should be presented, and what to avoid.
Don’t:
8. Don’t only demonstrate your Game pillars. As they are not hooks, do talk about your unique designs | Differentiate between the foundational elements of your game and what makes it stand out—emphasize the latter.
This point is similar to another given during the talk: “Don’t do an inventory system.” They share the same goal as your pitch don’t need to explain the standard systems. Know your audience. Imagine they are publishers who have listened to hundreds of game pitches, then demonstrating common features not only won’t make your game stand out but also bore them and lower their expectations.
9. Don’t show a general prototype that only has easy and basic interactions in every game, but prototype things that are unique, different, and hard (your hooks) | Only build prototypes that showcase the unique aspects of your game.
Again, this is similar to the previous point. I still include this as an additional one because I feel it can be applied to more than just game pitching. Prototypes are the methods to test out a feature, helping you decide if this design works or not. We should ask ourselves, “Do we need to prototype this first? What problem am I trying to resolve?” In the context of game pitch, I believe it is more an answer to "whether showing this prototype will help the audience catch the hook of the game?” Use the game It Takes Two as an example; instead of prototyping and showing the two characters can move and jump smoothly, it should emphasize its unique puzzle mechanic that relies on team effort to solve together. (Although I don’t really know what they prototype to show to others in their early stages, just imaging seeing both prototypes in action, the latter one definitely helps us better picture where the fun comes from and highlights its uniqueness.) Of course, moving and jumping smoothly is a critical foundation that we should put lots of effort into. During your game pitch, I agree with the Brain that it is better to show the latter one.
10. Don’t need lots of art, but focus on the quality of the art | It's better to have a small amount of polished art than a lot of mediocre assets.
I am not a professional artist, but I feel this is similar to what people are showing on their portfolios, where you need to show what you are capable of.
11. Don’t have over-polished art (especially for prototype) | This suggests a lot of work will be redone, and the team isn’t putting the right effort into prototyping. Don’t use the art to overshadow your incomplete prototype (mechanic-wise).
At first glance, this seems to contradict his previous point. From my perspective, it is correct that you should avoid over-polished art if the game pitch happens at the very early stages of your game’s pipeline. However, if the pitch’s goal is to invite more investment in an ongoing developing game, I believe it is generally better to show some polished art concepts/animations. So, the key point is to find the right level of polish based on your game’s stage. For early prototyping of a game idea, having any over-polished art is definitely the wrong direction cause we all know game development is an agile process that requires constant refinements.
12. Does it need that new tech? | Don’t use new technology just for the sake of it—justify why it’s necessary for your game.
13. Don’t just remake versions of popular games | Show that your game is more than a clone of something already successful.
14. Don’t include too much monetization | Avoid overloading your pitch with monetization models, as they will usually change in the future—the detailed plan doesn’t belong in a game pitch.
15. Don’t show your backstory | Avoid including personal backstory unless it directly adds value to the game’s pitch. Your game should be good alone without knowing all the backstory.
16. Don’t ask publishers for IP | They will say no, and the negotiation should happen before your pitch to the publishers.
Points 15 & 16 above share the same reason: Your game should be good alone without knowing all your backstories and without others’ intellectual property.
Do:
17. Explain the player experience in detail, moment to moment. | Focus on what the player is doing, seeing, and feeling during specific gameplay moments.
18. Acknowledge big technical risks and address them | Be upfront about potential challenges and have solutions or workarounds ready.
19. Realistic business plan | Make sure your business plan is both achievable and clearly presented
20. Be able to tell what are placeholders & Make the “Work In Progress” look like WIP | Make sure the audience can distinguish between final assets and placeholders. Clearly label unfinished elements so they don’t get judged unfairly.
21. For selling stories, show your writing skills instead of crappy dialogue | Demonstrate your narrative abilities through high-quality writing, not subpar placeholder dialogue.
Final touches.
At the end of the talk, Brain provided 4 essence guidelines he believed all game pitchers should follow:
Be Enthusiastic
Be Honest
Sell your Hook
Know your Scope
Designing a game is already a tough task, and selling that design to others can be even harder, especially for those who don’t feel confident in public speaking. One critical takeaway for me from this GDC talk is that game pitching is definitely a skill we can—and should—practice.
However, I feel the video misses an important point: there’s more to a pitch than just content and preparation. The act of pitching reminds me of Aristotle's persuasive technique:
Character (êthos) of the speaker
The emotional state (pathos) of the hearer
The argument (logos) itself.
Looking at the four points Brain shared today alongside Aristotle’s three principles from over 2,000 years ago, there’s a clear connection. Being enthusiastic and honest builds your credibility as a game designer and as a person. Selling your hook and knowing your scope make your pitch more logical and compelling. What’s missing a bit, though, is the emphasis on how you present and connect with your audience in such a short time—something that can determine whether your message truly resonates.
Finally, I highly recommend watching the full video for more insights. I haven’t included all of Brain’s points, and you might come away with your own take on his advice. I’d love to hear your thoughts on this blog or on game pitching in general. Thanks for reading!
