Gamespot has a great write-up on how games get pitched — both internally inside a publisher and by independent developers. I’ve now personally done more than a dozen pitches, and I have to say that I’m probably masochistic because I actually like the process; I suppose it’s the thought of going after something for the chance to create a product you’re passionate about. I’d probably loathe it if I was forced to pitch a match-3 game.

My first experience pitching was, technically, a complete failure. After building a PC prototype, I flew to a half dozen publishers to pitch our game as a PS2 / Xbox 360 / PSP / DS game — in reality, we were grasping for whatever we could get. The only reason we had these meetings at all was thanks to our agent I was working with for this product (incidentally, Warren is also the agent for N+ and Everyday Shooter). I believe our failure was justified — we had a polished demo, but an incomplete team and the market was such that a game like Eets was highly risky. From my point of view, however, this first product was a launching pad for the company — and indeed that’s exactly what happened. We continued to self-publish the game for PC online, secure a European retail distribution deal via Warren’s prowess, and we continue to sell the game online to this day.

Since then we’ve successfully pitched and signed three new games (Eets: Chowdown, N+ and an unannounced project), and each time it gives me a great sense of accomplishment in formulating the pitch and preparing the delivery. Going through the process so many times, however, has definitely altered the way I think about a pitch.

For the sake of simplicity, I’m using our decision to want to make a game and to pitch it synonymously, and in general, this is indeed what happens. I believe the vast majority of game development start-ups do one of two things:

1) Create a game and then find a market for it

2) Develop an idea you think could do well in the market, determine how much it’s going to cost to develop, and then try to find funding for it.

The first is obviously flawed, but it’s certainly understandable. Most independents, us included, started by making the game they wanted to make — economics be damned. For the record, I love this style of development — I just wouldn’t recommend anyone to depend their livelihood on it The second happens all the time, but in my experience it’s almost always an uphill battle. The thing is, without starting with the constraints, the idea always balloons to include everyone’s favourite features, each one pulling down the chance of the game actually being financially successful, and thus pulling down the chance of a successful pitch. Also familiar is taking that idea, and applying an aggressive schedule and lowering the costs to meet it. As one colleague once said “You’ll always find a buyer if you keep lowering your price, but at what cost?” This ends in the familiar massive overtime and feature cuts which burns everyone out.

Instead, I believe more and more developers are following the third path:

3) Start with the constraints, and then develop and idea from it.

My decision to create a game now starts with the resources constraints and then expands to how we can make the best possible game out of those constraints. That is, we may start with a pool of game ideas we’d like to explore, but for the most part they are totally undeveloped. Then, for each platform we’re considering, I give a narrow range of budgets and minimum expected ROI, and then ask “what can we build to achieve this result?”

Obviously, underlying to all of this is the notion that we’d be proud of the game, and that we won’t simply go for the cash grab. However, by starting with the constraints, I believe we actually build better games. This is because we’re forced to focus on the strengths of the game, and ignore everything else — creating a purer, better play experience. And guess what? This method has a way, way better chance of success in the pitching channel — and in the market place.

I realize I’m still only grazing the surface here, but if anyone wants me to delve into this in more detail, feel free to contact me or simply comment here.

I just realized: Currently, every single Klei employee can code to a certain degree. In fact, only our Art Director does not have Computer Science degree. Okay, there’s only five of us, but that’s still a funny thing that you can build entire games in this day and age with this kind of make up.

One thing I do believe in is multi-disciplinary talents. I’ve mentioned before that 90% of the art in Eets were created by programmers by trade, and the fact that our Art Director is quite proficient in Action Script is no small benefit. Our make up is something like this:

2 Specialized programmers

1 Artist who can code

1 Designer who can code

1 Programmer who can do art

During the development of Eets, we actually had 2 programmer/artists. I’ve been mulling on this a bit, and I’ve come up with the following reasons why I’m compelled to find as much cross-disciplinary talent as possible:

1) Communication is far better. Time spent explaining how something works on the art side versus the code side becomes minimal, and the final implementation is far cleaner, because both sides understand the needs of the other.

2) You don’t need to waste the specialist’s time doing simple tasks. The designer can script the entire level. The artist can write the script to interact with the GUI. The coder can hook up the art pieces.

3) Your schedule doesn’t go into smoke when one person goes out of commission. There are far more people that can take up the torch and finish the task instead — if you’re using SCRUM, this is especially important.

Interestingly, I’m finding that as middleware improves, there’s less and less reason to hire talent that don’t work well with other people — there’s less emphasis on engine creation, and almost every task requires that you work with someone in another discipline. I’m sure as Klei grows, we will start to hire more talent with less diverse education, but I will definitely push to provide the training and create better bonds between the disciplines. I’ve seen too much work go to waste because of that disconnect.

When Klei began life in my basement, we had a prototype for our game, Eets, and looked to which platforms we could port it to. Eventually (you can read the full story here), it found a comfortable home on the PC, but we also ended up with a neat controller prototype to work with. Around the same time, we noticed the rise of the Xbox Live Arcade, and pitched it to then-XBLA-games-portfolio-manager Ross Erickson. It was a hit, and in April 2007 we released Eets: Chowdown on the XBLA.

We’ve also worked closely with Slick Entertainment to bring N+ to the fold, and through both of these products, we’ve certainly learnt a few things:

1. Exposure

We know who’s on XBLA. Better than that, we know they’re ready and willing to pay for games. In fact, $10 on a PC is $10 more expensive than what PC users are used to, where on the 360, $10 is an incredibly great deal. Add in the fact that the barrier to entry for XBLA is relatively high (at least compared to the PC), and you’ll find that it’s far easier to get noticed on the 360 than on a PC.

Note: I’m not going to go on and praise XBLA’s conversion rates — they’re very high, but they’re also irrelevant. It’s like comparing the conversion rate of Wal-Mart and bikes to a bike shop (the bike shop will certainly have a higher bike conversion rate, while Wal-Mart certainly sells more bikes).

Microsoft also has a decently large install base, and the Dashboard is built to show off your game whenever anything new pops up. Arcade Wednesdays has been very successful at drawing eyes to the latest products out, and Major Nelson and the like help drive even more people to your games.

At least in our experience, we have done far better volume both in terms of downloads and purchases on the Xbox than on the PC. I also suspect that, for the average game, the Xbox Live Arcade tail is longer and thicker than the casual space.

2. Good risk / reward structure

Compared to traditional console titles, games on XBLA (and any other console download service) are cheaper to make, require far less marketing, and the production cycle is cut to a third. In fact, I could probably write an entire article on AAA titles, and why it’s a tough life to make one as a third party developer.

Compared to casual games in the PC space, you immediately have more guaranteed exposure, as we talked about above. Your royalty rates are also higher (depending on your arrangements), and, not unimportantly, your profile as a studio raises significantly when you are known as an XBLA developer (few) rather than a casual PC games developer (many).

These two factors means that, as a small-medium sized studio, Xbox Live Arcade is a great place to gain some exposure with a good chance of some decent ROI.

3. Great support from Microsoft

I have to say, we were very impressed with the level of support we received from Microsoft during development. All three key points of contact (PM, Test Lead and Release Manager) had lightning fast response times — closing on the final stages of development, I would email our Test Lead at some time past midnight, and received a response 15 minutes later.

Microsoft also understands where the key barriers are to small developers and removes those barriers for you. They either handle it for you (ESRB submissions) or give you direct contact to the teams you need to know to get it done (testing and localization).

4. Easy to develop for

Developing an Arcade game on the 360 is a smooth ride: you have more power than you need, and the platform libraries are mature and easy to use. For the most part (see the note below), you can concentrate on building your game as efficiently as possible. That means both using their internal libraries (such as networking and match-making) and external third party libraries that you may have been prohibited from using because you couldn’t guarantee your target market would have good enough specs on the PC.

I’m also really looking forward to seeing how XNA turns out. I’ve seen Nick do some amazing things with it.

Note: Certification is that necessary evil that certainly no smooth ride at all. After the first time through it, though, it gets much easier.

5. Access to achievements, leaderboards, upsell features, etc

Microsoft puts a fair amount of focus on these features, and with good reason. My suggestion if you’re building an Arcade game is, think about these things early, and make the most of it. They’re great for extending your product shelf life, and obviously your upsell is incredibly important for your bottom-line.

I think many AAA developers could use a couple lessons in upselling, and building an Arcade game might not be a bad idea to do that. Too many of the demos on the Marketplace actually make me want to buy the game less than before I played it because of how badly it was put together.

---

Obviously, it’s not all a bed of roses to develop for Xbox Live Arcade. There are certainly things that could be much improved in their systems, but it was definitely a positive experience for us. Next week: I’m on holiday, but I’ll think of something interesting to write about