There’s a lot of mistakes here, so let’s get right to it!
An Overly Ambitious First Project
Regardless of how much preparation we do, we all make our own mistakes. You’ll make your most mistakes your first launch, so it’s best to conquer that learning curve before your livelihood depends on it. Release one of your fun pet projects, a game jam game, or modify a template game. Whatever you do, don’t spend years on a game and launch it with no marketing experience. That’s a recipe for disaster. You’ve worked hard building your game, but that’s only half the battle. Getting people to play it is the other half. You owe it to yourself to be just as committed to getting people to play it as you were building it.
A chess app with a custom AI was extremely overambitious for my first launch. It took me at least 6 months (excluding the time spent on it part-time) after which I flubbed the launch in an effort to finally see some results. It may have gone completely unnoticed like the other 500 apps released a day if not for my one secret weapon, app store optimization. I’m fortunate in that people naturally search for terms relating to my app, Checkmate Chess Puzzles. Not all games have that luxury.
No Research
A little more proper research would have told me about existing free mobile app chess engines and cut my development time in half. It also would have shown me the keywords most used to find similar apps and improved my app store optimization during launch when I got my most traffic. It sucks to learn these lessons the hard way. A little time spent planning early on can pay off tenfold later.
Continuing to Build Without Market Validation
Everyone imagines the worst possible scenario of a finished game that never gets any downloads, but that should never be possible. Validate your game before launch, maintain those early supporters, and you’re guaranteed to avoid it. Finding out early that no one is interested can save you months and thousands of dollars.
Falling for Sunk Cost
I spent longer than I expected on main menu animations. Eventually, I had a custom intro and custom animations on each button that indicated what it did. My first point of feedback? It was too busy. I was too close to it and I didn’t want to see it, but it was definitely too busy. I spent a lot of time on an unnecessary feature that no one will ever see. Don’t do that.
This could also apply to your game as a whole. There comes a point where the game either fails to attract an initial following or is no longer growing, where it’s time to cut your losses and move on. We’ve all heard the story of Rovio (Angry Birds) and their 51 failed games before finding success. Unfortunately, it’s not uncommon in making games.
I’m still trying to figure out when it’s best to stop adding features, so if you have any tips then please leave them in the comments!
Failing to Get Feedback Early
This goes along with the last story. Subconsciously, I knew my app needed more, but I didn’t know what. I added superfluous details. Now, feedback from users constantly improves the app and keeps me motivated! I know I’m building features players want instead of blindly hoping trying new things and hoping that someone will eventually like it. Get feedback or you may end up painting the garage while your house is on fire.
While it can be helpful, don’t rely on getting positive feedback for motivated. It’s beyond your control and you likely won’t get it when you need it most. I received almost exclusively negative feedback until I launched. Mostly bug-fixes and nit-picky details, but sometimes it’s only stubborn determination (and Mountain Dew) that’ll keep you going.
Failing to Build an Audience Early
This goes hand in hand with my other issue. Growing an audience early means more feedback, compounding momentum leading up to launch, building anticipation producing greater desirability, and crucial first day downloads and reviews. Not only that, those early reviews are much more likely be positive as these players have become your fans, contributed to your game with their feedback, and gotten to know you over the course of your development. Building an audience is building an army. Do it right and your followers will be telling the world about your game for free. All you need to do is interact with them and spend some time to keeping them updated about your progress.
Falling for the “It’s not Ready!” Trap
The reason I failed to get much feedback or build a following was partially due to inexperience, but mainly due to falling into the worst game developer trap. I kept telling myself it wasn’t ready. I always had just one more feature in mind. Then it would be awesome. Then I could show people. Then I wouldn’t be embarrassed of my work. The truth is that it’s never going to be perfect. Part of being a game developer is being vulnerable. It means sharing something you’ve dedicated so much of yourself to. However, it’s that very vulnerability that’s so rare and valuable. Knowing what I do now, I should have gone to the indie game community. They understand the struggles you’re going through, they know a lot about what makes a game great, and they’re more forgiving of your mistakes. I didn’t want to share my work as I felt it wasn’t creative enough to fit in, but I’ve never been told anything like that. Offer advice or feedback to others before asking for it in return, contribute something worthwhile, and be vulnerable! The people around you will see that and respect you for it.
Updating Alphas Directly
This is a fairly silly one. I threw together a demo page, so I could share it with a few people (and then didn’t share it). When I eventually did share it, I had immediate crashes due to alternate browsers and memory issues stemming from running on the web. I then got into the habit of periodically uploading new builds when I finished a feature. (I built some scripts for this. Something I highly recommend.) As my app grew, so did my memory constraints and eventually those same memory issues started cropping up again. I uploaded a crashing build which immediately put me in a (completely unnecessary) panic trying to get it fixed on a poor internet connection before running off to a scheduled meeting. I only had that problem once. I added a test directory. Uploaded all builds to it and had a script to migrate the build it if all was going well. If not, then I could take my time to find the issue with the knowledge that the game on the main page was still running fine on a previous version.
Putting Off Time Saving Features
Once I decided to build them, my upload and update scripts took me no time at all and saved me from manually deleting the files I didn’t want to send to the server (such as the boilerplate html/css that accompanies every Unity build) which in turn sped up the time taken to upload. If it pays off according the xkcd time saving chart, then it’s time to build it now.
Spending Too Much Time Worrying About Criticism
Getting the wrong feedback at the wrong time can be crippling. You’re putting all your effort into a game and someone else’s callous remarks can easily destroy your motivation. Don’t let it. There will always be negative people out there. It’s best to ignore them. They’re likely venting out their other issues on to you in an effort to purposefully bring you down or they would have found a better way to phrase their concerns. Cut it down to the facts and either decide it’s valid, actively check if other users feel the same, or simply ignore it. Just remember, negative feedback is more likely to improve your game than positive feedback.
Analytics Analytics Analytics
Imagine if you knew exactly what frustrated your players, when they quit, and what stages they liked! Yo could tool your game to give them the best experience possible. It’s quite literally a game changer. I didn’t have analytics built in at launch and I immediately kicked myself as soon as the download, retention, and usage numbers started coming in. It was impossible to tell what any of the numbers meant. What features were most important? How were users spending their time? Why were people quitting? Were the puzzles too hard or too easy? Why weren’t people using hints or getting free puzzles? How many people finished the game and how soon? Should I create more content, build a better hook, or focus on getting more players?
About a week after launch, I had a friend’s sister said she downloaded the game before getting on a plane (ideal scenario!) and got stuck for quite some time. I asked her why she didn’t use hints and she said she didn’t even know there were hints! I had made a major misstep in my design and only found out by chance. Analytics would have told me the same thing, but much sooner.
If you have tips or good stories about using analytics, then leave a comment. I’m sure there are many more ways to use them that I’ve missed.
Not All Downloads Are Created Equal
I made an advertising mistake based on assuming that a worldwide ad campaign spreads the ads worldwide. (It doesn’t. It finds the cheapest ad spot possible.) I then mistakenly assumed that it was fine, because the cost per download was really low. However, since my game is ad and in-app purchase based, cheap downloads from ads means ads served to those users are equally low paying. I lost all my ad spend based on false assumptions. Not all downloads are created equal. Find your target and stick to it.
That’s not to say I didn’t find value in the experience, I learned more from that experience about the issues with paid advertising than I could have from months of reading books. Sometimes you just have to try it.
Overbuilding for Massive Sales/Getting Too Greedy
During my initial build, I spent extra time creating non-consumable level packs with index prefixes, so I could continue selling more level groups. 0_easylevels_50 would be the first fifty easy levels, 1_easylevels_50 would be the second fifty, etc. This was a very optimistic sales model and I didn’t even have enough levels built for more than one pack anyway. I shouldn’t have spent so much time on a feature that relied so completely on every other aspect of the app being a success and I shouldn’t have been so greedy with my early customers. I would rather have been too generous and had an extra happy customer-base. Later I could build the price up slightly if there was a proven market for it.
Choosing Perfection Over Practicality
Pride can really get in the way sometimes. In particular, it came up when I was adding the rewarded shares feature in my game. In the game, users can share to Twitter or Facebook in exchange for coins which give the players hints for how to solve the puzzles. My mistake was prioritizing functional perfection over the actual feature I was building. I could have taken the easy route and connected buttons to some share links with default content. However, I avoided this route as I knew that I couldn’t know for sure whether the player had actually shared anything and that felt like an incomplete feature. They could exit the sharing process, still get the additional coins, and know that the system was flawed. It exposed a crack in the facade of perfection I wanted to create, so I dug deeper.
I found APIs for Facebook and Twitter that would give me concrete proof of when a user has actually shared the post and thus I could give them the rewarded coins without fear of perceived bugs. However, it came at a substantial cost. I had to force the Facebook SDK to pop up a modal instead allowing their algorithm to use the optimum method for success (likely a method where the user is already logged in), because only modals gave absolute proof of success. (I did the research. Deep in the documentation they say that when using other methods just closing the page will send the app back a success message.) Even worse, the Twitter API required asking the user for posting privileges, bouncing them to a browser and back, and having them enter a code they (hopefully) copy and pasted from the aforementioned browser page. I was making it a nightmare for my users to do me a favor simply because I couldn’t deal with knowingly leaving a flaw in my game.
Not Focusing on the Bigger Picture
It can be easy lose the forest for the trees when you’ve got your head deep into a project. I’ve already mentioned several occasions of blindly continuing to build out features without prioritizing them or getting feedback. However, on a slightly different note. There’s another story I want to mention about ensuring that a feature is worth it at all.
I use a 3rd party API to place social sharing icons on the side of demo website. They looked great and saved me time. Eventually I found out they were messing with my layout on Safari and cutting off the top half of my demo. I immediately pulled the buttons until I could find the time to sort out the issue (which I ended up avoiding as I do not like messing with css). A bit later, I found out that safari is only about 3% of all browser use. I had completely pulled a potentially key feature to avoid 3% of my potential audience being frustrated. Obviously, a completely demo-ruining experience is too critical to allow, but selectively pulling the buttons from just Safari users was a much better solution and I would have reached it sooner if I hadn’t been so focused on building for all possible audiences rather than strategically targeting a core audience..
Not Having Press Ready at Launch
As I said before, there came a time when I just needed to launch the app. That’s what the people around me were saying and I didn’t want to spend more time on something that was starting to feel hopeless. I launched without any fan fair and my numbers suffered. Now it may be too late to approach busy writers always looking for fresh content to stay ahead. As others have said, it’s good to build a press page early, so you have a clear vision of your game, its important features, and your target audience.
Not Hiring Help Sooner
As I went over in My 5 Best Game Dev Decisions, the best strength is knowing your weaknesses. I know I’m weak in audio and art. Luckily I was able to find fantastic audio and some good art. Unfortunately, getting so much great stuff for free left me reluctant to spend any money. I made my own app icon and while it wasn’t horrible, it wasn’t very good either. Later, I hired a couple of talented guys off Fiverr for a total of $15 and got several fantastic app icons all of which were better than my current icon according to everyone I polled. Considering the importance of the app icon, it was a no brainer and I only wish I’d done it sooner.
If you’d like to see the new logo, check out Checkmate Chess Puzzles. The other logo options can be found on my Twitter @nomadjacob or @tangled_reality or on the app’s community page. You’ll be able to tell which was my original logo.
TL;DR
In case it isn’t clear, the main takeaway is to get started spreading the word about your game now. It’s never too early. Build a press page that focuses your vision. Start lurking reddit and following other game dev’s twitter accounts. Notice what works and what doesn’t. Put your demo out there as soon as it’s playable. Listen to feedback from your audience. They’re the ones that will ultimately decide if your game lives or dies. Join the game dev community. They’ll strengthen and guide you on the rough road ahead. Finally, have a bit of fun every now and then. You’re making games, so it’s almost part of your job to know what’s fun and that extra bit of goofiness will come through in a better overall game.
Have your own bits of advice? Made another mistake or just killed it the first time? Leave a comment! We’ve all got a lot to learn.
Be First to Comment