Wednesday, March 18, 2015

On Design: Puzzle Levels

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.

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.

Tuesday, March 10, 2015

On Development: Thoughts From the Week

The Vision

Having not accomplished much in the past week I started to think about why. Why had I not added to the design doc even though I knew I needed to? Why had I not worked on any of the technical pieces of the game even though I knew there was stuff to work on?

The question is easy to answer with excuses like "I didn't have time" or "I was tired" or "I just forgot" but those don't actually help the game. That time that was not spent working on the game is time lost unless something can be gained. So I thought about what I could gain by considering the reasons I didn't do much work.

The answer that I came up with was this: I wasn't sure of anything that I could work on. This seemed strange at first because of course there are things that need to be done. The game is nowhere near finished, so why was I struggling to find something to do?

I wasn't confident enough in my own ideas to put them down on paper. I wasn't sure if they would be good enough, and I wanted to avoid giving my teammates the wrong idea by putting them in the design document. Fundamentally, I was suffering from a lack of vision. I wasn't sure of what I wanted the game to be. The vision of the game wasn't clear enough for me to say "this is what we want" and then work out a solution to get there. I was trying to solve a problem without a clear understanding of what that problem actually was.

This is something that the entirety of the team is struggling with and it's slowing down development of Data Helix more than anything else. None of us seem to have a clear vision of exactly what we want.

Not that knowing exactly what you want is easy. Its probably one of the hardest things to figure out and at the same time, one of the most important things to know.

The development of a game is a constant work towards a goal. Without that goal, without that vision of the final product, nothing can be done.

Hopefully in the coming weeks the team can come together and reestablish the vision for Data Helix, freeing us up to begin working towards something instead of sitting still or wandering in random directions.

Tuesday, March 3, 2015

Keeping the dream alive

It has been quite a while since our last update, but that is a problem we hope to remedy! As UnderHaus continues the development of Data Helix, we've made it a goal to bring you updates on the status of the project each week.

Of course if some big things happen we'll be posting about it here and on our Facebook and Twitter (which you should totally follow), but rest assured that without fail, once a week, an update on the production of the game will go up on this site.

That being said, the development of Data Helix has slowed down considerably since our last update. Most of the team is busy job hunting, which is pretty necessary if we want to be able to live long enough to finish this game (which we do want to do, trust us).

But have no fear! Even while busy with other things, the team is still making progress.  We have put together a design document and are in the process of slowly filling it out. This will ensure a fleshed out and cohesive vision of what we want the game to be and one that is available to any team member who needs clarification.

So, from now on we'll be making regular weekly posts right here on the dev blog and so you don't miss out on any of the mid-week updates that will come with big announcements, make sure to subscribe!


The Underhaus Dev Team