Portal: More Than Just a Twist

Surprise, Surprise...

Why should you make your game surprising? As a whole, humans love surprises. We spot patterns quickly and get bored when things become predictable. And we are experts at predicting. Game developers (and other entertainment creators) have a hard time because if they start to lose customers if they serve the same dish twice.

Maybe it's why rogue-likes are so popular lately - unpredictable elements and possibly emergent gameplay. Sprinkle a bit of addictive player feedback loops and toss in a pinch of challenging gameplay. Stir three times and you've got yourself a game!

In other news, I am getting a bit hungry.

A Case Study on Portal

When people talk about surprises in video games, they often talk about about Portal. Now, if you haven't played it yet, stop reading and go play it.

Midway through Portal, there's a giant twist. And by most accounts, this is a pretty effective twist. Good game designers ask hard question, so this is the question of the day:

Why is the twist in Portal effective and how do we apply it to other games? 

This is a question I've pondered about for quite some time. I used to think that the twist in Portal was only based on narrative, but recently I've noticed that that was only a small part of it. There are plenty of games with twists in their story, but Portal somehow feels more special than that.



Let's take a look at the structure of puzzles in Portal.

Most puzzle games, from Angry Birds to World of Goo to Scribblenauts, have the same general structure.
They are a series of isolated puzzles that have about the same chunk size for each puzzle.

How most puzzle games are structured

However, Portal is structured like this:

How Portal is structured

Portal starts off in a rather traditional puzzle structure. It even has a "level number" for each puzzle. But after the midpoint the concept of isolated "test chambers" melt away. It's just a continuous long environment you travel through with implicit puzzles interlaced along the way. 

There are also a lot of differences to the twist besides puzzle structure. A big part of the surprise in Portal is setting up expectations and breaking them. This comes through in the tone, environment, and narration of the game. Most of these come across pretty clear: the first 20 levels are clean perfect testing chambers, and the rest of the game is played - the dingy and dirty spaces behind panel and testing facilities as well as the empty office spaces. 

Even the narration style is different. In the first 20 levels, the narration feels very hand-holdy. Something is said at the beginning of the puzzle, at the end of the puzzle, and maybe even while you ride an elevator. Later on, it feels that Glados is actively stalking you.

Crossing Genres

And this leads me to one hypothesis: 

In the player's mind, Portal changes from one genre to another

In other words, the game actually crosses genres. In the first half, it's just a puzzle game with a funny narrator. In the second half, it becomes an adventure game. The thoughts in the player's mind change from:

"Huh. How do I solve this puzzle?"

 into 

"HOW DO I GET OUT OF HERE. I HOPE GLADOS CAN'T SEE ME. WHERE DO I GO??"

Portal changed from a game being clearly rooted in one genre, and just about when you think it ends, changes into another game. And it doesn't cross genres half-heartedly. Unlike most other games, it doesn't dabble in another genre for a few brief moments before coming back to its original genre. Portal crosses that bridge doesn't look back.




And maybe that's the key to creating a twist or surprise on the scale of the one in Portal:

Make the first half of the game seem like one genre, 

and make the second half seem like another genre.

And when done correctly this could be very powerful. Think about a military shooter game that sudden becomes a stealth game after the first half of the game. Or better yet, a military game shooter that becomes an open world survival game. Ideally, games that cross genres would keep the same gameplay mechanic.

What if a stealth game like Thief suddenly became an assassination game based on revenge? One interesting thing is that to make these changes in gameplay genre will only make sense if you have a powerful change in narrative. This could be an interesting tool.

For example, consider going from "zombie survival horror" to "adventure". The twist might be getting bitten by a zombie and volunteering (or being forced) to leave the human compound try to do the most good possible before your time is up. The gameplay might change from "scavenging and running away from zombies" to "exploring the post-apocolyptic world looking for a cure or another human compound."





And...that's just a random thought I was having. Have a nice day.

Creativity Deadlock

After two weeks of pre-semester brainstorming and four weeks on discussion into the semester, we're having a bit of a problem: We have no idea what the game should look like.

At the moment, our project team is having trouble with artistic vision. It's one of those things that we didn't think would be a problem. Here is the basic premise: The art needs to be inspired by the narrative. The narrative needs to fit around the entire game. And we can't make the game without art. And this, ladies and gentlemen, is what we call a creativity deadlock.

The opposite of this

How do we break out of a creativity deadlock? The easiest way...is to just come up with everything at once! Just have everyone sit down and nail down the art, narrative, and entire game at the same time. But if you've done any team game development at all, you know that it usually doesn't work that way. Nothing comes together all at once. Even if you suddenly have a cohesive vision (which we struggled with from the beginning), that vision will indubitably change throughout the building process.

Another way to approach a creativity deadlock is to work from different angles. Experiment with art and narrative on their own and let them cross-pollinate each other. We also tried this approach for a few weeks, but it seemed that the pieces we came up with did not quite come as coherently together as we hoped. For example, our concept artist (who bases all his art  To be honest, I think this process could work if we had a lot of time to iterate, but we're feeling pressure to create things for GDC.

IGF Pavillion at GDC (photo credit to IndieGames)

Then are there any solid decisions for the game that won't change? Yes. One is the puzzles we have, and the other is having a jazzy soundtrack. But herein lies the problem.

The puzzles we have are based on a large variety of object, often not connected at all. Our game is supposed to give the feeling of unexpectedness and humor through the puzzles, and part of those feelings come through the context of the puzzles. However, at the moment, the context between the puzzles are not related, and this makes finding a common theme between the puzzles very difficult.

Also, "jazzy" turns out to be a very confusing term. Some team members immediately understand my interpretation of the word down to a T. Other members have different ideas about jazz or . However, this isn't really surprising - there's a huge variety of jazz.

Some concept art

Other things that we tried:

Making a ranked word association list. The idea is, as a group, create a list of words related to your game and rank them based on how important they are. This helped us inform each other what we were all thinking of and discuss which direction our game should head in. However, it still wasn't concrete enough to build things from.

Some other things I could have tried:

Instead of having one song or one picture to act as inspiration for the game vision, create a gigantic folder of stuff that give the atmosphere or feel of the game. Therefore, you only need a glance to get a comprehensive feel of the game. Include things like pictures, colors, and music. Of course, a danger with this approach at this point is that it might be too "blue-sky" and pull progress back again.

Word association graph

So what do we do?

Another possibility is that getting stuck all the time is part of the process. After all, we ARE asking a lot from our art: it has to be recognizable and stylish and unique that can be easily produced. Also, it can't be too similar to Portal, Scale, Antichamber, and Unfinished Swan. (In my opinion, Portal really nailed it in terms of design, theme, and narrative. Unfinished Swan was smart in picking a )

Maybe the key is to just try something - and not be afraid to fail and redo it until it feels right. Narbacular Drop took 1 year to produce and Portal required an additional 2 years and 8 months.The Unfinished Swan took about 4 years to make from prototype to full game...and let's not even talk about Fez.

I guess...we'll see what happens.

A Short Rant about Third Person Camera Angles in Video Games

Let's talk about something not related to anything.

Third person camera angles.

There's a lot of video games that use the "default" third person camera. You've seen them. The games where they place your character at the center of the camera and use your character as a pivot point.

It looks something like this:





There are some obvious faults with this type of camera system. The most general one is that it blocks your line of sight. Also, the view angle is not ideal in a lot of situations. When you move the camera down (as in moving your camera to almost parallel to the ground), almost half the screen is taken up by the ground close up. The other half is taken up by the sky, and you have a hard time telling apart depth. On the opposite side of the spectrum, if you rotate the camera up (and view from a higher ), all you get is the ground and you can't see objects far away.

This happens to be the camera system that a lot of MMOs adopt.

(Notice how some of these problems are not very obvious in Zelda: Ocarina of Time because when you need to look at anything the auto-targeting system takes over.)

However, a lot of games do something that make the camera angles a lot better. They simply raise the pivot point of the camera up a bit.

As you can see, Skyrim's camera is slightly better. The camera is looking more towards where the player wants to look instead of directly at the character. It let's you see more stuff and admire the view.

However, there are some practical concerns with this system when you start rotating the camera. The thing is, camera systems will limit the angle of rotation of their camera. For example, some won't let you rotate the camera up too high.

Now, suppose you are on a short inclined hill (as you often are in Skyrim). The ideal angle would be to look over the hill. However, the rotation limit locks your camera so you can only get a good look at the sky and not what's over the hill.

(Ok, so you think I'm probably a bit harsh on Skyrim. It's true that it has 3 camera modes: First-Person, Medium Range Third-Person, and Long Range Third-Person. And the one shown here is probably the least used.)

What I'm saying is, with a simple camera system there's always a bunch of compromises you have to make. But the experience can be so much better with a dynamic camera system that adapts to the player's actions.

Let's take a look at some screenshots from one of my favorite games, Shadow of the Colossus:







The effects of a better camera system are pretty clear. Almost every screenshot in you get while playing Shadow of Colossus looks like it could be a wallpaper. Not only does it look great when they nail the Rule of Thirds, having

Also, this is what the game looks like when you are playing. These screenshots aren't taken from special angles that aren't practical during actual gameplay.

(I'm looking at you, Skyrim)


As you can see, there are plenty of different ways you can improve from the default third person camera.

Here are a list of quick tips:

1. Don't focus on the character. Focus on what the player wants to look at

2. Don't put the pivot point of the camera on the player.

3. Change camera distance and angle when you want to show difference in size and scale

4. Change the field of view when you want to focus on something.

And that's the end of my rant.

Lessons from Building Virtual Worlds

Building Virtual Worlds (BVW) is a class at the Entertainment Technology Center (ETC). If you haven't heard of either, you might have heard of Randy Pausch, one of the founders of ETC and the BVW class.

The BVW class focuses on rapid prototyping and teamwork. In 4 months, I worked and completed 6 team projects. During the process, we worked with technologies such as the Kinect, PS Move, Eyegaze (an eye-tracking device), and Phidgets. We also worked on custom ETC platforms such as the Jam-O-Drum and the Bridge.

However, the most valuable part of BVW is not the technical skills you learn. The important things are the lessons you learn from working with other people.

So, here are the most important lessons I've learned from BVW:



1. Keep an open mind about "Game Ideas"

It's hard to explain your cool idea to someone, and it's also hard to understand why someone else thinks an idea is cool. Sometimes things just click and you "get it." A lot of times this doesn't happen.

I can't tell you the number of times that I thought an idea was a bad idea, only to realize a few days later that it was "the best idea ever."

So, two pieces of advice: don't try to stonewall other people's idea - but do ask for clarification. And if you are explaining your idea to someone else, really try to explain why an idea is cool to you. Don't expect people to be excited about an idea if you just describe what the game is about.



2. If you know you need more time, lower your scope

When you realize you have less time than you need, you usually try to adapt by working harder. "It's okay. I can pull a few all-nighters."

This works for a few cases, but "working harder" can only take you so far. You might be able to cut it just barely before the deadline - but that's not good enough.

That's because the final stages of development - including polishing and testing - have a huge impact on the end product. Something you finish right before the deadline will have quite a few rough edges, and maybe a few cracks as well. Usually, it's much better to have a polished product with less content.

It usually doesn't take a lot to put the finishing touches on a game - but it's very obvious when you don't.



3. The things you care about are different from what the audience cares about

You know that little problem in your game that really bugs you? That graphical glitch or color scheme that you spent ages tweaking but just couldn't get completely right?

The player isn't going to notice that at all.

Instead, he going to have strong opinions on other things that you got used to already - such as the floatly controls or the lack of clear instructions.

As a developer, there are certain things you will obsess about. But spending a lot of time on them isn't the most efficient you can do to give players the best experience they can have.



4. Keep a Priority List

    A priority list is basically a list of tasks you need to do to complete your project with a rating of how essential each task is. It works best if the list is shared with everyone (for example, by using Google Docs).
 
 It helps you...
       Keep track of all the things you need to do - so you won't accidentally overscope
       Makes sure you work on the important things first
       Allow members to have a simple way to distribute tasks
       Keeps everyone notified of progress
       Makes you feel accomplished when you cross something off the list


 

Getting Started With Custom Post-Processing Shaders in Unity3D

I had some trouble learning about how to make my own post-processing shaders in Unity3D, so here is a simple guide to help people get started.

Note: Post-processing shaders require the "RenderTexture" function that is only avaliable in Unity Pro. Even shader code like "GrabPass" (which lets you use the previous render pass as a texture) requires you to have Unity Pro.

Learning the Basics

The first step is to learn about the Cg programming language and the Unity shader architecture. While you could write your shaders using OpenGL instead of Cg, Unity recommends writing shaders in Cg for compatibility problems. Also, almost all shader examples are written in Cg.

Cg Tutorial:  http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter01.html
Unity Shader Reference: http://docs.unity3d.com/Documentation/Components/SL-Reference.html


Note: The Cg tutorial contains a lot of basic computer graphics knowledge that is good for review. However, you don't need to read about "compiling under different profiles" because Unity handles that internally. For Unity Shader Reference, the most important topics are ShaderLab Syntax, Writing Surface Shaders, and Writing Vertex and Fragment Shaders.

Writing Your First Shader

After going through those tutorials, it's time to write some post-processing shaders!

But first, how does Unity call post-processing shaders?

In Unity, post-processing shaders are different from regular shaders because there is no model to stick a material on. Of course, you could create a plane and stick your post-processing shader on that, but there is a better way to do this.

Turns out that the Camera class has a function dedicated to post-processing, called OnRenderImage. The Camera class will automatically call OnRenderImage, so you just have to fill it out like you do with Update or Start.

In that function, you should use the Graphics.Bilt function with a material. The Graphics.Bilt function will render the source texture using your material (a material is just a shader and the values passed in to it), and save it to your dest texture.

So there should be a script on your camera that does something like this:

// Called by the camera to apply the image effect
void OnRenderImage (RenderTexture source, RenderTexture destination){

 //mat is the material containing your shader
 Graphics.Blit(source,destination,mat);
}

Note that in this code, we never explicitly tell the material (and hence the shader) to use the texture in the "source" variable (which contains the rendered image of the scene) as input. This is because Graphics.Bilt will automatically copy the "source" texture to the material's main texture (or _MainTex in the shader code).

After that, we need code for the actual shader. Below is a simple grayscale post-processing shader. The vertex shader simply transform the vertex position and texture coordinate and passes them along. The fragment shader uses the texture coordinates to get the color of the current render (which is stored in _MainTex) and finds the grayscale color.

Shader "Custom/GrayScale" {
Properties {
 _MainTex ("", 2D) = "white" {}
}

SubShader {

ZTest Always Cull Off ZWrite Off Fog { Mode Off } //Rendering settings

 Pass{
  CGPROGRAM
  #pragma vertex vert
  #pragma fragment frag
  #include "UnityCG.cginc" 
  //we include "UnityCG.cginc" to use the appdata_img struct
   
  struct v2f {
   float4 pos : POSITION;
   half2 uv : TEXCOORD0;
  };
  
  //Our Vertex Shader 
  v2f vert (appdata_img v){
   v2f o;
   o.pos = mul (UNITY_MATRIX_MVP, v.vertex);
   o.uv = MultiplyUV (UNITY_MATRIX_TEXTURE0, v.texcoord.xy);
   return o; 
  }
   
  sampler2D _MainTex; //Reference in Pass is necessary to let us use this variable in shaders
   
  //Our Fragment Shader
  fixed4 frag (v2f i) : COLOR{
   fixed4 orgCol = tex2D(_MainTex, i.uv); //Get the orginal rendered color 
    
   //Make changes on the color
   float avg = (orgCol.r + orgCol.g + orgCol.b)/3f;
   fixed4 col = fixed4(avg, avg, avg, 1);
    
   return col;
  }
  ENDCG
 }
} 
 FallBack "Diffuse"
}