A little over a year ago, in August 2018, I started working on a small puzzle game for iOS. I’ve been steadily blogging about it along the way – from this first post (where I naively thought I’d finish and release the game in 2-3 months) to the previous most recent post (all about the push to get it finished enough to submit to TestFlight and start beta testing). And now, after tons of improvements and bugfixes throughout the beta testing process, I’m ridiculously happy to say that the game is now available as a free download on the iPhone App Store! Check it out here: https://apps.apple.com/us/app/bitey-trees/id1461650704
It’s been a long road – admittedly much longer than I thought it would be when I first got started. But it’s also incredibly satisfying to see something I made on the App Store, and to know I can see a project like this all the way through to release.
The TestFlight beta started in late June, and the game went live on the App Store on September 24th – So in this blog post, I wanted to take a look back on how the beta testing process went and all the changes made along the way.
Recruiting Beta Testers
Once I’d successfully uploaded a build to TestFlight, I initially only added my mom and two other close relatives. The idea there was to start with a small pool of supportive people I could talk to face-to-face, and identify any big game-breaking bugs or other serious issues before rolling it out to a larger pool of testers.
As far as the actual recruitment process to try to find that larger pool of testers, I created a simple signup page using Google Forms and linked it here on this blog (see the end of this post) as well as posting it on Twitter and on my personal Facebook account. From there, I would manually add them in on TestFlight, which I ended up doing at a fairly slow and controlled pace.
My whole mindset was that the ability to get someone’s first impression was a very valuable thing – and if I sent a new tester a version of the game with some known issue that I’d already decided to make changes for, it would be like “wasting” a potential source of new feedback. Looking back, I’m not sure this was quite the right approach, mostly because it sometimes resulted in a long gap between when testers would sign up and when I actually added them to the beta (to the point where a few people reached out to ask if they’d missed the invite).
So, this is probably something I’ll want to revisit and see if I can handle a bit more gracefully in future games. In the end, though, I ended up with 17 beta testers total – which may not sound like that many, but a high percentage of those provided detailed, actionable feedback which was invaluable for improving the game and squashing bugs.
Changes Made During The Beta
Over the course of the three months that the game was in beta, it went through 13 builds, each with various improvements and bug fixes. In this next section I’ll take a look at the changes made, starting with new features and then moving on to the bug fixes.
In the last update, I mentioned that the plan for monetization for this game was to release it for free and then take a purely voluntary approach – at certain points in the game, the user would be prompted to either watch an ad video or make an in-app purchase in order to proceed through the game. The ad video was implemented early on, before starting the TestFlight beta, but the in-app purchase was something I didn’t get around to adding until TestFlight build 6.
Part of this was procrastination – I’d never implemented in-app purchases for iOS before, and had heard that it could be a royal pain to test the functionality because it required a test account with a verified email address… And you could only test the initial purchase once from that account, because after that it would become a matter of “restoring” the purchase instead.
All in all I did end up going through four test accounts requiring four different email addresses (all temporary throwaway ones added on the same domain as this blog)… But other than that, it wasn’t nearly as difficult or time-consuming as I might’ve feared. Here’s what the final version of the “monetization popup” looked like:
During the beta I also learned that my original design had some flaws – permanently locking off certain levels based on either the ads or the purchase ended up running into the problem that sometimes it was impossible to load an ad, either due to network issues, or Google AdMob failing to “match” the user with an ad, which I didn’t even realize was a possibility at first. So the revised system ended up being based on a timer that keeps track of elapsed gameplay time, with fallbacks to gracefully handle the scenario where an ad couldn’t be loaded, so that the player wouldn’t be completely blocked from progressing through the game.
My goal for the initial release of the game was to have 18 levels across two distinct areas. At the start of the TestFlight beta, there were only 9 levels and a single area, so that meant creating double the amount of content. And, importantly, I didn’t want the next 9 levels to be exactly the same as the first 9 levels – I wanted them to introduce some new mechanic to keep things more varied and interesting.
And so the “treasure pickup” mechanic was born – on levels 10 through 17, there is a treasure chest that you need to move to and collect. The tree monsters will also spread across the map, and if they consume the treasure before you get to it, it results in losing the level. Here’s a look at one of the levels featuring a treasure chest:
In retrospect, I may have rushed the treasure pickup feature a bit, and it ended up shipping with at least one bug that needed to be addressed in a future update… But more on all of that later.
Aiming System Changes
Ever since the earliest versions of the aiming system, it used a setup where you would use a pan gesture to aim, and then when you end the gesture, it immediately casts the spell at the selected target. This worked reasonably well, but had the problem that it was impossible to cancel or switch spells once you’d started aiming. A few testers expressed frustration with this, since it could make the difference between winning or losing a level.
So in TestFlight build 10, the aiming system got a major overhaul. Ending the pan gesture no longer immediately fired off the attack, but instead left the game in an “aiming in progress” state, and from there you could pan again to adjust the aiming trajectory if desired. While in this state, a different spell card could also be selected, and a “cancel” button would also appear to allow the spell to be cancelled entirely.
It may seem relatively minor, but in a lot of ways this was a turning point as far as deciding what the game was going to be. Was it more of an arcade game centered around reflexes and making the right gestures correctly on the first try, or was it more strategy oriented, allowing you to take your time and plan out your moves? This change placed it much more firmly in that second strategy-based category.
There were a few cosmetic things that changed over the course of the beta. For example, the world map got a bit of a facelift, adding some additional detail and removing the unnecessary placeholder map markers that didn’t actually lead anywhere:
The magic cards also got an improvement. From the time they were first introduced, I had them set up with backgrounds that were pretty much identical other than the color – just sort of a generic wavy pattern. In TestFlight build 10, these were upgraded to cards that were designed to be more aligned to the element of the spell card.
There were some other changes that would be visually apparent, such as adding a slight drop shadow effect to the level description area. But these were mostly minor cosmetic improvements compared to some other bugs that had the potential to impact gameplay, and definitely needed to be fixed before release.
Display Bug Fixes
Throughout the development process, I’d been testing the game almost exclusively on my own phone - an iPhone XS. Early on in the beta test, I came to realize that this had led to some display bugs on different screen resolutions. For example, here is a screenshot my mom sent of the monsters overlapping the spell panel on an iPhone 6s:
Luckily, I had an iPhone 5c in my possession due to compulsively hoarding all of my old iPhones every time I upgraded, and it made a good test device – pretty much a “worst case scenario” of small screen sizes these days. The only drawback was the way it couldn’t be upgraded past iOS 10.3, and as a result didn’t have the feature I was using to display multiple lines of text that was only added to SpriteKit in iOS 11+, so I had to set up a custom solution for that.
After lots of testing and adjustments, the game was looking reasonably okay on a wide variety of screen sizes – from the tiny iPhone 5c to the comparatively giant iPad. Here’s a collection of screenshots showing the adaptive approach I took with it:
Rather than scaling things up or down, all devices display the graphics at the same size, and just space them out differently in order to adapt to the screen. (With a few exceptions kicking in for the smallest screens, since there would be no way for everything to fit otherwise.) This was admittedly a bit of a headache to implement and test, but I think it resulted in a nice crisp feel and I was pretty happy with how it turned out in the end.
More Serious Bug Fixes
Since this was my first SpriteKit game (and first time creating an iOS app of any kind), I was a little surprised that there were very few actual crashes. There may have even been zero throughout most of the beta, until I got too complacent and introduced a pretty spectacular memory leak somewhere around build 11.
But that isn’t to say there weren’t any game-breaking bugs that needed to be addressed over the course of the beta. There were actually several different bugs that would result in the game getting “stuck” in an unplayable state – not actually frozen, since sprites would still be animating and such, but where the game would no longer be responding to input correctly, making it impossible to continue playing. (At which point an actual crash may have been better, since not all of my testers knew how to force quit an iOS application so they could re-launch it fresh.)
Some of these bugs ended up being a pain to track down due to being difficult to reproduce. One in particular would only happen sometimes over a slow network connection, but not in airplane mode. Slowly but surely though, I was able to track them down and get them fixed… and while version 1.0.0 submitted to the App Store wasn’t completely bug-free in hindsight, it was at least mostly free of these kinds of big game-breaking bugs.
App Submission & Review
Late in the evening of September 21, a little over 13 months after starting this project, I finally submitted version 1.0.0 of the game to the App Store for review. It was a big milestone, and I commemorated it by posting a photo of the submission page and its screenshots, complete with fancy Instagram-style filtering, to Twitter.
Unfortunately, though, this first submission was ultimately not approved. The reason was given as “Metadata Rejected” – the app was submitted as having an in-app purchase (Remove Ads for $1.99), but I had failed to include any instructions on where/how to access the in-app purchase, and the App Store reviewers evidently couldn’t find it.
I’m not sure how common this is (e.g. if a lack of instructions wouldn’t have been a problem if the game had a big obvious “Shop” button on the landing screen to shove a bunch of microtransactions in your face)… But at the time it felt almost like a compliment, since I had wanted the monetization system to be as low-key and unobtrusive as possible for a free-to-play mobile game, while still having a non-zero possibility of maybe generating a little side income.
Since this type of rejection didn’t require you to submit a new build, I went ahead and wrote up some instructions on how to get to the in-app purchase, along with an uploaded image containing some additional notes and screenshots, and then re-submitted it.
At this point, though, I was pretty nervous that it would be rejected again. Specifically, I was worried that it would be a problem that there was no menu that allowed you to directly access the in-app purchase at any time – with the way I had designed it, the in-app purchase manifests as levels sometimes being “locked,” and will only pop up at certain intervals.
I preemptively devised an idea for a dedicated menu for viewing the in-app purchase status, and started estimating how long it would take to create (and how many more dummy email addresses I would need to test it fully)… Which led me to feeling a little bummed about how much it would delay the release of the game when I thought it was so close.
But then, happily, it was approved the next day! I had selected the manual release option, so I had the joy of clicking the release button on the evening of September 24th (though it took another day or so for it to fully propagate to the App Store.)
Trying to actively promote this game and reach a large audience hasn’t really been a big priority… In fact, the total number of downloads it’s gotten as of this writing (a few solid weeks after release) is so low that it’s almost pitiful. I announced the game’s App Store launch on Twitter and on my personal Facebook account, and have happily told various “real life” friends and acquaintances about it, but beyond that haven’t engaged in anything resembling an actual marketing campaign.
Although that’s not to say that I haven’t done any marketing activities – since this is my first game, I wanted to practice doing the kinds of things that would be needed for any serious game launch, such as creating a marketing website. I had snatched up the domain biteytrees.com shortly after deciding that’s what I wanted to call the game, and after letting it sit empty for many months, finally set up a simple HTML website shortly before the release:
I had also been collecting email signups here on this blog (using the MailChimp form in the sidebar) for over a year, and had actually built up a small handful of subscribers… Who I had never sent an email to, and who were probably starting to forget that I exist. So this seemed like a good occasion to send out my very first email newsletter:
Based on the above it might be clear that I have no idea what I’m doing on the marketing front… But even these few little things are a start, and I feel like it’s valuable experience to start dabbling in them. And I’ve been kind of thinking of the release as only the beginning – now that there’s an actual game to link back to, I can continue experimenting with different methods to spread the word and promote it to a larger audience.
Reviews & Feedback
Even though the total download count is low, feedback received on the game so far has been overwhelmingly positive. As of this writing, the game has received 10 ratings (including 4 written reviews), and is currently sitting at an average of 5 stars. Which seems amazingly high for a game made by one person working part time, with simple 2D graphics and a relatively small amount of content, in an App Store where it has to compete against games built by actual studios with many more developers and resources.
Granted, at this stage, I suspect that the ratings might be somewhat skewed in favor of people who were already interested or following along with the game’s development prior to release, and that the overall score might even out a bit if or when the game ever finds a larger audience. Still, it’s a really good feeling that those few people who’ve downloaded the game seem to be enjoying it!
And now for the most exciting part of this post – now that I’ve fully released my first game on the App Store, what project will I be focusing on next?
In the short term, I plan to continue working on Bitey Trees for a while longer, and put out a few more post-release updates to add more content and features, and of course fix any bugs that may come to light. (In fact, this has already started – in the time between release and how long it’s taken me to write this excessively long blog post, I’ve already released the first update, which adds a high score system!)
At one point, I wanted the game to have around 90-100 levels total for the “final” version, with a steady stream of new mechanics introduced along the way to keep things interesting… Plus I have a ton of ideas for things like spell upgrades, collectibles, bonus levels, other types of maps to explore, and in all likelihood way more features than I could ever realistically implement. I’m not sure how many updates it’ll be before I run out of steam and am ready to move on from this project entirely, but since it hasn’t happened yet, I figure I might as well ride the wave and see how far it goes.
At the same time as all that, though, I plan to be getting started on my next game! Or at least the early planning and prototyping phases for it. The biggest thing I want to tackle for this next game is releasing a cross-platform title, for both iOS and Android. To that end, I’ve been leaning heavily toward using Godot Engine, which I started learning for a game jam at the end of last year and enjoyed a great deal – though I haven’t completely ruled out the possibility of a different engine or framework just yet.
As for what the next game would actually be, gameplay and design wise? One thing I’m fairly sure of is that it won’t be the full RPG I was envisioning and prototyping way back in my first blog post. (Someday it will be time to tackle that project, but I still have some growing to do as a game developer in order to get there.) So this next game will probably be on a similar scale as Bitey Trees, in order to learn the ropes of releasing a cross-platform game in whichever engine or framework I end up going with… including figuring out all those little things, like handling different screen sizes or creating a save system.
But rather than doing another multi-level puzzler, I’d like to try something completely different for this next game. I’ve actually been kicking around the idea of exploring the “virtual pet” or “monster training” genre, and have even started to sketch out some ideas – though it’s still in the extremely early stages (so early that I might still decide to go in a different direction entirely). But one big lesson I learned over the course of working on Bitey Trees was that it’s really hard to finish a game when you don’t have a clear idea where you’re even going with it… so my goal is to have a design and scope as clear as possible before I start working on the next game.
And that concludes this very long blog post about my first iOS game beta test and release! For anyone who’d like to follow along with the latest updates on my game development adventures (or news / progress on my next game), feel free to follow on Twitter, subscribe to the blog’s RSS feed, or sign up for the email mailing list (reserved only for important updates, usually in the form of several paragraphs of my semi-coherent ramblings that no one else will get to see). Thanks for reading!