Blogs - lxndrdagreat

Setting the right mood in the environment surrounding the player is very important. A very difficult and many times incorrectly-done part of this is the lighting. Depending on whether the game is 2D or 3D, and if you want dynamic lighting all play into how difficult it is. As with most every other decision, your target device (computer, console, mobile devices, etc) and your target market will heavily influence the entire process; Devices have limitations, and different styles of games need different moods and environments.

With Fixbot, we wanted to have some lighting in one of the levels. We weren't really worried about having realistic shadows or dynamic lighting - we just wanted the idea of navigating the player in the dark with something like a flashlight to be another fun gameplay element.

With this being my first major game project using Cocos2D for iPhone, I hadn't done any form of lighting with it yet. I had done lighting (both dynamic and non-dynamic) in other PC and Xbox360 projects, using different 2D engines including Microsoft's XNA and the more cross-platform SDL. Even though I had done similar lighting styles with these systems, I was having trouble figuring out how to best do the lighting in Cocos2D. I think my biggest problem was that I was still learning the underlying core of Cocos2D: while Cocos2D is very advanced, and is a wonderful engine for indie developers because it is open-source, it was doing things a little differently than I was used to. Now that I have had more time to learn it, as well as time spent on digging through forums, blogs, and finally the engine's source code itself, I have a much better understanding of it.

At first, we tried doing the lighting in OpenGL. I had my best programmer, Ian, digging through OpenGL books and rewriting shaders to work with OpenGL ES (which is what Cocos2D uses). While Ian spent a week on that with minimal success (it just wasn't performing like we needed it to), I started researching again. I was digging through blogs and forums (and again the source code) looking for methods to do simple lighting in Cocos2D. I was looking for an old-school 2D approach to the lighting - have a light sprite on the screen, and color all of the other pixels on the screen based on their distance from the light. Another method I was looking for was where you have a black (darkness) overlay covering the entire screen, and then "cut holes" in it using the light's sprite (usually based off of the sprite's alpha values).

Eventually I found the start for what I needed in order to do the second method - cutting holes in an overlay. My biggest worry going in was performance - for the lighting we wanted, we didn't just want to have the player have the only "flashlight" - we wanted objects in the environment to have lights as well. This is when I found the CCRenderTexture class in Cocos2D. It's a very powerful tool that can be used to do multiple things, including blending and masking.

So, in order to create our lighting effect, I have a CCRenderTexture that covers the screen and is black. Then, every tick, it gets updated according to whether there are lights currently visible on the screen. It's always good to narrow down how much you are doing in a tick method to help keep performance high.My update tick works something like this:

• Begin drawing on the CCRenderTexture
• Clear the CCRenderTexture with black to make it look dark
• Set the color mask to ignore everything but the alpha channel
• Find all of the lights that are actually visible on the screen. This narrows down how much drawing is being done.
• Draw the visible lights (CCSprites have a 'visit' method)
• Reset the color mask back to normal
• End drawing on the CCRenderTexture

Overall this achieves our desired lighting effect, and with a decent amount of testing it's proven to be performance effective as well. Now, our players have flashlights so that they can see the things that go bump in the night.

Read the original post here

Early on in the design of Project Fixbot, we knew that we wanted large and somewhat complex levels, designed primarily around our movement style. We needed to be able to handle different kinds environments, and we wanted a lot of flexibility when it came to the design of the actual levels - this included the ability to have the ground at weird slanted angles. But this created some new challenges for us: how would we handle collision, with all of the different kinds of things the player could collide with?
One common way of doing collision is to handle it by using the object's bounding box and sprite to decide if collision has happened. Sometimes this includes using per-pixel collision to handle odd-shaped objects. The problem with using the bounding-box method in this case is the flexibility we wanted with our environments (weird slants and the like). Per-pixel collision checks can be expensive on performance, and in our case it wouldn't handle all our movement style easily.That was when I decided to use "surfaces" (as we call them) instead of using bounding-boxes or the art assets themselves for the collision.
I figured out that all we really needed to handle all of our movement and collision was an invisible line. These lines (surfaces) would tell our engine how the player and enemies should interact with it - whether that's by colliding or bouncing or something else. Using these surfaces lets our team jump from level design to level implementation much faster. While Joel and I were creating the surfaces and how they would work in the engine, Todd was creating a level editor that would let us create them. In the level editor the surfaces get created on top the level art assets, allowing Zak and everyone else building the levels to match things up quickly.
Getting the surfaces working correctly involved a lot of line-based math programming. In code, our surface class has a lot of helper methods we had to create to do things like computing the slope of the line, checking the distance between a point and the line, and checking to see if two lines actually intersect at all. Another tricky part was deciding what side of the line the player was on so that we could rotate him accordingly - it would be really annoying for the player if he launched Fixbot at a wall only to end up inside of it; getting that part working was one of the first major hurdle for us to get over.
Overall, the surface method has been difficult to implement properly, but has been very rewarding. With a lot of hard work and a lot of staring at the whiteboard, we've managed to build ground to stand on.

(original post at official website)