Lighting the castle

2011-09-02

With our two 3DS projects being in the final stages of development we felt that we could move a human resource away from the 3DS projects to our backburner project:  Ittle Dew.  As I am that lucky resource I thought that I would write a blog post about the project - and my work on it - and steal some of the limelight from the 3DS projects. Being a programmer one would think that my blog post wouldn’t be interesting (just a bunch of math – amirite?) but this week I’ve been working on one of my favorite and also the coolest subject within game programming – shaders.

Image1 - Screen shot of the game before we added lights.

The last time we worked on project Ittle Dew it looked something like in image1.  There’s nothing wrong with this picture, it’s still a nice looking game, but we wanted to do something more. We wanted to get rid of the flatness of the graphics and add some dynamicity to it. We accomplished this through lighting as it is one of the keystones for compositing a great looking image. Lighting in games can be troublesome. For example, games are dynamic in nature it can be difficult to keep the lighting of the scene perfect in all scenarios – maybe the player destroyed the light source, maybe he/she moved it. There are also some technical problems – how do you shape the light to fit the environment. For example; Light can be represented as a sphere, brightest in the middle and fading as we get further away from the center. But what If that light is on a wall, we would have to account for that wall and change the shape of the light to a hemisphere so that the light doesn’t pass through the wall. Further still, what if there is a ceiling right above that light, we’d have to reshape that light to a quarter of a sphere (see image2). And what if there’s a suicidal robot frog just next to the … you get the picture.

Image2 - A sphere representing light being reshaped to fit the environment.

Since project Ittle Dew is a game in two dimensions and its level design is built up from cells in a grid the problem with lighting gets easier. First of all the light would be represented as a circle and not a sphere and secondly the grid based level design means that level objects always blocks one cell of light (not one and a half, not a third, etc). The solution I came up with was to draw a line from each light source to all the cells within the lights circle and check if that line is colliding with an object. If it is then it means that something is in the way of the light and this cell won’t get lit. If not, it means that the light has a straight line to travel and will make this cell brighter. Finally we added some fuzziness to this to allow the light to pass slightly through corners – to add the illusion that the light is bouncing on the objects.

Image3 - Left: The cells of light the fire creates. The brightest cell is in the middle of the fire, the darkest cells are where no 'line' of light could get to. Right: Smoothing out the cells over the actual game creates this result. 

Watch the before and after below!

Image 4 - Before

Image 5 - After