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. Play the game online for free!
Nymble is a turn-based puzzle game playable prototype. 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
- Pixel art and animation
- Music composition
- Music production
(This essay will focus on the first three topics.)
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.
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.
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.
(And while I have your attention, here's some of my music!)
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.
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.
What if there was a turn-based game where jumping was possible? Or even encouraged?
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 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.
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.
More states would later come into play, as each actor may perform one of many actions during their turn. So to remind myself of all the possible states, I created a finite state machine each for the enemy object and for the player object.
When the enemy’s end state is reached, the player would have been destroyed and the level restarts. All actors are re-initialized to their starting positions.
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.
Perhaps the most challenging thing for me was figuring out how to prevent two enemies from occupying the same tile. The predefined motion-planning grid functions in GML require you to define which cells of the game area are passable and which are non-passable.
Because enemy objects are non-stationary, the tiles they traverse would need to be able to switch from passable to non-passable during the state machine execution. I wanted to avoid updating tile-passability each time an enemy left its
calculating state because that would be computationally expensive, and I wanted enemies to move towards the player, even if a clear path was not available.
So finally, I arrived at the concept of reservations, much like you would reserve a spot to occupy later. When the object is first instantiated, I initialize its reservation object to also occupy its starting cell, x0, y0. At the start of its
calculating state, I determine its initial direction using the path-finding functions, and store the coordinates of its next potential location x1, y1.
Then in the
moving state, with each enemy object, I check if its next potential location is already occpuied by another reservation object. If not, then I move the enemy’s reservation object to its next potential location x1, y1. After all this is done, the enemy executes its move. So now, with this method, enemies are also allowed to move in tandem, because they are always moving towards their reservation object, which uses its own separate reservation object collision checking system as described above.
At the time of writing this case study, the project had only just been made available to the public, so there wasn’t enough data yet for me to the document project’s outcomes. I may make an ammendment at a later time once the project receives more exposure and player feedback.
The prototype is currently hosted online at itch.io. If you’re interested, please go check it out and leave a comment to let me know what you thought. Thanks!