A turn-based puzzle game I created from scratch

One of my most ambitious solo projects yet, Nymble is a turn-based puzzle game that I created from scratch. View the official website for more info!

Nymble's official Trailer.

Nymble is a turn-based mobile puzzle game. It’s one of my most ambitious projects yet because it combines all of my expertise together in a one-person project:

In Nymble, you play as Jack, who jumps over things to interact with them. With this magical power, he can open chests to collect treasure, destroy enemies, and more. The object of each puzzle is to find a seedling to plant in a patch of soil. The seedling would then grow into a beanstalk which Jack could climb to advance to the next level.

Why make games?

For the longest time, I’ve been wanting to write music for video games. But from my experience, getting into this elusive industry at all is not an easy thing.

Generally, game development companies are most interested in composers with real working experience, who have shipped at least one major game. And me? I'd be jumping for joy to be asked to write music for any project, let alone a video game.

One of the biggest challenges in gaining exposure as a music composer, to me, is showing others what you’re capable of in an art form that is, well ... non-visual, in contrast to the work of illustrators, film makers, and sculptors. It only takes a split second to glance at visual art, and almost immediately, you can form an opinion.

People looking at art at a gallery. Visual art makes an immediate impact and does not require overcoming a high barrier for consumption. (Source: negativespace.co)

Listening to music, however, requires more active effort and investment on the part of the audience, and there’s a higher barrier to convince someone to go check out your work.

Seeing the challenge to enter the industry, I finally decided to take matters into my own hand, utilize that Computing Science degree of mine and code my own game. That way I have some kind of vehicle to carry my music, and have something tangible to show to people if the need arose.

Nymble promotional banner with official logo.

Game design

Bad UX ... on purpose

As a UX designer, I normally set out to to solve other people’s problems, rather than to create them. So designing a game with puzzles and challenges was fun in an ironic way. It was like I was creating pain points, and then designing a UX solution that would help overcome these pain points, but with just enough frustration left in so it still seems like I am helping.

Once I realized this, I was able to focus on how to design interesting levels and game mechanics that would altogether bring delight to the player.

Why jumping?

I wanted to make my turn-based puzzle unique by giving Jack a super power that was uncommon, slightly comical, but can also be used as a weapon. Giving him a gun or a sword would make his character too real, and take away from the light-heartedness of the game.

In playing other turn-based games, I would sometimes find my character stuck in a corner somewhere, but could probably free itself by simply jumping. So eventually I wondered, what if there was a turn-based game where jumping was possible? Or even encouraged? That’s how I think the idea came about.

Level Design

Level design for Nymble was especially challenging. Because the game environment changes with each possible move (kind of like a game of chess), it was difficult to visualize the steps the player would have to take to complete the level. Theoretically, I could have designed the levels using some method of graph theory, but I felt it would be beyond the scope of the project. (I just wanted something to hold my music, remember?)

First two levels. The first level (left) is somewhat of a tutorial. The player can go straight for the goal, or explore the rest of the level and see what happens when they jump over a sprout. The second level (right) introduces moving enemies, adding a new concept of danger and complexity.

For each level, I started by placing the key objects (e.g. a treasure chest and a soil patch) to give myself a rough idea of where the player had to traverse. And then I added in the other environment actors that would influence the player’s path in a way that would allow for wrong moves and make the correct path seem not obvious. Then I would run the level, check for dead ends, solvability, adjust, and repeat until I had a puzzle that satisfied some or all of these requirements:

With the exception of the first requirement, all the other ones are followed loosely at the start of the game, and followed more strictly as the player advances to the next level, as to gradually increase the game’s difficulty.


I also took on the role of engineer for this project. Nymble is written in a language called GML, or Game Maker Language, which is similar to JavaScript and C#.

Finite state machines

State machine for the player object.
State machine for the player object.

Since I knew the game would be turn based, I would need some kind of mechanism to control whose turn it is during gameplay. So at the very least, there would be two states: player turn and enemy turn. During the player’s turn, the enemy cannot move, and during the enemy’s turn, the player cannot move.

The player’s state machine has a few more steps because it takes in an input during the ready state. Unlike the enemy object, the player object is controlled by a human, and is allowed to make bad moves (e.g. that will result in getting stuck or destroyed). Finally, the level ends when the player is able to plant the seedling into the soil, which will trigger the automated animation sequence that runs on a timeline.

Calculating each enemy's next position

In Nymble, there is a turn manager that dictates when it is the player's turn, and when it is the enemy team's turn. The basic AI for each enemy is to move one step in the orthogonal direction that will take them closer to the player. From the perspective of a single enemy (E1), if an adjacent position is currently occupied by another actor (E2), it doesn't necessarily mean the enemy cannot move into that space, since E2 might move out of the way by the end of the enemy team's turn.

So in order to determine each enemy's next position, I used a concept of reservations. First I sorted all enemies based on a list of parameters (such as shortest Manhattan path to player, point distance from player, etc.). And then I iterated through each enemy to place its reservation in the location that would bring it closer to the player. If the ideal next position was blocked, then I would further iterate through each of the remaining orthogonal positions starting from the one that would bring the enemy closest to the player. This process would be repeated n-squared times and ended once each enemy has made a reservation, to ensure that as many enemies as possible move towards the player.

Pathfinding using reservations. The screenshot on the left shows the highlighted reserved spaces. The one on the right shows the enemy objects arriving at their reservations. Note how the path of the right-most enemy passes through the middle enemy, since collisions are not checked against the actual enemies themselves.

Moving from development to production


For a several years, while working on Nymble, I hosted the game while in progress on a handful of games hosting websites, including Newgrounds.com. Owing to its vibrant and active community, I was able to gather lots of helpful feedback from a large number (around 100) of player comments. Some feedback included:

At one point, the game was featured on the homepage due to its popularity, which attracted the attention of a few YouTubers who recorded their gameplay and gave their honest critiques. Watching their recordings helped me experience the game from the eyes of a new player. An interesting thing I learned was that most players tended to avoid dangerous situations by running away from enemies, because they did not know it was possible to jump over them. As a result, I adjusted the difficulty ramps, to introduce the player to mechanics more gradually, so they can understand better how to deal with enemies.

FutureCopLGF plays Nymble on Newgrounds.com and provides feedback on the star system and button placement. It was not clear which tasks needed to be completed in order to earn full stars. He also had some suggestions on button placement, which I took into consideration for future builds.


It soon dawned on me that before this game could be launched as a mobile game, there was still a ton of work to do, as producing the game itself was just one small piece of the puzzle. So pulling together all the skills I had at my disposal, I also took care of all the following:

Since many of these areas requires skills outside of my main arsenal, it was quite the learning process for me. But I still managed to do it all in the end.

Nymble's official App Store page.


Because this project was done on the side of a full-time job, I did not have time or energy to market it very aggressively after it was published, so the game did not gain much popularity as a commercial product. I was really lucky that the play-testing process kind of fell into my lap, as I did not anticipate the web version would garner so much organic interest. But now that I know it is possible to appeal to YouTubers with the help of a strong browser game community, I will consider that for future indie video game development projects that I may embark on.

Although there were some parts of the journey that were outside of my expertise, I am glad to have had the opportunity to develop some new skills. Overall it was a great learning experience and helped me understand all the work it takes to see a video game project from start to finish.