Thomas and Diane have posted a short guide to Pitching to Game Publishers over at the blog for their game consultancy. Apart from giving them some link love (they’re not even on Technorati yet), it’s an excuse for me to tack-on some quick thoughts of my own.
(NB: my experience on the publisher side is pretty short, just a year spent working with Thomas and Diane as one of the people doing due-diligence for them on the incoming pitches, and doing milestone-reviews on the signed projects that were in-development.)
Picking a couple of their points to add to:
2. Show Passion
I want to hilight the part about not trying too hard to “tell the publisher what they want to hear”.
Every publisher is (potentially) going to make huge sweeping changes to your proposal long before they even put it before the internal funding review committee. They assume this. They will listen to your first pitch, and will already be thinking about places it needs changing, and how they’re going to work with you to improve those.
What does this mean?
It means that you need to go in with a strong, clear, unapologetic design, and not be afraid that it is “not the right thing” in lots of small and not so small ways. Yes, check that the 30-second description is of interest to them, i.e. the most core essential aspects, but don’t worry about the rest – they’ll tell you what’s wrong, and give you the opportunity to change the bits they don’t like.
Unless you can read their minds, don’t try to second guess what they want to hear. IME, many developers are a lot worse at second-guessing the publisher than they believe themselves to be. (modulo the large number of old-hands who’ve done this lots of time and really can second-guess – but they wouldn’t be reading the article anyway :)).
In the end, this means that when the publisher mentally strips away the bits they expect to change, there’s nothing left, because you were too timid in staking out what you wanted to do. And – quelle surprise! – they quickly lose interest in you.
3. Show Prototypes
IMHO in your prototype (and partially in your pitch) you’re going to be judged on a broad range of things. Whether the game is fun is only one of them. In particular, I’ve seen people ignore too many of these, or go the other way: try and prove everything, spending vast amounts trying to write practically an entire game as their demo. Inevitably, when you show a publisher a seemingly complete game they’ll want changes made, if nothing else just to justify their own creative involvement, and so the vicious circle of spiralling costs starts.
Main things I remember looking for / at (off the top of my head):
- you know what a computer game is (this isn’t facetious; I mean do you know what a normal game menu is like? do you know what the “standard” control system is for your genre of game? do you know the difference between a good game and a bad one? etc)
- you know how to make games from an implementation POV (“ability to deliver” is almost everything in this industry)
- you know how to cut features brutally to achieve a shippable (the same reason as above, except that this one deals with the many times that you are prevented from delivering by external factors you have no control over – and so you have to somehow change the rules of the process in order to make it work anyway)
- you are good at accepting direction and showing that you did what was asked without twisting it…
- …or that you’re so much better at game design, marketing, implementation, production, and delivery than the publisher that they’re never going to need to impose direction upon you
- you have a proposal / idea that is somehow unique
- your output is consistently good in each core discipline (i.e. you’re not noticeably much worse at one of them): art style, novel game ideas, core gameplay, user-interfacing / usability, implementation / stability, technology, production/timelines/delivering what you say you will (you’d be amazed how many people shoot themselves in the foot by making promises to the publisher BEFORE even signing a contract, and then fail to deliver on them! That’s a great way to guarantee you won’t get signed)
- irrespective of what your people have done before, this particular set of them working together as a team is going to “gel” well
Depending on your situation some or all of those are already self-evident based on your portfolio of previous work as a team. Up to you to work out which may be weak or non-obvious. It’s great to get independent industry people (friends at other companies, for instance) to tell you what is not obvious to *them*.
Then you decide which of these “things we have but aren’t self-evident (so we need to show them explicitly)” or “things we don’t have (so we need to give some confidence that we WILL have them, or will make up for it somehow)” you’re going to deal with in your pitch, and which in your prototype(s). Again, up to you what goes where, but a good rule of thumb is to show something in the way that’s least effort for you to show convincingly. Don’t kill yourself trying to convince on every point and ignoring the cost-of-producing-it – remember you’re not getting paid for any of these prototypes.
Above all, remember that a prototype is wasted money. There is no way that you will ever get paid for prototyping, no matter how you look at it, unless th emoney is arranged before you even start making the prototype. No publisher will say “I love it – here’s the dev contract … oh, and I see you’ve spent lots of money getting this far. Here’s some free cash to ease the pain you’ve faced the last 6 months”.
On the subject of money: cost is negotiable. Many of those other items are not. If you’re not competent to make a game it’s going to be much harder to correct further down the line than if you’re simply asking too much money and we have to renegotiate a contract with you. Sure, contract negotation may seem difficult and expensive to YOU, but it’s practically free to US. But “hiring additional programmers into YOUR teams, and firing some of your incompetent staff” is a very long way from being cheap, easy, or desirable for us.
IMHO, you’re better off – initially – getting the above things to look good even at the cost of going in with a request for funding that is much more than the publisher wants to see.
- pitch everyone early, but arrange to meet them late, so that they all synchronise at the END not the START
- aim to get down to a shortlist of publishers you’re talking to as a “round 2” AFTER meeting all of them once, and tell publishers you’re cutting down the list. No publisher likes to be “wasting their time” talking to a team that’s talking to 20 other publishers and is very likely to sign with someone else, but knowing they’re on a shortlist won’t hurt (their egos) so much.
- perhaps non-obviously, sometimes f your pitch is weak, it can help if there’s no-one else you’re talking to, so the publisher feels they have the luxury of taking time over you. If they like you it might give them time to work out a way they CAN work with you
- conversely, if your pitch is strong, get everyone pitched ASAP preferably all in the same week. Pitching at GDC is probably a great start. But getting publishers lined up to speak to you all at the same time is, as noted, pretty tricky
- find out what the lead times are for the publishers you’re interested in, and fit yourself within them. Each will be different. If they don’t happily and eagerly tell you this, you’re possibly talking to the wrong staff at the publisher and need to get yourself a better contact, fast – the “right” people will tend to be very upfront about this, because it wastes their time if you come to them with a too-fast or too-slow set of expectations
- ditto each will be different for different “templates” of project. Some random templates are:
- AAA $20m+ project
- AAA $2m+ project
- Casual project
- Online project
- 3year+ proejct
- 2year+ project
- 1yr+ project
NB: that’s varying in some cases by genre, in some cases by cost, in some cases by development time.
The key thing here is that a publisher is typically a tree-hierarchy of decision makers, with local territories having discretion up to a certain size/time/cost before they have to defer to a more senior person / territory. Just like bank managers and arranging overdrafts / loans, back when the banks gave large discretion to local managers: sometimes you *can* get someone to approve over their normal limits if you’ve got something amazing, but mostly it helps to match your pitch/project size to the seniority / buying power of the individual person at the publisher who you’ve got the relationship with and who’s sold on your game.
5 replies on “Ptiching to Game Publishers – some thoughts”
Great article as usual Adam, but just for French-syntax-nitpicking good measure, it’s “Quelle surprise” :)
Oh, the shame!
Sigh. I never did understand the whole masculine/feminine thing.
Many thanks for the link, and the thoughts – all very, very valid points!
About the prototype, I agree that you need one to basically prove you can overcome the risks in the project (ie it should concentrate on the most risky points), but it is really hard to do when you’re still at paper stage early in the process, that’s why we were focusing in the article on the “programmer art -core mechanics prototype(s)” , which is not necessarily very long or expensive to do. Also, the most risky points are maybe not the same for the developer and publisher, so it’s tricky for the developer to put the cash upfront to do it, as the publisher might want to see different points proven (as you point out).
In a traditional development model, I would say the “full”prototype, vertical slice-type, would be expected at end of preproduction (and thus financed by the publisher) but if you use scrum there’s not really any point in separating pre-prod and prod (other than internal cuisine and politics), so the “prototype” should be always evolving, and not thrown away, it’s your build.
Thanks again anyway! We’ve added the part 2 now, please don’t hesitate to discuss too!
It’s simple, what’s the most unpredictable gender? Surprise HAS to be feminine.
LOL beautiful; point taken.