Let’s continue the tradition of explaining the design of my games using my latest creation, Sokobanana! I’m primarily making these so I can reference my design choices later in case I forget them, but I’m putting them on my blog for everyone to see. This contains spoilers for the puzzles of Sokobanana, so play that first so you know what I’m talking about. You might need to click ‘Read more’ to display the entire post.
At its core, Sokobanana is just a Sokoban clone. This is spiced up by banana peels – when stepping on them, you continue sliding in the same direction until you hit a wall. The original inspiration for this concept are the Slippery Trip puzzles that appear in the third Layton game. These are really easy, and I wanted to spice them up by adding some good old Sokoban to the mix.
As you might be aware, this isn’t my first attempt making a block transportation puzzle. Two years ago, I crossed it over with Picross, and a year later, I ported the concept over to a 3D game. There’s a lot that can be done with block transportation puzzles. I love exploring that area to see what works best. It starts with an idea of a mechanic that might work well in a Sokoban-style puzzle game.Then, a lot of testing follows, figuring out which implementation of your idea works best and is most practical to use for puzzle creation.
For Sokobanana, I set the victory condition to both ‘boxes need to be placed on all specific squares’ and ‘player needs to be on a specific square’. This victory condition worked extremely well in Tahira’s Tower, where there are both Sokoban-like puzzles where you must figure out how to get blocks from A to B, as well as puzzles where the goal is simply figuring need to get to B and use the blocks as a tool for that. Or even a combination of the two. This setup increases puzzle variety, and helps eliminate unintended puzzle solutions, so it was a really easy choice to adopt this victory condition into this new game.
In Sokobanana, there are basically two modes of transportation: walking and sliding. The player can walk everywhere and push boxes, but once you step on a banana, you go sliding. When the player slides into a box, he/she stops but the box continues moving instead. Boxes also slide when pushed on top of a peel. Players and boxes share the exact same logic in this game – with the exception that the player can, well, actually move.
I tried lots of mechanics that would work with pushing and slipping, but just a single one of them made the cut: the hole in the floor. It can’t be walked over, but it can still slide over it, as long as you don’t stop moving on top of one. This works really well with movement switching, and combined with blocks, opens up some interesting dynamics: when you can’t push a block, sliding could still work. Early in development, you could fill a pit by dropping a block into it, which would turn it into a normal tile. Bigger pits that can’t be filled up turned out to be more practical to build puzzles with, although a small amount of puzzles still uses these small pits.
There are lot of mechanics that got scrapped. Bumpers, breakable blocks, rough ground that would stop sliding objects… None of those really made for good puzzles. Here’s an older version of the source code with most of these features still operational. Finding mechanics that make sense, as well as the ability to create interesting dynamics with other mechanics that can be explored in puzzles, is hard. I previously detailed how I changed the core mechanics from the original Tahira’s Tower prototype to the final game. Maybe some scrapped gimmicks in this game would become useful if given a similar treatment.
Mechanics are interesting and all, but the dynamics steal the show – each puzzle teaches the player one way in which the mechanics can be used together. There are quite a few, so I’ll pick the three most important ones I want to go over here.
First: When a player is still starting out, he/she might think that a puzzle consists of two consecutive steps: Slide blocks to targets, and figure out how to get to the goal afterwards. Yet these can’t be viewed isolated: most puzzles require you to set up blocks in such a way so that, while traveling to the finish, all blocks slide in their correct positions as you’re doing so. It doesn’t work when you’ve already set them on their targets beforehand. This comes back in about a third of all puzzles, so it’s an important lesson it tries to teach you.
Secondly is the nature of setting up chain reactions, how blocks exactly pass on movement. Situations where pushing blocks doesn’t work, sliding might, and vice versa. Learning which type of movement to apply in which situation is taught over the entire game, and pits are a really useful way to bring across this lesson.
And lastly: Something will only slide off a peel when it is moving/being moved on top of it, not when it leaves the tile the peel is on. If you can find a way to stand on top of a peel, that opens up possibilities. Recognizing when it’s possible to ‘cheat’ sliding is explored in the final few puzzles of the game.
While we’re at it, why don’t we complete the MDA-model? I’m almost done, promise.
For a puzzle game, it’s very important that the art is readable, so it makes it immediately clear how a certain puzzle elements works, even before the player actually uses it. I’m very happy how that turned out in Sokobanana, even with Puzzlescript’s basic five by five tiles. The banana sprite is instantly recognizable: players immediately understand that boxes need to be placed on round marks, and they need to go to the goal flag-marked tile, without any textual explanation necessary. Awesome.
Making it obvious what pits do was a bit harder, because small pits were introduced first. It was displayed as a 2x3 black rectangle, and players thought the game was glitching out when they stopped sliding above a hole. Since then, small pits were introduced only halfway through, and large pits had a larger, more obvious, sprite, and a little sound effect that plays when you fall down one. This works, and also makes the function of ‘small pits’ more obvious when it gets introduced.
There’s also the ending of the game. There’s no real ‘finale’ puzzle in the game where you have to use all your knowledge to beat one final challenge, so I decided to make a silly ending instead as a reward. It took some time to get that to work (Puzzlescript isn’t built for doing stuff like this), but it’s a silly reward for beating a silly game based on a silly trope. The ‘silly’ part is also why the character starts rolling when sliding. (In development, I had it set up so the character stayed in the rotation where it ended its slide with. It looked very silly, but thought that was too confusing for the player in the end.)
I had the idea for Sokobanana in my head for quite some time, and it feels really good to turn that idea into a game, even if it’s just a really short one. This was on the to do-list for a long time, I’m happy how it came together and that I managed to build a solid puzzle game out of this idea.
I love working with Puzzlescript, and like doing both a long and a short project at the same time. Maybe I’ll make my next short project in Puzzlescript – at least I’ve done my Sokoban game for the year.