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.