GameDevBlog

Mistakes To Avoid When Going From Corporate To Indie: Being 'Proactive' Considered Harmful

I heard this definition of 'Proactive' once: fire erupts in the office. The reactive worker grabs a fire extinguisher and puts it out, but the proactive worker has already installed a sprinkler system. (The retroactive worker simply does nothing and says, "I told you we should install a sprinkler system." Jerk.) 

If that's really how to define 'proactive', then it sounds good on the surface. You're always prepared for every eventuality. If we look closer, though, we realize that the proactive worker seems to always be engaged in risk management. They install sprinkler systems, they buy insurance, they consult their lawyers, they file the proper paperwork, they get permission, they look before they leap. All of this takes a lot of time and money. If one of those bad eventualities happens, you're glad you were prepared, but I'm thinking it's quite possible that the expense in risk-avoidance ends up being higher than the expense of having to put out that fire that erupts once in a while. Talking expected value here.

Coming from a corporate background, we were very risk-avoidant at Torpex. We limited our liability. We consulted lawyers. We had E&O insurance. We made everyone sign NDA's. We operated in stealth mode. We didn't show Schizoid to people because, "What if they clone it?" We often refused to pitch games to publishers because, "We can only pull back the curtain once, you know." We didn't share with other indies how our games were selling. 

So we succesfully avoided some worst-case scenarios--this is the only clone of Schizoid I know of (but would anyone have cloned it anyway?)--but who knows how many opportunities we passed up? Opportunities to network - opportunities to find clients - opportunities to build our social networks - opportunities to raise awareness - opportunities to earn favor and respect. And how much did we spend, in time and money, on the legal stuff and insurance and fear and anxiety in general?

So I've mostly been trying the opposite approach this time. I've signed contracts without consulting lawyers; I've done jams with no agreements about who-owns-what in place; I've never made anyone sign an nda; I've announced games after working on them just a few days; I've put up trailers showing incomplete work. When problems arise - like somebody complaining about the way the water looks in the trailer - I fix them, maybe. (I'll show y'all that tomorrow.)

(I do have an offsite backup, though. Losing my work is a worst-case-scenario too grim to fathom.)

I didn't even have a separate bank account for the company until I needed one to get paid.

Is this sounding familiar? It's being agile, isn't it? Maybe it's not just good for software development. Time will tell...

So, yeah. I don't like being proactive. Not if it means risk management. I like showing initiative.

By the way - I'm running out of ideas for the Corporate to Indie Mistakes thing. Anybody care to share some juicy mistakes?

And please Like Happion Labs on Facebook, y'all.

Hubris And Feedback Continued

I think I may have missed the most important thing with my last post on hubris. It's not just the feedback on your product you have to listen to. It's any kind of advice whatsoever. And you have to really listen.

Going from corporate to indie is a completely different sport, and what works for corporate game development doesn't necessarily work for indie and may even be harmful. Overlarge teams, stealth mode, and overly rigorous coding practices are just a few things that pop to mind immediately. So the overarching thing is it's valuable to listen to other indies and learn the rules of this strange new sport. You're practically starting over.

Just one example - Torpex's PR guy told us we should make a MySpace page. (Yeah, this was a while ago.) He may have been wrong on the details but he was right on the idea - we should have started doing our own social marketing / networking, whether it was MySpace or Facebook or what. Our excuses for ignoring his advice were twofold - neither one of us wanted to take on the extra work, and it's hard to get started. When you first put up a page like that you're going to start with an unimpressive number of likes and fans, and the worry is that creates a sort of unimpressive social proof. "They only have fifty likes? Pffft." But you've got to start somewhere, and the sooner you start the better. Who knows how much of a community Torpex could have built up over the years.

This is something I've learned from playing story games and reading Keith Johnstone: real listening means allowing yourself to be changed. It's not enough just to hear someone.

Even without the hubris of being succesful in the world, most people have a nearly instinctive tendency to react negatively to new information. Some management science calls it 'reactance'; child psychologists call it 'bad first reaction.' We tend to shoot down others ideas. We don't want to be changed. When I was told to not launch the Kickstarter yet, my first reaction was, "But! Out of money out of time!" But that was just an excuse. I just didn't want to be changed.

If you can recognize that tendency in yourself, you can get past it.

And, speaking of social proof on social networks, please help me build some up by liking the Happion Labs / Energy Hook facebook page. 

Mistakes To Avoid When Going From Corporate To Indie: Hubris Edition

I thought I was pretty awesome after Spider-Man 2. Thought I could do anything. And there I was on a team with other Spider-Man 2 vets and none other than Richard Garfield of Magic: The Gathering fame, making Schizoid. How could we possibly fail? So much awesome in one team!

Well, one of the reasons we could fail was because our team size was too big, but I've discussed that already. 

Another reason was pure hubris. We thought we knew better than our players. 

I've been a believer in playtesting for decades - you watch the playtests and you figure out what went wrong and you fix it. And we did quite a lot of playtesting with Schizoid. The problem was we ignored a lot of the results. People would have valid responses - specific feedback - "Feels like your ship moves too slow" or "I hate these star shaped enemies! HATE THEM!" 

(These two criticisms were actually closely related, IMO. Your avatar moves pretty fast in Schizoid, if you're talking 'how long does it take to get from one side of the level to the other' or 'how many character-lengths do you travel per second' but often they didn't feel fast when you had a skulk (our name for the star-shaped enemies) bearing down on you.)

And we would say, "Well, they just don't *get* it. The skulks are supposed to be almost as fast as you, because that's what forces you to work together with the other player, and use strategies x, y, and z. Why, the skulks are practically the heart of the game!"

And - this is related to team size - all it takes is one or two people who are resistant to change to convince the others that, yes, our way was the right way.

So we shipped the game our way and, strangely enough, the reviewers and players had the same complaints as the playtesters. Huh. Go figure.

So, here's something I try to remember when I'm getting feedback, even if I think it's wrong. And this is true not only of games but any creative endeavor - that feedback I'm getting? That's the player's reaction. Maybe they don't "get it" - maybe they're "wrong" - but somehow my game has elicited this reaction in them. And if I'm not going to fix it, I'm going to have to somehow change the game so they "get it". Because once we ship, reviewers and players are going to have the same reaction. (Side note: on platforms where it's easy to do updates it might be okay to learn these lessons after you ship...)

For example, in Schizoid, maybe an intermediate enemy, a sort of immature skulk, that would gently introduce the player to skulk-fighting, would have helped. 

So, I've convinced you of the importance of feedback. Another question is how do you get it, beyond playtesting. Sometimes it's hard to get negative criticism. (Sometimes it's as easy as posting a trailer to YouTube.) People want to be nice, and they damn you with faint praise.

One little trick I've found helps? Mention how someone else doesn't like something. "A friend of mine said this was crap but he wouldn't tell me why. I don't know. What do you think?" When I do that, people start 'guessing' why the other person didn't like it - and their guesses are, of course, what they didn't like but were too nice to tell me.

Then there's the final problem that negative feedback hurts. I've never been great at taking critical feedback. It's something I've had to do for decades in various venues, whether it was creative writing workshops or bug reports or reviews of my games or what. And always, I feel it right in my chest, though I usually put on a brave face, take out my pencil, write it down, and, if necessary - ask if they can be more specific. (And then snap at my family later for no reason.)

Here are some things we can do to process critical feedback (which I forget to do all too often):

• Set aside a time for it. If I'm going to be hanging out with my family later, don't click on those comments on youtube videos or reddit or articles about my stuff, or read those e-mails that have feedback in them, because I don't want my brain to be circling around some nasty thing someone has said when interacting with my family.
• Remember what we're doing is courageous. We're putting yourself out there, making ourselves vulnerable. We're pretty cool that way.
• Remember it's ridiculous to expect everyone to like whatever it is.
• Remember they're criticizing our work and not our selves - the quality of our work has nothing to do with our self-worth.
• When engaging with someone giving critical feedback, find a way to agree with them. If they say, "This looks like crap." we can say, "It could definitely look better, that's for sure. We'll be working on that. Is there something particular that stands out to you?" 
• Remember it's just part of life. Just as a diabetic needs to get shots once or twice a day, we have to listen to feedback, if we want to exist at the intersection between art and commerce. (If we just want to be starving artists, we don't need to listen to anybody...) 

So, speaking of feedback, I could use some feedback on this: I just prettied up the Happion Labs / Energy Hook Facebook page yesterday, and intend to maintain it more actively, and have the occasional giveaway. Now, I can't help but notice that most of you haven't bothered to Like it. Hundreds of you visit the blog every day, and the candylike button is right there, and yet only sixty-something of you have actually clicked on it. So - why not?

And, for bonus points, what are some of your techniques for dealing with feedback?

Some Thoughts On Publisher Deals

Some publishers may not realize this, but developers eventually catch on. At this point, we realize that royalties are a sham, that on paper the product isn't going to make much of a profit and we'll never recoup our advance even if the game does moderately well. Which means our interests are no longer as aligned with the publisher's as we might like: if we're going to have to recoup an advance, we either need a megahit to start seeing those royalties or, probably the smarter thing, is to do as little as possible on the product since we're already getting all the money we're ever going to see.

You can argue that we dev should still put in the extra effort to make the game great, because it's our name on the product, because it might be a megahit, because we want to maintain a good relationship with that publisher. But I'd argue that's bending over and letting yourself be exploited.

Happily, some publishers have figured out that we've figured out the sham and are no longer calling the funding an 'advance', so the developer makes money with their first unit sold. Obviously this is much higher risk for the publisher! We can expect these deals to have lower prepaids - or that the publisher will ask for exclusivity or rights of refusal. Still, I think it's great, to be connected with the fruits of our labor again. And I think we'll see more and more of this, particularly now that developers have so many options.

On another note, Chris Natsuume of BoomZap had a saying: a developer can get prepaids, royalties, or keep their IP, and they get to pick two. I'm not sure where BoomZap even found those deals, because at Torpex, when we talked to publishers, we never even managed to sign advance+royalties deals. In hindsight, we probably were asking for overlarge advances, but also in hindsight, I have to wonder why we were even asking for royalties, when we knew full well the chances of them ever paying off were slim to none. The Torpex strategy was doomed to failure: it was essentially work-for-hire, and all it could possibly do is keep us afloat until hopefully we found a better strategy. Sure, staying afloat sounds better than sinking, but maybe if you're just treading water it's time to seriously think outside the box.

The new TDD

I'm doing something these days that a younger me would have been horrified of. Trailer Driven Development: the feature isn't done until I've made a trailer of it.

I'm doing this for a couple of reasons. One, because I'm working alone most of the time and I can't just call across the office, "Hey, check out the cool thing I just did!" and have my co-workers ooh and ah. (I can have my kids ooh and ah but it's not the same.) So making trailers and e-mailing them to Paul (and often, the world) fills that need. But also because the important thing right now is to sell the vision of the game, and what better way to do that than with trailers? In fact, if I'm coding something that isn't going to make good trailer and help the kickstarter, I'm kind of wasting my time, because the kickstarter might not even succeed.

This isn't so different from what any studio needs to do when they're in the early stages of making a game. Those early stages are often not about selling the game to the end player (who couldn't care less about our trailers, they want the game itself to be delivering the awesome, of course) but selling the game to publishers, biz dev people, bosses, journalists, and others who probably don't have the time or inclination to actually play your game (and put up with some gameplay that might not-be-so-awesome as they get over a learning curve...) and what better way to do that than trailers.

The younger me would have freaked out. He would have said, "Dude, you're a game maker, not a film maker." The younger me (and the older me, for that matter) has seen so many games make teaser trailers - sometimes just for in-house purposes, sometimes not - that are often prerendered in Max or Maya! - that create unreasonable expectations in people only to dash their hopes. (Medal of Honor: Airborne was one of the most egregious.) And it really chafed the younger me's hide when people got all excited over those games. "Doesn't anyone see!? Can't they tell these games are making promises they can't keep!?"

So that's where I'm drawing a line: I'm not making prerendered footage. (I don't actually have the resources to do that, anyway...) It's all in-game footage. And while I may be putting the camera in a place it would not actually be in game, and while there may be bugs and sketchy bits that I'm not revealing - which would be a sin to not take care of in full production - I'm okay with that level of sketchiness right now.

So have a 9-second trailer: this is addressing two pieces of feedback from the weekend. One, from @MaxSzlagor, that I need more landmarks. This is a pretty serious landmark. And another, from @RossCowman, that I need to let people know what the story is. The story is it's the future, and we have gravitic technology, and this is a massive example of that.

What do you think? (You see, if you give feedback, you can get credit! Being good gets you stuff!)

Mistakes To Avoid When Going From Corporate To Indie: Team Size Edition

It's been years since Schizoid came out and I just realized, looking at my old post-mortem, that I now have a really different take on "what went wrong" then I did then. Maybe it's just that my memory's shot ... but I prefer to think I've gained some much needed perspective.

I'm not sure if I've come right out and said it before: Schizoid was a commercial failure. I forget the exact numbers, but I think it sold around 20K units in its first month and eventually plateaued around 35K. I was horrified when those first sales reports came in, and spent the next few weeks in a funk. 

Still, back then I was really proud of and excited by the team we'd put together, a big team of industry veterans. There were eight of us, although most of them only worked on it part-time. This was coming off of Treyarch's Spider-Man team, so a team of eight actually seemed vanishingly small.

But by indie standards it was huge! Indie teams typically have two or three people!

Those 35K sales - which we saw $7 off each of - (this was back in the days of the 70/30 split) - that's $245K. If there hadn't been eight of us working for a year and a half, that would have been something. 

So here's a rule of thumb for you. When bringing someone onto your team, ask yourself if the likely increase in sales they're going to bring with them will justify it. If you're a lone coder bringing on an artist - or vice-versa - almost undoubtedly worth it. 

But a full-time producer who doesn't do any of the coding, art, or design themselves? Probably isn't going to make sense for an indie team. Producer type stuff like budgeting, scheduling, IT, QA and PR (lot of two letter acronyms those producers have to do!) is necessary, but probably not a full-time job, and another mouth to feed. We were a special case there - I love Bill Dugan and Torpex was his company so Schizoid wouldn't have happened at all without him, but be warned - it is really hard for a pure producer to start an indie studio unless you're willing to learn to code or make art.

Work will expand to fill the resources available to it. Schizoid has these slick circular roll-in roll-out front end menus. Why? Because we hired a UI programmer. If we hadn't ... if I needed to do all the UI myself ... I would have told James, the artist, after he'd mocked up the menus in Flash: "No way. Sorry, they look awesome, but I just don't know where I'm going to find the time to do that." So ... did we need the UI programmer? He saved me a month of work or so, but at what cost?

You might be thinking - "But if we don't bring on people to do these jobs, then we'll have crappy UI / voice-over / music / whatever." 

Back then, it didn't even occur to us to use stock sound effects, art or music ... or crowd-source our localization ... or do our own PR. It's quite possible to save a buck - or a lot of bucks if you don't have to hire the best for every part of your game.

There's a couple things you can do instead: do it yourself even though you're not an X or use stock assets. 

If you go the do-it-yourself-even-though-you're-not-an-X route: it's okay for some parts of your game to be merely competent rather than master-level. Truth is, most indie games aren't perfect. I'm not going to name names, but there's parts of all of them that seem amateurish in one respect or another. I don't think most people would have minded if Schizoid had boring, vanilla UI in front. (One of the IGF judges even complained about them - "Why didn't you spend those resources working on the design?")

For stock assets, there's actually a pretty nice advantage to using stock assets, beyond the price: you can look through volumes and volumes of stock assets and find stuff you know you like. But if you hire a pro, and contract them to do something, and they come back with something you're not crazy about, it's awkward... (I could tell you stories about this one concept artist...)

Arg. I'm finding this article really hard to write. I've spent two hours on it already, and I have to bring my daughters to a pumpkin-carving event at school. Let me just finish up with this: this is not the Big Mistake. The Big Mistake was that Schizoid wasn't compelling enough. A lot of people downloaded it, so our PR was good, but not a lot of people converted. So you might argue that we needed to spend more resources on it, not less. And there's really no way to know for sure, but I believe that Schizoid was destined for failure; it's a niche game that for the most part only other game designers (and the PAX 10 bless them) seem to really appreciate, a game that requires co-op on a platform that got in the way of co-op. (Journey, I believe, got the co-op right, though I don't know if it was profitable either.) So, that said, the best thing for Schizoid would be to get the Minimum Viable Product out there sooner at a lower cost, (though it would also make less money, sure) learn the lesson, and move on to the next game. :P

Thoughts?

How Long Should I Work On My Game?

Doom and gloom time! Indie game development seems to be at a real low these days. For every news story about failure, I know at least another indie dev who dramatically undersold expectations but is keeping quiet about it, because of the law of social proof: if you publish a news story that says, "Well, our game tanked," a lot of people are going to think, "It was probably a bad game, then!" 

Sometimes a game developer seems to do everything right - they're nominated for awards in the IGF and other indie shows; they spend years polishing their game to perfection, pouring their heart and soul into it; they build awareness in the interim with blogging and social marketing ... and then they sell five thousand copies, making much less than minimum wage. Why do some IGF finalists turn out to be Braid or Fez, while others ... don't? You got me.

But most of you know that, as I found out by posting that 'just how hard do you think indie game development is' survey a while back. My impression then was that a lot of people thought it was a pretty viable career choice - now I know most people have their head on straight and realize that trying to be an indie game developer is only marginally more sensible than trying to be a rock star or a novelist.

Now, for the few of you who just recently decided to become indie game developers, and are hard at work on your first game ... you poor fools ... I hope you have better financial success than I have had over the past several years ... but you may be wondering, "Just how long should I work on this thing?"

Should you just get a Minimally Viable Product out the door?

Should you work on it for as long as possible, going into debt, polishing it to the highest gloss?

I can't say that 'work on it as long as possible' doesn't work. This is the Braid / Fez / Castle Crashers / World of Warcraft strategy . It has produced some amazing financial successes. It's also pretty logically sound: we have a very hit-driven industry. If you want to make a hit, you're going to need to invest more than your competitors. And it used to be the only game in town - there were no platforms that allowed you to easily update your product and respond to feedback after you shipped. 

But that's not true anymore. It's so easy to release incremental updates with so many of the new platforms that the 'it has to be perfect at ship' rule is simply not true anymore. They shipped Farmville after five weeks.

And there are so many other reasons not to go there. First, it's far from a guarantee - think of Gaksetball and Outwitters and games I won't name that spent a long time in development only to crash and burn. The risks are very high, and you're probably betting with your life savings rather than someone else's money.

Another reason is that every time a game ships and fails, a bunch of people seem to pick that moment to pipe up and say, "I knew that would fail, because you did X, Y, and Z wrong." Doesn't matter what X, Y, and Z are - maybe they're your team was too big and you didn't listen to your playtesters and you didn't do enough inbound marketing. (<cough>Schizoid</cough>) The thing is, there's about a zillion mistakes you can make and you may be reading a ton of blogs (like this one) telling you what not to do and you'll have covered your ass in a multitude of ways but you'll still probably miss some important things, and those things suddenly will be crystal obvious ... after you've shipped.

So, another argument for going for the Minimum Viable Product: because it's good to fail early. There's something about shipping that reveals your mistakes in a way that just plain old listening to feedback doesn't accomplish. 

But we here at Happion Labs (and by 'we' I mean 'I') have a different reason to ship games that aren't yet perfect: because perfectionism is an unhappiness habit. Perfectionism usually means nothing is ever good enough. You're constantly focusing on that 1% that sucks instead of the 99% that's pretty good - and that's a drag. Being a perfectionist means making yourself miserable for years, thinking, "Once I ship a perfect game I'll be happy," only to find out that your game isn't perfect or - even if it is perfect - you're still not happy for some reason. The doom and gloom can hurt morale. And you risk never shipping, because you don't give yourself permission to fail. 

So ... don't be a perfectionist. You might say, "Easier said than done!" and you might think I'm free of the devil of perfectionism, because all of the games I've made are deeply flawed in one way or another, and I shipped them anyway. (Not to mention my blog posts.) But perfectionism happens to me too. (Perfectionism bit me particularly hard with my novel, which I spent ten years working on.) So how do I avoid perfectionism when shipping a game?

• Have a deadline
  Most of my games had a hard deadline we couldn't escape: the company would run out of money or our contracts had penalties for lateness or we had a frickin' movie release date to hit. (Do I wish we could have released an update to Spider-Man 2 that fixed what most of the reviewers complained about? You bet.) So it was pretty easy not to be a perfectionist on those titles. Didn't have a choice!
  So pick some possibly arbitrary date and tell yourself that you're going to make the best game you can in the time available. Some of the indie rpg designers I know (Vincent Baker & Epidiah Ravachol) call this 'the countdown.' It's quite possible it'll blow by and you won't be finished, and you'll just keep working, but it helps.
  (I'm feeling the devil of perfectionism with this blog post about perfectionism - fortunately Cathy just called to say dinner's ready, so I have to ship.) 
• Remember The Law of Diminishing Returns
  This is even more true for software projects than other creative works, because the more you work on your game, and the bigger it gets, the harder each change takes to make, and the less value you add for effort invested. 
• Agile good, waterfall bad
  As rapidly as possible, get to a point where you've got something you can ship and make it incrementally better. Yes, you'll have an endless list of things you want to do to make your game better. Nobody will know that you intended to add HDR or network play.
• Improvise. Turn off the internal critic
  The other day I was shown a design document for a fantasy game and it had a bunch of made-up fantasy-sounding names in it, like "The Kingdom of Borgavovix" - and I was like, "Where did you get these names that sound like they come from a random word generator? J.R.R. Tolkien didn't just make shit up, he had a linguistic basis blah blah blah." That was my internal critic talking. If the product shipped and was succesful, nobody would have to know that Borgavovix was just some word that the designer made up while on the toilet or whatever - it would just become accepted canon, like, say, Tatooine. Two useful things from improv theater when you're being creative: 'go obvious' - say the first thing that pops in your head, even if it's Borgavovix; and 'yes, and...' - don't shoot down other's ideas, build on them.
• Remember You Have A Ton Of Game Ideas And The Sooner You Finish This One The Sooner You Can Get On The Next One
  Which would you rather do? Make one 'perfect' game or a whole bunch of pretty good ones? I'm pretty proud of having made a bunch of pretty good games. I do wish I made some universally loved, 'perfect' game like Braid or Portal, but I wouldn't want to erase all my other games for it...
• Remember Perfectionism Often Stems From A Feeling Of Low Self Worth
  Dropping some therapyspeak on you. Being highly critical of your work can stem from being highly critical of yourself, which, who knows, might come from highly critical parents or peers or who knows what sort of unresolved childhood trauma. It's important to remember that your work is not your worth - the game you're working on might be the crappiest POS under the sun, but you would still give the last of your water to a child dying of thirst in the desert. Wouldn't you? So ship that game (that really isn't that crappy after all) and be proud of yourself.

Thoughts?

The Eternal Cycle of Platforms

There's been a lot of doom-and-gloom in the indie game developerosphere for a while now. A lot of us corporate developers jumped ship to make indie games because we saw how succesful others had been. For me it was Xbox Live Arcade - "Look at these games! They look like they take only a few person-years to make! And they're making bank! Let's do one!" - for most it was iOS. 

The early days of Xbox Live Arcade were heady. It seemed like even mediocre games were profitable on the platform. But it took a year and a half for us to finish Schizoid. The market seemed strong almost all the way up until we shipped - a couple titles came out before us that didn't sell much but we could rationalize it away. "That was a truly crappy game." "That was a sequel." We even turned down publisher money because with our back-of-the-envelope forecasts it seemed we'd make more going on our own.

And then we shipped, and our sales were not anywhere near where we expected. A lot of that was on us - we had a terrible conversion rate. Maybe the game wasn't as good as we thought, maybe the trial was terrible, but part of it was that XBLA was maturing as a platform. There were a lot more titles on there, and if someone was only 'meh' about your demo they would go download another one.

We weren't completely naive - we knew that the gold rush days of XBLA couldn't last forever. But we did think we would make it in time.

The iphone happened somewhere in there. We weren't in any position to get in on that - too busy with our stuff. 

The iphone has been the same story. A lot of developers who took a risk when it was an unknown quantity did scary well; there followed a gold rush where a lot of the fast developers also did well; and then things petered out. I have plenty of iOS developing friends who were in the same boat as us - by the time they shipped, it was hard to make a buck anymore.

What's easy to forget is that this has been going on since the beginning of videogame development time. The same thing happened with the Atari 2600. The early crappy games on the 2600 sold like hotcakes, and then one day ET comes along and takes up a landfill and the entire game industry imploded.

(Okay, I'm not that old, I wasn't in the industry yet. Close, though - I started making PC games around when the SNES came out.)

Back then it must have been quite a shock. What seemed like a guaranteed stream of revenue suddenly dried up. They had nothing to compare it to. They didn't have this history of consoles and platforms coming and going that we have now. Videogames as a whole looked like a fad whose time had run out.

Eventually, of course PC game sales and Nintendo reanimated the corpse and the game industry looked better than ever. It's an eternal cycle. New consoles, platforms, storefronts arrive. The products in those stores/ channels do really well at first, because they don't have much competition. Those early successes even help the products build mindshare, build their brand, so they can go on to have good sales in other, cluttered, channels. But then the stores get cluttered and it becomes hard to stand out. This doesn't mean the platform's completely useless anymore - it just means mediocre and unremarkable products aren't viable. A remarkable product with good marketing, or a product that already has a strong brand, will do fine. Like Fez or Minecraft on XBLA this year.

So when I say Xbox Live Arcade sales aren't what they were, or iOS sales aren't what they were, I am not pointing fingers or casting blame. Some do blame the platform creator. "They made titles less discoverable!" they often shout. But it is not the platform holder's fault. This is what platforms do.

So if your business strategy is "We're going to make a lot of games for Platform X" you are being naive. I suppose nobody would disagree with that right now. But in the gold rush days of a popular platform, it's easy to forget. You let yourself believe that sales on the platform are always going to stay strong even for the median titles.

Allow me to suggest two other strategies.

• Seek out new platforms and be on them. Spry Fox did this - they got on Kindle, in G+, on Android, the Chrome Web Store - and not all of these attempts were hugely succesful, but Triple Town on Kindle captured the lightning in a bottle. (But it's too late now to get on Kindle and expect gold rush success. Another platform that's become too cluttered.)
  Incidentally, a mistake I've repeated twice now, (when will I ever learn?) is to mistake new technology for a new storefront. 
  Me: "Ooh. This new technology (XNA / Chrome native client) looks really cool! I'm going to make one of the first professional games (Schizoid / sixty second shooter) for it!"
  Customer: "I don't care that your game uses new tech. To me, it's just another title in a cluttered store (XBLA / Chrome Web Store)."
• Take your time making a remarkable game and market it well - let's call it the Blizzard strategy - always works, in lean times and fat times. Though it's also a terribly risky strategy, liable to leave a smoking crater if your game isn't as remarkable as you thought it was. (We thought Schizoid was pretty remarkable, actually. And, hey, it was in the PAX 10 and nominated for a couple of XBLA awards.)

This brings me to a really interesting thing: Kickstarter.

You can think of Kickstarter as a platform / store / channel. There's products in there and people buy them. But it's much less cluttered than the traditional store, because once a product is in Kickstarter, it only gets to be there for a limited time, and then it's booted out to make room for the next product. Clutter is gradually increasing a little in Kickstarter because it's becoming more popular, but I don't believe it's the nonlinear growth you see in a standard digital store where products live there forever. Kickstarter could have some serious legs.

So, me, I'm not feeling the doom and gloom. Videogame development is and always has been hard - every now and then some group of developers are in the right place at the right time and catch a big wave, and then other developers are disappointed and frustrated to have missed it - but:

• There's always more waves / platforms / stores coming. (That's why I'm making a Playstation Mobile game right now!)
• You can still have a big success the old fashioned way: make a remarkable game and get the word out.

Or both. Did I mention sixty second shooter Deluxe is going to be the funnest dual-stick shooter evar?

What's Getting Through Your Funnel?

Linked up a couple of my old talks on the blog. I personally don't really like watching talks on the computer - too slow! - I'd almost rather read a transcript. But if you're not like me, there they are.

But skimming over my talk on Prototyping and New Product Science - I'm honestly not sure how much of that I still believe. 

There's a couple of strategies you can use when developing new games:

"Throw stuff at the wall and see what sticks" - the idea here is that you put a lot of minimum viable products out there, looking for something that'll catch fire. We could call this the Rovvio strategy - the story is, after twenty-something tries they made Angry Birds.

"Spend a crapload of resources" -  the idea here is that nobody's going to care about your crappy little minimum viable products. You need to build a great game, spending years on it, and build an audience at the same time. (So in some ways it's the same, because maybe you put out a crappy minimally viable alpha version to start building that audience.) The Minecraft strategy.

So my talk more-or-less says to combine the two. Make a bunch of prototypes to see what's promising, and then spend a crapload of resources to turn that into your shipping game. Make some experiments, find your Tower of Goo, and turn it into World of Goo. One of the places where my talk falls down is in its methods: determining 'what's promising' is basically a gut-check by senior management. Would they recognize a Minecraft or Sims if the minimally viable prototype was in front of them?

Putting a free version out on the internet is one way to see where the traction is, but what if none of your products have much traction? How do you know how much traction is enough? Most of us aren't going to have a Tower of Goo that goes viral - we're going to have a handful of stuff and some of it will be more popular than others but none of it will set the internet on fire.

While doing that talk we were working on a prototype with Microsoft. We actually did a couple different prototypes, and my favorite got cancelled after weak testing. 

Now, less work went into my favorite than the crowd favorite. It wasn't ready to be shown. But we had limited time and opportunity to get it in front of people. So we ignored my gut feeling that my favorite was the good one and went ahead with the other.

(And what happened to that project? It got greenlit - but then the project was handed to a different studio. Nice. And the other studio messed it up and it got cancelled, deeper into the funnel.)

The problem, I now see, is that in trying to reduce game development to rules-of-thumb and New Product Science was I was trying to bypass my brain. I've been making games for a long time and I should just trust myself to make the right ones.

I'm not getting rid of the idea of the funnel - I've got all these prototypes (and one minimally viable product) in the funnel: We're No Angels and Numbergun! and sixty second shooter and Energy Hook and Total Party Kill and a couple more that I haven't put Out There.

Where I'm making sure to use my brain is this: We're No Angels and Numbergun! are the ones that have gotten the most press. The old me would say those are the ones that are closest to catching fire. And yet I'm continuing to work on and promote sixty second shooter and Energy Hook. Because those are the strongest games. There's clever design in them. The others just have catchier visuals.

Is there a take home lesson here? Maybe it's, "Don't Let Your Strategy Override Your Common Sense." Hmm, sounds like common sense, doesn't it? But I bet people let their strategy override their sense all the time. I suspect that these funnels and greenlight systems and new product science that big game companies indulge in nerf the minds of their best people.

How To Be Positive - In Performance Reviews And Life

I'm trying Monte Cook's A+ thing this month - the 'no negativity' thing. I like to think I'm generally pretty positive on the blog anyway - for the most part, my "Notes On..." articles, for example, are to call out the elements and mechanics I like in different games. But for the rest of this month, I'm going to try to 100% it.

Which is tough, actually, because I seem to be hardwired to find flaws. Which is not a happiness habit. But I'm suddenly reminded of something: performance reviews.

I haven't had to give performance reviews in years, which is one of the many things I love about being indie. But when I did have to give them, I had a trick for keeping them positive. Like I said, I'm hardwired to find flaws. When I got ready to write in the comments section of a report's performance review, whatever little way they had let me down that year would be the first thing to pop into my head.

But, instead of writing that down, I flipped it around and made it a positive. And then wrote that positive on everyone else's review.

Programmer X's code was sloppy - had a high bug rate? I wrote on programmer A, B, and C's performance reviews that they had low bug rates. Programmer Y needed their hand held? I wrote on programmer A, B, and C's reviews that they showed initiative. Programmer Z liked to run a 90-yard dash? I wrote on programmer A, B, and C's reviews that they saw things through to the end.

As I was thinking about this article I realized I could apply this technique in other places. It's hard for me to give praise - but if one of my daughters is driving me up the wall, instead of criticizing her, I can always turn around and praise the other one for how well behaved she is. (Hopefully not right in front of the first daughter though, how lame would that be.)

I can also turn the content of negatives into positives. Yes, it can be frustrating when my daughter takes ten minutes to clean up her board game. But I can praise her for how conscientiously she's organizing the pieces.

Some people may feel a bit iffy about this practice. Is it a little bit dishonest? Shouldn't I just say what I feel? Wouldn't my reports want to know what's bothering me about them, so they can fix it? I know when I ask for feedback on a game I'm making, I want the brutal honesty. (I hate it, but I want it.)

Well, maybe, but performance reviews are the worst time for that. If a report is so sloppy with their code that it's a problem, as their manager I need to tell them right then. I shouldn't wait an average of six months for performance review time to come around.

And if the problem isn't a big problem? If it's just a nitpick? Then why bring it up at all? The reason you're a valuable part of the team is probably because of a few big positives - for the most part I'm willing to take the bad with the good, do my best to ignore those nagging nitpicky things. We've heard how a ratio of five positive interactions to one negative interaction is important at work (and in marriage) - so I'll leave as many negative interactions as I can off the table.