Here's a game design summary of Tahira's Tower! This is a bit more rambley and longer than my other 'The design of X' posts because the game has gone a long way from what it used to be. It might also spoil some puzzley bits from the game, so that's why you might have to click 'Read more...' to see the rest.

Messing around
I had a load of free hours in my secondary school, in part to thanks to some of the most terrible timetables a human can imagine, and since I had my homework all done for the day pretty much all the time, I spent those hours playing with either Puzzlescript (If I remember correctly, Picross Pushers was birthed in a similar way to this game!) or a prototype in BabylonJS. It was advertised in the MeatlyJam as a possible engine of choice, and while I didn't ended up participating in that particular jam, I guess something about '3D graphics in browsers' must have clicked with me. For the record, all my games up to this point have all been in 2D, so I must've thought it to be a good way to check this wicked new dimension out. Yo.

For me it was really just messing around up to that point. BabylonJS has this amazing playground feature where you can just program something without ever leaving the warm embrace of your browser. And it had cloudsave so I can always pick up where-ever I might've left off. The playground is also used to preview demo's, so whenever I needed something graphics-wise I'd just check it's corresponding demo, often only two clicks away.

The earliest dated log is around March 2015. Then a lot of stuff happened and I kinda forgot about it. The final thing from the playground, dated May... well, you can try it here: http://www.babylonjs-playground.com/#KPJM4#27.

Rise from the grave
It's January 2016 when the project unearths again. That's when I put both Mobility and Tahira under source control to keep them synced across two computers. I had a new vision of the project. In it's current state, it could only be described as '3D Sokoban'. I had some new ideas that would make the mechanics better, allowing for deeper puzzles. Combine that with some fresh graphics, and boom! I used Brackets to replicate the workflow from the playground: code on the left, Ctrl+S, updated game on the right.

First, in the original Sokoban (let's shorten it to 'ban from now on) blocks obviously can't be stacked. There have been sideview 'ban games (like Boxes & Balloons) where gravity is introduced to the concept of 'ban.
My idea was to be able to move a stack of crates (for clarity, 'crates' are push-able objects) as a whole. In the current version, if you walked into a stack of crates, only the bottom one would slide out, and the rest of the stack would keep floating above your head. In the final version, if you push the bottom of a stack, the stack will move as one. If you pushed from somewhere higher, then the stack is split into two, which I thought would create good puzzle scenarios, but now you can also push a stack into a higher block to split it into two.

Secondly, if you try to push a crate through another crate in 'ban, they won't move as a line of crates. And that's the way I had set up things at the start. It's perfectly fine. But since stacks of blocks had already been upgraded, I figured it would make more sense to have lines of crates move as one when pushed. On it's own not incredibly interesting, but combine it with the new stack rules and a load of possibilities open up.

This last change, as you'll notice in the game, the player character will climb (immobile) blocks that are one level higher than her currently. When you attempt to push a crate, but the crate can't be pushed because it's blocked by something, only then the character will attempt to climb the crate. In the prototype, there was a toggle button to make the player *either* climb or push the crate. I hope you can see that the current solution is a much more clearer and intuitive way of climbing crates.

This reminds me of a puzzle
Oh my, the puzzles! I already touched on a lot of this in another blog post so I'll just summarize that here.

First, I explored which different mechanics and dynamics my puzzles supported. Then I sorted those in the order that I wanted the player to learn them, and I had my list of puzzles to be created. I followed the list quite closely (as well as updating it whenever I found a new dynamic) but while building puzzles sometimes I just found a better idea and made that instead. 
Each puzzle has gotten a *ton* of individual attention, I easily expect at least a hour, maybe an hour and a half to build a puzzle and make sure it has a unique solution, is clearly view-able and not too confusing. Not to mention all puzzles that got scrapped. I wanted my game to explore as much of the possibility space as possible, so similar puzzles have no place in my game, and the mayor reason why I choose quality over quantity for this game.

Basically speaking, the puzzle is to get the boxes to the correct slots on the stage, but that is often only one layer of the puzzle. The player needs to get to the exit with all blocks on their slots, and sometimes there are no slots on the level at all which make the entire puzzle revolve around getting to the exit. Sometimes I use the targets to brute force a single solution, but often try not to use them to avoid spoiling the solution too much. This also is a huge deal in most puzzles of this game.

You'll also notice there are some levels without puzzles. I intended to have little breaks for the player, giving him an easy win after a series of destroying puzzles. They are pretty empty, so I put in some poetry to give them a reason to take a break.

Finally, I'd like to talk about the importance of (preferably infinite) undo in puzzle games. It helps the player such a big deal on iterating on their solution, including rewinding fail states to the moment it went wrong. It should be a necessity in all puzzle games. You'll notice that there are no death hazards in Tahira's Tower. In past versions you could fall off the level (crates can still fall off, of course) which would result in getting it reset. Which is not fun, and I prevented it from happening entirely by reverting the move when the player ends on a bottomless pit.

Yet another puzzle game in SPAAAAAAAACE
Wondering where the space theme came from? It was the only kind of skybox I found a generator for. Shame's on me for this one.

And what's in a name? Tahira means 'purity', which refers to the cleanness of puzzle design. And the Tower part is really, really only to make it an alliteration.

You can toggle the camera between three angles, nicknamed 'Isometric', 'Straight-on', and 'Top-down'. Originally I had a camera you could rotate the full 360 degrees for, but that went nowhere. You see, I had 'W' mapped to up, but from the default angle you move to the North-West when pressing that button. But change the camera angle, and the character would move in a different direction entirely, seemingly arbitrary unless you knew what the original angle was and where the camera is now. This is somewhat difficult to explain, so please play the prototype, move the camera somewhere with the mouse, then try to walk around without your brain breaking down.

So we could script something that remaps keys depending on where the camera is positioned! No way, I don't think that can be implemented in a natural way. Why not just limit camera angles? Oh, and add a top-down view to help the player orientate. Brilliant!

Okay, another seemingly random design choice: the player character emits light! OBJECTION! It's an excellent way to figure out where your character is if you can't see her directly! This was done before the top-down view camera and has become less useful since, but it's also a good way to help you orientate.

Musician Luke Steinmann found my Mobility devlog and volunteered to make music for this game (he's currently cooking something up for Mobility as well). That makes this the first Amazingcookie/Auroriax game to feature custom music! The music is very relaxing which should help counter balance how angry you're going to become from the game. The game features no other sound effects, which I think would break the serenity of the game. (I actually had the same problem with Hexaria until I implemented crystallophone selection sounds, instead of BFXR sounds, recently.)

It's May as I'm writing this, planning to start general playtests soon. I'm really glad to have this out of the door. Don't get me wrong, but I'd really start with something fresh. I realize that it's a good skill to actually finish games, and to have that idea 'past' me toyed around with finally wrapped into a palpable format. It feels so good to finally wrap something up and seeing people enjoy it, or in the case of this game, seeing people struggling to solve the various difficult puzzles laid out for them!

Thanks for reading. Good luck trying to solve Finale.

The paradox of porting a web game to Android
Here's a little appendix about the mobile version of the game, written in July.

The mobile version of this game was pretty tough. There's been multiple occasions where I thought it was simply impossible to port the game  to Android.

I used Phonegap Build to get Picross Pushers on Android, so my first attempt was to use that for Tahira as well. Didn't work out, just gave me a white screen because it didn't support WebGL. After a while I found out the existence of cocoon.io, which is a similar service but also provides a Webview+ render engine which does support WebGL!

Then there were optimization problems. Where Tahira ran masterfully on a PC, the first time I ran the game on a phone was at a marvelous 2 FPS. It took a lot of time before I found out optimization tricks that would have little impact on how the game looked: stuff like grouping the static blocks on the level into one mesh to reduce draw calls, cloning objects instead of creating them, and disabling lighting on the skybox. The only graphical difference is that shadows are disabled on mobile, since the shadows on mobile don't look as stellar as on a desktop browser, and saves quite a bit of rendering time.

Yet another problem was input latency. The time between a tapping the screen and the app registering the input is 300ms, and getting around that delay is extremely difficult for some dark reason. Luckily one of the dependencies of BabylonJS is a library with pointer events that ignore the delay on mobile device, but I only figured this out on the day of launch, when I had actually already given up on solving this particular problem.

The controls and UI were also interesting challenges. I wanted to do swipe controls again like in Picross Pushers, but I liked my split d-pad design so much in jumpNULL that I used that instead. Screen space on a mobile device is very scare, so much that I cut the little text accompanying every level to keep the screen clutter free.

So there you have it. All the trials I've gone through to assure you a portable port. You're welcome. You can obtain my sweat, tears and blood handily wrapped into an app on the Play Store.

First big thing, I'm finally launching Micro Massive II. It has been in a launch ready state for quite a while (since the beginning of 2015, in fact!), I felt it was a bit lacking and wanted to polish and fix it a bit further, but I never got around to do and did it in very small bursts throughout the year. It expands a bit on the first game by including levels that take use of the full screen aesthetic. If you don't know the original game, it's a precision platformer and can get quite tough at times. Obtain from GameJolt or itch.io. Or look at the GIFs made during development!

To practice working with nw.js for Tahira's Tower, I packaged the GameJolt version of Picross Pushers with it, so you can get it for Windows natively. Great if you want a fullscreen or offline experience. Grab it from GameJolt or itch.io!

Lastly, I've just updated the vault. I dug through my big folder full of game stuff and drilled out a few more items. The vault is quite full now, so dig through if you like that sorta thing.

I have more stuff nearly ready, so I'll probably make a similar post soon. See you!

Mobility has gained a devlog since my last blogpost here, but Tahira's Tower is also progressing nicely! Most stuff is in, what I'm going to focus on now is getting all puzzles ready. Today I'm going to focus on how exactly I'm doing that. This is mainly intended to describe how I'm developing this game, but you might also be able to take some points out of here to include in your own puzzle design workflow!

In my previous puzzle games (Mathventure and Subarashï) I explained the game rules up front. So the players are aware how the puzzles work before diving in. In Mathventure the puzzle is often figuring out which route to take that results in you getting the value necessary to win the level, while Subarashï's puzzles are about deciding what to blow up and in which order. It's similar to Sudoku: once you figure out how to solve a Sudoku, you can use your existing knowledge of it to solve every other Sudoku. A 5* Sudoku is just a 1* Sudoku made harder, you can still apply the same rules to solve it.

But recently games there have been some puzzle games that, instead of introducing new mechanics of the game, build puzzles around the player realizing new game dynamics. That might need some explanation: in puzzle game X, you have block type A. The first puzzles are about block type A, then block type B is introduced, there are some puzzles about B, and then there are some puzzles about how A and B work together. Game X introduces new mechanics during the game to keep it interesting. Now take Game Y where mechanic A is introduced in the first level and every level after that teaches a new way to interact with A. You will need A to be somewhat deep to keep it interesting (the deeper it is, the more puzzles you can make). Game Y also doesn't need any instructions, because part of the puzzle is figuring out how it all works.

For my game Tahira's Tower, I'm basically porting Sokoban to a 3D environment. There have already been some Sokoban 3D games, but this one actually adds depth, gravity, and climbable objects, so the gameplay is 3D, not just the graphics. I'm changing puzzle design to a dynamic based one, in particular focusing on the rules regarding the added third dimension. I've already played with the Sokoban concept before in Picross Pushers when I combined the Picross/Nonogram mechanics with Sokoban ones.

Making up puzzles for it is surprisingly difficult. To quote this RPS article, making a puzzle game is very much like a puzzle itself. First thing I did is figuring out how all mechanics work together to create the various dynamics, put those in a single list. That's basically all puzzles I could make without padding it. This means you should make a few prototype puzzles to figure out what dynamic rules pop up in your game.

Then, I converted the list of mechanics and dynamics into the list of puzzles. There are the puzzles introducing the mechanics at the very beginning of the game, and the rest is about exploring the dynamics. Important is that you list which knowledge the player must have to pass the puzzle, because if the player doesn't when he starts the puzzle, he must learn so while solving it. This list went through multiple iterations, so it's by no means definitive and can be resorted if needed.

Then you go and make puzzles, and probably find more or better ideas to make puzzles while doing so. If you get something entirely different than from what you had the intention to make, it shows that your mechanic is deep enough to support various kinds of puzzles. See how deep the rabbit hole goes, so to speak! Important is that each puzzle learns the player something meaningful about how the game works, make each and every puzzle have a clear purpose.

For example: each chapter in Braid starts with 'The Pit', a single screen room where there's a pit between you and the exit, with the key to the exit positioned at the bottom of the well. The trick is that the puzzle's re-occurrences are slightly different each time. So by presenting the player with a challenge similar to one previously faced, but where the previous solution is no longer valid, it forces the player to think outside of the box and come up with something new. Note that Braid teaches the player new mechanics with this puzzle, but I'm planning a 'Staircase' series of puzzles that teaches new dynamics in a similar fashion.

The problem with games where the player keeps learning things over the course of the entire game, that if they solve a puzzle without (consciously or subconsciously) understanding it, they might miss knowledge to solve a puzzle later on. In order to test properly for this, you'll need all projected puzzles to be in your game, which could take a while. Also never teach the player something by 'forcing' him to do it (locking him into a single move, for example), let the player try to figure it out for himself.

So, the takeaway:
Three subtypes of puzzle games:
- Single mechanic-based: Enter A, A hard, A harder, A hardest (the same thing made more difficult). Examples: Sudoku, Picross/Nonogram, Sokoban
- Multiple mechanic-based: Enter A, Enter B, A+B, A+B Harder (challenge comes finding out how the new mechanics work with the old ones). Example: Sokobond, English Country Tune.
- Dynamic-based: Enter A, A Dynamic 1, A Dynamic 2, A Dynamic 3, etc. (Use existing mechanics in new, unexpected ways every puzzle). Example: Stephen's Sausage Roll, Tahira's Tower!

How I plan and build the puzzles in Tahira's Tower:
- List all mechanics & find all dynamics created by them
- Create a puzzle list: teach all mechanics first, then the dynamics. You have about as many puzzles as you have mechanics, dynamics, and other cool puzzle ideas. Iterations on this list are totally allowed.
- Create the puzzles on the list. I iterate on the individual puzzles while making them, and often I find new interesting dynamics to build puzzles around.