As of mid-January, I’m now 5 months in to this little iOS game development adventure… Which I started back in August, thinking it would take 2-3 months. The game started out as a blank slate, but after some iteration and experimentation, it’s shaping up to be sort of a mini RPG where you fight using casual “bubble shooter” mechanics, with the concept based loosely on my game jam entry for Ludum Dare #42. (You are a wizard up against a rapidly-spreading forest of carnivorous monster trees!)

Needless to say, the original estimate for how long I planned to spend on this was somewhat over-optimistic… Which I’ll get into more later in this post. But progress has been moving steadily along, and since it’s been a little while since the last update, I figured it’s time to take a look at all the progress made over the past few months!

New & Improved Visuals

To start things off, let’s take a look at some of the changes relating to the graphics and visuals, since these are the most obvious signs that progress has indeed been happening:

From Square Grid to Hex Grid

At the end of the last progress update, I mentioned that I had already gotten started on switching the gameplay from happening on a square grid to a hex grid. Admittedly, this was not really necessary in order to finish and release the game – it already worked on the square grid, after all. But the switch ended up being relatively painless, and here’s what the end result looked like:

Two screenshots from a mobile game, one showing gameplay on a square grid, and the other on a hex grid.
The old square grid layout (left) vs. the new hex grid layout (right).

Visually, I think it was a huge improvement. The arrangements of the tree monsters look more organic, compared to being arranged in perfect straight rows and columns, and give more of an impression of “surrounding” you. And I think it also opens up more interesting possibilities for the mechanics as far as how the monsters spread, how they block each other while aiming, and how you might strategically move around the map.

New Wizard Sprite & Animations

In the last update, I talked about making the first draft of the animated sprite for the main wizard character, but mentioned that I wanted to go back for a second iteration. (In particular to finalize the colors and details for his outfit.) So I went ahead and got that done – here’s a view of the updated 3D model in progress:

Photograph of a laptop with 3D modeling software on the screen, with a stylized wizard character in progress.
The revised 3D wizard model in progress.

Funny story: I was working on this a few days after Christmas, when the decorations were still up, but didn’t notice until I snapped the above photo that maybe the choice of colors would look holiday inspired, heh. I was aiming for more of a maroon, though, and here’s how the final rendered sprite with the thick cartoony outlines turned out:

Animated gif showing the three new wizard sprite animations (idle, running, and casting spells).
The updated versions of the animated wizard sprite (idle, running, and casting spells).

It’s not perfect – the running animation in particular is a little off in places. But I’m probably going to stick with these (at least for the initial version) rather than going all perfectionist on it and re-doing it more times… Given how small this character appears on the actual screen, it probably wouldn’t be worth it anyway.

And finally, one of the bigger and more noticeable changes, is that the game now has a proper launch screen… Featuring some artwork, plus an actual logo and title! Presenting…

Title screen with "Bitey Trees" logo and an image of one of the monster trees.
The title screen and logo.

Just having this in place makes it feel much more “finished,” though I’ve gotten mixed feedback on the title. Some people like it as a fun / funny / catchy title for a casual mobile game, while others have pointed out that it doesn’t really capture what the game is about or what the gameplay is like very well. Which I suppose is fair – there are almost certainly more descriptive titles I could go with, though the challenge is finding something that’s also (hopefully?) memorable and easily searchable, plus short enough to fit and look nice on the iOS home screen.

In that vein, here’s a demo of what the current icon and title could look like in a lineup of “real” app icons:

iOS app icons for Facebook, Twitter, Instagram, and a possible icon for the "BiteyTrees" game.
The current version of the app icon as it would appear on the home screen.

I don’t completely hate it, and have mostly decided to just stick with this, but yeah. Titles are hard.

New Features

Aside from the various visual improvements and additions, there have been some more substantial changes involving actual new features and mechanics:

Level Intro Popup

The ability to pop up some kind of level intro text was one of the essential items I had listed on the remaining to-do list from the last update. And happily, that feature now exists, complete with all the UI elements and animations needed to make it work:

Animated gif showing the UI for a level details popup in a mobile game.
The new level details popup box.

The current plan is for a narrative to play out through these short journal entries from the main wizard character, each no longer than about the length of a Tweet. Hopefully this will allow for some interesting narrative elements, while also not getting in the way too much for more casual play styles. (Since all of it can be easily ignored by anyone not interested.)

Originally, I was thinking that this popup would serve as a container for the tutorial system as well, but the more I worked on it, the more it seemed like that should be a separate thing. Ideally the tutorial system would be shown on the same screen where the gameplay is unfolding, and possibly have some animated elements to demonstrate instructions if/where needed. So, that’s something that still needs to be added.

Improved Game Save System

Some of the earliest iterations of the game (dating all the way back to September) had a game save system, but it was very simple. It used UserDefaults, which seems to be not particularly recommended for frequent writes and/or large amounts of data, and was limited to a single saved game.

Originally, I was thinking of just keeping that system through the initial release and beyond… But on further consideration I started to worry that it might be too limiting, and that the longer I waited, the harder it would be to change. (Especially if trying to change it after release without breaking things or causing issues.)

So I decided to go ahead and rebuild the whole system to use Core Data, which seems to be better suited for lots of data with small frequent writes. Here’s a look at how the saved game screen evolved:

Two screenshots showing the game save UI for a mobile game, one with a single game save, and one with three save slots.
The old saved game screen (left) vs. the new multiple game save slot system (right).

I’d eventually like to replace that “Reset All” button with the ability to reset only individual save slots, but overall, I think it’s a big improvement. In addition to being able to support multiple game saves, this system makes it much easier to add all kinds of data, and I’ve already added fields to keep track of the total elapsed time and the amount of times each level has been beaten, just because I could.

But more importantly, this system should be able to handle whatever I might want to throw at it down the road, such as new abilities, items, artifacts, achievements, or whatever else.

Mix & Match Mechanics

Last but not least is a bunch of changes to how the gameplay mechanics are implemented under the hood… Which will probably be hard to illustrate, but may also be among the most important changes made recently. The big new thing is the concept of a “turn lifecycle” (since this is for all practical purposes a turn-based game) where different mechanics can do different things at different points in the lifecycle.

This is all pretty experimental for me, since I haven’t created a game with a system like this before. But basically there’s the “player turn” phase and the “enemy turn” phase, and each phase has the possibility of different things happening based on user input and which mechanics are present on each level. This includes animations, and it handles all of the timing considerations so that the “enemy turn” actions won’t begin until the “player turn” actions have completely played out (even when these may be a completely arbitrary and unpredictable length).

The gif below shows a bunch of different mechanics in play: player walking, player casting spell, monsters spreading, and monsters attacking. This new system also made it easy to implement the “chaining” feature, where a spell can spread to adjacent enemies of matching color (which was another big to-do list item from the last update):

Animated gif showing gameplay mechanics on a hex grid.
New mechanics: running to adjacent tiles and 'chaining' attacks to matching enemies.

Individual mechanics are isolated and decoupled from one another, and it’s possible to compose levels with different combinations of mechanics. I’m hoping that this framework will allow the flexibility to eventually add all kinds of new and novel mechanics that can be introduced as you progress through the levels, including one-off “special mission” or “boss battle” type levels that would probably be a huge headache to create otherwise.

(But like I said, this is pretty experimental and theoretical for me at this point – I’ll have to see how it actually goes in practice!)

What’s Next?

So at this point, I’ve spent almost double the amount of time on this little project as I originally planned… And it’s still going to take a bit more to get it over the finish line. In the last update, I talked about scope creep and the challenge of prioritizing what’s actually most important in order to call it “done”… And I think those things are still my biggest problems.

In fact, looking back over this post, some of it could be considered not strictly necessary. The visual improvements to the wizard sprite, for instance, could almost certainly have been put off to a later phase. So even though I feel pretty okay about the state of the game overall, and the progress made so far, I also realize I need to keep making an effort to prioritize the most important stuff in the name of actually getting it done.

Because at the end of the day, this was intended to be a small first project… A “practice game” of sorts. Something to learn from, gain experience at releasing things, and pave the way for bigger and more ambitious game development projects.

The Remaining To-Do List

So with all that in mind, here are the final remaining items needed before this little game is ready to start making its way to the App Store:

  • Monetization system. This one was on the previous to-do list, and it’s something I want to get out of the way as early on as possible. Since I was planning on trying out the the good old “ads with a single low-priced in-app purchase to remove ads forever” strategy, I want to start iterating on this and figuring out how to minimize its annoyingness (if that’s even possible).
  • Tutorial system. It seems like it needs some kind of in-game tutorial, based on my experiences so far with handing it to people and seeing if they can figure out what to do. Like I mentioned earlier, this’ll need to be a new feature to display them during the actual gameplay levels rather than in the popup beforehand.
  • Game content and balancing. Right now there are exactly 9 levels (some easier or harder than they probably should be), and not really any possibility of adding more. At the very least I’ll need to balance the difficulty of the existing levels, but I’d also really like to add the possibility of more than 9 levels, with groups of levels separated out into “chapters” or “areas” connected by the narrative.
  • Background music and sound effects. I’d mentioned the need for audio in the previous update, and haven’t made any headway on it since then sadly. But it’s something I’ll want to have in place (in at least some kind of placeholder fashion) for the initial release.
  • Beta testing. Currently planning to do this in two phases: First, one where I send it to a handful of “real life” friends / family / acquaintances to get some preliminary feedback and rule out (or discover and fix) any big game-breaking bugs… And then a second phase where I’ll try to cast a wider net and see if I can find interested beta testers on social media, Reddit, forums, or wherever else.

And then of course the actual release and submission process… But hopefully that’ll go relatively quickly compared to the whole list above.


So that concludes this latest update on the status of my little ongoing iOS game development project. I’m hoping the next update will be all about the final changes to get it finished and released, but at this rate, who knows? Stay tuned for the next exciting update to see how it goes!

For anyone who’d like to follow along with the game’s progress, feel free to follow on Twitter, subscribe to the blog’s RSS feed, or sign up for the email mailing list to get a notification once it’s released. Thanks for reading!