Ship it Fast - Why we developed and shipped a tiny game in 2 months

Before I get into the meat of this article, I’d like to offer a little context for our situation. Moth Likely is a brand new micro-game crafting studio based in Melbourne, Australia. Adrian Tosello and I officially formed the company in May while working on a number of prototypes. At that time it was our intention to explore potential aesthetics and themes that we are interested in crafting our brand and titles around. After a few months of prototyping and discussion, we realised that although making games we are passionate about is important to us (after all, creative expression is why we’ve both chosen to strike out on our own) we also need to validate the sustainability of our intended business model.

With this in mind, we set ourselves some goals: establish whether we can turn around a relatively polished game in 2 months; discover how hard it is to get a game of this scale on iOS in 2018; figure out how hard it is to implement opt-in advertising and in-app-purchases; collect data on what kind of organic reach we have as an unknown company and use this game to test a number of marketing methods/ platforms post-launch.

Here's the part where I shill the game for “context”! If you’d like to see the final product before reading on, you can download Oshka for free on iOS devices. For those after a TL:DP (too long didn’t play) version, Oshka is free-to-play, endless Russian Matryoshka doll stacker with a cute and minimal folk-art aesthetic. The goal of the player is to stack their Matryoshka as high as possible, collecting coins along the way to unlock new doll skins, with a secondary goal of exploring outer space and finding Easter eggs for the intrepid stacker.

Circumstance

It maybe goes without saying, but as a tiny company in its infancy, we weren't in any position to expend significant resources by purchasing data, nor did we have a backlog of titles to look at for guidance. Understanding our position and respecting our limitations, the goal of this project was to create something really small that would allow us to validate our business model. Additionally, we imposed a number of limitations on ourselves; those being a 2-month development timeline, a child-friendly aesthetic, a single touch input mechanism, as little text as possible and a portrait locked experience to allow for single-handed play. All of these decisions loosely followed our core organisational values, the main one being accessibility.

Compromise

Perhaps the most obvious thing about taking on a project this short and with such tight financial limitation is the sheer number of compromises we knew we would need to make. Coming into a 2-month project, we were very aware that our scope would need to be tiny. We knew to expect unexpected disruptions, design issues stemming from a lack of planning time, necessary but unplanned iteration and unforeseen systems we might need to include to address platform requirements, just to name a few. To experienced game developers this might sound obvious, but I’ve always considered game development to be an exercise in compromise, and my reason for outlining our more notable ones below is simply to give you an idea of what kind of compromises you may need to make taking on a similar project scale and timeline.

Throw unique mechanics out the window

Unique and exciting mechanics usually mean more upfront design, time required to implement, iteration cycles and testing time. We went with an automatic wobble on the dolls which required us to only need to check for a single tap input to trigger the doll launch. Our thought process here was with less time designing an overly complex system up front, the more time we’d have to implement and experiment with it.

Pick a simple art style and stick to it

Despite wanting to initially go down the path of a painterly traditional folk-art vibe for Oshka, I realised if we wanted to get it out the door in 2 months I’d need to simplify the style and make it as easy as I could to generate new art assets. This didn’t mean I had to skip the folk aesthetic entirely, but it did change how I approached things. To keep our art scope down we:

Crush your insecurities and perfectionist tendencies

Admittedly I struggled harder with this than Adrian did — he had spent the previous year doing a game a day/ week/ month regularly and had beaten his perfectionism down better than I had. In most cases we had to be comfortable making do with the first or second version of whatever it was we were doing, be that doll art, environment art, system implementation, etc… every time we found ourselves wanting to revise something we had to ask “is this worth it?”, “does leaving it as is impact our core goals?” and “will the benefit of this revision be measurable to us after launch?”

Cut content to MVP only

Initially we had planned for 15 unlockable doll skins at launch. Every few days we would revise this number based on how quickly I was getting through creating them, how much play time it was looking like it would take to unlock them and how much time it would take to implement them as in-app-purchases/ coin unlockable shop items. We also heavily cut down on how many environment Easter eggs we had planned for launch. Sure they might have been a nice polish addition, but most of our players wouldn’t ever see them.

Build a working system ASAP over an overly polished one

When Adrian was putting together the main stacking mechanic, he quickly built a system that validated our idea of how it would work. This system met our needs at that moment which as far as we were concerned would serve us until the end of the project.  With more time and planning the code could have been cleaner, but what was most important here was that it simply worked.

Go against what you believe is the best design implementation for one that works just fine

Of all of the compromises we made, this one was the hardest. We were pretty certain that this game needed a near miss mechanic and we tried to implement this a few different ways. Binary systems can be boring and frustrating. It is a well-known fact that success and failure is more meaningful when there’s a chance of an outcome that isn’t quite either — like small wins during major jackpots to encourage you to gamble again the next time. We got stuck on the best way to add a near miss mechanic for two weeks mid development and it became apparent that the systems we were trying would take too long to implement. Despite it being a more interesting design, we bit the bullet and cut our near miss system in favour of the simplicity of what we already had. We felt the near miss mechanic wasn’t ultimately going to impact our core goals of assessing market viability given our means for this project.

Mistakes made and lessons learned

What did we do right?

Main takeaways

Going forward from Oshka we have learned a number of valuable lessons and are continuing to try new things and collect data as we go. It is our intention to share articles regarding this data and those lessons in the near future. Our main takeaways so far are:

Ultimately everything that has come out of Oshka so far has reflected exactly why we embarked on the project in the first place. We set out to develop and ship a game in 2 months because we wanted to answer some fundamental questions on how we might go about being a sustainable mobile development studio in 2018.

We knew we wouldn’t find out what we didn’t know until we had put ourselves through our paces and we’d rather do that on something small than on a project we’d poured our heart and soul into for 6 months or more. Humans have a tendency to be terrible advice takers and despite having heard a number of warnings about the very mistakes we made/ lessons we learned previously, it only really hits home when you go through it yourself.

We are much better off having shipped Oshka. We have way more information than we did a few months ago, we understand first hand the value of a marketing first approach and most of all, we know we’re certainly capable of shipping a polished game in 2 months. If you’re a new team looking to validate the market, a business model or simply your own abilities, I highly recommend taking a similar approach.

This article was originally featured on Blog Likely the official blog of Moth Likely.