Level Design for Puzzle Games
I don't think many people would argue if I claimed that level design in a puzzle game is the single most important thing. It is what separates the fun puzzle games from the boring, the intriguingly challenging from the ridiculously frustrating. A good puzzle game cannot have bad level design.That being said, creating good levels is not easy. There are so many pieces that need to be combined in order to create good, compelling levels, which I am going to attempt to explore in this post with some occasional insight into Data Helix's design philosophy and goals. I'm not going to go very in depth into each of these because I can in no way be considered an expert and certainly don't have the answers to all of these questions.
Designing for Fun
This might seem redundant, or something that would normally go at the end, but ultimately if the puzzles aren't fun, compelling, or interesting in some way then no one is going to play long enough to appreciate the other brilliant design decisions that were made. It goes without saying that making the puzzles fun is the top priority.
But how to do this? Well now that we've established fun as the primary goal we can talk about the things that might be used to make levels fun.
The Mechanic
To start designing levels we need a basic mechanic that is easily understandable and has a lot of variation. Without these two things puzzles can be frustratingly hard or get very dull. Data Helix has the second piece in spades. There is so much variation that can be applied to the mechanic of rotating a three dimensional space. The only problem with this mechanic is that it's not intuitive. Lot's of people have enough trouble navigating through a three dimensional space, and that's before you make them change it around every 10 seconds.
Which segues nicely into the next section,
Teaching the Player
The holy grail of level design is creating a level (or levels) that are so intuitive that they teach a mechanic or multiple mechanics without ever needing to explicitly tell the player what to do. Believe it or not, there is a relatively simple formula to create these kinds of levels.
Firstly, you introduce the mechanic in a safe environment where the player can fail without much consequence. This lets them take their time in figuring out how the mechanic works without having to worry.
I am being very vague here because there are a lot more other things that contribute to the intuitiveness of a mechanic or how quickly a player knows what to do like the visual design, but that's a post for a different time.
I am being very vague here because there are a lot more other things that contribute to the intuitiveness of a mechanic or how quickly a player knows what to do like the visual design, but that's a post for a different time.
Secondly, you present the mechanic in a way that presents some danger or a fail state that is significant enough to challenge the player. This reinforces and strengthens their mastery of the mechanic.
Thirdly, you put a slight spin on the mechanic so that it either works with a secondary mechanic or has changed in just the slightest way in order to provide that bit of extra challenge, while still staying true to the mechanic that the player knows.
Lastly, you return to form with a level that retests the player's mastery of the mechanic in a different way than it was done before. This works best if using the mechanic is optional and can be used to achieve some kind of bonus for the player, rewarding them for learning your mechanic.
I'll leave it at that for this installment of On Design, but there is certainly a lot more complexity in level design then I have touched on in this particular post, so hopefully I'll be able to flesh it out more in the future.
In the meantime, the Underhaus team will be using this basic design philosophy to design most of our levels in Data Helix and we'll, with any luck, get out a more refined and well designed demo then the one we showed at ClutchCon.
I'll leave it at that for this installment of On Design, but there is certainly a lot more complexity in level design then I have touched on in this particular post, so hopefully I'll be able to flesh it out more in the future.
In the meantime, the Underhaus team will be using this basic design philosophy to design most of our levels in Data Helix and we'll, with any luck, get out a more refined and well designed demo then the one we showed at ClutchCon.