Puzzle Design and Occam's Razor

Recently in Game Design class we have been developing individual "tutorial" levels in Unreal in order to showcase mechanics we developed previously. And naturally, the route I've chosen to go with my particular mechanic requires me to dive straight into the insane world of puzzle design.

My mechanic is a simple magnetic ball with a magnetic field that can be toggled from positive to negative. The first part of the tutorial level that actually demonstrates the magnet's field is a large, sliding metal block that is, by default, blocking the player's path. The player must discover how the magnet interacts with this object and then utilize that information to progress.

The first iteration was an utter mess. It was the first time I had ever attempted staging a puzzle for the player to solve, and I had attempted to throw too many minuscule things at them at once. During initial playtests, the players never received the correct information, even though they received a large quantity of clutter.

I realized that my problem with the design was in the fact that I had designed the puzzle in a linear fashion, a habit I had brought over from Scripting class. When writing scripts to solve problems, it is legitimate (and many times necessary) to solve each new problem with a new piece of code. If that code creates new problems, write yet another piece of code to tackle those, and so on! (Incidentally, this is the same approach I use in designing magic tricks!)

With puzzle design, I discovered that this method of creation is impossible. When the player went the wrong way, I would throw in a wall or a distraction to make them go the right way again. When one path doesn't work right, I made another. This is what led to the player's confusion, when there were more things in the puzzle meant to account for the player's actions than there were to actually solve. With magic tricks, this is a beautiful thing - it separates the audience from the solution. But in puzzle design, it's exactly the opposite - bad, bad, bad!

So, I decided to go the opposite route. I challenged myself to make the puzzle as simple and transparent as possible, while still being functional. I ended up taking out about 60% of the level. Anything that didn't explicitly benefit the design fatefully met Occam's razor. Things I'd always thought necessary, after further consideration, were found to be nothing but problematic, and/or had much more elegant solutions. The next playtest was an outstanding improvement.

My other discovery at this time was the complete lack of documentation concerning puzzle design for games. This is alarming, considering that all games, at their core, are puzzles, and good puzzle design is essential to creating a good game. There are certainly masterful puzzle designs in popular games (Braid and Portal stand out to me as recent examples), but my fascination with the process of designing these scenarios is largely unsatisfied.

Solving puzzles requires a certain mindset. Creating puzzles involves seeing through the same mindset, both forward and in reverse, through a haystack of probable failures and dead ends, all the while balancing the tightrope of self-designated design and keeping an intimate record of exactly what is being presented to the player and how they might see each point of the puzzle through their own eyes.

Creating puzzles is insane. I'm going to bed.

The Favela Level...

...is due tomorrow morning. Here are a few screenshots:



Now, time to polish OneUP for Game Design class Friday morning...

Simple method to avoid texture tiling...

The biggest game engines support texture blending for things like terrain. In other words, you can "paint" different textures onto the same surface in a manner in which they blend smoothly. See, for example:


Why would one not use a similar process with variations of the same kind of texture in order to "paint away" any noticeable tiling? This could also be used to add "dirt" or "dust" variations to specific parts of the ground - say, perhaps, in the corners of an old unkempt room? Maybe one could have a clean tile texture and blend it in areas with a broken tile texture to give the effect of realistic abuse? Perhaps I'm missing something, but this process seems like it should definitely be used more often in games.

Textures, textures, textures!

Something that has become more and more apparent to me through my experiences with games and other 3d mediums is the unbalanced (and largely unrecognized!) importance of textures.

When a designer decides they want to create a realistic looking 3d scene, they will no doubt first stress the detail of the model; is it accurate in shape and size? Are the nuances of edge, smoothing, thickness, curve, and definition being modeled correctly?

Next, the person will no doubt turn to lighting as the second ingredient in creating a real-looking scene. If there are no shadows or highlights, we'll end up with a very fake, flat-looking scene that won't look convincing at all.

So, once the model is built, and the lighting is cast, the creator steps back at the clay render and says "yeah, that looks great! Now I just need to slap a texture on."

And then they end up with something like this:


This is a case where the model is quite satisfactory, but the result still looks like Nintendo 64 crap. Why? Because a sword's textures look nothing like what we see.

In fact, textures appear to add to realism more than the model itself does. For example, take just a simple, basic hut model:


Now, what will this look like once it's textured? It's easy to imagine it going the route of the sword above. But instead, the artist here has paid extremely specific attention to the textures, no matter how simple they appear to be at first glance. And so the result we get is:

Stunningly realistic in its simplicity.

A HUGE pet peeve of mine is when people will put dark lines or shadows in their color maps in order to simulate depth (think of any crate from an old Quake game). That is the job of the lighting and shaders! In real life we don't find shadows "painted on" to objects... so why would we do this in a game? I can understand doing this maybe 5 years ago, but since then real time lighting and shader depth in games has improved to the point where there shouldn't be a need to fake color maps any more.

A great model with great lighting will look terrible if its texture doesn't accomplish the same look and interaction it would have in real life. Taking a picture of a bumpy wall in real life and importing it into a game will end you up with an unrealistic, flat, bad-looking wall. Why? In real life, objects are already being hit with light that wraps around their 3-dimensional attributes. When you throw a picture of something that already includes rendered light on a 3d surface into a game, that game is now going to treat it as a flat surface, and the result will LOOK like a flat photograph in the game. You don't want a bedroom with photographs of wallpaper glued to the walls; you want a bedroom with wallpaper. You don't want a treetrunk with photographs of a tree glued to it; you want a treetrunk!

This means thinking about textures in different ways. Use color maps for raw colors... use bump maps, models, specular maps, and lighting for depth and realism. Don't paint light onto color maps, or you'll end up taping photos to walls.