Kickstarter is no new thing, having been around now since 2008, and it’s been used to successfully fund thousands of different projects from movies, to iPhone tripod mounts, to video and board games. However in the video game world Kickstarter really only started to get noticed in a serious way after Tim Schafer launched Double Fine Adventure in February of this year which amazed everyone by raising over 3.3 million dollars. There have been a lot of stories written about the how’s and the why’s of the project’s success, with people wondering aloud whether or not it was the end of traditional publishing, simply a passing fad, or something completely different. While I don’t think traditional methods of funding are in any danger I do think using the power of the internet to fund projects that may not have been funded before is a bit of a game changer. That said, I realized early on that in order to succeed I’d need some things that almost all successful projects have in common: giving people something they want and credibility.

Give Them What They Want

The part of giving people something they want is kind of nebulous, but basically I mean providing something unique or interesting that wouldn’t otherwise have happened without Kickstarter. Again some good recent examples are Double Fine Adventure making a game in an under-served niche with a lot of demand, or the Pebble Watch making something amazing that didn’t really exist up until now.

Also having interesting backer rewards can go a long way to building excitement. Certainly a copy of whatever it is your backers are helping you make is a no-brainer but think beyond that to physical rewards like posters, shirts, 3D printed models and other exclusive items that wouldn’t exist without Kickstarter. People like cool stuff. Just remember to budget for the cost of producing and shipping your rewards before setting your goal otherwise you might not end up with as much money as you had hoped for in the end.

Credibility Goes a Long Way

What do I mean by credibility? I mean, basically, anything and everything that will answer the question that every potential backer is going to have on their mind (or should, anyway) when they look at your project: “Why should I trust this project with my hard-earned money?” Luckily there are a number of ways to answer this question that will help convince people to pitch in and make your dream a reality. The unfortunate downside is a lot of these answers are not easy ones and getting money through Kickstarter is not as simple as just throwing something up and waiting for the money to pour in.

There are quite a few good ways to answer this question to the satisfaction of your backers, and while you yourself may not be able to provide all of them, as long as you can capably address enough of them it will help immensely in gathering support for your endeavor. Here are a few that I’ve been able to identify and work with:

Have a proven track record – This is one of the big reasons Double Fine Adventure did as well as it did. Here you had a company who had a lot of experience in creating great games and two of the biggest names in graphical adventure games, Tim Schafer and Ron Gilbert, providing something that a lot of people really wanted. Obviously not everyone is Tim Schafer, but having provable previous experience and success is invaluable. In my own case I had already shown with my previous game Red Nova that I was capable of releasing a good game. Also while I would recommend against leaning too heavily on someone else’s credibility, especially if they’re not going to be responsible for the final project, I’m sure that having Danny Baranowsky attached to the project has helped a lot.

Have something to show – A lot of projects seem to be in the concept stage, and while that’s fine if you’ve got other factors working in your favor, it can be a huge help if you have a prototype or something in progress so you can show people that they’re not just backing an idea, but something that exists and will eventually turn into the final product. It’s a common aphorism in the start-up world that ideas are all but worthless, and execution is the hard but invaluable part proving to investors your ideas have merit and it’s honestly no different with Kickstarter. I think this really helped with projects like The Glif and FTL, where they had prototypes they could show how they worked and get people excited that way. As well, in my own case, having 8 months of work already put into Drifter I was able to give people a more definitive idea of what they were putting their money into.

Have a good reason for why you need the money - Being able to give a good reason why you need financial assistance to complete your project can help as well. People like to feel that they’re helping make something possible that may not have been before without their help. If your campaign comes off as a blatant cash grab, people will see through it and you’ll have a tough or impossible time getting funding. Kickstarter may seem like free money, but it isn’t!

Have a clear plan and be reasonable – Outline what you’re going to do with the money if you get fully funded. Be cautious of asking for too much or too little, because some people will question whether or not you’re being realistic about your goals. I’ve seen a few projects ask for huge amounts of money in the wake of Double Fine’s windfall not realizing that they themselves had originally asked for a “mere” $400,000, which up until a few months ago, was an immense amount of money for a video game project on Kickstarter.

Get people excited before Kickstarter – Having people who are already excited about your project before you even touch or think about Kickstarter is probably a good idea. This should be happening regardless, but I figured I’d just point it out here because not having support when launching a project could doom it to failure. Having people who like what you’re doing and believe in you and your project are worth more than any financial support you could ever raise.

Put thought into your rewards – This is somewhat keeping in line with the concept of having something to show for your work, but what I mean is you should actually take some time to think about what rewards you’re offering. Try and make them unique and desirable. For example a lot of projects offer posters, but I felt I needed to go above and beyond which is why I sought out a professional illustrator (in this case Steve Courtney) to create something truly special. Also producing physical prototypes of the rewards, while potentially costly, can help because people like being able to see what they’re getting in return. And of course, if you can, try and have some rewards that involve your backers in the project somehow.

Be sincere – While I’m sure there have been projects that have been launched for all the wrong reasons, and may have yet succeeded, I feel strongly that because you’re basically asking people for money before any product exists it will most certainly help to be sincere about what you’re doing. People can smell BS from a mile away so you might as well not have any around to begin with.

That said, I think certain aspects mean a lot more than the others, and having a really strong showing in some of them can completely make up for not having anything meaningful elsewhere, but remember, chances are you are not Tim Schafer or Brian Fargo, and you probably aren’t making something completely groundbreaking or re-making a cherished property from years gone by, so work hard, be humble and give people a whole lot of reasons why you’re deserving of their hard-earned money.

I’m making a very (very) limited run of 18″x24″ archival-quality wide-format prints to take with me to GDC 2012 (in less than two weeks!). I’ll have to think of some clever way to distribute them, assuming anyone actually wants one Chances are you won’t be able to get one of these, however, I have something special in store to announce sometime after GDC which should see them get a wider distribution.

Edit: Steve has blogged about the poster as well.

Anyway, without further ado, here you go:

Anyway, this isn’t the normal fare for this blog, but these cookies are just too good not to share. So without further ado, the recipe:

Ingredients

1/2 cup margarine or butter
1 can of sweetened condensed milk
1/2 tsp of vanilla
2 tbsp of cocoa powder
1 1/2 cups of shredded coconut
2 cups of graham wafers
1 pkg of marshmallows

Combine margarine, condensed milk, vanilla and cocoa powder in a medium saucepan on low to medium heat. Just heat long enough to melt the margarine/butter and then remove from the heat and combine that with the coconut and graham wafers. Take a cookie sheet and cover it with a sheet of wax paper.

Take a golf ball sized amount of mixture and flatten it out on the cookie sheet, placing a marshmallow in the middle. Wrap the cookie mixture evenly around the marshmallow until it resembles a smooth ball.

Once you’ve used up all of the mixture, place the wrapped marshmallows on the cookie sheet in the fridge and refrigerate them for ~2 hours, or until the balls have cooled all the way through.

Slice each ball in two and enjoy! (Keep them refrigerated or frozen for maximum awesomeness)

I apologize in advance if this is not the Right Way to do this, but it works, and that’s the main thing. Also I reference C++ but any object-oriented language that supports sub-classing should be able to implement something similar.

Anyway in Drifter there will be NPC ships which are flying around doing any manner of things which could be anything from delivering goods, mining in an asteroid belt, to trying to hunt the player or even other NPCs! With so many potentially different behaviors it would be nice to make it easy to add new ones as well as make it easy to use any AI with any ship without changing vast quantities of code.

In Red Nova it was a bit of a mess with one AI class and each enemy type’s behavior described by a couple of functions in that class. It is messy and a pain in the ass to modify, and considering how much more expansive Drifter is I really wanted to do something better and easier to manage this time.

First of all, all small ships in Drifter are all controlled by a generic ShipObject class. This object tracks things like location, heading, weapons, shield strength, hull integrity and cargo and presents a number of “inputs” to the ship such as steering, throttle and firing control. In the case of the player ship these inputs are operated by the touch controls, whereas with NPCs we can point some code at the associated ship object and let it manipulate these inputs.

This is where the generic AI class comes in. Each ship object has a pointer to an AI object and during the game logic loop every ship has its “process” function called. In that function a similar “process” function in the AI object is called. This is defined as a virtual function in the super class, which means that all derived classes will implement their own “process” function which will describe the behavior of that type of AI. To that effect, the generic AI super class also has pointers to aspects of the game state that would interest a potential AI agent such as the state of the current star system, other ships, asteroid fields and space debris such as jettisoned cargo and floating ore.

So now whenever we add a new NPC into the current star system we merely pick one of the existing AI classes as appropriate, create a new instance of said and attach it to the ship object and leave it to its own devices (or give it some specific task). Another neat feature that emerges from this is that we can add an autopilot for the player’s ship using an AI module.

Finally, if for whatever reason I feel the need to replace the hard coded AI behavior with scripting this gives a very clean entry point where I can replace the AI objects with a scripting system which performs a similar task.

How to finish a game: get part way through a project, get an awesome idea for another game, ignore it and finish the one you’re working on.

It ended up getting retweeted quite a few times, so I guess it kind of struck a chord with people. With that in mind I got to thinking about other barriers to completing games I’ve encountered over the years and figured it would make a good blog post.

Having tried to start this whole game development thing once before in the late 90′s, I’ve done quite a few things that have derailed me from actually completing a game. When I started again in 2009, I knew I had to avoid all of these pitfalls in order to actually get a game out the door, so that was my biggest priority, actually finishing a game. I’ve finished 2 games since then, and I’m on my way to completing my 3rd, so hopefully this advice may prove useful to you as well.

Limit your Scope

Quake is awesome! I know I’ll make a first person shooter!

That would be me, shortly after playing Quake, getting ready to embark on one of a series of unfinished game projects. At the time, instead of trying to make a game I could finish at my then current skill level I shot for the moon and, unsurprisingly, didn’t make it very far. I learned a lot of important skills, but I failed miserably at actually making any games.

That said, the first thing you need to do before you even start a game is at least plan what kind of game you want to create. The most important part of this planning step, as hinted at above, is to understand your limits as a developer or a team and make sure you pick a project that you can complete in a reasonable time-frame.

What’s a reasonable time-frame? For some people that might be six months, for others it could be a year, and for others still it could be two years or more. The point is: don’t bite off more than you can chew. You might learn a lot doing it, but if you’re seriously trying to make games all you’re going to do is waste your or your team’s time that could be better spent actually working on a game you can complete.

I’m not rightfully sure that you can really understand your limit unless you run into it a few times, leaving a few unfinished games in your wake, but at least be aware of it so you can begin to get comfortable with setting goals and making games.

Avoid the Creep

The evil twin of our friend Scope above, is Scope Creep. What is Scope Creep? It’s when you start working on your project and that little voice in your head goes “Wouldn’t it be cool if…” and then you’ve got something else to add to your game. If this keeps happening, you may end up spending way more time working on your game than you expected.

Sure, it might be cool, but before you start adding things to the original plan make sure you understand the implications. If it’s not absolutely necessary consider adding it to a list of things you can add after the game is released. In this day and age of digital distribution and patching there’s no reason why you can’t keep adding cool stuff to your game after it’s out. It’s not like people don’t enjoy getting new things to play with.

Resist Temptation

As hinted at by the tweet that inspired this post, game designers are almost always thinking about making games. Combine this with the fact that certain aspects of making games are just not very much fun and you have a potential recipe for disaster. At some point, you’re going to get an idea for a really awesome game in your head, right in the middle of doing something else on the game you’re currently working on, and it’s going to be really tempting to start doing the interesting groundwork on the new game to distract you from the monotony of the current project.

It takes discipline, but the best thing you can do at this point is add the idea you just came up with to your list of future games you want to make and get right back to working on the game you set out to finish in the first place.

Don’t Re-invent the Wheel

It seems like the temptation to create your own middleware and tools is common among game developers. It’s a weird affliction in a way, as you don’t often see carpenters building their own table saws or, in keeping with the wheel analogy, car makers manufacturing tires. I understand the reasons one might want to do this, and sometimes they’re quite legitimate. Other times, it’s more of a case of the Not Invented Here syndrome, where people seemingly mistrust anything they didn’t create themselves in-house. Yes, creating your own rendering engine or 3D modelling software (both of which I myself am guilty of) is a great way to learn new things and be in complete control of your project, but my point is you’re trying to create a game not middleware or tools!

The important thing here is to keep in mind that a lot of common problems in game development have already been solved, and probably more completely and robustly than you ever could do yourself. Some of these solutions cost money, some are free, but understand that your time is valuable and it is better spent actually working on finishing your game. So always spend some time before tackling a difficult problem evaluating if adopting an available solution will end up bringing you closer to finishing your game or not.

Conclusion

This is by no means meant to be an exhaustive list of things to think about when trying to finish a game, but I hope it will be useful to those out there trying to get their games off the ground. As well, by all means, feel free to suggest additional things you’ve learned that help you finish your games in the comments below.

Update: I was just about to post this to /r/gamedev on Reddit when I noticed a link on the sidebar to a post called “Finishing a Game” by Derek “mossmouth” Yu. I had actually read it ages ago, and it’s a very good post and covers some of the same ground I’m covering here, except more in depth… and with better pictures and diagrams. So, when you’re done here, I’d highly recommend you check it out.

Frankly, this line of thought is a festering load of dingo’s kidneys. The videogame is a medium, not entirely unlike the motion picture, and just because Michael Bay is releasing Explosions 4: Revenge of Explosions next summer doesn’t mean that Francis Ford Coppola will never be able to direct a movie again in his life.

Yes it kinda sucks, and yes people have a right and even duty to point out that it sucks, why it sucks, and how they think they can make things better, but it’s not going away and neither are the kinds of videogames that helped to define and continue to define this industry. That is unless we stop making them, but whose fault would that be?

Addendum: Just to clarify, there’s nothing inherently wrong with making games as a business (I mean, that’s what I’m trying to do after all) and there’s nothing particularly wrong with the free-to-play business model. Just like everything else in life, this is not a black and white issue. All I’m ranting against here is this idea that videogames are all of a sudden dead because a certain (tiny) subset of the industry is carrying out business in a way that people find questionable.

I had mentioned on Twitter earlier how I had written a script to convert all the WAV assets in Red Nova from unnecessarily large 32-bit floating point 44 kHz format to a space and memory saving 16-bit integer 22 kHz format. This basically cut the size of the files to less than half, which is pretty fantastic when you’re dealing with a hand-held device with memory constraints like the iPhone. Hell, it will also improve loading times!

Anyway someone asked me to share the script I made, which is a fairly simple Bash script. Just create a file somewhere, call it something like convertwavs.sh, and paste the following into it:

#!/bin/sh
mkdir oldwavs
for f in *.wav
do
   cp $f oldwavs/$f
   afconvert -f WAVE -d LEI16@22050 $f $f
done

Run chmod +x convertwavs.sh from the terminal to make it executable, then change to the folder containing the WAV files you want to convert and run the script like so:

/path/to/convertwavs.sh

It will make a sub-folder called oldwavs and copy the originals there in case anything goes wrong and then convert the files in place. That’s it!

A few days ago someone linked to the low-poly work of Kenneth Fejer on Google+ and apart from being awesome it gave me the idea to try and play around with the style. Not only was it low poly work, but the textures had an almost pixel-art appeal to them which I found intriguing.

You see, I’m a programmer most of the time but I do enjoy doing arty things, which some may say is unusual for a programmer, but when you’re making all of this stuff on your own it certainly helps. I don’t think my models are the best by any stretch of the imagination, but they’re certainly passable, but one thing that I’ve always never been satisfied with is my ability to texture them. This is why this pixel-art style appeals to me, because it’s a lot easier (at least for me) to create pixel-art.

Anyway, so I played around and created a few tanks in Blender and The Gimp and posted them as animated GIFs to Twitter and Google+:

People seemed to dig them, some even expressing a desire to see how they were created. So I figured “Hey, I’ve always wanted to do a screencast… I’ll make a tank and record it!”

So basically I recorded making the tank in 3 stages. Modelling, unwrapping the UV texturemap, and actually creating the texture. I wanted to do the whole thing in real-time but the whole process took a little under 3 hours so I won’t subject you to all of that. The Modelling videos are a little under 30 minutes total and the UV unwrapping is about 15 minutes so I’ve only edited those a little. The texture creation took almost 2 hours so I sped that up dramatically in a sort of time-lapse and then narrated over the sped-up video.

The videos are all recorded in 720p so feel free to view them directly in YouTube to get more detail.

Low-Poly Modelling – Making the Model Part 1 of 2

Low-Poly Modelling – Making the Model Part 2 of 2

Low-Poly Modelling – UV Unwrapping

Low-Poly Modelling – Texturing

And this is the final product:

Anyway I hope you enjoyed this and weren’t put off too much by my occasional mumbling and/or breathing directly into the goddamned mic!

You could convert to OGG Vorbis, which is of course free and clear to distribute as you please, however many devices (including iOS devices) do not support hardware accelerated decoding of OGG Vorbis files so you are losing some of your CPU cycles for your music decoding. Luckily, there is a third option: The Advanced Audio Coding or AAC format, which of course is supported in hardware by all of Apple’s portable devices. There are patents surrounding AAC but none of them restrict the distribution or streaming of files encoded in AAC.

Anyway now that I’ve spent all that time leading up to a single command, here it is…

afconvert -f m4af infile.mp3 outfile.m4a

And that’s it! As far as I’m aware you can use any of the iOS SDK methods for music playback with this new file.

This post is geared somewhat towards the App Store, which is what I have the most experience in, but I’m sure a lot of this advice could be applied to any game on any platform.

The biggest reason I am posting this is because I see a lot of really fantastic games coming out all the time and many of them get lost in the shuffle because of one or more reasons which I’ll hopefully address below. It hurts me to see so much blood, sweat and tears go into the development of a game only to have it thrown to the wolves and eventually fall into obscurity. That being said, not every game is going to be a success, but for the love of all that is good in the world if you care at all about your game try and give it the launch it deserves.

First of all, I just want to get it out of the way and say that I believe that the “gold rush” on the App Store, if it even existed, is long since over. That’s not to say that there aren’t any opportunities to be successful on the App Store, it’s just that it requires a lot more effort or a lot more luck to achieve that success. To continue the analogy, if what we had before was a gold rush where any crazy old prospector with a goofy hat, a straggly beard and a fart app could dip a pan in a river and come up rich now we have a gold mine where anyone with the right tools can get even more gold out of the cold, cold earth of the App Store.

The primary, and perhaps unfortunate, conclusion I’ve come to when it comes to the secret to success on the App Store I can sum up in two words, but I’ll use four for emphasis, and mild swearing:

Hard God Damned Work.

Sure luck still plays a big factor, but you aren’t doing yourself any favors by not taking advantage of the fact that you yourself can (and should!) do everything in your power to give your game the best possible chance at being successful. Yes people often deride the App Store as a “lottery” of sorts, usually in a somewhat dismissive tone because you know, only fools play the lottery, however it is the only lottery I know of where you can stack the odds in your favor.

So without further ado, in no particular order, are some things to help improve your chances on the App Store. But remember, it’s going to be a tough slog and your first game may not be successful but if you don’t give up and learn from your mistakes you’ll be bound to succeed.

If You Build It, Will They Come?

There seems to be an attitude that is prevalent in a lot of people that if they make something amazing it’ll automatically sell like crazy. The fact of the matter is, this is generally not going to happen and statistically speaking your chances of getting noticed at release without any marketing work are so small you might as well put your game on a USB drive and throw it in a dumpster. I don’t know if this attitude has a name or anything, but I want to be clever and scholarly and call it The Field of Dreams Fallacy, it has a nice ring to it don’t you think?

Even if your game really is so awesome that the entire world will be clamoring to get it on release day, you should still take some time and effort to try and get the word out about it beforehand. Many indie devs take advantage of the open development process to help get people interested in their game early, sharing stories about how the game is being developed, showing work in progress screenshots and generally talking about the game. There are many forums out there geared towards showing off your stuff. Take advantage of them!

While there are some who are concerned that someone may steal your game idea, just remember that it’s not necessarily the idea that’s important, but how you execute that idea. Also you may run the risk of being criticized which will hurt, or ignored which might also hurt, but if you’re not out there trying to find a potential audience for your game then it’s going to hurt even more when nobody buys it. Also if you do get feedback/criticism take all of it in and evaluate whether or not it is valid and/or worthwhile to heed. Yes it’s your baby and your creative vision, but it is for that reason very easy to ignore the flaws in something you are emotionally attached to.

Another important thing you can be doing at this stage is attempting to find people in the games journalism space who may be interested in giving you early coverage. These people are often very busy, so don’t become a broken record and annoy the hell out of them, but they do need content for their sites and that content includes news of up and coming games like yours! You may not find someone right away, but don’t worry and don’t give up, you may have to find a less busy site which is in need of new things or a big scoop, just remember these smaller sites and writers may and do go on to become bigger players in the industry so don’t ignore them, they need you as much as you need them.

Also when you do decide to pitch your game to them, just don’t parrot the usual “It’s addictive!” or “A unique twist on <genre>!” (Note: I am guilty of having done this in the past, I am not proud of it) These journos are sick of getting PR like this in their inboxes and even if they overlook your liberal use of hyperbole-filled content-free language it certainly isn’t helping your chances of them actually paying attention to your game. So here your best bet is to be succinct: Tell them why your game is awesome in plain english and make it very easy for them to see either screenshots, or even better, a video of your game in action. The key here is do not waste their time, they get dozens of new game pitches every day so you need to stand out!

At this time it would also be a good idea to start building a list of sites that you think might be a good fit for covering your game, both generic to the gaming platform you’re on or for indie games in general as well as genre specific sites. It would also be a good idea to use a site like Alexa so you can sort these sites by how much traffic they get. Don’t use it to exclude smaller sites, because you need all the coverage you can get, but it is good to know if a site is worth spending more time, effort and resources on or not.

To sum this one up, let’s just say that I spent about half my time working on what I would call marketing aspects of Red Nova during it’s approximately 7 month development period.

Failure to Amaze and Delight

Another relatively common problem a lot of indies seem to encounter is they release a game that is technically good but is either visually and/or aurally dull, an uninspired genre clone, interesting but frustrating to play, or any other combination of reasons that prevent users from becoming interested in and eventually falling in love with your game. Or at least falling in like with your game, anyway.

Basically, the more interesting your game or some aspect of your game is, the easier time you will have getting players, and more importantly, the lovely games journos mentioned previously talking about your game. You can address this in two different ways: polish and features.

As emphasized in a recent blog post by Noel Llopis, polish is a very important aspect of making a game. I won’t try and repeat everything he said here but the upshot is extra time spent polishing your game is always time well spent. Little things like the right sound effects, visual effects, extra animation, more explosions and so on can take a good game and make it truly great. It really is amazing how much more complete a very simple game can feel if you go that extra mile. It’s all about psychology, and people definitely notice these things.

Another way you can help differentiate your game from the competition is by concentrating on features that make it unique or better than most of your competition. These features don’t necessarily need to be complicated to implement but every novel or interesting thing your game does that the other games don’t increases your chances of getting noticed. Take some time to think about this and go that extra mile, trust me it will be worth it in the end.

Finally, always take time to make your game pleasant or at least not frustrating to play. If your game is annoying to play because the player is frustrated by the controls, then they are not going to enjoy the game at all. I learned this lesson well with the constantly fiddly controls for Chromodyne and hope I have managed to serve my penance with my improvement of the rather poor state of action touch controls with Red Nova. In the end, it turned out that I could promote this improvement as a feature, which ultimately helped earn the game a lot of good press.

A Launch Day is a Terrible Thing to Waste

This is probably the biggest and most common mistake indie iOS developers make, and that is the failure to recognize how important it is to take advantage of the control they have over the release date of their game. I realize the desire to put your game on sale immediately after you get the notification that your app is “Ready For Sale” is a strong one, I have felt it myself. DON’T DO IT! Keep that release date set to some point in the future and pick a day for your release date, change the release date in iTC to that date and stick to it. The idea here is to try and maximize the amount of buzz surrounding your game over a short period of time to generate a spike in sales, hopefully getting you into the charts.

If you have been doing everything right, by now you have gotten some game reviewers at least somewhat interested in your game. If not, especially if this is your first release, don’t panic too much, but you will have your work cut out for you. You see at this point you have 50 promo codes you can give out for your game even though it isn’t available for sale. The idea here is to get those codes into the hands of reviewers so they can write up a review and hopefully if things go well, have it ready for the release day. You can use the list of sites I mentioned you should make earlier to figure out who best to give promo codes to. If you have already gotten coverage earlier in the development cycle, it’s a good bet to give those sites promo codes for sure.

Use this time to create a press release as well. There are a number of press release services online that can get news of your game to a huge number of news services that cover different aspects of the games industry and you’d be wise to take advantage of them. You never know who might pick up the news. Also much like your pre-release pitches, keep the hyperbole and marketing-speak to a minimum. The easier you make it for someone who has to pour through dozens if not hundreds of press releases a day to see that your game is interesting and awesome the better.

Another thing you might want to consider, as a small and relatively unknown indie game developer, is the actual day you release your game on. For some reason it has become “common knowledge” in the iOS world that the best day to release your game is on Thursday. I’m not sure how this got started but for a number of reasons it’s actually now the worst day for a small and relatively unknown indie game developer to release their game. This is because practically everyone is now releasing their games on Thursday, from the crazy old prospector with his fart app to all of the big publishers and everyone in between. This means that it is going to be that much harder to get attention for your game seeing as it’s basically going toe-to-toe with the game release equivalent of the God King. I don’t know if any other particular day is better, but the rest of the week is quieter and you stand a better chance of getting more coverage from more sites because they need content every day of the week, not just Thursday.

One last piece of advice here, that I of course learned the hard way, is it’s probably a bad idea to launch close to the Christmas holiday if you don’t have a huge name for yourself or a lot of pre-release buzz surrounding your game. There is going to be a massive amount of noise from new releases and massive amounts of sales and even though there are going to be a lot of new device owners looking for games, chances are they probably won’t be buying yours.

Conclusion

The upshot of all this advice is that you have more control over the path to success that your game can take than you think. Yes luck is a massive factor in how successful a game is, but you should still do everything in your power to give your game the best possible environment for that success.

Most important of all: don’t give up, learn from your mistakes, learn from other people’s mistakes, and eventually you will get rewarded for your patience and hard god damn work.