Wow, the year's nearing the end of April and I still haven't released anything yet this year. I miss the time I could turn in one game per month, but now my project are getting bigger and longer... So here's some stuff to fill up that emptiness while I am working on Tahira's Tower and Mobility!

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.