A year reflection on our first mobile game project

“It was critically important to expand beyond the world of Flash in the browser and we’ve succeeded on that front.”

We’re going to be moving onto exciting new things starting in 2017, but before we do, we wanted to share our development experience with you!

What Went Well?

The number one thing that went well was launching and updating the game with few bugs. We managed to assemble a great group of testers throughout development, which helped us crush bugs before they went live. This led to fewer bad reviews and helped BioBeasts keep a rating well above the 4 star mark. We feel that buggy releases are the top reason for low ratings, so we went to great lengths to avoid them, averaging around 3 or 4 beta releases before each live update, and spent several months in beta testing before the original launch.

In addition, people had great initial reactions to the game whenever they tried it. There was excitement and curiosity at what else the game had to offer, especially among our target audience. It was great to see the reactions of everyone trying the game out in person, in particular when the game was first coming together after spending weeks working on it by ourselves.

Finally, our team did an excellent job of continuously pursuing memory optimizations to make sure as many devices as possible could play the game well. BioBeasts had a small footprint and reasonable framerate even on low-end phones, which was critical for a fast, skill-based game like ours.

What Did We Learn?

From the start, we allocated a very short amount of time to create a playable game. Based on this limitation, we made the decision not to include certain time-consuming features such as cross-promotions with other Artix games, a central account system, social features, or a database backend.

One of our key lessons was that these are probably must-haves for almost any future mobile game, and not recycling these features from a previous project added substantial dev time. In fact, as BioBeasts showed initial promise, and the company allotted us an expanded timeline, we frequently found ourselves building things we originally said we would never build. In hindsight, properly scoping the game to include these core features would have saved us countless hours retrofitting.

"We frequently found ourselves building things we originally said we would never build. In hindsight, properly scoping the game to include these core features would have saved us countless hours."

Essentially, the amount of work needed to get ramped up and have a launchable game was greatly underestimated. Between implementing payments, ads, analytics, doing marketing, creating a website, learning Unity, and all the other things not directly related to making a game playable and fun, development took much longer than anticipated.

Our next lesson was that the core of the game -- wrecking robots as a beast -- needed to be great on its own and have enough longevity to work without other features. We still think it was solid, but we spent perhaps too much time building other mechanics to support this main concept, rather than focusing hard and polishing that one idea to a mirror sheen.

"When it was clear that we needed additional features to make the game successful, we missed an opportunity to retool and improve the core hook."

There was a point during development when the core gameplay seemed fairly solid and the team felt that we’d have a great game if we just added more enemies, levels, and Mutations. This put on us on a path that well exceeded the original scope, and in hindsight should have been a red flag. When it was clear that we needed additional features to make the game successful, we missed an opportunity to retool and improve the core hook. The call between reimagining what you have, and pressing forward because you can visualize what the game might be is a tough one, indeed.

Financial Challenges

As pressure for better financial performance increased, we felt there was never a good opportunity to stop game dev and add deeper data collection, especially to learn more about how people were finding BioBeasts. This led to long, mostly unexplained growth early on, with large numbers of daily installs we couldn’t account for. In the first 5 months following launch we were optimistic and attributed this growth to the game’s quality and overall positive reviews, but suddenly our install rate fell heavily, and we could not explain why. After following up on several theories as to why BioBeasts saw a sudden 85% loss in daily installs, we were unable to find any specific explanations.

This lack of data made it difficult to recover the game’s traction. We were unable to justify paid advertisement as 5+ promotional trials failed to recuperate the investment, and our efforts to promote BioBeasts organically had similarly decreasing returns. In the future we believe our games must be able to deeply track where players are coming from so that we can adjust our strategy and the game to fit them better.

"We were unable to justify paid advertisement as 5+ promotional trials failed to recuperate the investment, and our efforts to promote BioBeasts organically had similarly decreasing returns."

Along these lines, we learned that relatively strong install numbers and a good rating did not directly result in strong sales. Initially, well under 1% of BioBeasts players spent any money. The team spent a lot of time overhauling our sales mechanics to both keep the game interesting and allow players to spend more money if they wished. Unfortunately, by the time our improvements went live, our high install rate had dried up and while our conversion rate increased 2-3x, the game never reached a sustainable financial state.

Unity Engine and the App Stores

Our goal was to prove we could move away from Flash and create something fun for the mobile market. We felt in the long-run it would be a critical mistake to focus on a single platform so we selected Unity as our cross-platform development engine. We wrestled with the idea of proving ourselves first on a single market, but didn't want to miss an opportunity if things went well at the launch. Given our minimal experience with either store, we decided to pursue both the Google Play Store and the Apple App Store from the outset of the project. In hindsight, for our first mobile project, this was probably a good decision as we would have made plenty of mistakes and created tons of rework later if we did need to port. However, now having leveled up a within the mobile world, we might do things a bit differently.

For starters, we learned that Apple and Google are vastly different worlds. It felt as though Apple almost requires you hit the top charts in order to be successful. There appears to be little middle ground, you either are top dog or you hardly exist. Google seems like a better option for getting discovered as a smaller player in the market. Whereas Apple seems more ideal for large studios and companies that can money-blast their product to the top of the charts, Google’s tools and overall design seem to support faster iteration and made it much easier for us to get updates out. As a specific example, when our team discovered one of our only critical bugs that ever actually made it live -- despite 2 or 3 beta builds -- we worked together with our testers and had a patch ready that day. On Google, a fix was simple: push the build out and players have it in a few hours at most. On Apple, however, the process was significantly more tedious. It took over 12 days between submission and verification to get the patch approved and released.

"In hindsight developing for Apple really slowed us down as their processes take a lot longer and only provided about 10% of our total installs and sales."

In general, developing for Apple slowed us down quite a lot, and only accounted for roughly 10% of our total installs and sales. While it was easier to test across a much smaller variety of devices, the publishing process was far more convoluted and often cryptic. If we were going to try a smaller game in the future, we’d likely start on Android, and port to iOS if we saw proper traction.

What would we do differently for future games?

There were a couple standard practices we specifically decided to buck in order to have a game that stood out in the ever-crowded app store:

• We opted to deeply link your skill to your progress/currency, and to have no paid-only currency.
• We shot for difficult, repeatable levels instead of many easier levels due to time constraints.
• We were trying to balance skill-based depth and challenge with more “casual” preferences and wider appeal.

Linking skill so tightly with progress had a couple rough consequences. First, it created a huge difference in how quickly someone was able to buy stuff. It allowed very skilled players to absolutely blow through the content, while lesser skilled players may have become bored or frustrated from lack of progress. It became impossible to balance the prices of shop items when our best players could gain BioBits dozens of times faster than newbies: everything was either too easy for our veterans, or might sticker shock others out of playing. In the future we would like to keep everyone on a more level playing field when it comes to purchasing things, while giving expert players other ways to show off their mastery.

Next, because we didn’t have time to build out 200 levels a la other mobile games, we opted to build a few levels that would be random enough to stay interesting, and change as players progressed through the difficulty modes. While some took to this challenge, many others were turned off by it. It was also difficult to play for just a few minutes, which is the way most of us want to play mobile games. Finally, it led to many players feeling like they were making no progress, even after several attempts at the game. We now believe it is helpful (or even paramount), at least in the beginning, for players to make consistent, noticeable progress. The exception is if you make it very, very clear that the game is designed to be difficult on purpose (a game that rhymes with Bark Goals comes to mind), but that’s likely a niche audience on phones.

"We now believe it is helpful (or even paramount), at least in the beginning, for players to make consistent, noticeable progress."

We chose a path that almost required the game to be difficult so that it would last longer than an hour (a no-go for free to play), while trying to appeal to a wider audience that generally doesn’t look for difficult games. This muddied our goals a bit, and made it a tougher sell for either group. It also made it tricky for the artists to pick a singular art style to match the game’s tone. While we received numerous compliments on the style and look of the game, it may have been even more cohesive if we went all-in on cutesy, or gritty, or violent, or whatever other style served the game best.

What's Next?

2017 is certain to be exciting and there are many opportunities for all of us moving forward. We’ll be looking to Artix for direction on where to go next. It is our intention to build on what we’ve learned and share our experience with rest the company. Once again we want to extend an EPIC thank you for your support, testing, feedback, and patience as you’ve given our team the runway to make games and learn along the way. We’re excited to see where 2017 takes us, so stay tuned for our next update! We wish you the happiest of holidays, and a super new year!