Things I Don’t Care About

I’d like to address something things I don’t care about and I think if you want to make games for a living you should also not care about. Please note that I’m generally referring to small indie devs here: trying to make the next Halo is going to run your face into some serious issues this post isn’t really trying to tackle.


First to Market

This was sparked because I recently read a game postmortem bemoaning missing the “local multiplayer train.” Ignoring for the moment the many other issues that make that comparison disingenuous, first to market for video games barely matters at all. The entire premise of an advantage for first to market involves being able to stay ahead of your competition; You’re not doing that in games barring some enormous technological advantage or something like a mountain of cash.

There are successful video game companies, big and small, that make a living polishing the heck out of their products and being good at customer service. I don’t want to say Blizzard never innovates, but they’re widely known for taking pre-existing ideas and polishing them to a mirror shine. They’re also known for taking their sweet, sweet time.


It’s Too Nichey!

Unlikely. You’ve just not managed to convince those players your game is worth paying for. You’ve got to be really, really narrow in focus in order to claim your potential market is just too niche. I’m going to go out on a limb and suggest that if both Firewatch and Papers, Please can do well so can your game, although perhaps not on that scale.


You use MMOFPSRPGRTSMOBA! It’s Super Saturated!

Your game is not getting priced out of the market because there are too many games in the same genre. Do you know why we have these large genres? Because they’re popular and people keep making things in those genres and people keep consuming them. I’ve never met a gamer who loved a particular game who would refuse to buy a game similar in genre and quality. There might be some friction due to pricing, but I think it’s fair to mention that gaming is increasing in popularity; there’s a whole lot of people willing to spend a whole lot of money on games they would enjoy.

Aside: There is something to be said about standing out, and being unique can make you stand out. But being in genre X is not going to be the primary factor in a game’s failure.


Visual Arms Race

Don’t care. Couldn’t care less.

I don’t mean visuals don’t matter – they do. But in an aesthetic sense. Not a photorealistic or graphical fidelity sense. Not a can-I-burn-your-latest-graphics-card-to-the-ground sense. There is a general expectation that games should look better as time goes on, and fair enough, but graphics are time consuming and expensive. As a small developer your advantage is not in competing with AAA or middle tier “AA” budgets. Your advantages are being nimble: you can pivot faster for cheaper, focus on details that those massive open world games can’t, and generally do a better job polishing your game because your scope is smaller and your marketing message tighter.

Aside: Ever notice that games aiming for photorealism don’t age well? Super Mario World still looks great. Just sayin’.


UE4 versus Unity versus C++/SFML versus…

Use. Whatever. Can. Make. Your. Game.

There are considerations regarding technology, your personal/team’s experience and so forth, but overall for the kind of your games small developers make it does not matter.

Aside: Someone’s going to get on my case about performance on a specific framework on a specific platform, and my response is I don’t care. Find a solution and use that. Don’t waste months debating.

I use Unity/C#. I think coding in C++ is significantly slower than C# and that’s a massive negative. My current game could be made in UE4. It could be made in the 3D version of the engine I used for my last game.

Did you make your game? Yes? Good, I don’t care what you made it in. You made it work so give yourself a pat on the back.



I know that this is traditionally a point of concern for game developers. I once ran a sale in the middle of a big game developer event and other developers were like, “Huh?” Sale did great.

Timing is important; Anyone who grew up on console platformers knows that. But overall I prefer a long, slow marketing burn. It’s great for four reasons:

  1. It provides you with a long time period to simultaneously develop and market.
  2. It reduces the overall impact of one specific launch date on your game sales.
  3. It gives you data on who your core users are and what they want, and how to retain those who are not.
  4. It gives you time to adjust your price.

Aside: Pricing is very important. VERY. IMPORTANT. Set up experiments and collect data. Perform your due diligence. Do not listen to people who tell you to just go lower because more people will buy and it will “obviously” result in more revenue. Also don’t let these ding dongs convince you they are not ding dongs:


In case it’s not abundantly clear, it makes no sense to let people who don’t like your product determine its price. Crocs are worth zero dollars to me; if you sell Crocs you should not price them at zero dollars because of that.

Similar to my last game I’ll be soft/alpha launching my current game. I don’t expect the initial months to be amazing, sales-wise. That’s fine since this is fact-finding and community building. The money will come, but later.

Aside: This may not be applicable to all types of games. Short games, or games not designed for replayability will most likely suffer from this marketing and development approach. In those cases your launch is significantly more important and you should not be taking this section’s advice. Uh, except that middle bit about pricing. Take that advice.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.

Working On Working

I’ve been called a workaholic by other workaholics who don’t consider themselves workaholics which is probably not a good sign. I consider myself a programmer and track my hours spent working and employ various metrics because I like measuring things.

From 2010 to 2015 I averaged about 15.4 hours of work a day (that’s 5,621 hours of work a year). Around September 2015 I “owed” myself over 365 days (over a year!) of weekends – Saturdays and Sundays where I worked the whole day.

I’ve been trying to work a lot less these days. The wake up call was when my father, previously a workaholic, told me I was working too hard. When the hardest working person in your life tells you that you might be taking the thing you know them for to an extreme you tend to take notice.

I took a vacation from September 2015 to January 2016 where I only averaged about 3.8 hours of work a day; I bought a work laptop specifically for the trip so clearly I’m not doing this cold turkey. It was fun. I spent a lot of time with my nephew, who is a little hellion, and ate way too much food. My nephew also kept begging for way too much food.

It’s late January now and I’m still catching up on work my contractors did for my game while I was off playing uncle, but it cleared up some issues I had floating around in my skull.

Task-Based Scheduling

It’s always better to think about work in terms of tasks rather than time. You can’t divorce the time aspect of tasks, but it’s just better to say “I got tiny task X done today” rather than “I worked eight hours today.” For one thing it’s just more meaningful – I doubt your commit logs say, “Worked for eight hours on [System Y].” For another when you’re talking about day to day REAL WORK TM getting done, the time scheduling doesn’t even really matter. No, really.

I mean I knew this years ago. I think most people (apart from managers) understand this intuitively. But my four month vacation also made something a little more clear to me: don’t jump the gun if you have the time.

I don’t mean if you find yourself with a windfall of two hours and you can hammer something out on your todo list to not take advantage of it. I mean just don’t do this consistently. I’m not talking about burnout which is a separate and very real thing. I’m talking about clarity of purpose and avoiding redundant work.

Maybe this is different for other programmers, but I frequently find myself implementing a system, tying it in with relevant systems, then doing a bunch of filler work to get everything working smoothly. Unnecessary things. Things that may change. This isn’t about pre-mature optimization, this is about not knowing at a given point in time what is actually needed. It’s more like, “Hey, this thing knows about [some value] now. This should tie into the GUI, right? And it needs code-specific handling when interacting with…”

It’s subtle and annoying when you realize you’ve wasted your time, like when you made an entire inventory system before realizing inventory is a real crappy system for your game and you could have figured that out just by hard-coding a healing potion and a sandwich.

This also means your task list really needs to not be things like “Make [Massive System X].” It needs to be broken down into very small, bite-sized tasks you can accomplish in a relatively short amount of time. Personally I think that if you can’t do it in 15-30 minutes you haven’t thought it through or broken it down enough yet.

Aside 1: As the exception that proves the rule, if you’ve done something frequently enough and you know for sure you can slam it out really fast without thinking too much, you can put giant-looking items on your todo list. For example coding up a simple grid-based level generator for a roguelike game is pretty straightforward for me these days. I don’t need to break that down into room/corridor/placement/digger/whatever components anymore on paper or in my head. A benefit of experience you can apply to the things you know a lot about.

Aside 2: If you’re coding a bunch of systems that you don’t really like but are too attached to to throw away, this is also a Very Bad Thing TM.

Maybe I’m just really concrete sequential and this all sounds ghastly to you. Sure, and I guess it depends a bunch on what kind of game (or non-software project) you’re trying to make as well. I don’t work well in chaos, but maybe you do.


Vacation What?

Right. So my four month vacation had me using a laptop which, though quite nice for development, was not up to my main dev machine standards. So this limited what things I could work on. I ended up spending a lot of time cleaning up old code and scripting for side mechanics because even my old Mac Classic let me type text reliably.

But four hours feels a lot less than sixteen hours a day, and when January rolled around I felt like I had a lot of catching up to do. Turns out not that much catching up to do.

It’s not that I got so much done, it’s just that working in a lower capacity actually made me focus on what things mattered and what didn’t. You know how if you have a set budget you start buying random crap? Well it’s kind of like that except you’re budgeting with time. Hey, I’ve got sixteen hours of work to do today; Let’s do a buncha crap.

I consider myself fairly disciplined, particularly regarding issues of prioritization, but apparently I’m not. A review of my current project since inception revealed that I wasn’t actually doing much better at doing real work that stuck around. I had previously reviewed my last game and discovered that I spent [EMBARRASSINGLY REDACTED] percentage of my time on systems that just never made it into the final game.

Turns out the percentage from my last game had aligned almost exactly with the development of my current game. Awkward. But the work I had done recently while on vacation? All in the game, at least currently.

I know, more current work is more likely to still be in the game. Obvious, right? Except I went back to a one week period I took a working vacation on my first game and reviewed what I had done during that period. Turns out all of that stuff, written about nine months before the game fully released, made it into the final game.

Well shit. That seems like a pattern.


I Hate People Who Waste My Time And I Really Hate Myself Right Now

Without exact numbers on how much work makes it through to final release it’s hard to determine how much to restrict your own work time. I mean yeah, maybe if I work 25% fewer hours 100% of that work gets through, but how does that work exactly? If four hours a day means 100% (haha yeah right but argument’s sake okay) of work is effective, does eight hours mean the first four hours is 100% and the last four is like 50% or what?

It’s probably some weird graph curve but that’s actually not that important. It’s not important because I know three things:

  1. I can’t get the bare minimum I need done for my game if I only work four hours a day (28 hour work week). Not if I want to release in a reasonable time frame.
  2. I prefer to finish sooner rather than later.
  3. Any amount of work between 4 and 16 hours a day is better than 4 or 16, assuming I estimated the time of tasks reasonably accurately.

I think this means that I should be trying to schedule tasks per day that I think will take me four (or a little more) hours a day, every day for the length of the project, and more or less stick to it. Inevitably some work will expand into available time, because I suck at estimating and because some things crop up that you didn’t plan for, and if not that leaves me time to expand on non-bare minimum tasks.

It’s a weird way to approach a creative project, perhaps, but I also have the benefit of making turn-based tactics games, and so spending more time on the core stuff has a lot more value than if I was making a game that really depended on loads of new content (e.g. a fully-fledged RPG.)



  • Populate your todo list with the bare minimum, core things your game needs to be the game you want it to be.
  • Make a schedule of the tasks you need to get done every day until release (and maybe post-release!)
  • Stick to it and use extra time to work on extraneous stuff.

P.S. I’m down to about 60 hours a week on average for Steam Marines 2. Progress.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.

Markets and You


What Games Are Not

Games, as @retroremakes paraphrases my mini Twitter rant, are not commodities. This is a good thing because commodities are goods or services that have substantial fungibility – that is they can easily be substituted.

Copper is a commodity. Crude oil is a commodity. Tea leaves, coffee beans, and sugar are commodities.

There is only one Diablo 3. There are similar games, but the fungibility is low; Torchlight 2 is not a proper substitute.

You can absolutely have games that act as commodities, such as high accuracy clones within a mobile market, but we’re not going to discuss those here, because you weren’t so foolish as to try and make and sell one of those, right?


Why Does This Matter?

Within the last few months I’ve been distressed at an appalling spate of poor analyses within (indie) game development. They range from urges to aim for small games that earn 1,000% profit, citing indie game development bubbles, and more recently suggesting game developers are in dire straits because of an impending “indie mass extinction event”.

I’ve already addressed most of the doomsaying in previous posts – I’m not interested in lending any more page space to that stuff. Instead I will talk about what you can do if you want to sell commercial indie games successfully.

Aside: The insufferable phrase “it depends” is implicit throughout most of this. Anyone telling you they have a hard and fast process to strike indie game oil 100% of the time is pissing in your sugary breakfast cereal. This doesn’t mean it’s all up to the roll of some dice, it just means you need to focus your attention and time and effort on elements you can actually control. You know, like most of life’s endeavors.


Understand the What and the Who

I’ve said that obscurity is the biggest obstacle to indie devs and this is still true. The key to this is knowing, very deeply and assuredly, what you are making. The lock is who you are making this thing for.

There are a myriad of ways to fail:

  • Having a poor trailer (e.g. 10 seconds of your pointless company logo, 10 seconds of buildup, you get the idea.)
  • Technical issues like crashing or corrupt save files.
  • Uninteresting game loops.
  • Inappropriate pricing.
  • Marketing/PR issues.
  • Poor launch due to timing or other factors.
  • Your payment processor/distribution platform went AWOL.
  • You can’t sell your game because your cat chewed through your website server cables.

Et cetera. Warner Bros. sure did underestimate how negatively PC gamers would react to all those technical issues – the backlash with Steam refunds and Batman: Arkham Knight was sincerely astounding to see unfold.

So understand what your product and/or service is, first and foremost. I don’t mean in broad strokes. Don’t tell me your game is “A pixel art platformer.” Tell me your game is, “A cooperative precision platformer with backstabbing elements in a rich, colorful water-moon world.” Or something like that. If you can’t even excite yourself with your game description go back to the drawing board.

I really mean this because you’re eventually going to try to sell someone with the concept of what your product is. Nothing will kill your sales faster than a description no one has any interest in (aside from no one knowing about your game!)


Move and Shoot Game

That’s what my game Steam Marines 1 is, and what Steam Marines 2 will beSure, there’s window dressing: Oh, you’re controlling steampunk marines on a spaceship fighting robots and aliens! Oh, there are roleplaying elements and you have character portraits and stats and armor and weapons and, and, and…

But at the end of the day the game is about moving and shooting. If someone does not enjoy moving and shooting, they will not enjoy either Steam Marines game.

Aside: You’ll note that shooting already implies a bit of narrative sugar on top of the game mechanics. Shooty games are different from point-and-click adventure games although you’re generally still placing a cursor on a thing and clicking.

It’s important to sell directly to your audience if you’re an indie developer. This is why we should be happy games are not a commodity. You will spend your time explaining in loving, but concise, detail why your game is not SPACE MARINES IN SPACE 6: THE SPACENING. You will explain this one awesome core mechanic that binds the game together. You can sell the narrative – steady progress as enemies close in all around you, or a procedural world to explore and burrow and build, or everyone is playing mind games with your character and you have to escape a web of lies.

And it’s more important than ever that you sell them on, and deliver, a real idea. Not some carbon copied anemic version of an idea. Forget Steam refunds – if you want to do this long term you should want to cultivate 1) a core user base, and 2) a reputation for producing quality.

Aside: When I say quality, I mean quality to the people who understand and want and are willing to pay for your product. You can’t please everyone, but there are definitely some people you should want to please.

Find a niche, a specialty, and fill it while ringing a bell. You are not selling salt for fifty cents a pound, you are selling BEST F%$^ING GAME OF THE YEAR 2016 FOR $9.99 USD, COME ONE, COME ALL.


Effervescent Effects

There are market realities to face. It is unlikely your zombie survival simulator is going to stand out from the crowd of other zombie survival simulators. Yes, even if it’s a Souls-like. This does not mean the games market is over saturated, or that you can’t sell zombie survival simulators. I’m just saying you’re going to run into some competition in that market.

I promise you one thing: you are not anywhere near market saturation for your tiny indie game. Your problem is the exact opposite – you haven’t got anywhere near the sets of eyeballs to glaze over your game. Now there is a cost to getting more eyeballs on your game, and if your potential market is too small this can mean it’s not cost effective to try and market more.

Aside: Early on when I was developing Steam Marines many people (other developers!) remarked on my amazing incompetence for trying to make a commercial roguelike. These days commercial roguelikes are thriving and those sorts of people now call me a sellout. What-the-fuck-ever.

But as Simon Roth says, it’s way cheaper to market a game a bit more than to make a whole new game. Also, you can probably use the practice.

There are many ways to stand out, and from my last five years of observations most indie developers do next to none of them (including myself when I first started, I might add.)

Aside 1: You may ask how I could possibly know that last bit, and it’s because sometimes I’ll just straight up ask them what they did for marketing/PR. The short version is tweeting a few times and posting to Screenshot Saturday is not a good marketing plan. Sometimes you get sad public accounts of developers basically admitting they did nothing.


(Edit: Raigan Burns, a developer of N++ and author of the above linked Neogaf post, emailed me and explained that the N++ team actually spent “about $50k and 3 months on marketing through the course of the project”. So perhaps N++ is more an example of marketing gone wrong as opposed to zero effort.)


Aside 2: “Build it and they will come” is bullshit. That’s no kind of business strategy.


The Devil’s in the Details

Marketing is not a dirty word. It means communicating the value of your game to potential customers. That’s it. However you do it, be it social media or gaming websites or good old fashioned feet on the ground knocking on doors, you’re trying to say “Hey, look at this great thing you may be interested in!”

Things you can do to market and promote your games:

Those are just some of the more generic resources and options. In my case I physically went to board game meetups because Steam Marines had intrinsic appeal to those people. You can go to genre or device (iOS/Android) specific podcasts or streaming channels on Twitch or YouTube.

Not every platform is going to dump your game in front of hundreds of thousands or millions of eyeballs – you should probably hit as many as you reasonably can. There are many postmortems of successful Kickstarter campaigns and you can learn a lot from those – there’s a ton of overlap!

Ignore Greenlight postmortems – Greenlight is a seriously low barrier to entry these days.

If this sounds like it’d be an awful lot of work… it is. The bottom line is if no one knows about your game no one will buy it. That’s a bit of an irreducible problem.


Holy Moly, Batman!

You don’t have to do all of these. In fact you most likely do not have the time to do so, particularly if you are a one person shop. There are lots and lots of resources on indie game development, the business and marketing angles, and so on. The internet is a vast and wonderful resource – use it to your advantage.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.

Cover Systems and Overwatch


Cover me – I’m going in!

Ostensibly a cover system, within the context of a generic turn-based tactics game, is to provide positional play options. It can also provide a mechanism for regenerating health (more common in shooters) and encouraging indirect confrontation of obstacles. If not the latter it can also encourage turtling: whereupon the player chooses not to move because there is no risk the player is willing to take to improve her position.

Games like XCOM: Enemy Unknown cover provides passive benefits, such as 1) stopping enemy units from flanking, and 2) reducing the probability for enemy units to hit them with ranged attacks.

What I find interesting is that a simple cover system can be replicated mechanically in other ways – cover is just frequently chosen because it passes both the realism/simulationist test as well as providing for some thematic tension.

There is no traditional cover system in Steam Marines 2. Instead units can directly suppress other units which apply ranged-to-hit debuffs. There are a number of benefits to this system over a cover system despite both affording a player’s units probabilistic defenses against attack:

  • Unlike traditional cover a player can stack her unit’s suppression, whereby a unit suppressed by one marine might receive a -15% chance to hit, two marines suppressing the same target might confer a -30% (or non-linear stacking) chance to hit.
  • It encourages units to be more proactive in terms of movement and fire, the core tenets of the Steam Marines series.
  • Expending ammunition to suppress a target is more costly than simply finding cover; Waiting too long to advance once suppression orders are given is a drain on ammunition (which is finite) as well as still allowing the reduced chance to take damage. Even if ammunition is not finite turn-based tactics games generally have weapon reload mechanics which should be taken into account.
  • Since suppression acts as an active cover system there is more granularity to the power scale of employing it tactically; Having a marine get -30% chance to be hit in cover is different from having a marine that can suppress a target for -30% chance to hit. In the first situation the mechanics encourage the marine to be on point and reduce the chance for all shots from all enemy units to land. The second situation encourages more positionally-minded play since the marine can only suppress one target, and it cooperates better with units that perhaps have a higher chance to hit but a less powerful suppression debuff. Thus getting all marines increased cover evasion in the first scenario breaks the power curve much more than buffing suppression for all marines.
  • It really emphasizes that Steam Marines 2 is about squad cooperation. A lone marine is very vulnerable, much more so than a lone marine in a traditional cover system.
  • It doesn’t have any finicky edge cases with melee units. A traditional cover system doesn’t provide any offensive debuff for melee units, but an active suppression system does – and should!

You don’t have to have one or the other, or even either or – you could have a hybrid system or something completely different. I just personally prefer a more active tactical system.

Aside: Suppressing a target who auto-retaliates and kills your marine completely fits in the theme of a brutal, challenging game. Auto-reprisal systems that trigger on direct attack as well as suppression also add a lot more decision making to the process. Low health, high suppression marines might not be the best unit to lead suppression with, after all!

Active suppression systems also work well with a lot of units crammed into small, line-of-sight breaking level layouts. Steam Marines 2 does not have the destructible environments of its predecessor and this makes choke points like hallways and doors deadly. Leapfrogging by advancing, suppressing, and repeating is preserved from a traditional cover system except you don’t have to rely on the environment cooperating with you.


We can’t see shit, sir.

Overwatch, or any mechanic that allows interruption or interaction for a side when it’s not their turn, provides for both varied gameplay and tension. If I send a marine through that tile is he going to get cut to shreds? This is largely an information war more than anything else for two reasons:

  1. The opposition has to know about your plans in order to avoid/counter it.
  2. You have to have a hunch that reaction is more beneficial than a similar action performed on your turn.

The problem with Overwatch, or Guard Mode as it’s called in Steam Marines, is that it’s frequently a “default” action. It’s just something you do when you don’t know what else to do. It’s a safe action. As with cover and turtling, I prefer to dig that out of my systems.

The other appeal of an Overwatch mechanic is that, in a traditional cover system, you don’t have to really move around much. Again, it’s playing it safe. As mentioned above in the cover section Steam Marines 2 has an auto-engage target. Whenever a unit attacks or suppresses another unit, the defending gets to attack the attacking unit – order depends on circumstance.

This makes attacking similar to defending. You need to suppress and move to good positions and you (should) suppress and attack targets to avoid effective retaliation. There are pros and cons to this. Pros include a depth of tactical decision making and much more active turns.

A rather large con includes the potential for “samey” feel turns, where you suppress, move, attack, repeat. This is, on its face, only marginally different from move to cover, attack, repeat. The main difference from that gameplay level is the micro decision is who suppresses whom as opposed to who moves to what cover. It is arguable that the traditional cover micro decision is superior because it can be made hastily, without too much thought, and be reasonably effective. Whereas picking bad suppression targets can really doom you in a suppression/retaliation system (given a high enough damage-to-average-unit-health circumstance).

Therefore Guard Mode in Steam Marines 2 provides a very different mechanic from the first game. Instead of acting as an Overwatch marines in Guard Mode have increased accuracy, damage, and initiative when retaliating against attacks but not suppression. The key difference is the positional play element – you actually want to push marines forward and place them in Guard Mode.


Wait, what about turtling?

You don’t actually want to turtle with Guard Mode because enemy units can dogpile suppression and then rip your marines apart individually. You need to be actively taking them apart with both your rear and forward units rapidly otherwise you’ll lose due to attrition.

It gets particularly hairy when you factor in that attacking/suppression/Guard Mode are now in their own resource pool and no longer related to action/movement points. A unit with two attacks per turn who can attack then suppress or suppress then enter Guard Mode is a very different beast from a unit with only one attack per turn!

It’s not quite a weapon triangle, but it can help to (sort of) order it in that kind of cyclical fashion:

  • Guard Mode > Attack
  • Attack > Suppression (on non-attacker)
  • Suppression + Attack > Guard Mode

Or, combined:

  • Suppression + Attack > Guard Mode > Attack > Suppression (on non-attacker)

Simple, right? Right?


Of course, the effectiveness of such a suppression/Guard Mode system is highly dependent on the numerical balance of the game with regards to weapon accuracy, range, damage, armor and health on units, et cetera. So far the results are promising and I hope to keep refining the current system.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.



As of the writing of this blog post Steam Marines has a  67% positive rating across 213 user ratings on Steam. On Desura it has a 9.3/10 rating across 37 user reviews.

Steam Marines User Reviews on Steam.
Steam Marines User Reviews on Steam.


Steam Marines User Reviews on Desura.
Steam Marines User Reviews on Desura.


Steam user ratings are on a binary system of either “Positive” or “Negative” and you must choose one of those two ratings when creating a user review. Desura user ratings allow any integer from 1 to 10. Steam has more units sold versus Desura, but not at a 213:37 ratio (Steam has sold significantly more than ~5.76 times Desura’s units sold.)

The upshot here is that audience matters a lot. A smaller, more understanding or focused audience means better reception, more patient to stick out the beginning of your game, more willing to actually leave a review, and this also translates into willingness to pay a higher price. You should court these players for your core audience.

It should also be noted that some of these core players will be on the larger platforms like Steam as well, they’ll just be surrounded by non-core players. It was something akin to torture to watch the Steam Marines user review score slowly drop as the game sold more and more to people who weren’t really fans of the turn-based tactics genre, or difficult games in general.

That’s okay, though. Steam has refunds now and it should keep your audience more focused and allow for more consumer confidence in general.

Steam Marines Too Difficult!
(I am unreasonably proud of this.)


It’s stuff to keep in mind as you try to communicate your game to potential players. I won’t make any special commentary about how to convince people, but I will mention that I personally prefer an audience that actually plays and likes my game. It helps cut back on the community building effort as well as the negative reviews.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.

No More Tales

(I apologize for the high number of links in this post. I’ve also pretty much decided to no longer speak publicly about game development finance for a variety of reasons, so I’ll be skirting some points and issues.)


No More Tales

Apparently Tale of Tales, developers of Sunset, are closing their doors. Their official site is hammered and down at the moment so the first link is a GameInformer one. The upshot is they went into debt, sold only 4,000 copies between crowdfunding and the Steam sale, and have decided to no longer make games commercially.

It is always unfortunate when a group of creatives can no longer fund their activities. That said there are lessons and warnings here that have have to do with marketing, creative vision, and being realistic.

The first is that knowing who your core audience is, and being able to reach them, is of the utmost importance, more so than ever given that Steam has opened its gates. Tale of Tales has been around as an indie game company since 2002. They had 2,228 backers on their Kickstarter campaign in 2014, raising a total of $64,636 USD. The combination of gross unit sales and backers and sales history (which they know but I am not privy to) should most likely have indicated that their core audience is extremely tiny, almost certainly under five digits.

It sounds like they tried to do everything right in a traditional indie game developer manner; Broaden the appeal, spend on marketing and advertising, and lean on external funding. Whatever the case may be the aggregate result is now failure in a monetary sense.

It is always easy, though perhaps not any more accurate, to pick at details in retrospect. I know first hand how jumbled the process can get when you’re elbow deep in the guts of making and marketing a game. That said there are some broad stroke, red flags:

  • A “game for gamers” Sunset is surely not. If they believed this they truly missed the mark in understanding who their audience was and the market at large. There are enough people making abstract art games that it’s fairly well-established as a niche more than an underserved market.
  • Advertising, as in the act of purchasing ads, is not useful on a small scale. This, too, is fairly well known particularly on the internet. Maybe a game like Sunset can’t push for hard YouTuber or Twitch streamer cooperation. Maybe it’s just not that kind of game. I can’t offer a solution here, but I can diagnose the problem. That was probably wasted money.
  • Good ratings are good, but it has to take into consideration the total quantity of players as well.

The third point is desperately important. With the advent of a more open Steam, GOG Galaxy being in beta, and Itch growing remarkably quickly, literally everyone has wider access to the gamer audience.

It has been my observation that many small indies these days are selling a few hundred to a few thousand copies of their games and are ecstatic. And they should be! Baby steps is how anyone gets through this ever-changing market. But that is not sustainability. When you get 100% positive reviews out of 20 that is not so remarkable. Pretty much anyone can shake up 20 positive reviews from their personal pool of friends, relatives, and friendly developers.

Your parents might tell you your game is the best thing ever, but your parents are not your core audience. As I mentioned in a previous blog post,  you need a resounding YES. Not a lukewarm yes, nor a bright YES followed by words and no sale. A marginally interesting game someone will pay ten dollars far is superior to an enormously interesting game someone will not pay anything for. Steam refunds is a thing now, too; software is catching up to the physical goods world.*

This is a hard pill for creatives to swallow, but we’ve all swallowed it in micro-forms throughout our careers. When you agonize (waste time) getting that thing just right that no one ever notices. Even game critics miss this so often – almost every game that’s not a pile of poo was a labor of love, that was iterated over and polished in some parts and not others. It’s just that the games that gain followings, large followings, get examined thoroughly enough to merit such deep analysis. Who wastes their time dissecting games that are popularly perceived as trash?

This is the hard truth – no one starts off caring about your creative prowess, your time and effort spent. You do not deserve their money, their attention, their time; You have to earn it.

This is why so many creatives fall back on the luck argument. It dodges all the hard truths and lends a fallback excuse. People don’t talk about luck when creating material objects nearly as often. Maybe because the physical fetish can somehow snap a critic back into reality – this is a thing*.  For some reason software has less of that effect on most people.


A Number

My number is 20,000. That is the number I want to personally hit as the number of core users for the kind of games I want to make. In my circumstances 20k unit sales, at something like $10-20 USD each can keep my head afloat and making Next Game. Other game developers, some more experienced than I am, tell me that this is folly, that I am setting a trajectory for crashing and burning. Maybe they can see something I can’t.

But even if they’re right and I’m wrong, you still need to know your number. You need to aim for it hard. If there is no Next Game, there is no game after that.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.

Steam Marines 2 – State of the Game


State of the Game

Steam Marines 2 has been in development for about eight months now and is still in pre-alpha. The first game was a straightforward dungeon crawler. It was very no-frills, just clear/escape each level and kill the baddie at the end. The sequel is a bit of a different beast.



Steam Marines opened by making you pick a difficulty level,  bringing you to a squad creation screen, giving you a blurb about awaking from cryo-sleep, and dumping you unceremoniously in a procedurally generated level.

Steam Marines 2 shakes that up a bit. For starters there’s no difficulty level to choose from. Instead starting a new campaign brings you inside the interior of a spaceship. What, where’s the squad creation? Well…

Mission Briefing
Mission Briefing

You can just jump right into the first mission by hitting the Launch Mission button, or you can hit that suspicious looking Squad Loadout button in the upper left portion of the screen…

Roster Selection
Roster Selection

This isn’t fully fleshed out yet, but the general idea is that from the interior of your steampunk spaceship you can flip between your ship base and galaxy view, look at and gear your marines in roster/squad lists, and view and accept missions. Don’t worry, I’m aware that font is terrible for displaying numerals.

This is great because Steam Marines was all about an intrepid squad of four marines, huddled together trying to survive a hostile boarding of their vessel, whereas Steam Marines 2 is about receiving missions from the Steam Marines Corps directly, while trying to engage in directives from the Earth Council and balancing the needs of the system you’re in. Safeguarding civilians and gathering resources to aid your primary goal constitute the new strategic layer.

Gear is now modular – you can mix and match helmets, chest plates, gloves, et cetera. Marine classes have semi-randomized pools of talents that generate different talent trees once marines are promoted. Enemy units return in robotic and alien flavors, but have separate faction goals, and you’ll learn more about their motivations. Maybe you’ll even find some new allies?


Marines, MARINES

Steam Marines 2 is still ultimately about turn-based tactics. The old square grid has been retained, but the action and movement and aiming system has been overhauled:

Squad Ready
Squad Ready

I’m still playing with fog of war, but I’m leaning heavily toward either a very dark layer of fog for already explored areas, or simply blacking it out entirely, meaning you can only really see what your squad sees at any given point. It has the benefit of making the game feel more claustrophobic and introducing even more imperfect information since players are unlikely to remember the exact layout of the map once they’ve moved on.

Marines can see and aim in a full 360 degree arc and facing is no longer a factor in game mechanics. While the environment is in 3D for eye candy, the same ruthless mechanics of turn-based combat apply. This is not a hide-behind-a-corner-and-fire tactics game. The universe of Steam Marines is brutal, life expectancy is short, and losing all your marines still a very real possibility.

Since facing has been removed, this makes positional play even more exacting. There is no facing action cost (default on in the original game), and you cannot sit back in a wide area and take potshots in Guard Mode – ranged enemies will be able to pick you off at any angle!

Environments are not destructible this time around, however, and this opens up new avenues of attack and defense. Choke points become much more contentious, and units both in the Steam Marines Corps and on the side of the robots and aliens will have unit-specific tools to rush and otherwise break up that layered tactic.

Escape via blasting a hole in the wall and running away used to be an option. Now if your back’s against the wall you’re forced to fight. Or plan ahead so your back doesn’t get against a wall.

You’ll also have a full roster aboard the I.S.S. Delhi, as well as a larger squad size to play with.


The I.S.S. What-Now?

The I.S.S. Delhi is the first human controlled ship you get at the start of a new campaign. It’s a small Corvette-class steampunk military vessel, complete with a skeleton crew of Fleet officers and a handful of marines. You’ll have to obtain more resources and personnel on your journey – Earth is very, very far away.

Steam Marines 2 is not a 4x by any stretch of the imagination, but you don’t just control a squad of four marines anymore. You manage a roster, you manage squads, you manage Fleet personnel, and you manage… ships?


Ship Designs
Ship Designs

Oh snap – ship upgrades? Ships? Almost certainly ship upgrading. I’m not sure about managing a fleet yet, but I’m mulling over some possibilities. It will depend heavily on how the strategy layer shapes up over the next few months.


Also don’t let me get sidetracked with scope creep, please and thank you.

Third Person Shooter
Third Person Shooter

I had this idea where if you were down to one marine the player could have the option of running and gunning in third person mode. I mean you’d probably still die but it’d be a cooler way to die.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.

Indies Can Do No Wrong

There was a Polygon article with the title Big indie’ Kickstarters are killing actual indies.

There was nothing wrong with the main thrust of the article. Points were made, namely that in many Kickstarters (I’d add crowdfunding in general) costs and budgeting are not made clear. If you follow my Twitter at all you’ll know these are issues I rant about rather frequently.

But of course if you follow my Twitter you’ll also know I get rankled when indies ignore when other indies behave badly by going after non-indies for the same bad behavior. Specifically:

Indies Can Do No Wrong
Indies Can Do No Wrong.


I did the math earlier along with some other pithy tweets, but the upshot is that the developers of Kickstarter – Elsinore are (currently) running a Kickstarter with a goal of $12,000 when they believe, according to the Polygon article, that they needed $672,000. That is approximately 1.8% of what they think they need to complete the game. By comparison $500,000 of $5,000,000 is 10%, or 6.9% of $7,200,000.

Indies, as a group, participate in pretty much all of the bad behavior that they accuse “AAA” or “big indie” studios of. This includes crunch, chronic (and more severe!) underpayment of employees and contractors, and obviously crowdfunding without transparency or even a hint that they actually created a workable budget.

My suggestion is to not support unethical developers, wherever they are, whatever their status of indie or big indie or AAA or AAA indie or AA or whatever label you feel most appropriate. In these cases the most relevant label is unethical.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.


Mistakes, Problems, and Solutions (Part 2)

It Always Starts Small

I think a lot of people start off interested in making games the same way I did:

“That doesn’t look hard to make. I bet I can do better.”

If that’s accurate then it’s hardly surprising that the two causes of developer failure, underestimation and hubris, pop up so often – they’re the impetuous for starting in the first place.

Good and bad, right? Many people fail without starting in the first place, but that misplaced motivation can come back to bite you if you’re not careful.

The first blog post was about how I failed in the development of Ignition Impulse. This second blog post is about how I failed in the development of Steam Marines.


Play It, Sam

It started as a small game called Quad. Conceived as a small, turn-based, squad-based RPG, I started posting about it in my forums in early 2012. Feedback was minimal, but there was some interest there so I ran with it.

Aside: You can already see one big problem – “Quad” is a terrible name for a game. Just try Googling it. It took me about six months to rectify that!

I was doing a lot of other things behind the scenes; “real” development didn’t kick in until around April 2012. In-between I tried prototyping a bunch of other games, did more research on the games market, and other assorted failure prevention type stuff.

The core of Steam Marines is having a four marine squad moving through a spaceship and fighting off robots and aliens. Pretty straightforward! It was turn-based, used an action point system, and made some probably questionable design decisions like locking movement and firing to cardinal directions only.

The hooks for the game, the bits that set it apart from my point of view, were that it was brutally hard and straddled a middle field between shorter, more casual games and longer grindfests. During development the “Steam Marines is hard” angle overshadowed everything else.


But It’s So Bouncy

There was not one failure here, but a series of failures of communication between myself and potential players. Steam Marines looked bouncy, toony, and colorful. But it was, at least from the average player’s perspective, overwhelmingly difficult. What makes this worse is that I knew this – in fact, I deliberately balanced the game on “Hard” difficulty since I knew I had a personal preference for difficult games.

In other words, I was catering to a niche within a niche and I was not explaining this well.

Many early players and Let’s Players got it immediately, primarily fans of traditionally harder/permadeath games. Everyone else sent me hate mail.

Aside: It is a very weird feeling to have made something that people literally hate you for making. It’s not all bad. Sometimes you get an email reading somewhat like, “I hate this game. I hate you. I’m starting a new game.”

If I had paid more attention to the mobile games sphere I probably would have gotten this right away. People simply associate bright colors and bouncy animations with easy/casual. But I didn’t and the resulting backlash from players was both confusing and damaging to morale.

I like to think I have thick skin but the truth is after a few dozen people tell you your game is crap and you are crap (and for the same reasons!) you start questioning every decision you ever made. Riding low on the results of Ignition Impulse did not help any.

In the end it was a combination of stubbornness and people giving me actually constructive feedback that got me back on track. I really want to stress this: you need to be both stubborn and open-minded to do this (well.) You need to be open-minded otherwise you will miss good feedback and opportunities, but you need to be stubborn enough to reject the crap feedback. And you will get a lot of crap feedback.

One might argue that the pertinent trait here is the ability to accurately assess a given situation, but I think the problem is deeper than that. Frequently the issue is not one you can parse out objectively. Issues of preference, balance which is contingent upon the individual, et cetera abound during game development. At the end of the day you’re going to make some bad calls no matter how sharp you are. Practically speaking your goals should be to minimize the frequency of those and mitigate the really bad mistakes you inevitably make. “Always make the right decision” is about as useful as “never make spelling errors.”


Marines, Ho!

Art was coming into the project and I was feeling good. The game was starting to look like a real game, I had some really cool theme music, and I was on Reddit and Twitter talking with other developers and promoting my alpha.

In August 2012 Steam Greenlight was launched, ostensibly to help indie game developers get onto Steam in a more streamlined and orderly fashion. I can’t be overly critical of Greenlight. Mistakes were made and the process was far from perfect, but Valve made a large effort to do something that they did not have to do that did end up helping many indie developers.

Steam Marines landed on Greenlight the opening day… and took about 400 days to get Greenlit. A note on Greenlight to any developer currently in that pipeline: you need to push hard to get eyeballs and yes votes. Yes, there was an initial surge of eyeballs when Greenlight was new and shiny. It still took me and my tiny community over a year of bush kicking to wrangle up the required votes to make it past the finish line. I’m sure developers who have run successful crowdfunding campaigns agree.

Aside: Even if your game is so awesome it can make it without external effort on your part, I can’t recommend doing that. Push it, promote it, don’t stop talking until you make it. Out of all the walls you will face during development Greenlight might be one of the longer, more torturous ones, but it isn’t the highest.

Don’t think I did everything right in this case. I missed the opening hours of the Greenlight launch because my artist at the time assured me he would have the necessary assets (logo and so forth) ready on time. He did not.

I did get lucky in some ways. Negative comments on the Greenlight page were few and far between. Some cries of “Clone!” but they were mostly shot down by other commenters. It was a good trial by fire for learning to deal with people who had no prior investment in my game, and how to answer soft but firm.

I did reach top 100 relatively quickly, although there were some very dispiriting months where Steam would Greenlight a few titles… and Steam Marines would actually drop a few places in rank. I don’t have good advice for that kind of demoralization.

Sometimes there are no clever tricks; you just have to roll up your sleeves, get out, and push.


Abracadabra (Or, “Problems Go Away If I Ignore Them, Right?”)

This post is about failures with Steam Marines. It would not be complete without mentioning management of contractors. By and large I believe I lucked out. I ended up with mostly great people to work with.

My intention is not to point fingers at anyone. The following is a non-exhaustive list of problems that can crop up with any contractor, employee, et cetera.

  • Have a contract.
  • Have an exit clause. Think hard on what the terms should be. Do not ever think, “Oh, well this will never be used.” If it will never be used then why is it in the #[email protected]%ing contract?
  • Be very clear on what the expectations are in the working relationship.
  • Be prepared to sever the working relationship if necessary.

Being saddled with someone who does no work is not the worst thing. The worst thing is being saddled with someone who is actively damaging your project. Please be aware of this.

 Aside: There are a myriad of ways someone can damage your project. They can produce subpar work. They can produce no work while saying they will. They can undermine your processes. That someone can also be you.  Try not to be that person for yourself or anyone else.

I’m a fairly caustic individual. I’m blunt, willing to be rude to make a point, and I found it difficult to pull the rug out even though all the red flags were there. I don’t really have an excuse but I think my only explanation was that I felt I didn’t have many good options. Given that the project survived and thrived despite those issues, that was clearly a misunderstanding of the larger situation.

I can see it with a bit more clarity now, so let me offer you this advice as explicitly as possible in the event you find yourself in a similar mind-and-decision-blurring predicament:

You always have better options.

I’m not guaranteeing you’ll see them, but they exist.


Moving On

I’m skipping ahead a bit here. Steam Marines was Greenlit, it was voted for Community’s Choice, and made a bunch of sales and money on Steam, Humble, Desura, and IndieGameStand. Into profit territory, woohoo!

Aside: You have a budget, right? Go read Commercial Indie Games & Risk and Budgeting blog posts if not! Actually do it anyway.

There were a lot of little details and failures all over the place. I don’t have too much to say on any of them individually, but I want to impress upon you the volume of problems, or potential problem situations, that can crop up:

  • UI/UX. Even if everything is rebindable people will complain about your defaults. Some people will love your buttons. Other people will hate your buttons. Some will even say your buttons are uninspired.
  • Most players will never look at your menu options.
  • Enemy AI that announces its intentions is widely considered more intelligent despite the fact that it is an incredible act of stupidity for any party to announce their actual intentions to the opposition.
  • 99% of people don’t read anything in-game; 1% read everything.*
  • You can make an announcement, sticky a thread, blare it in-game, and people will still miss it.*
  • You can make the screen shake, throw up character dialogue, and center the camera on an event and people will still miss it.
  • You need to be very, very, very specific about what you are promising and what you are not promising. People will still crucify you but at least you have something hard to point at after the fact.
  • I used words like “Hard” and “Normal” to describe the difficulty levels when creating a new game. Also on the ship decks which had an entirely different meaning.
  • People really hated ‘Z’ as the default keybinding for firing a marine’s weapon. Okay, that one was one me – I could have picked a better default.
  • Gamepad bindings are driver specific. There are different drivers on different operating systems – you get the idea. I wonder why so many consoles don’t allow rebinding?
  • Linux players are few. They cannot buy in numbers of Windows players… but they seem very tech savvy and figure stuff out without contacting tech support (that’s me.) Linux users will also cheerfully report esoteric bugs on their esoteric rigs with a cheerful, “I know this is esoteric – don’t worry!” (If you are good at ignoring problems that aren’t really problems to your users this one is probably fine.)
  • Mac users are not as tech savvy. Less than 5% of the player base but 50% of the tech support.
  • People will tell you they have up-to-date drivers. Then you see their dxdiag dump files.
  • People will tell you they did XYZ to resolve some issue. They did not do XYZ.
  • What are system requirements?*
  • Get called an X because a customer did not realize Y (my favorite was someone who called me a scam artist because he did not realize Steam Marines was a 2D game.)

(*This is why marketing is hard. I am a strong advocate of slow burn, early and often. There are valid arguments for timing release of information and such, but my position as a small developer is that marketing is an enormous wall I need a head start on.)

There’s a minefield of things that can go wrong. Even if you are kind, cheerful, and helpful people will spit in your face. That’s just going to be something you (or someone you hire) will have to deal with.

My advice: be polite and be as helpful as reasonably possible.

To be honest I don’t follow that advice 100%. I may or may not be known for being somewhat snarky on the Steam discussion forums for Steam Marines. I think the right combination can be snarky but helpful and/or comic.

If you can’t swing comedy then just be polite.

Aside: Sometimes I respond to Steam reviews. Sometimes the negative ones. Some people do not take any kind of developer comment well, apparently. Sometimes having that PR person, that layer of insulation, is a good thing. Assess your own personality profile when it comes to this, too.

So many ways you can fail to so many people, so little time.


Are We There Yet?

Probably not. To recap I failed pretty hard at game naming, conveying what Steam Marines was actually like to play, didn’t manage contractors as well as I could have, and probably made a bunch of miscellaneous bad calls during the design and implementation of the game.

I got some decent coverage from some sites and YouTubers, and they definitely helped me through Greenlight, but if they were timed better they would have been spent actually getting sales as opposed to votes.

I started selling at too low of a price. Every subsequent price increase actually increased my unit sales. Oops. There are some confounding variables here – obviously the quality of the game was increasing alongside the price – but I’m fairly confident I priced too low early on.

I have merchandise (shirts) but never pushed it hard. I still assume my player base is on the small side to make that a profit center.

I didn’t go to any major game development events like GDC. I didn’t enter into any game contests like IGF. To be frank I consider these mild failures at most. While I am biased as an introvert I don’t consider physical hobnobbing to be that much of a leg up, and contests… well I don’t put much stock in those, either. I consider time spent on social media, and perhaps some physical location promoting at local gamer meetups, to be more productive. But maybe I’ll change my mind in the future. Steam Marines is, after all, a niche game. A game targeted more broadly would probably benefit more from these larger events and platforms.


That’s the end of Part 2. I don’t know if there will be a Part 3. Oh, wait, one more thing. Let’s end where we started:

“That doesn’t look hard to make. I bet I can do better.”

Maybe your game will encourage the next generation of game developers. Your game doesn’t look that hard to make after all. They can probably do better.


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.

Mistakes, Problems, and Solutions (Part 1)

(This is the first of probably two posts and is primarily from a developer standpoint.)


I Have No Idea What I Am Doing

My first commercial game, Ignition Impulse, was an almost completely unmitigated disaster in terms of profit, scope, design, and whatever else you can think of to measure success of a video game.

It was intended to be similar to a childhood game I played incessantly, Escape Velocity, with space combat, trading, and exploration. Simple! 2D! What could go wrong? I picked up a small commercial game engine and set to work.

I want to be clear I wasn’t quite that naive, but if you asked me circa 2010 if I thought Ignition Impulse would have been a commercial success I probably would have given it even odds. The hard reality was that after a year in development it was done in the sense that it was playable. It had no polish and my trailer was embarrassing, I released it as Pay-What-You-Want (PWYW) on the now defunct site IndieVania and grossed under $2,000 USD.

Aside: It did not help my morale that Space Pirates and Zombies (S.P.A.Z.) – an example of a non-terrible game made in the exact same game engine – was light years ahead in terms of everything that makes a video game good. And it was being developed alongside my own pale imitation of a game. Ouch! I should have taken notes – but for some asinine reason I did not.


Aside #2: PWYW as a game selling model is unworkable. Look to the mobile market for models that actually work. In this aspect at least I was incredibly naive. This wasn’t shareware in the 90s and I suspect this wouldn’t have worked well even if it was.


Tangible and Intangible

There was very little real value obtained from the development of Ignition Impulse. I made basically no money, I had developed mostly in a bubble, and my company name seemed very apt. Here’s a non-exhaustive list of mistakes I made:

  • I took a game engine I had no experience in and thought my first game would go relatively smoothly. (Read: Programmer underestimation.)
  • I built zero contacts within the game industry; not journalists, not even fellow developers. (Read: Introvert + lack of community building experience.)
  • I built no community prior to release. (Read: I DID NOT EVEN MAKE A WEBSITE.)
  • I did everything myself. I am terrible at art, music, et cetera. But oh ho – it was all MINE! (Read: Creator hubris.)
  • I started marketing after I finished the game. (Read: I thought marketing was maybe 10% of the importance in claiming success; it’s probably closer to 90% and it requires way more time than most people think it does.)
  • While I did take a look at similar space type games prior to development I did not do so very thoroughly since I missed the in-development S.P.A.Z.

Perhaps oddly only two things I did not completely fail at was projecting the development schedule and the budgeting for the project. The only +1 for my prior programming experience, apparently. Still, a very clear disaster.

If I’m hard on newer game developers it’s probably due in no small part to recognizing them making the exact same mistakes I made. Not everyone has the stubbornness and financial buffer to recover from blowing up a project like I did.

Aside: This is how green I was – I almost named the game White Hole. I am not joking. I wish I was joking. I think I still have an image of the game with that title. No, I won’t dig it out and show you.


So It Goes

Mistakes were clearly made. The obvious thing to do after failing all over yourself is to examine why you failed. I no longer have the note, but I remember scratching out the basic problems with creating a financially successful video game circa 2011:

  • You need someone to make the game, market the game, sell the game, support the game, and collect the money. (Read: Don’t do everything yourself – lean on other people.)
  • I’m a programmer by training and trade. I can make a lot of the game by myself. But I clearly need to find other people to do the art, music, sound, et cetera. (Read: Budget for contractors and/or partners. Solo development has significant drawbacks for both quality and morale.)
  • Start marketing and community building sooner. Sooner. Much sooner. (Read: Is it playable? If not, make it so. If so, get it into players’ hands.)
  • Networking is a must. You need to find all those people to help you. You need to communicate to them, have them communicate to you, and be able to adjust your project trajectory based on that information. (Read: You get what you give. Whether it’s Reddit, Twitter, TigSource, or your local coffee shop gaming meetup, you need to become a productive member of that community. Otherwise you are an outsider and humans, as the fickle and tribal beings that we are, will not help you.)

These are the four main areas where I stumbled and fell. The problems are now outlined. Solutions?


“Never Tell Me The Odds”

By this point I had collected myself and gorged on the various literature on the topic of game development. It was clear that I was in over my head. I had never seriously used a mobile device and I had no understanding of that market. I was a desktop coder through-and-through. Stick with what I know, I’m sure I thought.

You can dig through my other blog posts for hard numbers, but the short version is game developers as an industry are not compensated well. Lots of people want to be developers, fewer start, and fewer still succeed. The odds are stacked against you unless you have serious financial backing for development costs and a hard marketing push.

But, being the stubborn fellow that I am, I outlined the problems and came up with some solutions. I made a company website. I made a game website with forums. I started, almost on day one, to post about my game on various sites. I released screenshots, gifs, developer thoughts, mingled with other developers online and a few in-person, and gave and accepted advice from hard-earned experience.

The nice thing about failure is that it loves company. Developers, as a group, are great people to commiserate with – the pain is real and shared. They are also, unfortunately, a bad bunch to look toward for career advice. Here is some advice I have been given by other developers who failed around the same time I did, some also having much longer strings of failures:

  • “PC gaming is dead.”
  • “You have to target the mass market to succeed.”
  • “Success is all blind luck.”
  • “Make it and they will come.”

The short version is that my second game pretty much puts all four bits to bed. This does not mean that PC gaming is inherently better or good compared to other markets, that you might have an easier time targeting a mass market, or that there is no luck involved – but to suggest such extremes is clearly demotivating and inaccurate.

Survivorship bias is a hell of a thing. I could nod to a lot of postmortems and quotes from bigger, successful indie developers to try and affirm what I currently believe. Instead I’ll simply point out two salient points:

  • Lots of developers make games.
  • Most of them fail to become successes (at least financially.)

You can extrapolate a lot from just those two bits of information. The first is that if you do what the average developer does you should expect to have average performance which is not good – so aim higher.

Observation #1: Don’t necessarily reinvent the wheel (unless you have a really cool wheel), but do consider what you can do differently from others in your field. It will not only help you stand out, but will also give you and others a different perspective – you might find your intended audience isn’t but another is!

The second thing you should notice is that there are only a small handful of successes, but an even smaller number of genres those successes fall under. Excluding perhaps outliers like Papers, Please these games can be categorized into fairly broad genres.

Observation #2: Genre originality is not required for success. Do not be dissuaded from doing “another X” simply because there are other Xs; there are other Xs because Xs have succeeded!

Did you look at the survivorship bias Wikipedia link I posted above? In the article it describes quite an illuminating story:

“During World War II, the statistician Abraham Wald took survivorship bias into his calculations when considering how to minimize bomber losses to enemy fire. Researchers from the Center for Naval Analyses had conducted a study of the damage done to aircraft that had returned from missions, and had recommended that armor be added to the areas that showed the most damage. Wald noted that the study only considered the aircraft that had survived their missions — the bombers that had been shot down were not present for the damage assessment. The holes in the returning aircraft, then, represented areas where a bomber could take damage and still return home safely. Wald proposed that the Navy instead reinforce the areas where the returning aircraft were unscathed, since those were the areas that, if hit, would cause the plane to be lost.”

But hmm – we don’t have access to much data on the characteristics or development processes of failed game projects – do we? You have a little information from the Ignition Impulse project and some few others, but not nearly as much about the standout successes.

Well we can almost certainly determine that finding common traits in successful games will, over all the data, have some applicable relevance to making your own game succeed. It’s just the questions of which information is actually salient and what other information you have but overlooked.

The WWII bomber story should have automatically drawn your attention to a big red flag, namely that you’ve probably never heard of the vast majority of failed games. There are plenty of games – but you’ve never heard of most of them. In all likelihood you know about more successful games than unsuccessful games – especially if you are just a gamer and not also a developer.

Observation #3: People need to know about your game in order to become players. It doesn’t matter if you’re pushing that new-fangled-X-killer or a tiny nation border crossing simulator. What I’m trying to say is that marketing and word-of-mouth is an unarmored weak spot. So armor it.

It is frequently the third and fourth mentalities in combination, “luck = success” and “build it and they will come”, that conspire to ruin so many developers. Don’t be like those developers – you need to do more than just build your game otherwise you really are just relying on luck!

Which brings us to our final observation.

Observation #4: Failed developers and failed projects may not explicitly tell you how to succeed, but there is value and data there. We can’t know for sure what all the common elements are between all failed developers and failed projects, and maybe there aren’t any, but we can identify patterns. Thought experiments: What if you discovered that the vast majority of failed game projects were released more than 100% behind their original schedules? Or 75% were over budget? Or the average size of the teams was 1.3? Or if 90% of the games were in 2D? Or 3D? Or if 99% were never localized? Or if 87% were only on Windows?


What about combinations? Not too many successful games about 11th century South America… but also not too many unsuccessful games about 11th century South America. Sometimes knowing what you don’t know is also useful.

There are an infinite number of ways to succeed and fail. Don’t just rely on your past experience – seek out others’. This is just the good old fashioned advice to learn from other people’s mistakes. None of us can fail or succeed as broadly as all of us.


These All Seem Like Really Basic Failures, Bums

Yeah, I know. But we see them over and over again, and not just from new developers. If you’re a programmer ask yourself how many times you make the same stupid, silly syntax error. If you’re an artist ask how many times you lose work because you forgot to save your file (or imagine something else because I’m not an artist.)

They’re basic, but people forget or are tired or are stressed or it’s passed to someone who is and the accountability chain breaks – you get the idea. These aren’t even nitty-gritty details that you might never even think of. Occasionally I tweet about old screenshots of your games existing forever (because the Internet) and whenever I do I usually get a few seasoned developers checking and going, “Oh, shit!”

For empirical reasons I’m a big fan of going over the basics and checklists. Unless you’ve never forgotten anything I suggest you write it down. Actually, even then. You’re not always working alone after all. And we can’t all be John Carmack, right?


That’s the end of Part 1.

Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below.