This is a freshly added feature, so it may yet be ripped out due to performance concerns, but I thought I'd share anyway.
So we've now got dynamic shadows on the player sprites in the game. We can't do anything with the static wall shadows as that would be just too costly, which is a pity, but I'm hoping we can run it on the larger baddie sprites without the game grinding to a halt ( Since O2 has been basically in pre-production for a week and a half now I've been refactoring a lot of the code, such as the particles, to gain performance which should hopefully enable us to add even more eye candy than in the original ).
Let's get our hands dirty with some theory of how it works.
On the map we add some "Light probes", which are our light sources ( The actual light images you see in the game / map are just that, bitmap images, so we had to add specific ones. It does have the advantage of giving us more control though ).
When we plot our level we loop through all the light probes and store their x,y and alpha. Then we do a distance test to the player and sort the array where we store all the light probes based on that, so the very first one closest to our player at the start of the level is at the front of our array.
From there we just check every time the player moves their distance to the light probe. Based on that we can set the length and darkness of their shadow ( So it's a little bit of atan2, and some scaleY / alpha code wise ).
The tricky bit is moving from one probe to another. Originally I just checked the next and previous light probe in the list ( Hence pre-sorting them at the start ), but when there were a few together ( Like in the example above ) that could break, which wasn't part of the plan. So I've just altered it that on even frames we check the 5 probes "behind" the current one in the array, and then odd frames we look 5 in front ( The check is just a simple distance check, if the probe we're testing is closer to the player than the current one, then make that the current one ). That seems to have fixed things, although it needs testing on a complex level, which is why it may still yet be ripped out.
The first approach wasn't a dead loss, it's much quicker than the current one as we're only checking against 2 probes, so I've kept that code for the npc and it'll be what I use for the baddies, as I think we should be able to get away with it.
As a final touch the shadow is animated, it's actually a walk cycle from our Knight's Quest game, but with scaling / blurring and alpha you couldn't ever tell. Speaking of alpha, the reason we store each light probes alpha property is because that sets the intensity of the light source, with full 100% alpha being the brightest possible light sources. I'm toying with adding colour information to them too ( It'd be so easy if we could just add a tint and read that, but unfortunately not ), as it would be cool if for example when you're approaching a console the screen would not only let the player cast a shadow but light him up too ( It would make them similar to their Unity Light Probe namesakes ).
There are limitations to this, we're only ever running one shadow sprite as opposed to 4, so in the in-game grab above the sprites should be casting shadows from the other 2 light sources too, but this is just meant to be a bit of subtle eye-candy so there's only so much cpu cost we can spend on them. I'm sure someone on Kongregate will let us know about it anyway.
And that's basically it, hopefully it'll make the cut as it does look cool.