Happion Labs GameDevBlog

Mistakes To Avoid When Going From AAA To Indie: The Movie

Here's a cautionary tale on Indie Game development from Matt Gilgenbach. Some people think that - particularly with console development - you'll get out of it at least what you put into it. Not so - my experiences with Schizoid and Matt's experiences with this say otherwise. There's no sure thing in indie game dev.

http://www.gdcvault.com/play/1017963/Obsessive-Compulsive-Development-Retro-Grade

And it also goes to show migrating from AAA to Indie is harder than you might think. It is almost a completely different sport, seems like. 

A couple possible 'mistakes' that Matt didn't call out explicitly (or if he did, I spaced at that moment) that it's easy for us ex-AAA people to fall into:

Why are you writing your own engine? 

I did this with Schizoid and with the Richard Garfield game that endlessly chased publisher funding to no avail. Oh yeah, and Sixty Second Shooter. With Schizoid and Sixty Second Shooter it was arguably the right call, because it let me have "first game with such-and-such tech" PR stories, but who can say for sure. Anyhow, my own internal logic went something like this - and maybe Matt shared it: "This is a really simple indie game. Therefore it'll be easy to write our own engine." And then later, when we decided to add awesome post-processing shaders or network play or this that and the other already solved feature, it became a burden. (And another thing that led me down the path is it's also fun to write your own engine.) But you have to ask yourself: are you a game developer or an engine developer?

Obviously there are plenty of hugely succesful indie games out there where they wrote their own engine, so it's hard to say making your own engine is clearly a mistake, but you also have to wonder - would given succesful indie game X *not* have been succesful if they used a pre-existing engine?

What's Your Relationship To Feedback?

I have a difficult thought to articulate here. It's not cut-and-dry. I keep rewriting this paragraph as I think about it. As indie developers showing our work to people, whether it's just youtube videos or alphas or showing it off at conferences and contests - we're going to get more feedback on our work than we could respond to in our lifetime. That can be murder on a perfectionist. A lot of people-on-the-internet complained about the graphics in my first trailer for Energy Hook, and since I've became perhaps overly concerned with making it look better, even though the game isn't supposed to be about the graphics, it's about the gameplay. The graphics are supposed to be a means to an end and while I'd like them to look distinctive and consistent and not bad it's certainly a mistake for me to waste time trying to compete in that arena. And yet I have been anyway.
On the other hand, a place where feedback can be really beneficial is when there's some feature or fix that I think might be important - and none of the players I show the game to seem to notice. There can be a massive time savings there as I punt on the feature or fix that nobody cares about. Matt might have saved some serious time not working on things if he resisted the temptation to add features that nobody asked for?
So, you need feedback, not just to find out what you should fix but also to find out what you don't have to fix. But some stuff that feedback says you should fix - you shouldn't. And that's the really tough part. How to decide. Maybe asking- "Is this going to be one of my actual players or is this just a random internet troll who isn't going to play my game anyway because he just wants the next CoD?" -is a good place to start...

And speaking of feedback, I'm looking for more. I'm selecting just a few people to look at an early pre-alpha build of Energy Hook to figure out what I should fix before showing it to journalists before the Kickstarter. If you'd like to, and have a few hours to play it and write up some thoughtful, specific feedback, comment here or send me an e-mail (jamie@happionlabs.com) and I'll put your name in the hat. Let me know what kind of computer you have and whether you're a mouse/keyboard or gamepad sort of person.

Unity 3D And Teamwork: Adventures In Source Control

You'd think with a name like "Unity" it would be easier to use on a team. I've heard people complain about Unity's source control capabilities before but always assumed they were solvable if we used something external that had binary file locking, like SVN or Perforce. (Or even SourceSafe, shudder.) 

Once I tried to synchronize work with Paul, though, I realized it's not so simple. Turns out that Unity doesn't respect the read-only flags on your files. So even if your source control package sets your binary files to read-only while someone else has them locked/checked-out ... Unity will let you go ahead and modify the files anyway.

The read-only flag is how I've made sure team members don't bash each other's changes ever since we first used SourceSafe with Die By The Sword at Treyarch in 1999. Unity is the first tool I've used that doesn't seem to respect the flag. 

Because of this, it seems like everyone I've talked to who uses Unity on a team has their own set of voodoo for dealing with this stuff, whether it's "whiteboard checkouts" or just living with the occasional collision.

So, after Googling and searching Unity forums and spaces for answers fruitlessly, I contacted them directly, and they sent me a plug-in. (EDIT: forgot to include the script. Here it is: RespectReadOnly.cs )

I haven't tried it with Unity Free but it partially works with Unity Pro. It's intended to be used with Unity Team, which is an additional $500 and out of my price range, where it will grey out things in the inspector you shouldn't be able to edit. But even without that, it won't write over readonly files and with a little modification (which I did) it will protect you.

So hopefully they'll work on this more and roll it out for those of us not using Team, because it seems weird to me that we should pay an additional $500 per seat for a single function. If you're using Unity with someone else, or plan to someday, please vote up the issue - I just used all my votes on it - so we can all work on a team easier sooner.

A System That More Or Less Works

In the interim, here's our source control policy and system. This is what we do, and you could do it too, or use it as a starting point. It took me a lot of trial and error to get here, so hopefully this will save other people some time.

I'm certain I spent more time working out our source control system than I actually would have spent redoing work after collisions between me and Paul. Whoops. But I've been a source control enthusiast ever since 1999; old habits die hard. By the sword.

Anyhow, my loss can be your gain.

So:

We use Unity Pro. (This is such a good deal. You get so much: static batching - i.e. much faster render times; postprocessing effects; and more, all for $1500 / person. Even if you're just a hobbyist it seems worth it - hobbyist photographers spend more on their camera equipment, yeah?)

We use Edit->Project Settings->Editor->Mode->Meta Files and Asset Serialization->Force Text. This means we don't have to lock our prefabs. Our experiments with simultaneously editing prefabs on separate machines turned out great. 

We put the RespectReadonly.cs file (below) in our Assets/Editor directory. That makes it go.

We use Unfuddle hosting and SVN. (We tried Assembla and Perforce, which was a tooth-grinding ordeal, and Assembla and SVN, which kept disconnecting in the middle of large checkins.) Under a gig Unfuddle is free, although we expect to hit that ceiling soon, and it almost never makes you have to think.

Because we've set External Source Control, we don't need to check in the Library directory. And none of the individual files (.sln, assemblies, etc) in the root directory need to be in source control - they get generated by Unity if needed. 

So it helps to figure out how to ignore files with SVN. It's kind of tricky with vanilla command-line SVN, but SmartSVN on the Mac and TortoiseSVN on Windows have some built in extra stuff that makes it easier. (On SmartSVN you can right click on a folder and go to Properties->Ignore Patterns and ignore things like LightMap*, Library and .DS_Store. TortoiseSVN has tsvn:needs-lock.) We also don't bother adding the LightMap files. These are things we'll generate on a more as needed basis, and don't want to use up the depot space with them. 

We set svn:needslock on our .Unity and binary files (.fbx, .dae, .jpg, etc). SmartSVN makes this easy - in Project->Settings->Locks set "needs lock" for binary files, and make Binary Files include *.Unity.

And then we could add and commit our files. (With SmartSVN, if you've forgotten to set "needs-lock", it's pretty easy to set a bunch of files en masse: set it to show files from subdirectories and filter on the extension you're looking for, select all, and set it.)

And once it was all in there, the hard part was over. We can now get the latest revision and work on things in Unity. If we're changing scene files and binary assets, we also Lock them so nobody else is working on them at the same time. 

Even if we both need to work in the same scene at the same time, it's doable as long as one of us is only changing prefabs.

Hope this helps other people, so they don't waste as much time as I do. Good luck! And if you have any questions I'm happy to answer.

Side Note: Why Not GIT or Mercurial?

You may ask, "Hey, Jamie, why not use the new hotness?" I used Mercurial for sixty second shooter, and appreciate it, but (so far) GIT and Mercurial are not intended for file-locking, and file-locking is the number one reason I want source control right now.

Having a history of changes is nice. Being able to make tinier commits to a local repository that I then push to the master server would be nice, but is pretty far down on my priority list. Preventing Paul and myself from accidentally working on the same scene file simultaneously is huge.

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?