The Visual Game Experience

In Lecture 8 of Game Design and Production, we talked about the visual game experience. Now before we get into the knowledge keeping of this post, I got a confession, on the day of this lecture, since this class is at 8am, I opted for an extra hour of sleep over actually going to class. But because of the awesome hybrid of in class and online awesomeness of this course, I was able to watch the lecture online and catch up no problem. So shout out to in class online hybrid courses, here’s to hoping more classes in the future start doing this.

So what is the visual game experience? It’s what you see. When you are playing a game it is the data that your eye sees and processes. Is that simple, but creating and designing visually appealing data for your eyes can be quite the challenge.

Is this a tree, person and town...or is it a face!?

We talked about optical impressions, which involves:pattern recognition and motion tracking; Optical art (pictured above) and visceral reactions. Visceral reactions include aesthetic sensibility “does what I’m looking at make sense?”, primal reactions, dark = scary and taught reactions, reactions that we have learned from life for example, guy walking towards you with a hokey mask and knife at night, chances are he’s not going to give you a cookie and you should probably run.

The bulk of the lecture was spent talking about Alexander’s 15 Properties of Living Structures.

Alexander’s 15 Properties of Living Structures

1.    Levels of scale – The visibility of goals, scoping of the level to accommodate the current objective.

2.    Strong Centers – Strong areas of focus for example depth of field to add emphasis on what you should be focusing on.

3.    Boundaries – The ability to see the limitations, so instead of having invisible walls, place an obstacle..

4.    Alternating Repetition – “Repeating elements to give sense of order” for example in Super Mario Bros. when you have the grey brick tiles with the black background, you know theirs a boss fight coming up.

5.    Positive Space – Keeping focus on objective, backgrounds that do not detract the player from their current goal.

6.    Good Shape – Keeping things simplistic

7.    Local Symmetries – Keeping things small for example in Portal several smaller rooms are easier to grasp than one big room.

8.    Deep Interlock and Ambiguity – The phenomenon that occurs when things are so dependent on each other, you cannot have one without the other.

9.    Contrast – Using strong opposites to achieve difference. For example in Portal, white tiles = portalable and black tiles = not portalable

10. Gradients – Things that change gradually. For example in GTA V there is a transition between the city and the country side.

11. Roughness – Imperfections that are put there on purpose. This could prevent things from looking weird for example a room where everything is perfectly packed away may lead you to think “Is anyone actually living here or is this all set up for show?”

12. Echoes – Involved using previously discussed proprieties but modified a little. For example two objects that are different but perform the same function, for example the cubes in Portal the pink and blue cubes do the same thing but the variance allows for a breath of fresh air.

13. The Void – Calm contrasts, large empty spaces can create the feeling of calmness. For example the church in Bioshock Infinite.

14. Simplicity & Inner Calm – This involves using only the essential objects for a scene. No additional props or anything, just what’s required for the player to play.

15.  Not Separateness – How all elements of the game come together. Why are these object here?

This was a very informative lecture, especially as a guy who’s into graphics programming this gave me a real sense on where I should spend resources for maximum visual appeal.

Game Engines Blog 1

Game Idea 

Open world (GTA style) game where player plays as a robot who thinks he is a boy fighting crime in the hood. We’ll call it “Roboy in da Hood”. This is a direct sequel to our first year GDW game “Roboy”. In this post I will talk about some of the core engine features we need to implement to make this game happen.

AI

There are going to me many entity types in the game; cars, pedestrians, enemies etc. All entities will need to select the appropriate action for based on what’s going on around it. Then it will need to be able to determine where it needs to go to accomplish the action selected and finally it needs to figure out how it’s going to get there.

Physics

To my limited knowledge of physics engine (hopefully that changes after this course) a physics engines only jobs are: applying kinematic forces and collision detection. Those are two hefty jobs which are vital to Roboy in Da Hood (and just about every game ever). We are using Havok as our physics engine which is used by many commercial games. Hopefully with a little elbow grease we can use it to its full potential.

Audio

Based on the first lecture slides, 2LOC, the engine we are using has support for FMOD and OpenAL which are two libraries that handle audio. I’ve only ever worked with FMOD and it gets the job done. Not sure why it has both FMOD and OpenAL but then again I don’t know a whole lot about audio programming.

We will use audio to help set the mood and theme of the game. There will be ambient audio and music which just plays over top everything and there will be audio which will be played from collision call back functions such as:

onCollisionEnter(), onCollision(), onCollisionExit();

I don’t know if 2LOC has these functions (or some variation of) implemented or not but I expect to use those three functions a lot throughout the development of this game.

Rendering

Ahh rendering. What could be said about rendering? Rendering is the cat’s meow. The bee’s knees. Needless to say, rendering is my cup of tea. This year we are using Ogre as our rendering engine. I've never actually worked with Ogre but I heard things about its architecture which leaves me kind of skeptical. But looking at the 4 images in the Ogre gallery (click), they look pretty good. I can see bloom, depth of field and shadow mapping effects in all their glory which leaves me kind of confused because if the guy who made that demo can pull off those effects with Ogre then surely with a little perseverance, passion and time with the Ogre documentation I can pull off those same effects in Ogre…right? Right??

It says we need to draw a picture...well okay:

General Purpose GPU Programming

General Purpose GPU Programming is a huge interest of mine. Having multiple threads in a program is one thing, but having thousands to perform a complex mathematical computation, that's a whole different story.

With GPGPU programming we can do hundreds of calculations at the same time, rather then doing one at a time sequentially. Since modern GPUs have thousands of cores, we can put a calculation on each core and perform many calculations at once.

Showcasing our Game

The Level Up Showcase was on April 3^rd, 2013. Level Up is an annual event where students from all around the GTA showcase their games.

Level Up was an experience to remember. It was held in the Design Exchange in Downtown Toronto. We arrived at the location at 10 am and stayed there until 11 pm. Needless to say, it was a long day. All throughout the day, the place was packed. There were very few moments where someone wasn’t playing our game, whether it was a fellow student, a visitor or an industry professional.

Level Up was neat because we were able to see the games produced by other students from other post-secondary institutions in the GTA. We exchanged business cards with industry professionals and other students. 

UOIT GameCon was on April 9th, 2013. GameCon is a UOIT event where all UOIT Game Dev. students come together to showcase their game. GameCon is awesome because we get to see what our fellow classmates were able to create over the semester. 

Our game, A Case of the Mondays won an award for Player's Choice Best Second Year Gameplay. That was pretty cool, it is very rewarding to know people enjoyed playing our game.

Evolution of the Graphics in A Case of the Mondays

From the start we wanted to create a great looking and game. Since we have three programmers on our team, I was able to focus on the rendering and graphics programming while the other programmers focused on the game play. By splitting the work this way, we were able to achieve the best of both worlds.

I wanted to make the game look as good as possible and in order to do that, I had to use modern OpenGL 3.0 functionality. This included VBOs, VAOs, shaders and use of our own matrix stack.

Here is a screenshot of the game as it appeared back in December 2012.

Here he have basic per-vertex shader being performed by depreated OpenGL lighting functions.

We then implemented basic shaders to perform per fragment lighting. In the image below we have two per fragment spot lights which light our scene.

As soon as first semester needed  it became apparent to us that we could make a pretty game at our experience level.

Here are some screenshots of the final build of the game.

We are using deferred shading to allow us to have dozens of lights on screen, we have written our own blending shader, shadow mapping and we apply a bright pass filter to make the lit ares of the game look brighter.

The images below compare shadow mapping vs no shadow mapping.

Shadow mapping disabled

Shadow mapping enabled

 Shadow mapping provides a subtle but welcome addition to the scene.

The difference between the first semester screenshots and the second semester screenshots really make me proud to say that I worked on this game. Graphically it looks like a pretty decent game, in my opinion.

Prototyping Composition in Photoshop

This blog post is more of a tutorial. We explore ways to composite two rendering passes together. You could just keep jimmying values in your shaders until you get your scene rendering how you like or you could save some time and use a tool like Photoshop to prototype.

Prototyping your composition in Photoshop is mind blowingly easy. First lets reflect what composition actually does, it takes two images and outputs one image comprised of the two input images.

A traditional method of composition is using an additive blend where you just take the color of the two input images and add them together to get your composted image. The code looks like this:

It's dead simple.

Photoshop has a whole list of blending modes that can be applied to layers. To prototype your composition in Photoshop all you need to do is take screenshots of the two images you want to composite, put them in their own layers in Photoshop and cycle through the blend options.

Above are the two images I want to composite together. On the left is my unlit scene and the right is my light.

Here I am applying a divide blend on my two images.

Using different blend options to composite images can create a wide array of different effects.

Here is a multiplicative blend.

The multiplicative blend creates a very dimly lit scene.

And here is a soft light blend, which is what we use in A Case of the Mondays. 

The soft light blend creates a scene with a heavier light influence.

By performing a simple Google search, you can find the mathematical formula to perform almost any blend. Here is the function for a soft light:

From this function, we can easily create a shader which implements it:

It's literally one line of code.

If you cycle through all the blend modes and you cannot find one that you like, your free to make your own. You can play with the opacity levels of the images, the hue, saturation etc. until you create the look you are going for. Then to create your own blending equation, just look at your history in Photoshop and you should be able to derive a shader that performs the effect by looking up each of the functions for the effects you applied and throwing them into a shader.

Blending in OpenGL

OpenGL has a wide array of different blend functions that it will do for you with the change of a state. 

However getting your scene to blend nicely can be tricky, especially when you have multiple passes you want to composite together and having transparent objects just makes blending even trickier.

The OpenGL wiki has a fantastic page about all of the different blending options in OpenGL so I won’t spend a lot of time restating what that very descriptive wiki page already states. 

The basic idea of blending is: if you are drawing an object on top of another, how do the overlapping fragments behave.

 If you have an opaque object with depth testing enabled, the fragments that belong to the object that is closer to the camera will be drawn with full opacity. Simple enough but if you have a transparent object in front of an object, you need to take the alpha channel of the fragment into considering. Fortunately there are built in OpenGL blend functions that do this for you. However it is up to you to draw the objects in the correct order (transparent objects are drawn last).

Here is a demonstration of the light accumulation pass in A Case of the Mondays using  a couple of different blending modes.

Above is a screenshot of the light accumulation using the following blending states: 

glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

Here is the same screenshot using different blending options:

glBlendEquation(GL_FUNC_ADD);

glBlendFunc(GL_ONE, GL_ONE);

Notice that the two images look very different and all I did was change a few OpenGL states. The first image is a lot darker than the second. In the game we use the second option simply because the light has more of a presence and therefore influence in the scene.