This site was archived on 7 February 2017, and will no longer be updated. Check auroriax.com for the latest info.
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.
Comments
In my most recent games I included a 'sketches' section in the credits. I've heard that some people like that I include them, so I'm keeping the trend. This time the credits listing is deliberately kept minimalistic, so that's why I'm including them here for you. You can play the game here.
This might contain puzzle spoilers for Tahira's Tower, so please click the 'Read more' button to see them. If you want to prepare yourself for Tahira's Tower (which finally launches tomorrow!), here are some games you can play to get into the mindset.
Free: GUM - Super simple mechanics but incredibly well presented. An updated version was released yesterday, in fact! Jelly No Puzzle - Super simple but incredibly difficult. Alan Hazelden's Puzzlescript collection - A varied collection of well designed puzzle games. Corrypt - Here's where puzzling gets really meta. Thread with care. Paid: English Country Tune - Extremely varied and difficult puzzle game. Also check out Sausage Roll. Art of Balance - Enjoy the fishy physics (fishics?) and stack blocks preventing the tower from falling over. Has less strong puzzle design, but is backed up by good multiplayer. Blockwick 2 - Simple, fun block shoving puzzle game. Some gimmicks are weird, but overall really smart design. Sokobond - +1 for the scientific accurateness, has some awesome puzzles. Also check out A Good Snowman. If you know any others, let me know! In the meanwhile, I'll finish my last tweaks for Tahira and blow you all awake with it tomorrow! 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. |
Welcome!I am Tom, game design student and hobbyist game dev. I like gaming, especially Nintendo's work and indie games, and I'm a hobbyist game developer myself. You can find all my games here, as well as software tools, prototypes, custom levels and this blog. I hope that you just have as much fun playing them as that I had creating them!
Now PlayingUseful postsRhythm game Logic
Edge of the Sky design Hexaria design Colorful Corps design Rhythm jam postmortem Naming your game Wario Land 4 2015 fave games 2014 fave games Archives
July 2016
|
This site was archived on 7 February 2017, and will no longer be updated. Check auroriax.com for the latest info.