Today I took the plunge on level design. Now before I move on let me just get it out now: I hate level design. Many a project has been abandoned because I placed too heavy an emphasis on level content. In the past I dealt with this by playing to my strengths. By either writing procedural levels or avoiding them all together, I was able to finish projects and pursue other ideas. This was an excellent practice—but now I’ve decided to grow in this area through Precarious Potions.
I’ve been doing a lot of thinking lately. I’ve begun thinking that like good writing, good level design requires revision. Good writers chop out every word which does not add to the main thrust of the work. They rearrange, remove, and rewrite until their finished product often looks quite different from their original draft. Creatives often get attached to their work, so this process is hard. At this moment I have about 20 finished levels for Precarious Potions. Getting those levels to exist was a painful, frustrating experience. I spent weeks on them—but as I look at them now I realize that they were best seen as a preparatory doodles or sketches.
This week I returned to a project I started during the summer of 2012. Around August I put it down because several problems in the core design had stumped me. Now after a nice long nap Precarious Potions is fresh for work. Like most of my games, the core mechanic is simple. The player’s task is to move a fragile potion to a goal location by removing books one at a time from a precarious stack. The result is a bit like Jenga meets Marble Madness. The beauty of this system was that I could do much with little content. I hoped it would have a lot of depth for next to no complexity. Unfortunately the rabbit hole wasn’t quite as deep as I had imagined. Unwilling to compromise and out of ideas, I moved on for a while.
Since then, Precarious Potions has received a major face-lift. The content I needed to diversify the gameplay was blessedly the result of only a few hours of work. Instead of one kind of potion and one kind of book, I found a few simple elements within each and tweaked them ever-so-slightly. The result is an entirely different game for almost no work. I now have several different kinds of potions and books, each with their own properties. Some are slippery, some bounce, some are immaterial and others are extremely heavy. Hopefully some really engaging puzzles will emerge out of the combinations that result.
Stay tuned for more–hopefully more to see relatively soon!
Lately I have been wrestling with a problem. If you are a game designer, you probably wrestle with this problem, too.
I have limits.
This shouldn’t shock too many people. Everybody is limited in some way. But my current limits reside in my developer tools. As a programmer, this can be cause for panic. We want freedom to do whatever comes to mind in our projects. Choosing an environment that limits is often seen as a bad design choice.
I certainly didn’t start here. I learned to make games in an environment that allowed me to create my own architecture from scratch. I had nearly complete freedom. But what did I do with that freedom? I made physics engines that never got used, powerful map generators that mapped nothing playable, and generally wasted my time. Lately I have begun using Construct 2, a third party environment for creating html5 games. Making the transition from writing code to clicking on predesigned behaviors was like putting down my carpentry tools and picking up Duplos. It was humiliating. However, what I discovered over time was that by limiting myself in this area, I began making leaps and bounds in my design decisions. I started making more games in shorter amounts of time than I ever had, and they were better than when I had had more freedom.