So you come across a neat-looking new game on Kickstarter. It's got fancy concept art, it has some big names involved, and their pitch is really convincing! Surely this will be the game of our dreams?
Well, maybe not. The failure of the Yogscast game is just the latest in a long string of high-profile kickstarter busts. Obviously, backers should do their due dilligence and scope out the project before pledging, but if we're honest, most of us don't have time to run the numbers and dig really deep. So I propose this simple rule of thumb test (I didn't create it, but it has served me well), I call it "the two-out-of-three test":
A score of one or zero means the developer is playing it safe, but keep in mind failure is still possible (this is game development after all). A score of 2 means it's risky - and that's not a moral judgment, sometimes it's important to take risks, it just means you should understand there's an even-or-better chance of this game not shipping. A score of 3 means you should expect the project to fail.
1. Is it a NEW TEAM?
Have these people ever worked together, and have they ever shipped anything? This is probably the most important question of all. Even if the members are individually talented, shipping is a team sport where synergy, cooperation, and most of all communication are far more important than any individual skillset.
Obviously, a new team composed entirely of industry veterans is not the same as a new team composed entirely of fresh-faced newbies who have never worked on a game at all, but the point still stands. Teams that have worked together in the past and already know how to get a game out the door are much more likely to do it again.
2. Is it a NEW DESIGN?
Have these people ever worked on a game in any way similar to this one before? This question probes how well the team understands the design risk. If you've only ever made 2D strategy games, you will have a lot of unpleasant surprises in store when you try your hand at a full-3D open-world exploration game.
Of course, sticking only to the kind of games you've done in the past can lead to stagnation; we need people to take risks sometime, which underscores this point:
It's easier to pull off a risky new design if you're not also saddling your project with engine and technology risk.
3. Is it using NEW TECHNOLOGY?
When it comes to technology, there is no substitute for experience. Programming languages have learning curves, engines have bugs, middleware has leaky abstractions, and it's a safe bet that a bunch of things won't work the way they're documented (if there's any documentation at all). Nothing beats someone who knows the details of the tech inside and out the way an experienced river-rafting guide knows every rapid, waterfall, and sunken rock.
Every single one of these points brings its own amount of overhead - teams need to gel, designs need prototyping, technology needs learning. The more overhead a project has, the more time and resources are spent just dealing with that rather than dealing with the game.
Of course, my simple 3-point list isn't a substitute for a hardcore analysis, but it should be pretty easy to do just by scanning the front of a kickstarter pitch and doing some light googling. As for people who are running kickstarter campaigns, I strongly suggest you feature your answers to the "two out of three" test right on your pitch page, and if your score is two out of three, you'd better have a good argument for how you're going to overcome that risk if you want my pledge.
...
"But Lars! Aren't YOU making a crowdfunded game?"
Yup! I guess it's time to put my money where my mouth is and subject my own project Defender's Quest II: Mists of Ruin, to the test. Here's my super-biased self-analysis:
1. Is it a NEW TEAM?
Nope, it's the same (core) team from before. We have a few new contractors and special guests here and there (including musical superstar Nobuo Uematsu of Final Fantasy fame who is doing our main theme), but the core team remains the same as in Defender's Quest 1: Myself as programmer, Anthony Pecorella as designer, James Cavin as writer, Kevin Penkin as musician, Karen Petrasko as lead artist.
The day to day workflow for the new game is very similar to the old one - I sit down at my computer and program from 8 to 5, and coordinate online with the other team-members as needed.
And before our current core team assembled to ship Defender's Quest: Valley of the Forgotten, Anthony, Kevin and I shipped CellCraft, and before that James and I shipped Super Energy Apocalypse. So we like to think we know what we're doing.
2. Is it a NEW DESIGN?
If the "2" in the title wasn't a dead giveaway, this is a straight-up gameplay sequel to the original. We're taking the "Final Fantasy" approach to sequels - evolve the mechanics and experiment with some new gameplay ideas, but with a fresh new story and world each time.
We've learned a lot from the first game and we have a solid grip on our particular variant of the Tower Defense / RPG genre, which I've come to calling the "Tactical Defense RPG".
3. Is it using NEW TECHNOLOGY?
Sort of. The original game was written in Flash Actionscript and published in Adobe AIR, but the new game is being written in Haxe/OpenFL. The programming languages are very similar in syntax, as well as the coding pipeline (I'm still using FlashDevelop, the same IDE I used for the first game), but there are definitely some differences. We made the switch to Haxe because, like Unity, it lets us target multiple platforms from the same codebase (it does this by cross-compiling to the native language of each platform, be that C++, Actionscript, Javascript, etc).
The main thing that made me jump to Haxe was the HaxeFlixel engine. We'd been using the ActionScript version of Flixel for Defender's Quest 1, so having the same basic framework available in the new system meant my Flixel experience mostly transferred over intact.
Our overall score is 1/3 -- most of our risk is in the technology sector, and we've got a solid plan for working around that. Now that I've been working with Haxe for well over a year and am regularly contributing code back to HaxeFlixel, I feel confident.
A word on consoles
Consoles have become more open that ever before, but don't underestimate the complexity of shipping on one. You're dealing not only with technology risk, but also tons of paperwork, contracts, the cost of dev kits, not to mention you have to play completely by the platform holder's rules.
We are looking into console support for DQ2 very seriously (we've already made some really good progress) but we have never promised we're going to ship console versions of the game, let alone a simultaneous release with the PC version. There's just too many unknowns. I'm pretty sure we can do it, but I want to keep expectations among our backers as low as possible.
So there's my simple little test for quickly analyzing the risk in a crowdfunded game. Hope it helps backers and game developers alike!
This is a companion discussion topic for the original entry at http://www.fortressofdoors.com/will-that-crowdfunded-game-ever-actually-ship/