Last August, I started working on a small puzzle game for iOS, and have been blogging about it along the way. Update #1 took a look at how it all got started, and creating a very minimal “playable” game over the first few weeks. Update #2 saw the game start to morph into something resembling its current form, including the addition of “aiming” mechanics and some real player and monster sprites. Update #3 detailed yet more progress, in particular on things like the visuals, mechanics, and save system.

And now, since this little project has been in flight for a solid 10 months now, it’s probably about time for another update!

Two screenshots of a mobile game, showing development progress (before and after).
The game as it looked in the last update (left) vs. how it looks today (right).

In the last few posts about this project, I’ve mentioned that it’s taking longer than I intended (my original naive estimate was 2-3 months). Granted, this has been very much a part-time hobby project that I’ve been attempting to tackle while working full time and raising a family… But a big part of the problem has also been the iterative, fly by the seat of your pants approach I’ve been taking, which has lead to some feature creep due to having no clear definition of what “finished” looks like.

A turning point came in April, when I decided to skip participating in another Ludum Dare and instead spend that same weekend trying to power through the tasks needed to get this game finished enough to submit to TestFlight (Apple’s beta testing system) and be able to start sending it to a few people to try out. I didn’t manage to get it over the finish line that weekend, but the mere prospect of having to do so really helped me re-prioritize things.

I ended up switching from a Trello board to GitHub projects, and created two separate ones: “MVP” and “Backlog.” This made it easy to create GitHub issues whenever I thought of a feature or polishing task, but also provided a place to put things aside to come back to later if they weren’t important to do right away. It may sound like a silly imaginary distinction, but separating things this way helped me progress through the remaining tasks needed to get to a TestFlight MVP in a much more focused way.

In the last update, I had identified four major things that I considered essential to have in place before moving on to a preliminary beta test. In no particular order, these were:

  1. Tutorial system
  2. Audio System (background music and sound effects)
  3. Monetization system
  4. Game content and balancing

The goal over the past few months has been getting each of these items “finished” in the most minimum way possible. And to some extent I think I’ve gotten there on all four, though it’s worth questioning how minimum is too minimum… but more on that later in this post.

First, let’s take a look at the latest progress:

Tutorial System

Throughout the development process of this little game, I’ve periodically handed my phone to people to see their reactions, and a common theme seems to be that the controls aren’t entirely obvious at first. Most often people try tapping on different parts of the screen, wondering why it’s not doing anything – and while the “aiming” controls using a drag / pan gesture seem intuitive enough once I explain that’s what you have to do, this had led me to decide that the game needs some kind of light tutorial to help introduce the basic controls at the beginning.

So I ended up creating the most basic tutorial system possible, which just pops up a couple of simple text-based messages:

A simple tutorial system in a mobile game, featuring pop up text boxes.
Initial version of the tutorial system, featuring simple popup text boxes.

These introduce the two basic things you can do as a player – cast spells (using the drag / pan aiming controls), and move to an adjacent tile (by tapping on it). These two messages are currently the full extent of the “tutorial system” for now… and while there are probably other ones I can add, I’ve been hoping to avoid getting too heavy-handed with them, since it tends to annoy me when games have excessive tutorials for things that I could figure out on my own. So, I’ll most likely hold off on adding any other ones unless / until I identify other areas where players are getting “stuck” due to some other non-obvious thing that really does need explaining.

Audio System

Having music and sound effects was one of those things that I knew the game would definitely need – but for the longest time, I procrastinated on adding any. Part of that may have just been due to the prospect of setting up a system for handling audio, including some kind of options menu, which I hadn’t done before. But when I did finally decide to tackle that feature, it ended up going really smoothly, and I was happy enough with the end result:

Screenshot showing the UI for an audio options menu in a mobile game.
Options menu for toggling the music and sound effects on and off.

For now, I’m just using public domain and creative commons sources for all the music and sound effects (due to not having the time or skills to create these on my own just yet) – but I’ve been amazed at what a big difference these make as far as making the game feel “finished” and polished.

Monetization System

A monetization system has been on the to-do list for the last few updates, and it’s been another thing I’ve procrastinated on. But the desire to add it has been driven by two things: (1) Knowing that I’ll need to release this game for free if I want to maximize the chances of people actually playing it, since that’s just the reality of games on mobile, and (2) I wanted there to be at least the possibility of making a little side income after putting in all the work to finish and release a whole game.

But the typical mobile game monetization strategy – aka having some “premium currency” (gems or whatever) that you try to manipulate players into buying a potentially unlimited amount of using real money – strongly conflicted with my principles on how to make a mobile game not suck. (Check out this post I wrote a while back with some design thoughts on what makes a good mobile game, which has an entire section on monetization techniques.)

So I figured that pretty much left some variation of the “ads with a one-time in-app purchase to remove ads forever” strategy. When it came time to start tackling this feature, I started out thinking I would have interstitial (full-screen) ads displayed at certain times… but I just couldn’t seem to figure out a way to implement them in a way that wasn’t just way too annoying. After some rethinking, I decided to switch to a purely voluntary approach that uses reward video ads and lets players decide how to proceed:

A screenshot showing a monetization system in a mobile game, featuring voluntary reward videos.
Preliminary version of monetization system, centered around reward videos.

I’m pretty happy with this setup, and the feedback I’ve gotten from others on it has so far been pretty positive. (As hinted in the above screenshot, the actual in-app purchase to unlock all levels without ads isn’t implemented yet, and I didn’t consider it a prerequisite for getting to TestFlight, but it will be on the to-do list for the actual full release.)

One other thing to note about the above screenshot is that it shows a glimpse of the new “world map” feature – this was another item on the remaining to-do list from last time in order to allow more than 9 levels. Each map marker leads to a different “area” containing 9 levels each, and there’s not really a limit on how many of those I can put on the map. But that being said, I currently only have the level designs (mostly) fleshed out for those first 9 levels so far, which brings us to the subject of…

Game Content & Balancing

Once I’d gotten all those “boring” things like the tutorial and monetization systems in place (to some minimum degree at least), the time came to start fine-tuning the gameplay content… After all, having gameplay that’s well-balanced and fun is the most important thing in all of this, right? But in the process I started to feel like the gameplay was missing something. Like it was a little too simple, and a little too repetitive, and just didn’t really present the player with very interesting or challenging decisions to make.

I struggled with this a bit, but eventually decided to try making some slight overhauls to the gameplay mechanics. Specifically, the spell selection buttons got replaced with a deck of cards that deals out a specific hand of spells you can cast, and the monsters got HP bars that get depleted based on the power of the spell cards. This is what the end result looked like:

Animated screen capture of a mobile game with RPG style combat and a card deck based spell casting system.
The new spell-casting system in action.

I made the switch from buttons to magic cards over the course of a single weekend, and came away feeling like it made a really big difference (and improvement) to the basic gameplay. I had more expansive ideas about different attack patterns and effects the different spell cards might have – but in the interest of getting it to a “MVP” state, right now they just have elements and attack power values, with the idea of potentially expanding it to add new features in a “V2” post-release update.

Submitting to TestFlight

After months leading up to it, and after struggling with setting up the right certificates and profiles on my developer account for longer than I’d care to admit, I finally uploaded the first build of the game to App Store Connect on June 25th! …And then immediately discovered a bug where the game could get stuck in an unplayable state when a video ad fails to load. Fast-forward another week or so though, and a second attempt at the “Version 1.0” build, and I finally had something ready to potentially send out to testers!

So far, I’m figuring I’ll stick with my original plan of doing a two-phase test: “Phase 1” with a handful of real life friends / family / acquaintances, and then “Phase 2” where I try to find interested beta testers on social media, Reddit, forums, or wherever else. I’m at the beginning of Phase 1 now, and have just started sending it out to a few people for feedback (which is exciting but also a little scary!)

And in preparation for Phase 2, I went ahead and made this little signup form for anyone who might be interested. If you’re reading this, own an iOS device, and like the idea of a casual puzzle RPG game with a slightly silly theme, please consider checking it out!

From TestFlight to Release

Even though I could technically submit the build now for Apple to review and see if they approve it for release on the App Store, there are a few more changes I’m hoping to make

  • Adding level designs for another 9 levels (for a total of 18 for the initial release)
  • Improving the UI of the game save slots (in particular getting rid of that “Reset All” button that blows away all data without so much as a confirmation)
  • Adding the in-app-purchase to unlock all levels without the need to watch video ads
  • Updating the world map screen to remove unused map markers (to avoid giving the impression of having more content than there actually is) and maybe add a little more detail

This is in addition to any bugs that may come to light during testing, as well as any changes I may decide are necessary based on feedback. Overall though, even with all of the above improvements, I’ve still been struggling with feeling like the game is horribly unfinished compared to where I’d like it to be – which may be a result of having more ideas and ambitions than I have time for working on this little hobby side project.

It might also be that despite working to get this game to a MVP status, it’s still too minimum to really be viable. Are 18 levels enough? Are the mechanics enjoyable enough to play for more than a few minutes? These are questions I also hope to get a better handle on through the testing and feedback process… But either way, between this TestFlight phase and probably a few post-release updates, I’m hoping to get it as close as I can to a fully realized, finished, polished game.

Conclusion

Anyway, that concludes the latest chapter of my little ongoing iOS game development project. If all goes well, the next installment will be all about how the testing process goes, improvements and bugfixes based on feedback, and the final push to get it released on the App Store. Stay tuned for the next exciting update on this blog, and in the meantime, feel free to follow me on Twitter for smaller progress updates along the way. Thanks for reading!