Game dev: From zero to App Store, as a side project. How and why.

Marco Bellinaso
15 min readMay 6, 2020

--

Developing a game is a challenge on its own, and more so if you do it as a side project while working a full-time job. And maybe have a family. This is my story for Yuppy, a collection of mini educational games for iOS and Android. Why I made it, the struggles I faced, and how I eventually managed to finish and actually sell it.

A video intro of Yuppy

Around mid-last year I was on the search for something new to study to keep me busy after work, and the desire to make a game rose again from the back to my mind, after having tried multiple times in the previous years, always unsuccessfully for various reasons (poor/difficult tools for my skills, lack of people to work with, etc.). This time however I decided that if I was going to start it, I had to finish it (meaning, it had to end up in the App Store, and people had to be able to play it for real) because I could not tolerate yet another failure. I was conscious of the constraints I had to respect:

  1. It had to be something that I could do alone, because I didn’t have anyone to work with. It’s difficult to find people willing to do side projects in the first place, but even if I had found someone, I just didn’t want to depend on someone that might not be driven or serious enough about it, or maybe didn’t want to put in the same effort, or that maybe was simply ok to do it in a super chilled way and finish it in maybe one year. Knowing myself, if I don’t manage to finish something in some way (an MVP worth releasing) in 3 months, I quickly start to lose interest (and hope). So I didn’t want to have external dependencies, and nobody but myself to blame.
  2. Opposite to number #1 in a way, I also didn’t want to be someone else’s regret, in case they were quicker or more skilled / more driven / with more time to devote than me.
  3. It couldn’t be something that required unique and custom hand-drawn art, because I couldn’t do it myself and couldn’t afford external paid help. It had to be something that could work decently with stock art or a ready-made design purchased from one of the many websites available for this. Same for music and sound effects.
  4. It couldn’t be something that would take too many months or years even for an initial release. And that would need to take into consideration that I was basically starting from scratch completely with Unity, as the previous prototype of years before was super basic and done almost randomly, without much technical understanding of how everything works and fits together. I also had to consider that one month of effort full-time (8hrs/day) would have roughly translated to three months for me, working in the evenings and weekends (I cover this aspect in more detail down below).

In addition to all the above, if I had to spend my free time to work (I love programming of course, but it’s definitely not as relaxing as watching a movie on a couch) it had to be something with purpose, not a game that people might use to kill 5 minutes of downtime. I wanted to make something educational and targeted at children….and that’s how Yuppy’s idea was born: it would be a collection of mini-games, to learn to write, count, play music, develop brain skills such as spatial and abstract thinking, etc. Well, put that way it sounds big, but in reality I just wanted to make something small, but still useful for kids and their parents.

And so it began…

How I approached the new game, starting from scratch

If you want to actually finish something that you start as a side project, optimizing the time that you spend on it must be one of your top priorities. In addition to my own experiences, I saw many friends falling into the trap of beginning something by trying things in a random way, starting over a few times as they discovered new and better way of doing something, and eventually giving up because they didn’t see enough progress and had consequently little satisfaction and motivation.

My approach when I start something with a tech stack I’m not already familiar with is the following:

  1. Analyze and decide which tech I want to use, according to the required knowledge, complexity, cost, and the quality of results that can be obtained. There are many game engines, but the two leading ones are Unity and Unreal Engine. Both can be used for pretty much any type of game — maybe unless you intend to do an AAA game — but Unity felt much more approachable to me, also in terms of availability of easy tutorials and content of various types. As mentioned before, I had a few friends successfully working with it already, so picking it was an easy choice. And I’m super happy with it, considering how straightforward and pleasant it is to create screens visually with customizable prefabs and standard objects (in my case they are all simple 2D scenes, but creating 3D environments is not too different in terms of approach), set up, tweak and preview animations and particle effects, and just generally try out something you’ve done by hitting Play and using the game one or a few seconds after (how long it takes depends on the complexity of the scene, number of assets to load, whether the scene can run independently or it needs to load other beforehand, etc…but in my case it has been super easy, especially compared to the typical “write code > compile > launch sim > upload build to sim > run > test” process with native iOS or Android projects).
  2. Study everything I can find about the topic, to get a decent high-level understanding of how things fit together, and how common problems are solved. In the case of Unity games, this means understanding scenes, game objects, coordinates, cameras, prefabs, animations, sounds, movement, colliders, rigidbodies, the physics engine and the GUI system. I know that many will say that practical experiments are unavoidable, but for me that only happens after studying as much as I can first, because that allows me to try things that I more or less understand in theory already, so that hopefully when I try something it’s going to be correct in terms of approach. This doesn’t mean that I won’t find many obstacles along the way, I definitely will…but at least I try to minimize the chances of going down a completely wrong route, or one that will be limited by technical constraints and that will require a hack after another to progress, if not to throw everything away and to start from scratch. To give you an idea, I think I spent at least one month at this stage, watching plenty of videos from Brackeys, Code Monkey and Blackthornprod, as well as taking this short Udemy course and part of this longer one. In general, I greatly favor video tutorials over books or articles for topics like this which are highly visual, and when possible I favor a complete course rather than many videos from different authors, to ensure the level of depth and style are consistent, the content has fewer repetitions and is already organized in a way that makes sense, and examples grow over time to cover new things by building on top of previous ones rather than starting from scratch every time.
  3. Start some light prototyping of a base idea to get myself familiarised with the new environment/tech. In my case, I started by re-doing the Animal Sounds mini-game I did a couple of years ago while learning React Native (article here btw). It was super simple, it didn’t have much logic and all the UI was statically built with the Scene Editor, but it still allowed me to learn how to make scenes, game objects, customizable prefabs and scripts, as well as some light animations and sound handling. It was also great to see how it took me something like a couple of evenings to do all this (by reusing all the assets I had from previously), rather than the many days I spent for the original RN version. Unity was already showing its power, even for something this basic!
  4. Move on to something more complex, add more and more features and details (eg: new logics or mechanics, sounds, animations, etc.). Yuppy has turned out to be a collection of as many as 10 mini-games as of now, so after the first one I had plenty more to work on, and most of them taught me something new I hadn’t done before (which also helped with keeping the project interesting, because not learning equals boredom).
  5. Finish it off with the final graphical assets and sounds, but also things like analytics (with Firebase and Facebook), the parental gate (in the case of a Kids game, but it could be settings, leaderboards or other auxiliary functionalities otherwise), the loading screens or progress bars, the support of In-App purchases for unlocking protected content (greatly simplified by using RevenueCat by Jacob Eiting), the terms and conditions, the landing page, the screenshots and App Preview videos for the app stores, the compilation and packaging for both iOS and Android…and of course the process of ironing out all bugs founds by the friends that got the initial beta and possibly some performance optimizations. If all this sounds easier or quicker than creating the actual 10 mini-games, it means you’ve never heard about the 80/20 rule…Because I can guarantee that this part will be massive and actually the part in which you’ll start to hate the whole project and just desire to either finish it quickly and forget about it…or burn it and forget about it.
  6. Fortunately this time I managed to finish it…then forgot about it for a short time…until I realized how cool it was to have made something completely by myself that people could use and enjoy. Several people actually enjoyed it so much to decide to pay for it, and I can promise you that it gives incredible satisfaction and boost of energy. It’s not about the money (which is still very negligible considering the absolute number of downloads and sales), but it’s really about the realization that you’ve built something that people consider worthy of giving you money for. In fact, I personally think it’s even more satisfactory than earning more but from tricking people in clicking annoying ads.

How to do it as a side project, with limited time?

So, you and I have a full time, 8hrs/day job, and we want to do something else (a game, but another kind of app as well) on the side, right? With a limited amount of time, and possibly other chores to look after (family and children? a partner? friends that you really like and that want to see often? A huge house or garden that require constant maintenance? gym every day? a local sports team you coach?) it’s going to be a challenge. Heck, it’s a challenge even without all those additional things…
Here are some things that I considered, and that allowed me to handle it:

  1. You can’t do everything. You’ll have to pick some things, and leave out others, unless you want to burn out quickly or unless you know for sure that your body and mind can do well with a few hours of sleep per day and for a prolonged period. For me, sleeping less 6 or 7 hours per night just isn’t going to work well. I can’t and don’t want to take time away from family, so I had to cut other hobbies like reading novels, playing video games and watching Netflix. I’m starting something again now, but I stopped those activities for around 6 months. And that hurts and can stress you.
  2. Try to define a plan and stick to it. For example, say that you’ll work from 11pm (after family goes to bed) to 1am, and wake up at 8am (that’s what I do, as I don’t have commute time and can wake up rather late, but going to bed earlier and working from 5am to 7am might be another option if that fits your schedule better). That’s 7 hours of sleep, and 2 hours of work during the week. Maybe you can put some extra work during the weekend. Once you’ve decided, try to actually work in those slots regularly and make as few exceptions as possible. If you start skipping one day, that can easily become two, then a week, then 2 weeks, and all of a sudden you’ll realize that you haven’t worked on your project for so long that you’ve forgotten details about it, the original idea doesn’t make much more sense or doesn’t seem that interesting anymore, and you’ll just find other excuses to quit.
  3. Use your time wisely. If you’ve got 2 hours a day, really focus on your project without distractions in that time, don’t check out social media o jump from video to video. Make a list of things you want to accomplish at least at week level, if not more. This will help you to keep on track, and to realize soon if you’re slower than anticipated, so that you can change your plan accordingly, or maybe realize that you’re wasting time in ways you can avoid, and fix that soon. As mentioned previously, I also study everything I can about the tech and my specific idea as the very first step, to avoid working on approaches that might quickly turn out to be roadblocks. In case you get stuck with something, ask questions on dedicated forums (eg: the official Unity forum), Stack Overflow or in the comments sections of YouTube videos you watched. Or ask friends and colleagues that know about that stuff, if you’re lucky to have some that work in that area.
  4. Make an estimate of the work required, calculate the required elapsed time, and decide if you’re ok with it. The sample plan above corresponds to a total of around 16 hours a week, which equals 2 full-time days. It’s not bad at all, because it means that if a small game could take 1 month to develop if you worked full time, it would take 3 months in this way, which I think it’s very reasonable. A 2 months game would take 6 months, which is still something you can handle with enough will power. There are also smaller games or projects though, which could take 2 weeks working full-time, and the time working part-time would change accordingly. As an example, Dani (another YouTuber I follow) made this small but nice game in 1 week. I consider myself decent at making estimates that aren’t too off the reality, but if you have less experience or are starting with something that you really don’t know anything about (let’s say you have very light programming background in general, because you work in another role) it’s easy to severely underestimate the work, which means that after the 3 months of work you initially estimated, you might figure out you’re only at 30% of the project, and at that point you give up because you can’t take it for another 7 months!
  5. Either do a very small game…or plan from the beginning to split your grand idea into multiple releases which will add levels and features incrementally. This is a great idea in all cases, so that you can start testing the game with some people and see if they like the overall idea. But it’s also good to avoid the problem above, because releasing soon will give you the boost you need to keep going. I’ll say this again: releasing something to the app store, publicly, for people to actually download and play, is super powerful. It gives you confidence and it’s actual proof that you can do it. Ideally try to have something out within 3 months (or less, depending on the level of knowledge you start from). Even before the initial public release, show it or give it to friends and family for some early feedback. Friends and family feedback can’t be trusted that much, because it’s unlikely that they’ll tell you your game sucks — even if it were true, if a friend tells you that, change friend because that’s not what you need in this stage of the project. It’s more important to see that you’re able to finish something, rather than the actual beauty (or playability, fun, etc.) of it. Many first efforts won’t be that great, but that’s not the point, you will improve for sure if you don’t give up.
  6. If you’re not an artist, look for stock images/sounds/music whenever possible (there are plenty of websites, but I recommend Vecteezy for vector graphics as it’s rich of content of with a great price), seek external help for the most imporart parts (maybe the app store icon), but for the rest try to keep it simple. There are many casual games that succeeded despite their very minimal art.

Conclusions — Is it worth it?

As I hope I made clear thus far, creating something more that’s more than a prototype, something that’s in a state you can publish, is a lot of effort, and you might ask to yourself if it’s worthwhile investing so much time and energy into something that might very likely give back zero in terms of money. And if you talk about money you’d be correct, there would be much easier ways to make some extra cash, such as doing some freelance work.

A lot of freelance work that you can do on evenings or weekends though is going to be small projects, for small companies or individuals that need something but they can’t afford a real consulting company with all the overhead that comes with it. They just want “some guy” to “make it work”. The problem is these clients are typically non-technical, they are cheap, don’t have clear specs, and so on. So doing this kind of freelance work is the perfect way to get stressed for a few bucks, not doing much interesting. For me, after working 8hr/day on something cool and with a huge scale (see at the bottom of the page), I have zero interest or willingness to do any of this. Unity and game development is something completely different from what I do at work, it’s something new and exciting, it keeps me active mentally and I simply enjoy it, so it’s worthwhile regardless of the money (or the lack thereof).

Your mileage will vary according to many aspects (your financial situation, the type of work you already do at your real job, etc.) so I can’t answer it for you. I can only say that I would hardly consider it “wasted time”, even if it was just for the experience you’d gather about a new technology, publishing to a new type of audience, releasing on a few different stores.

Many people, myself included, are not naturally keen on publishing MVPs, or unfinished/unpolished work, or generally work that they don’t feel very proud of, that they don’t consider up to the standard that they work at their regular job. They are afraid something like that can damage their reputability and public image. Forget about all that. This is not your regular job, you’re not paid to do it and nobody but you can decide what is worth publishing. It’s something you’re doing on the side, at night and in your free time, to have fun and to learn something new and exciting. Being new for you, you’re justified for not doing top work. Also know that just for the fact of doing it, you’re above the average person that thinks they can do anything and are quick to judge others finding issues of all sorts…but don’t do anything themselves.

You have all the reasons to be proud of what you did if you manage to finish something. I’m proud of what I did, and so will you. And this is enough to make it worth it.

Call for help

After all the work on the game, and some attempts to spread the word about the game, it’s obvious that I still need to nail marketing and strategy :| (I know some of the theory behind “building an audience”, but it’s easier said than done :)
Any idea, suggestion, help that you can offer, it will be super appreciated ;) Use the comments below, or ping me directly on LinkedIn or Twitter.

In return, you’re welcome to add a link to your game/project and describe your experience as a comment to this article :)

Who am I and what do I do? As it should be pretty clear by now, Yuppy and Unity are my current hobby, but I proudly work as a solutions architect in the Mobile Team @ ASOS.com (iOS app | Android app). ASOS is the biggest online-only retailer in the UK and, let’s be real, the best tech and fashion company in the world. Some of the technologies we use are Swift for iOS, Kotlin for Android, React and Node on the web front-end, .NET and Azure on the back-end. If that sounds interesting to you and you happen to live in beautiful London (or are willing to move here — after all, it’s the best city in Europe, except for some in Italy!), do get in touch!

--

--

Marco Bellinaso

Principal Architect @ASOS.com (and iOS / full-stack dev for fun)