JavaScript lighting making slow progress

Posted on March 30, 2012 | 4 minute read

[caption id="attachment_47729” align="alignleft” width="223” caption="Lighting notes…"]JavaScript lighting notes[/caption]

I know, I know another post about lighting. I promise this will be over soon (I hope).

Last night and this morning I finally picked apart the lighting code from the example game I’ve been looking at to understand the lighting technique. I rewrote the required functions in my game and removed any dependencies on the other game’s own entities.

Just copying the two main controller extensions would be easy. The main challenge was that these controller extensions also contained a whole bunch of other stuff that hindered things on my end. They were doing some really really cool stuff with generating resources, entities, and background maps on the fly. But that’s not what I need. Our levels will need to be more structured than that and ideally we’d be able to build them in something we can see, where we can arrange tiles and entities visually. The Weltmeister level editor is perfect for that and this game was bypassing it completely.

So this morning on the train it took a bit of effort to untangle the dependencies between the sample game’s fog of war effect and the background maps it was generating on the fly. These background maps were covering up my own Weltmeister level, so they really had to go. I started off copying and pasting chunks with the intention of revising them, but ended up just rewriting it all by hand because so much stuff had to be cut and changed.

And it finally worked. I can now construct a level visually in Weltmeister while having the fog of war laid over it after the fact, during run-time. There is still a lot of cleanup to do (a massive amount), but it’s functional.

Now the hard part

[caption id="attachment_47730” align="alignleft” width="300” caption="Lighting notes 2."]JavaScript game notes[/caption]

Now comes the hard part. My lighting needs to actually be totally different from this lighting in terms of behavior. The one and only reason I was interested in seeing how this lighting was made was for the smooth looking transitions between tiles - in short, just for the visual animation side of things. The behavior itself is nothing like what I’m looking for.

We don’t need fog of war

Currently this lighting is a totally awesome fog of war effect. As you walk along the map parts that are completely dark get revealed. The problem here is that they don’t get hidden again. So you’re basically revealing a trail of light behind you. This, while cool, is not what I need. This game requires the light revealing the level around a light source. When the light source goes past a particular area, it gets dark again.

Visuals - yes, still.

The next problem is still the visuals. While the animations are awesomely smooth with the current tile flipping, you can still see the tiles. I think this is largely an art thing at this stage - the behavior is exactly the same in the sample game, but due to the style of the world tiles that it’s using you can’t actually see the borders around the light tiles fading in and out. My current world tiles are simple placeholders that are pretty much almost flat looking blocks of color with very little texture. This makes the blocks of light and shadow tiles extremely visible against them.

Lighting formula

The other challenge is going to be tweaking the formula to emit light around our light source the way it needs to be emitted. Finding a way to change thresholds etc to make it look natural for our world. Changing the level of visibility is easy (and this will need to be done on the fly!), but the actual level of gradience etc within those levels may require messing with the original formula.

Mechanics and influence on other gameplay factors

As I mentioned above the level of lighting will need to change on the fly during run-time depending on other factors. This in theory, from what I’ve seen in the code, should be easy (you just set the visibility you want as an integer in the light emitting entity). But that’s not all - not only does the lighting need to change visually, but the reach of the light and other factors have an effect on other entities and events in the game. I know this is possible to implement and from what I’ve seen I have a few ideas, but it can get tricky.

Right now my main priority is making previously visited areas hidden again as I mentioned above. That will at least start scratching the surface of what we need.




Categories:game dev dev games
comments powered by Disqus