Sunday, July 24, 2011

Adventures In Level Design: The Long Road of a Failed Design

Over the course of the past several days, I've been working on a series of puzzles for another Portal 2 map. I had what I thought was an exceedingly clever idea for a mechanic to work a puzzle around, so I got to work right away fleshing it out from the ground up.

I began on paper.
The core of the idea was for the player to jump down a deep shaft to gain speed, and land on a 45 degree slope at the bottom. This would have two effects, as I illustrated crudely above. If a portal was placed on the 45 degree slope, the player could shoot out of a flat surface at an angle. Conversely, if repulsion gel was placed on the slope, the player could bounce off of it and into the 90 degree wall at a perfectly straight angle, allowing them to pop out of a portal with a straight trajectory.

I named it the Repulsive Drop. It worked perfectly on paper, but I had my doubts about the physics engine of the game keeping up. So before I built an entire puzzle, I constructed a prototype in a rudimentary room.

The bottom of the Repulsive Drop. The grey areas are where portals should be placed.


The first problem I ran into was that the player would have to be exceedingly accurate in their plunge, requiring them to not only land on the portal, but land on a very specific spot on the portal. If they grazed the edges at all, they wouldn't come out at the desired angle. Discouraged but not defeated, I came up with this solution:

A grate at the top of the plunge makes the initial drop more precise, while leaving room at the bottom for the portal to be placed.
Through some testing and fine tuning, I was able to achieve both desired launch angles from this prototype, so I began construction of a test chamber which implemented it.

I had a puzzle completely designed by that point, so I set out constructing it all in the level editor. The last thing I did was install the Repulsive Drop.

Accuracy was still a problem, so I shrunk the drop point as much as possible.
I gave the work-in-progress level to some friends for play testing. It was important that someone besides me could grasp the logic of the puzzle, and also that other people were able to get the desired results from the Repulsive Drop.

It took them a long time to even figure out what the theoretical solution was, and when they did, they couldn't get the Repulsive Drop to function properly. It turned out that as the designer of the faulty mechanic, I was taking for granted just how tricky it was to get the thing to work properly. No one could make it through the angled portal at the bottom cleanly, and were popping out of it at odd angles.

The nature of Portal puzzles does not require the player to be particularly dexterous or quick with their hands in order to solve a given puzzle. So when they tried to use the Repulsive Drop as intended and it didn't work, they didn't try it a second time, they just assumed the solution was elsewhere. I tried desperately to continue tuning the Repulsive Drop so that there would be no room for error on the player's part, but in the end it was just not possible.

WORK, DARN IT.

Eventually I had to admit to myself that, as much as it pained me to do so, the entire idea needed to be scrapped. Play testers were confounded, and the mechanic was janky in the best of cases. So the past few days of work on this concept have been entirely fruitless, except for the lessons I've learned.


  1. Don't be afraid to let go of bad ideas
  2. Play testers know best
  3. Naming your design ideas makes it that much more painful when they die

With these lessons taken to heart, I move forward to continue work on this map. It's a tough and frustrating thing to give up on what I still believe is fundamentally a clever idea, but it can't be helped. I'll just have to move forward with some better ideas.

Thank you for participating in this Enrichment Center activity

Saturday, July 16, 2011

Adventures In Level Design: Wherein I Complete My First Puzzle

With a little bit of elbow grease and some colored lighting, I have successfully designed a puzzle.

In all her glory. I can't get that potato off the Portal Device, but whatever.
Having learned my lesson about slap-dash level design from my previous failure, I decided to be very careful and efficient when designing this one, but I was also able to retain some of the ideas that I liked from that puzzle. I began by making the following chart:


Switches
Controlled Items
Tools
Floor Switch 01
Angled Panel

Floor Switch 02
Emancipation Grid

Discouragement Beam
Chamber Door

Button
Cube Dropper
Cube


Excursion Funnel


I divided all the elements I wanted in the puzzle into three categories. First, the various switches that would need to be switched to complete the puzzle. Second, each item controlled by those switches. And third, the tools in the test chamber that would assist the player in interfacing with those switches.

When looking at the puzzle in this model, the way to make a difficult puzzle becomes very clear; create more controlled items and less tools. In my particular puzzle, the Excursion Funnel needs to be used three times for three different tasks, and the Cube (once acquired) needs to be used on two occasions. Tools that have more than one purpose are absolutely essential for making a puzzle interesting and challenging.

However, not all elements of a puzzle can be accounted for using this particular model. World geometry is often a core part of a good puzzle, as what elements you have access to can change depending on where in the puzzle you're standing. I'm going to try to come up with a different model to design puzzles in that can account for this, besides just drawing a picture, as that requires you to have an idea that is almost fully realized before you can begin the actual work. Not to mention the room for human error it leaves, as I learned the hard way.

If you'd like to download my puzzle to try and solve it, here is a link!

Tuesday, July 12, 2011

Adventures In Level Design: Portal 2

As I sought out temporary avenues to practice game design without a team of programmers and artists, I suddenly remembered that all Valve games come with the development tools to make mods and custom levels. Feeling emboldened by the amazing entries in Valve's official mod contest for Portal 2 (a delightfully vexing puzzle game with a simple rule set and some dastardly challenges), I set out to learn to use the tools and practice level design. Here's what I've learned so far.

While browsing the super helpful wiki on the subject, I came across a couple of schools of thought for level design. One method for designing a Portal puzzle is to use a chart to plot out the various states you want the puzzle to go through before you complete it. This can help you design a puzzle before you really have a vision of what it's going to be. For example...



1 2 3 4
Emancipation Grid On On Off Off
Floor Button Unpressed Unpressed Pressed Cube'd
Storage Cube Hidden Out of reach Obtained On button
Small Button Pressed Cube dispensed x x
Chamber Door Closed Closed Closed Open


This is a simple 4 step puzzle that I designed as a basic way to get started. I selected the elements that I wanted in my puzzle first, and then decided what they should be used for and when they should be used. Apart from knowing what each button actually controlled, I didn't really have any kind of concrete image in my head of what the puzzle would be at this time. But this simple chart gave me a foundation to work from. I ended up with a puzzle that looked like this:


Prolonged exposure to the button!
Ultimately I deviated a bit from the original chart (you can see there are two floor buttons, and the cube was never out of reach), but the chart was just a place for me to get started.

My second attempt at making a puzzle didn't follow this methodology at all, and also happened to be a total failure. Perhaps a coincidence.

I had this idea after intense brainstorming, rather than through vague ideas slowly taking shape as I built the level. In this second puzzle, I wanted to make the player use a cube to press a button to reach the exit, but also require the cube to press another button to OPEN the exit. This time, I had a very clear image in my head of what I wanted the level to be, and I drew it out on a piece of paper before constructing it for real, just to be sure it all worked.

This time, the puzzle was more complicated than I could keep track of in my head. I tried to work out the finer details of the puzzle in a similar way one would if they were PLAYING the game. I created a challenge that was literally impossible, and then tried to make it possible with as few changes to the stage as possible. I would also want to try to obscure the changes I made in some way, so that they wouldn't just point out the answer in a tremendously obvious way. This was the result...

The dilapidated art style of this map is symbolic for my failure.

Much more complicated. It would have been quite a challenging puzzle I believe, if it were possible at all! Sadly, no changes I could come up with would make the puzzle possible without it becoming super simple.

The lesson here is to work backwards. Come up with the solution first, and then build a puzzle to obscure that solution. I'll update more as I make more puzzles, and I may post links to them if I ever find success!