Thursday, September 29, 2011

Lighting Experiments

The setting of the game calls for very atmospheric and moody lighting. Some of the game mechanics will even require limited visibility and localized lights in the game world. The only way to do this is to build a realtime lighting system for the game.

I've been testing a few different kinds of lights for the game. At the left of the image is a large white light that's illuminating the blue ocean. In the middle is a line light that will be used for the laser weapon in the game. The light in the bottom right is actually colored slightly orange, but the water turns it green. It also has a shaped bloom effect.

The lighting system works by drawing light sprites into two separate surfaces. One is multiplied with the original unlit image and the other is added to the result. This allows lights to color the surrounding environment as well as cast bloom effects. This image shows the raw buffers from the screenshot above without any game objects. The light sprites are generated procedurally although I'm experimenting with precomputing them for the final game.

Sunday, September 25, 2011


I've been working on the sprites for the video game--so far we're required to have one player sprite and one enemy sprite. Here they are:

The top image is Waddy, our player character, with his starting weapon, a laser gun. The bottom one is one of the submarine enemies that will be common in the second level. Obviously the second one still has to be edited a little--I'll be replacing the black guidelines with a more subtle dark grey--but I guess they'll do for now.

Both sprites were drawn and animated using layers in Photoshop using ImageReady. Then each sprite was converted into a sprite sheet. It's a little time-consuming, but the fiddliness of the whole process is weirdly therapeutic as well.

Wednesday, September 21, 2011

Assignment 3

Just gonna talk a bit about what we did for Assignment 3.

As of now our program has 4 main classes. The class constructs the screen, constructs players/enemies in a group, and calls group.update/group.draw. We're implementing the "leftover interval" update scheme, where we have a global "frame-time" variable that keeps track of all the time that must be spent updating, and from which "interval-length" intervals are subtracted. is the class from which Player and Enemy will inherit. The purpose of this class is to keep track of a player/enemy in the screen, and have special methods, to be implemented in subclasses, for when the player/enemy hits the border of the screen. For instance, the player class plays audio every time the player touches the edge of the screen, and the enemy class changes one component, horizontal or vertical, of its vector, so that it bounces.