📱 I made my first mobile game and here is what I've learned

After 3 years of nights and weekends working on my friends and my first ever mobile game, I am pleased to say that it is finally released on Google Play. It's a simple dice/board/strategy game with online play. The focus of this post is not the game though, but please check it out and leave your feedback. Your comments are much appreciated! 💖

Why did this simple game take 3 years? Here are the top reasons:

• We didn't have any experience making games
• We didn't have an artist, so we had to do everything ourselves at first
• We started with a game that was too complex for a small part-time team
• We rebuilt everything 3 times because we weren't satisfied with the results

Now that the game is finally published, I want to look back and answer the question: "What did we learn today?"

Forget everything else: test your core gameplay loop ASAP

You may have heard this advice many times before. Well, here it is again because it is just so important: test your core gameplay first! What is "core gameplay"? It's a combination of core game mechanics and graphics/animations that bring those mechanics to life. Mechanics alone are not the full experience, and it is pointless to test them in separation.

Here is what you need to do:

• Define a minimum representative set of mechanics
• Sketch out the animations that will make those mechanics feel alive/interactive
• Put it all together in a small publishable prototype
• Connect Firebase to your prototype and add as many events as you can
• Get some of your target audience to try it out

How do you know your gameplay is good?

Some of the metrics you can use:

• Mean / average time spent daily playing your game prototype (anything above 10 minutes is good)
• Second-day retention (anything above 30% is good, above 50% is amazing)
• Second-week retention (anything above 10% is good, above 20% is amazing)
• How many actions are players making in-game (are they idling, reading, or actually playing)?

Gameplay is fine, and you are committed? Set up infrastructure first

Before you start building a complete game, get the boring parts out of the way. Here is a list:

• Analytics. We use Firebase and it's awesome, but it has its limitations.
• Authentication. Firebase or PlayFab are good choices.
• In-app purchases. Use Unity IAP directly or with PlayFab.
• Ad networks. AdMob is a popular choice, but there are simpler SDKs like IronSource
• Logging. If an error happens, you want to be able to find exactly why it happened very quickly. We log to Seq via custom infrastructure, but there are more streamlined solutions for mobile apps.
• Privacy policy, terms of service, data deletion policy. These are all required by nearly every service and should reflect the reality (don't just copy-paste somebody else's policy - read it through).

Why do these first and not the game itself? All of these things require understanding and integration with external SDKs. If you are not familiar with them or aren't aware of changes in the latest versions tracking down these problems closer to the release date will be very distracting. Before the release, you should focus on the game and first user experience, not on the complicated infrastructure. It should be working like clockwork by then.

Focus on first user experience at least 25% of your dev time

This is a big one that most developers ignore. How your game is experienced by new users that just installed it is everything. Is the entry compelling enough? Does it draw players in? Do you explain the mechanics well? Is the tutorial engaging/interactive or a wall of text?

Remember, people that just installed your game have no idea what's behind the first screen. They don't know the mechanics, and they don't know if there is amazing art behind it. You have 1 minute at most to capture their attention and convince them that your game is worthwhile.

Test your game as if you just installed it as much as you can. If your eye gets "sore" from repeating the same thing too many times, step away and come back later. Ask your friends to play through the first 5 minutes. Make a diagram. Anything to make the first few minutes spent in your game fun, compelling, engaging, and educational enough.

What's your user acquisition strategy?

Most games have a very narrow set of players. You might think that your game is for everyone, but that is far from the truth. Even behemoths like Candy Crush have a limited set of players that are dedicated to it.

Find your niche, your average player. Your audience should be as narrow as possible. Expanding is always easier than contracting.

How do you find your audience? One trick is to set up super targeted campaigns on Facebook (think 10,000 people) and test out your core gameplay on them. Pretty soon, you will have a clear understanding of the markets where your game is doing well. Focus on those.

If you have tens of thousands of $ to burn, you can always target a large set and let analytics tell you who your players are, but that is prohibitively expensive for a small indie team.

No, seriously, you need a user acquisition strategy yesterday!

Besides paid ads (and those take a lot of effort to do correctly as well!), where are you going to find your players? It is a question that you cannot leave unanswered. Start doing your research before you write the first line of code.

Good code is good, bad code is bad

Unity is great as an engine, but don't follow the examples in the documentation. Most of the time, they are not meant for production. Even the sample projects that ship with it aren't great.

The best thing Unity did recently was open source collaboratively-made games. The initiative is called "Open Projects," and you can find the first one on GitHub. It has a well-thought-out architecture and is very easy to understand. You can't go wrong with learning from it.

The key thing to remember is that bad practices are still bad practices, whether you are doing game programming or web development. If somebody tells you, "here is how you do it in Unity," but things don't feel right - chances are there is a better way. Tightly coupled code, "god objects," methods of 1000 lines of codes, violations of SOLID principles are just a few things that you should avoid.

Thank you for reading! Make sure to check out our game on Google Play.

Peace!