Nymble
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 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:
UX design
Software engineering
Programming
Pixel art and animation
Music composition & production
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.
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.
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?)
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:
The puzzle should have a visually interesting start state.
The puzzle may look deceptively simple.
The puzzle allows for some dead ends.
The number of possible solutions is fixed.
The puzzle allows for solutions where some bonuses were not achieved.
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.
Engineering
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
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.
Moving from development to production
Playtesting
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:
Not being sure what contributed to a higher score.
Game UI button placement was not intuitive.
Bug and crash reports.
That the game was frustrating, but in a good way.
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.
Go-to-market
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:
Designing and developing the marketing website
Copywriting and content strategy
Producing the trailer
Joining the Apple Developer Program
Capturing and preparing screenshots to Apple's strict specifications
iOS Deployment
Social media launch Announcements
Post-launch debugging
Soundtrack publishing
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.
Conclusion
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.