Sokobanana design

February 7, 2017

Let’s con­tin­ue the tra­di­tion of explain­ing the design of my games using my lat­est cre­ation, Sokobanana! I’m pri­mar­i­ly mak­ing these so I can ref­er­ence my design choic­es lat­er in case I for­get them, but I’m putting them on my blog for every­one to see. This con­tains spoil­ers for the puz­zles of Sokobanana, so play that first so you know what I’m talk­ing about. You might need to click ‘Read more’ to dis­play the entire post.


At its core, Sokobanana is just a Sokoban clone. This is spiced up by banana peels– when step­ping on them, you con­tin­ue slid­ing in the same direc­tion until you hit a wall. The orig­i­nal inspi­ra­tion for this con­cept are the Slip­pery Trip puz­zles that appear in the third Lay­ton game. These are real­ly easy, and I want­ed to spice them up by adding some good old Sokoban to the mix.

As you might be aware, this isn’t my first attempt mak­ing a block trans­porta­tion puz­zle. Two years ago, I crossed it over with Picross, and a year lat­er, I port­ed the con­cept over to a 3D game. There’s a lot that can be done with block trans­porta­tion puz­zles. I love explor­ing that area to see what works best. It starts with an idea of a mechan­ic that might work well in a Sokoban-style puz­zle game.Then, a lot of test­ing fol­lows, fig­ur­ing out which imple­men­ta­tion of your idea works best and is most prac­ti­cal to use for puz­zle cre­ation.

For Sokobanana, I set the vic­to­ry con­di­tion to both ‘box­es need to be placed on all spe­cif­ic squares’ and ‘play­er needs to be on a spe­cif­ic square’. This vic­to­ry con­di­tion worked extreme­ly well in Tahira’s Tow­er, where there are both Sokoban-like puz­zles where you must fig­ure out how to get blocks from A to B, as well as puz­zles where the goal is sim­ply fig­ur­ing need to get to B and use the blocks as a tool for that. Or even a com­bi­na­tion of the two. This set­up increas­es puz­zle vari­ety, and helps elim­i­nate unin­tend­ed puz­zle solu­tions, so it was a real­ly easy choice to adopt this vic­to­ry con­di­tion into this new game.

In Sokobanana, there are basi­cal­ly two modes of trans­porta­tion: walk­ing and slid­ing. The play­er can walk every­where and push box­es, but once you step on a banana, you go slid­ing. When the play­er slides into a box, he/she stops but the box con­tin­ues mov­ing instead. Box­es also slide when pushed on top of a peel. Play­ers and box­es share the exact same log­ic in this game– with the excep­tion that the play­er can, well, actu­al­ly move.

I tried lots of mechan­ics that would work with push­ing and slip­ping, but just a sin­gle 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 mov­ing on top of one. This works real­ly well with move­ment switch­ing, and com­bined with blocks, opens up some inter­est­ing dynam­ics: when you can’t push a block, slid­ing could still work. Ear­ly in devel­op­ment, you could fill a pit by drop­ping a block into it, which would turn it into a nor­mal tile. Big­ger pits that can’t be filled up turned out to be more prac­ti­cal to build puz­zles with, although a small amount of puz­zles still uses these small pits.

There are lot of mechan­ics that got scrapped. Bumpers, break­able blocks, rough ground that would stop slid­ing objects… None of those real­ly made for good puz­zles. Here’s an old­er ver­sion of the source code with most of these fea­tures still oper­a­tional. Find­ing mechan­ics that make sense, as well as the abil­i­ty to cre­ate inter­est­ing dynam­ics with oth­er mechan­ics that can be explored in puz­zles, is hard. I pre­vi­ous­ly detailed how I changed the core mechan­ics from the orig­i­nal Tahira’s Tow­er pro­to­type to the final game. Maybe some scrapped gim­micks in this game would become use­ful if giv­en a sim­i­lar treat­ment.


Mechan­ics are inter­est­ing and all, but the dynam­ics steal the show– each puz­zle teach­es the play­er one way in which the mechan­ics can be used togeth­er. There are quite a few, so I’ll pick the three most impor­tant ones I want to go over here.

First: When a play­er is still start­ing out, he/she might think that a puz­zle con­sists of two con­sec­u­tive steps: Slide blocks to tar­gets, and fig­ure out how to get to the goal after­wards. Yet these can’t be viewed iso­lat­ed: most puz­zles require you to set up blocks in such a way so that, while trav­el­ing to the fin­ish, all blocks slide in their cor­rect posi­tions as you’re doing so. It doesn’t work when you’ve already set them on their tar­gets before­hand. This comes back in about a third of all puz­zles, so it’s an impor­tant les­son it tries to teach you.

Sec­ond­ly is the nature of set­ting up chain reac­tions, how blocks exact­ly pass on move­ment. Sit­u­a­tions where push­ing blocks doesn’t work, slid­ing might, and vice ver­sa. Learn­ing which type of move­ment to apply in which sit­u­a­tion is taught over the entire game, and pits are a real­ly use­ful way to bring across this les­son.

And last­ly: Some­thing 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 pos­si­bil­i­ties. Rec­og­niz­ing when it’s pos­si­ble to ‘cheat’ slid­ing is explored in the final few puz­zles of the game.


While we’re at it, why don’t we com­plete the MDA-mod­el? I’m almost done, promise.

For a puz­zle game, it’s very impor­tant that the art is read­able, so it makes it imme­di­ate­ly clear how a cer­tain puz­zle ele­ments works, even before the play­er actu­al­ly uses it. I’m very hap­py how that turned out in Sokobanana, even with Puzzlescript’s basic five by five tiles. The banana sprite is instant­ly rec­og­niz­able: play­ers imme­di­ate­ly under­stand that box­es need to be placed on round marks, and they need to go to the goal flag-marked tile, with­out any tex­tu­al expla­na­tion nec­es­sary. Awe­some.

Mak­ing it obvi­ous what pits do was a bit hard­er, because small pits were intro­duced first. It was dis­played as a 2x3 black rec­tan­gle, and play­ers thought the game was glitch­ing out when they stopped slid­ing above a hole. Since then, small pits were intro­duced only halfway through, and large pits had a larg­er, more obvi­ous, sprite, and a lit­tle sound effect that plays when you fall down one. This works, and also makes the func­tion of ‘small pits’ more obvi­ous when it gets intro­duced.

There’s also the end­ing of the game. There’s no real ‘finale’ puz­zle in the game where you have to use all your knowl­edge to beat one final chal­lenge, so I decid­ed to make a sil­ly end­ing instead as a reward. It took some time to get that to work (Puz­zle­script isn’t built for doing stuff like this), but it’s a sil­ly reward for beat­ing a sil­ly game based on a sil­ly trope. The ‘sil­ly’ part is also why the char­ac­ter starts rolling when slid­ing. (In devel­op­ment, I had it set up so the char­ac­ter stayed in the rota­tion where it end­ed its slide with. It looked very sil­ly, but thought that was too con­fus­ing for the play­er in the end.)

Wrapping up

I had the idea for Sokobanana in my head for quite some time, and it feels real­ly good to turn that idea into a game, even if it’s just a real­ly short one. This was on the to do-list for a long time, I’m hap­py how it came togeth­er and that I man­aged to build a sol­id puz­zle game out of this idea.

I love work­ing with Puz­zle­script, and like doing both a long and a short project at the same time. Maybe I’ll make my next short project in Puz­zle­script– at least I’ve done my Sokoban game for the year.