The purpose of taking an independent study course this fall-- was to focus my time and energy into gaining new skills that would make me more valuable as a game designer/ world builder. At the beginning of the semester I committed to designing, building and scripting a level in UDK.
I have spent the past several months designing a game level based on Valve’s popular game series Portal. Portal is a puzzle game that is fairly simple to understand-- there is an exit, cubes, obstacles, and of course portals! The player must reach the exit door by meeting the conditions set by the level designer. The game is constantly giving the player feedback based on their actions-- in other words part of the job of the level designer is communicating to the player what is happening and why; re-enforcing the game’s rules and objectives.
Communicating clearly to the player the results of their actions, coupled with great level designs which are logical but cleaver, leads to a very enjoyable experience. At the end of each level the player feels that he/ she has accomplished something on their own, and they sometimes even feel like a genius! The goal of any game designer should be to make a game that is FUN and Portal does this successfully by the ways stated above.
Using Portals game formula as a template did not guarantee a fun experience. Although it did help me stay focused on a core concept; I still needed to plan things out, and remain open to changes along the way. I started my design on paper first-- It was one puzzle with three layers or parts. While the player can move around the level and interact with multiple things, there is only one correct solution to the puzzle. In other words the player must successfully satisfy the conditions of part 1 of the puzzle before they can complete part 2 and so on.
My first level layout on paper.
A later drawing to refine the flow of the puzzles.
I used my drawings as a guide while blocking out the level in The UDK editor using the BSP builder brushes. During this stage of the level design, some minor changes took place, mostly regarding scale and spatial relationships within game space.
BSP of the level in UDK.
I wanted to make sure that each trigger, button, and lift had a little breathing room so it would be very clear what button activate what. Some other changes that I made during this stage were adjusting where the cube droppers where located along with their respective triggers, so that when the player triggered the dropper, they would be in a position to see the cube fall as a result of activating it. In the image below you can also see the level design evolved over time.
The final BSP.
There were a couple of core Gameplay elements that I wanted the player to learn while playing this level. First, pressing a trigger ‘does something’ -- in this case drop a Companion Cube. Second, putting Companion Cubes on the round Super Buttons activated ‘something else’ in the level. Third, the player can pass through the shield doors, but the cubes cannot. Four, if the player falls into water, they die! Fifth, blue portals wrap you through to the red portals and vice versa. Lastly, a level is completed by exiting through the large double doors.
The shield door.
These things are communicated to the player by giving the player immediate feedback visually. When the player pushes a button, the blue lights that breadcrumb to the respective object turn yellow. By using the color change, the player knows he/ she has successfully activated something in the level and where!
When the Player carries a cube through the shield door it is destroyed, and the lights from the dropper turn back to blue to indicate that there is no cube in level from that dropper. Likewise with the lift system, when the player activates the lift; the lift goes up and the lights turn yellow. When the lift is in its resting state the lights turn blue. By communicating clearly and constantly to the player-- the player is able to learn the rules of the game world quickly.
(top) The cube dropper inactive. (bottom) the cube dropper activated!
The whole level is scripted in The UDK’s visual scripting language Kismet. Kismet is a visual scripting logic that uses events, conditions, and actions during run time. Portal’s levels flow logically, driven by ‘if then statements’ which helped me learn Kismet. An example of this would be the end door sequence-- if there is a cube on each of buttons next to the exit stairs, the final door trigger is activated. However, if only one of the buttons has a cube on it the player cannot exit. The door sequence uses a ‘counter’ to see if the total number of active triggers are two. If a trigger is empty, the counter is multiplied by zero… keeping the door closed.
The Kismet sequence used to control the functionality of the final door.
The final door with breadcrumb lights.
The kismet sequence that I’m most excited about is the portal system. The idea comes from the beginning of the actual game from Valve before the player gets the Portal Gun. Below is the Kismet for the portal system.
The Kismet sequence for the portals.
The first time the player pushes the portal trigger, the blue portal is activated and the first red portal is activated. By pushing the button again, the player toggles in-between the two different red portals.
The portal panels before being activated.
The portal panels activated!
Lastly, my studies took me into uncharted waters! While making my level, I quickly noticed that my cubes wouldn't activate triggers. This led me a learn how to set up a UDK project, use Visual Studios, nFringe, and create my own classes using Unreal Script. This was my first attempt at any lower level programming and gave me a better understanding of kismet and how things function within a game. Below is a custom class that I created for my cubes in Visual Studios. It still needs some work… Anyone want to help? Pizza!
class CompanionCube extends StaticMeshActor
ClassGroup(RyanPortal);
DefaultProperties
{
Begin Object class=StaticMeshComponent Name=StaticMeshComponent1
StaticMesh=StaticMesh'ART_III.Meshes.cube_rust2'
End Object
Mesh=StaticMeshComponent1
Components.Add(StaticMeshComponent1)
}
In conclusion, this semester I have accomplished everything I set out to do and more. As a result I have a better understanding of how game systems work and have increased my overall ability to solve problems. Furthermore, after this course I feel confident that I can build many more functional levels and explain to others what is happening in the game and why. Lastly, I learned things about myself as a designer and artist. The most revealing… I care more about Gameplay then visuals, and I really like pretty games.
