Back in August, I started working on a small casual puzzle game for iOS. The idea was to go through the whole process of fully finishing a game and releasing it on the app store, in order to learn the ropes of doing it… And also create something simple but fun in the process. In the last update, I summarized the first six weeks of progress, taking it from the simplest possible game (a screen with a “win” button and a “lose” button) to a very minimal puzzle game with placeholder sprites.

And now, since this little project is at right around the 3-month mark, I figure it’s time for another update to take a look back on the progress over the last few weeks!

Two screenshots of a mobile game, a "before" with placeholder sprites, and an "after" with a wizard sprite and tree monsters.
Spoiler: The previous iteration of the game (left) vs. the current iteration (right).

New Mechanics

The biggest and most important additions have been related to building out the gameplay mechanics. At the end of the last update, two of the items on my to-do list were to add multiple different spells, and a system of “MP” for casting them. Happily, I can cross those items off the list (or at least the initial versions of them) – here’s a look at how they’re shaping up so far:

Spells

The idea was to have different spells with different strengths and weaknesses, and to be able to switch between them. In order to enable this, I set up some fairly basic buttons with symbols for the three different elements, and made it so these light up when you press them:

Animated gif showing three buttons being pressed, each with a glowing elemental symbol.
A closeup of pressing the (super glowy) spell buttons.

Currently, the only effect this choice has is to change the color of the attack (shown further down in the post). But hey, it works!

The MP Bar

One of the main goals behind the MP mechanic was to serve as a natural limit on how long a single level can last. Currently one MP point is consumed for each turn you take, and the MP bar is designed so that it reflects both the overall percentage as well as the exact number of turns remaining:

Animated gif showing an MP bar with its value decreasing in a mobile game.
A closeup of the MP bar decreasing.

Note that the above gif was recorded while taking turns as fast as possible, in order to show it decreasing… Actual gameplay will probably go at a more relaxed pace.

The “Aiming” System

And as for the biggest change in mechanics… In the last update, I mentioned that the overall direction of this game seems to be a combination of a turn-based RPG and some kind of casual bubble shooter game. The further it progressed, though, the more the system where you directly tap on a specific target (and instantly hit it) started to feel a little clunky and boring to me.

So I decided to try out a system where you need to actually aim, in a similar fashion as many bubble pop type games out there. After some fun times playing around with angles in SpriteKit, I got it set up and working:

Animated gif showing a mobile game with a wizard fighting animated tree monsters.
The most recent iteration of the game, showing the new aiming functionality and gameplay overall.

It follows a fairly straightforward “drag to aim, release to fire” control scheme that I think works pretty well on a touch screen. And interestingly, I think it makes the game both easier and harder… Easier because you can fire off shots faster and don’t need to move your fingers as far across the screen, but harder because you need to line up your shots and it’s possible to actually miss.

I may end up tweaking or changing this aiming system further… But for now, I’m reasonably satisfied with it as a primary gameplay mechanic.

Creating Animated Sprites

The second big thing I’ve been making progress on recently has been the visuals. In the last update, there were some quick-and-dirty animated sprites that I’d dropped into the game just to get a feel for how to set it up. Since then, I’ve created the first iteration of the “real” animated sprites.

The Monsters

First, the monsters. I created a 3D model in Blender, and then rendered it tiny and cartoony in four different color variations. (I also put in a little extra effort to make them visually distinct in ways other than just the color… So hopefully it won’t be difficult or impossible to tell them apart if you’re colorblind.)

Animated gif showing four different tree monster sprites.
Animated tree monsters in various colors.

I had some trouble with the thick cartoony outlines, and may be tempted to try polishing these up a little. Though I need to keep in mind that it isn’t a high priority. Finishing the game is the main goal… So it’ll be important to resist perfectionist tendencies and avoid unnecessarily re-doing the same things over and over.

The Main Character

Second, the main character. In keeping with my RPG influences, I wanted this little game to have an overarching narrative… Including an actual protagonist who has a name and a backstory. So with that in mind, I took a stab at designing and exporting my first real game character:

Two images of a wizard character sprite in progress, one with a sketch on graph paper and another with a 3D model in progress.
The initial sketch of the main character (left) and the 3D model in progress (right).

He’s a novice wizard on his first assignment from the wizard’s guild. Some local villagers are having trouble with some plants getting in the way and messing up their gardens… Which sounds like a perfectly tedious mission to push off onto the new guy. No one expects that these “plants” are much bigger and more aggressive than expected… And that’s how he ends up stuck out there, cut off from headquarters and trying to defend a bunch of villagers from an ever-expanding forest of monster trees using only level 1 magic skills.

It took about a week between the initial sketch and the first animated version of the character sprite, rendered in a similar style as the monsters with thick cartoony outlines. It may seem a little silly to model and rig an entire 3D model just to produce an animated sprite of this size, but I think it was still more efficient than trying to manually do it frame by frame (at my skill level at least). Plus I can easily make versions facing in multiple directions, and plan to rig and export more animations like walking, running, defending, and casting spells.

Animated gif showing a stylized wizard sprite with thick cartoon outlines.
Animated wizard sprite (1st iteration).

For this one, I definitely do plan to do a second iteration to polish and improve… At a minimum, I need to finalize the colors and details for his outfit. (Since I just exported the initial version in a plain brownish color… I wanted to avoid getting stuck on the smaller details at this stage.)

Creating a “Level Editor”

Another big area of improvement is content management for levels. From the start, the idea was for this game to have multiple levels. But I didn’t want them to all be the same, or randomly generated… I wanted to be able to hand-design them. And in order to hand-design them, I wanted to be able to easily create the level layouts visually.

There are probably fancier things I could have done for this. But for my purposes, SpriteKit tile map nodes seemed sufficient. I created a tile set with abstract symbols, one representing the player’s location and one representing the location of a monster. From there, I can set up and preview the level’s layout in Xcode’s scene editor:

Animated gif showing a very simple grid-based level editing tool.
A view of the 'level editor' in action.

When loading the level, the code looks at the tile definitions on this map, and uses it to place the monsters or player character in the game. It’s super simple at the moment, but has room for expansion down the road if needed. (For example, I could easily add symbols for different monster types, obstacles, blocked tiles, and so on.)

Code Management

Last but not least, I’ve been devoting some extra time and effort to code quality over the past few weeks. It’s not the kind of thing that makes for flashy screenshots, sadly… But for any ongoing development project, it’s important to keep the codebase clean and manageable. And for a hobby game project, I think it’s extra important that the code stays fun to work with… Rather than devolving into a mess of spaghetti that you just want to throw out.

So one big thing I’ve been doing is adding unit tests where I can. And I even tried out a “test driven” approach when adding parts of the aiming feature, which actually worked out pretty well. As it stands, the game currently has 85 unit tests. Which is a lot more than zero… But also far from full coverage. So I’ll have to keep pushing on this going forward.

I also did some refactoring and reorganization, though there are some things I still want to restructure code wise… For example, right now actual gameplay mechanics can’t be changed on a level-by-level basis. (And it’ll take a bit more restructuring to get it there.) But overall, I’m feeling pretty good about the current state of the game’s codebase.

What’s Next?

One thing to note: In the first update, I mentioned the ideal goal of completing this project within 2-3 months… And it’s been 3 months now. From the beginning I suspected that timeline might be overly optimistic, since this is a very part-time hobby thing I’m attempting while working full time and raising a family. And the time thing has admittedly been a big issue. No matter how determined and hard-working you are, there are still only so many hours in a day.

But another issue, I think, is scope creep. As I continue to evolve this little game, I sometimes find myself wondering if certain changes or additions are actually necessary… At least as far as working toward the goal of finishing and releasing it. What does “done” even look like for this game?

After all, if I decided to call it “done” right now, and never made another improvement or added another feature… I guess it would be pretty close to being viable. But I really don’t want to flood the App store with the 9 millionth low-effort mobile game that I wouldn’t even be interested in playing myself. A few weeks ago, I wrote up this blog post with some thoughts on what makes for a good mobile game… And I’d really like to hit as many of those points as possible with this one.

So, I guess it’s a bit of a balancing act. On the one hand, I want to make it good. But on the other hand, I want to keep it small and prevent it from dragging on into some kind of crazy multi-year project. So I need to keep the focus on those remaining tasks that are essential for this little game’s initial release.

The Remaining To-Do List

Having said all that, here are the big remaining items on my to-do list:

  • Convert it from a square grid to a hex grid. This is admittedly more of an aesthetic thing… And I decided to tackle it before thinking too hard about all that “figure out what’s most important” stuff I just said. But it’s already in progress, so… Whoops.
  • Implement a “chaining” effect for spells. The current idea is that spells may hit multiple monsters depending on the element of the spell and the element of the monster. Balancing the difficulty level will be a part of this as well. Right now the higher levels are basically impossible to win… I think the chaining feature will go a long way toward fixing this, but will need to test things out and see.
  • Add a tutorial system and level intro text. For the tutorials, the plan is to intentionally use a light touch rather than holding the player’s hand… Probably just popping up a little instruction message at the start of certain levels. (I can always go back and make it more heavy-handed later if needed.) I also want to add in a bit of narrative-related text for each level somewhere, either on the level itself or on the level selection screen.
  • Add a monetization system. I know everybody hates these, but they seem to be a necessary evil in the world of mobile, where anything priced above $0.00 gets shunned. Since I’m philosophically opposed to the concept of being able to buy your way to victory, I was thinking of trying out the good old “ads with a single low-priced in-app purchase to remove ads forever” strategy.
  • Add some audio. I don’t have any of this in there yet, but want to add it for the initial release. Just some minimal background music and sound effects, with related controls for enabling and disabling it.

There are other tasks, like making an app icon and such… But I think these are the main tasks remaining as far as actual in-game functionality. (At least to get it to a beta testing phase and maybe initial release – I do still hope to keep evolving and polishing it a bit after that.)

Conclusion

That concludes this latest update. Hopefully in the next one, I’ll be able to say it’s ready to download and play! But that will depend a lot on how smoothly the remaining items on the to-do list go… And also whether I end up needing to add any big additional ones.

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!