designerzord

By Sam Rosenthal

Finding the Feel: The Level Design of "Where's My Water?"

For the last few weeks I have been contemplating the best way to sum up my design process for "Where's My Water?" in a blog entry. I ended up writing an essay on this exact process for a writing class at USC, but because of the nature of the assignment I had to use a different tone and style than the more conversational voice I use to address my audience on Defiantly Digital.

So I spoke with my Dad (the best writer I know) on whether or not it would mesh well with the rest of the site, and he suggested writing a blurb at the beginning of the entry, exactly as I am doing right now, to prepare my audience for a different tone and style. He also politely reminded me that I'm writing for my own website, not The New York Times.

Touché Dad. On to the essay!

logo.jpg

The most appropriate way I know to begin a discourse on level design is to highlight the distinction between a level designer’s task and purpose. The level designer’s task is to create the spaces the player occupies throughout the course of the game. Their purpose is to manipulate behavior.

A level designer is a digital architect that uses mechanics, the learned behaviors in a video game, as building blocks. They determine how to teach their audience a mechanic and subsequently test varying degrees of proficiency. Knowledge of the player’s learned mechanics and information is the level designer’s most valuable tool.

Underneath this almost mechanical description of level design is an idea much harder to quantify. While every level designer shares a similar overarching task and purpose, another distinction must be made to separate the good level designers from the rotten. A good level designer understands what I call “the feel,” an abstract concept that simply refers to the emotional reaction a player experiences to an interactive event. The feel is an all encompassing concept that governs every single interaction within a game, from player movement to the time it takes to pull a switch. It has two states with varying degrees: wrong and right. The creation of a level’s geometry is a useless task if the geometry cannot push the player to perform the correct action, and pushing a player to perform a specific action is also useless if the action’s execution feels awkward and clunky.

Task, purpose, and feel are the three components of level design that I defined as my governing principles while crafting levels for Disney’s “Where’s My Water?”. In order to assist in transforming the concept of playing with water physics into compelling puzzle game, I was tasked with creating spaces that would turn the normally smooth journey from water to a bathtub into a far more complicated process. My purpose of course did not involve the manipulation of water physics, but of human behavior, and thus determining a level layout that would push the player along the correct path to a puzzle's solution became a matter of utmost importance. Naturally it was always preferable for the level layout to allow for playful experimentation, as long as such experimentation did not lead the player to mistake an incorrect approach for the proper solution. But it had to feel right.

Until a level felt right it was considered a failure, regardless of whether or not it accomplished its task and purpose. My team used the word "kludgy" to describe a multitude of occurrences that would cause a level to feel wrong, from not providing enough screen space for a difficult section of a puzzle, to the feeling that a solution was reached due to accident. Occasionally we did not have a concrete reason for why a particular level felt kludgy, and so we trusted our gut instinct.

The Creature Feep team

The Creature Feep team

I found it essential to keep the feel at the forefront of my attention, because it was this abstract concept that governed a more mechanical operation. Level design certainly requires a great deal of artistry, yet in certain stages of a level's development the technical process overtook the artistic.

Every level, regardless of whether or not it would appear in the game, was stored in a Dropbox folder that every member of the team could access. Our creative lead integrated Dropbox within our development game builds, enabling us to freely make changes to any content within the game without having to deploy a new build to see the changes reflected. For example, if I created a level layout in PhotoShop, I could save it to my Dropbox folder and immediately make changes to the level in my development build without having to go through a convoluted and time consuming export process. This system saved an extraordinary amount of time and hassle.

Another system was created to help reduce the level designers' reliance on other members of the team which came into play during the "draw" stage of level development, but I will save the details of this system for later.

My level design process was spread across five stages and three screens. I referred to the stages as brainstorm, draw, place, code, and test. I utilized a Dell monitor, MacBook Pro, and iPad to simultaneously accomplish specialized tasks in each of the five stages. The brainstorm stage was exactly as it sounds: pure idea generation. Despite require little to no use of technology, I found this first stage to be the most difficult. Every member of my team at Disney, myself included, were firm believers in the idea of a "high level concept," a matter of fact idea that illustrates what the designer hopes to express, and the brainstorm stage's core challenge was to create a compelling high level concept. However, should a new high level concept appear too similar to that of an already successful existing level, the new level is usually scrapped. Therefore, it was crucial to come up with an original high level concept for each level created. For example, suppose my high level concept involved a solution that required the player to find a way to give the water enough momentum to clear a gap (as seen in "Do a Sweet Jump"). Now suppose that a level already existed with a similar concept. Regardless of the layout that the levels used to illustrate this concept, they both expressed the same idea, therefore it would be redundant to include both in the final game. Until the final stretches of development, it was always more useful to fill an empty slot with a new level concept than replace an existing level by expressing its concept differently. Coming up with a compelling and original high level concept was a daunting and difficult task, and I filled plenty of garbage cans with poor concept sketches of ideas that never came into fruition.

workstation.jpg

The draw stage marked the beginning of the transition from paper to screen, conceptual to concrete. The level layouts were drawn in PhotoShop and loaded into the game with the system I alluded to earlier. Designers were given several different materials to work with when creating the layouts (dirt, rock, water, etc), and each material was represented in PhotoShop as a color. The PhotoShop files were exported as PNGs, and when the game read the PNGs it translated the colors into their corresponding materials. This system allowed a designer and an artist (I should say theartist, we had only one) to work independently from each other, for the artist could update or create new textures when needed, which would be immediately reflected in all of the levels. A designer could create levels without requiring art, and the artist could create art assets without requiring level design.

The dimensions of the PhotoShop canvas were set to 90 x 120 pixels to match the screen size of the iPad. Originally we designed the levels at 86 x 120 pixels for the iPhone, but had to resize and subsequently redesign a fair number of the levels in order to support the iPad as well. The iPad's extra two pixels on each side of the screen could not contain any content necessary to complete the level, since they would not appear on the iPhone version of the game. If the canvas height exceeded 120, the game automatically determined the level to be "deep," meaning it would require the player to use a scroll bar to see the entire layout. Most deep levels were either two or three screens deep, with dimensions of 90 x 240 and 90 x 360. Swampy's bathtub covered a significant portion of the game screen, further limiting the amount of screen real estate available for the puzzle. We developed a visual language to be used in every level that dictated how to place rock shadows and highlights, what angles were acceptable and unacceptable for certain materials, and how close level content could come to the heads up display before it was considered a "HUD crowder." Once drawn, the designer loaded the empty level into the game build to place objects.

The objects used in the place stage consisted of every man-made or unnatural item found in the game. These ranged from water spouts to bombs, and were accessible through a large list within our in-game editor. The editor was created exclusively for development purposes and was only accessible in the game build, therefore I found the iPad to be the most practical tool for this stage of development because its large screen real estate made small adjustments possible. Aside from access to the object list, the editor included interfaces for selecting objects, moving objects, duplicating objects, rotating objects, linking objects, placing tracks between objects, moving objects into the foreground, and for a few other practical uses. Many of these interfaces were not present in the original version of the editor and were later added to assist designers as the level designs became more intricate. The interfaces turned manipulating objects into a rather simple task made more visceral by the iPad's multitouch screen. Designers could drag objects across the screen using one finger, and could rotate the objects with two fingers. An object could be linked to another by selecting both objects and pressing an onscreen button, which would inform the game that first object would trigger an action in second. The actual actions that would occur as a result of the trigger had to be specified in code, but the editor's visual interface removed the annoyances that came from implementing core gameplay concepts in the code every time work began on a new level.

The level code, not to be confused with the game code, was done in XML. Objects were defined by a start and end tag, and between the tags the designer was free to manipulate any of the available properties. The available properties were described in a text document and were divided into categories based on their corresponding object. Spout properties, for example, allowed a designer to change the type of fluid the spout contained, the angle and direction in which the fluid shot, the number of particles ejected, and so on. If an object was linked to another, its resulting movement could be handled within the code by adding a motor and manipulating its properties. Like the level editor, several properties in the game code were created as development moved forward and level complexity increased. While creating the level "Under the Radar," I struggled to find a way to make the bombs rotate around a center point because we had no game logic to support the execution of this concept. I spent a few hours plotting each bomb's trajectory in Excel, and I input the coordinates each point along the trajectory into the code. This solution was far from elegant, and we later added logic to simplify tasks of this nature.

Some of the levels I created for "Where's My Water?"

Some of the levels I created for "Where's My Water?"

The first four stages all dealt fundamentally with either task or purpose, but the test stage was unique in that it dealt with feel. Every change made to a level was tested immediately, regardless of how minute, because every change altered the feel. If the player was given less water at the start of the level resource management would become a priority, just as the subtraction of obstacles would lower the difficulty of a given level. Some changes to the feel were more difficult to identify. A frame of rock would cause a level to feel overbearing, while keeping the top of the screen empty would cause a level to feel more relaxed. No matter how a change affected the feel, it was only identifiable in the test stage. I tested my levels hundreds of times before showing them to the team, who would test them a few times and usually reveal problems that I could not have seen due to my knowledge of the solution. Our formal playtest sessions were the most revealing because the game was played by groups with no prior knowledge of the mechanics. I do not mean to suggest that the test stage is the last of the stages, for the level design process has no beginning and no end. It is not sequential, but cyclical, and the five stages often take place out of order or simultaneously until a level feels just right.

Words cannot do justice the euphoric sensation of finding the right feel, but a good designer can satisfactorily explain why it is achieved. When a particular combination of geometry and numbers elicits a particular reaction, it often feels like magic to the player rather than the result of careful planning, tweaking, and calculation. Every interaction has a feel, and when used in conjunction with one another, a level designer can encourage a player to voluntarily engage in a sequence of strange behaviors. However, if the behaviors have an intriguing feel, they seem natural rather than strange. The game development is long and often convoluted, but the coding, the concept sketches, the testing, and the level editing are all small components of process intent on making people feel differently than they would otherwise. Details disappear from memory in a mere few days after playing a well made game, but the feel is impossible to forget.

 

Level Design: Jelly Car 3

The majority of my time since April has been spent at the Disney Interactive Media Group’s mobile division, where I design levels for two very important franchises. During my first few weeks I created levels exclusively for JellyCar 3, and from then on I worked as a level designer on an exciting new property. I am not ready to talk about the latter just yet, but JellyCar is fair game!

While the rest of the Creature Feep team, led by JellyCar series creator Tim FitzRandolph, began work on our next game, it was my job to create JellyCar levels to be released as downloadable content throughout the remainder of the summer. Three of those levels have already been released as part of the “Adventure” pack, with two more slated to be released over the next few weeks.

I have included videos and descriptions of each level I created, in addition to the level layout as seen through our proprietary level editor. The levels were created entirely in the editor, and throughout the design process I was able to either create my own assets or use any assets created for prior levels. Additionally, I could manipulate the various properties of any given object, including mass, material, “squishiness,” and of course, motion. The connection between objects that trigger motion in other objects is visually depicted by a dotted line, and the motion is programmed through a separate user interface.

One of my greatest delights as a game designer is to surprise the player, a challenge that is inevitably made more difficult when working on a sequel. I quickly established a golden rule for myself: if it already exists in the game, it is not worth creating. The five levels I designed all stretch the capabilities of the level editor, and I believe each offer a wholly unique experience. Without further adieu, here are the levels I created for JellyCar 3.

X-Ray

 

xrayjc3.png

The high level concept of “X-Ray” is rather simple: hitting a white block reveals the outline of the level for a few seconds, after which the level vanishes until the player reaches another white block. I is designed to challenge short term memory and spatial awareness while simultaneously introducing a new concept to players. X-Ray was my first level to use specially colored blocks to alter the environment, a concept I continued to play with in several of my later levels.

My inspiration for X-Ray was somewhat of a happy accident. When I began tinkering with the level editor I noticed that when an object in the foreground overlaps an object of the same color in the background, it is given a grey outline to keep it discernible. I took advantage of this feature by creating two gigantic black squares, placing one as the closest object to the foreground and the other as the closest to the background. Between the two squares I designed the level layout and carefully determined the location of the white blocks. Because the white blocks are triggers, they are always visible to the player regardless of their position in the object hierarchy, making them perfect guides to move the player in the right direction. When the player’s car touches a white block, the giant black square in the foreground is lifted for a few seconds and the level layout is revealed. The grey outlines of the level on top of the black background produces a visual effect similar to that of an x-ray. For the diehard, I created several unique assets to form a Mickey Mouse face that envelops the level’s secret exit.

The video appears overly dark, so please download the level to learn more!

Jelly Pinball


jellypinballjc3.png


At its core, JellyCar 3 is an enjoyable game because it is fun to play with physics. Another one of my favorite games that asks the player to take physics into consideration is pinball, and I thought it would be fun to combine the two.

“Jelly Pinball” has all of the features you would find in a classic pinball table, from the launchers to the bumpers, but in this rendition you play as the ball in a machine made out of jelly. Each bumper is a trigger that opens one of three gates when touched, and when all of the gates are opened the level exit is revealed. The secret exit is quite a bit trickier to reach. To obtain it the player must first cross the gaps at the peak of the stage to reach a tiny bumper that causes the entire top of the table to open up. The table top forms a bridge leading to a Sticky Tires power up that enables the player to traverse along the outside of the table to reach the secret exit. The secret exit is visible at the very start of the level, acting as a carrot on a stick to encourage the player to seek it out.

Jelly Pinball was a challenging level to design because the flippers strike the car at a high speed and at an unnatural angle, often causing the car to “break” (an instance that occurs when the game can no longer handle the way the car is positioned). I had to find the perfect angle and speed that would allow players to have fun with the level without worrying about the JellyCar breaking down.

Crazy Wheel


crazywheeljc3.png

For some reason I became obsessed with the idea of a level that the player could spin, and that idea ended up turning into “Crazy Wheel.” Specially colored blocks are once again used to introduce the level specific spinning mechanic. The level spins 180 degrees whenever the player touches a black block, and the only way to reach the exit is to spin the level to fill gaps that would otherwise make progress impossible.

Crazy Wheel was painstakingly difficult to create for both technical and design reasons that I did not take into full consideration when I initially came up with the idea. On the technical side I ran into a huge problem right off the bat. Every object in JellyCar 3 rotates about its center point, but unfortunately there is no way in the editor the move the center point of an object. This proved problematic because the level’s spinning effect could only work if every object rotated about the origin. My solution to this problem was hardly elegant: I created every asset in the level from scratch and calculated the proper distance from the origin for the individual vertices of each and every one of them. Playtesting of course unveiled problems with the placement of certain assets, which meant I had reevaluate the vertices’ distance from the origin or recreate the asset in question since simply moving it would ruin the synchronous spin.

From a level design standpoint, it was difficult to keep track of the level’s critical path while adding new elements, since the level was essentially divided into two separate halves. I redesigned the layout seemingly every ten minutes, always struggling to balance the introduction of a completely new style of gameplay with level design that felt engaging rather than automatic. Players struggled remembering the previous location of the constantly shifting pieces, and as a result I added white blocks that are not affected by the spin. I also restricted the level to just four colors to communicate the concept as clearly as possible. Black indicates a spin block, white indicates an object that will not spin, and red and blue indicate objects that will spin.

Quilt

quiltjc3.png

My goal for “Quilt” was to create a level that would seemingly take away control until the player is able to recognize the level’s pattern and formulate a strategy. The red squares move horizontally and the blue squares move vertically, and if blindly approached they will usually carry the player back to the level entrance. Once the pattern is recognized the remainder of the level is a pure timing test.

Quilt is full tricks I learned from my previous levels. The simply color scheme highlights the concept without distracting the player’s attention, the blocks seemingly vanish from the edges of the screen similarly to visual effect in X-Ray, and after Crazy Wheel it was no longer daunting to keep track of dozens of object paths.

Growth

growthjc3.png
growthconceptjc3.jpg

I knew from the get go that “Growth” would be the last level I would design for JellyCar 3 and possibly the last level ever released for the game. By this time it was clear that we were moving on to bigger and better things (that you will be hearing about soon), so I decided that it would be appropriate for the final level to start small and end big.

The level layout for Growth looks like a confusing mess of triggers in the editor, but hopefully you can get a feel for the layout from the concept sketch. Every time the player hits a red block, the four walls move outward to reveal more of the level, and in game the effect looks like the level grows right before the player’s eyes. The level components serve different purposes as the level expands; what was once a barrier is now a bridge. The secret exit is hinted at halfway through the level, and should the player remember the visual cue by the time the level is fully expanded they can use a balloon to acquire it.

And that’s it! I had a blast working on JellyCar 3, and I hope you will have as much fun playing my levels as I did making them. You can be sure to expect a similar blog entry in the near future detailing a whole lot more level work for...

Well you’ll just have to wait and see!