Building a Simple iOS Game: The First 6 Weeks of Progress

After completing a submission for my first game jam, I decided on my next goal: to fully finish and release a simple iOS game. The idea was to go through the whole process of developing a small casual puzzle game from start to finish… To make something light and fun, while also learning the ropes of releasing something on the App Store.

Going in, I didn’t have a rigid plan for what the end result would be. I figured I’d build it up iteratively, starting from the most simple possible thing, and then expand on it. Experiment a lot to figure out what’s fun, and see where it goes. Still, there were a few elements I really wanted to continue playing with from the game jam:

1. Grid-based puzzle gameplay
2. RPG-inspired theme
3. Some kind of satisfying progression system

Ideally, this project would be “completed” (at least enough so to release) within 2-3 months, and then I would do a few post-release updates to improve it based on feedback, add additional levels or content, etc.

That timeline may be overly optimistic, since this is a very part-time hobby thing that I’m attempting while also working full time and raising a family. But I started up the project on August 15 (according to the first commit in the git repo) and since that puts it at about the 6-week mark now, I figured I’d do a blog post to take a look back on the progress so far!

Setting Up The Project

One of the side goals of this project is to pave the way for the bigger, more ambitious RPG project I want to make (as mentioned briefly in my dev blog introduction post). Since I was planning to build them both with SpriteKit, I wanted to make it as easy as possible to reuse code between the two projects.

Which may sound strange at first… Would the RPG and the casual puzzle game actually have anything in common? The games will no doubt look very different in the end, but under the hood I could see some common components that both could make use of:

• Game state, input, and scene transition handling. I had built up various wrapper and utility classes around this for the RPG game, but no reason they wouldn’t work for the puzzle game as well.
• Buttons and other UI elements. Personally I’ve found that these things can be a bit of a pain in SpriteKit, but already had them set up and working for the RPG game, so might as well reuse that too.
• Game save & tutorial system (in progress). Parts of this will certainly be game-specific, but I could see the overall framework being potentially reusable.
• Monetization system (not yet built). I’d like to release the puzzle game for free, and experiment with ways to monetize it. (Ideally in ways that would suck the least for players.) This will likely involve some combination of ads and in-app purchases, and that functionality should be reusable across projects.

So the first order of business was moving around some code. All of the stuff that already existed in the partially-built RPG project, I extracted into a new git repository, and then added it to both projects as a submodule. This took a little refactoring, since some of the above mentioned already-built components weren’t quite as modular and decoupled as they could have been. But by around the two-week mark, the structure was in place.

The First Iteration

As already mentioned, I wanted to build the game iteratively, starting from the most simple possible thing. But what does that actually look like? At this stage, the goal was just to get a first draft working, and had only three requirements:

1. Multiple levels, and the ability to progress through them
2. A win condition, to allow for progressing through to the next level
3. A lose condition, which kicks you back to the starting screen

And with that in mind, this laughably simple skeleton for the game was born:

As simple as it may seem, having that basic framework in place felt like a huge step forward. Practically already a finished game! Or at least the game equivalent of a blank canvas to start painting on.

Adding Some Actual Gameplay

Over the next few weeks, I built out the beginnings of a grid-based puzzle to replace the “win” and “lose” buttons. It’s shaping up to be at least somewhat RPG inspired… You control a little character that can shoot magic spells at hordes of monsters. Gameplay unfolds in sort of a turn-based fashion: you shoot at the monsters, and afterward they may either attack you or multiply. The goal is to defeat all the monsters, and also stay alive.

While the game is still in a state of flux, at this point I’m imagining the end result to be sort of a combination of a turn-based RPG and one of those casual bubble shooter games. Here’s how the most recent iteration of the game looked as of this past weekend:

A few quick notes on the visuals: I’m planning to make all of the art for the game on my own. Here’s a rundown of the tools I’ve been using for various things, as well as how “finalized” I consider the assets to be at this stage:

• Inkscape: Used to make the the heart meter and other icons. I’m reasonably satisfied with how these turned out and will likely leave them as the final versions, with maybe some minor adjustments.
• Blender: Used to make the little cartoonish animated sprites, rendering them from 3D models at a tiny resolution. (Though these are likely placeholders, to be replaced with more detailed and polished versions at some point.)
• GIMP: Used only a little, to resize and save some of the final assets at different resolutions for retina display.

Overall, things have been going surprisingly smoothly. Working with Swift and SpriteKit has been a genuine pleasure. And so far, there haven’t been any major things I’ve struggled with too much or gotten stuck on. Only time will tell if this trend will continue as the project moves forward though!

Where’s it going from here?

There are definitely still some more things I’d like to try adding to this little game before I’d consider the core gameplay mechanics to be complete. Some examples include:

*A concept of “MP” that depletes as you cast spells, to increase the challenge and prevent levels from dragging on for too long. *Different types of monsters with different strengths and weaknesses. *Multiple different spells with varying effects and/or attack patterns.

And of course, once that’s in place there’ll still be a few other things it needs before it’s ready to release. Balancing, play testing, a tutorial system, sound effects and music, some kind of settings menu… And probably more other things I’m not even thinking of. But going through the process of figuring all that out, and releasing a fully finished game, is the whole point of this project!

I’m planning to aim for a blog post every few weeks until it’s finished… And in between, continue to post shorter updates in tweet form. 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 (no spam I promise) for further updates. Thanks for reading!