Otter Game WIP

Hey folks, I wanted to share a project I'm working on at the moment that I think is going pretty well!

It's a sort of faux-3D platformer with an otter main character. I've made a bunch of shaders that do things like extrude the 2D tiles into 3D, add some globular lighting, and turning textures into sorts of layered spheres. But otherwise it's 100% Fusion.

Here's what it looks like in action:

Please login to see this picture.

(Better quality link) Please login to see this link.

And some moves you can do with the spear:

Please login to see this picture.

(Better quality link) Please login to see this link.

Thanks!

I can try to put together a write-up on how I'm pulling this all off, but it relies a lot on the custom shaders to do the heavy lifting. But hey, it might still be interesting!

Alright, here goes!

So each tile is one object. I've got an external tileset which is converted, chopped up, and loaded into the tile objects at the start of the frame.

Each tile needs three pieces of data: color, slice data, and what depth it is in the screen. So the conversion at the start crams these bits into the RGB channels.

Please login to see this picture.

The color is converted into a simple palette of 5xRed, 5xGreen, and 5xBlue, which comes up to 125 colors. This way the color valule fits into a single 8-bit color value. While 6x6x6 (216 colors) also works, I end up using those extra colors as a cheap buffer for darkening them, which I'll get to later. I store this simple color data in the Green channel.

Next, the "slice data".

Please login to see this picture.

Each tile is eventually extended into 7 distinct slices, which gives it that fake depth effect, and I need to track whether each pixel is ON or OFF for each of these 7 layers (7 ended up being the most I could loop through in the shader, but it's just about enough to get the effect across, and it also fits neatly into an 8-bit color value!) I use the alpha channel to store this slice data while I'm working on the tileset, but once it's converted in goes into the Blue channel.
Since it uses 7 bits, there's one bit of data left over. This bit gets used to optionally darken the frontmost slice, and helps give the front face of the tile a little distinction.

The Red value is left empty for now, but the shader will handle it later.

Once the conversion is done, the tile objects themselves are created. Each layer of depth goes on its own actual layer in the frame, and the objects are positioned and resized as appropriate in space. The tiles will dynamically read the level data from a 3-dimensional array as the game goes, thus there are JUST enough tiles to cover the whole screen on each layer. Since the farther back in depth you go, the more tiles you'd need to cover the screen, I have to limit the number of layers, as they add up really fast. I work with 11 layers, and it ends up being nearly 1800 tile objects alone!

Each layer of tiles has its own shader applied to it, which takes the depth position of the layer as well as the slice data in the Blue channel, and copies the whole layer into the 7 slices of depth. At this point it also gives each pixel its depth data, which ends up in the Red channel.

Here's what the depth value looks like on its own:

Please login to see this picture.

The sprites themselves are more simple, since they don't have the whole slice data to work with. So each sprite has a shader on it that converts the color data, and applies the depth value. It compares the depth versus the tile background, and only draws it if it's in front. That way you get proper layering.

Some sprites ALSO get depth applied to them, but I do this the simple way: each sprite just gets 7 extra display objects that are positioned in space.

Once all the sprites and tiles are placed, there's a layer on top that handles the lighting data.

Please login to see this picture.

The lighting is a little tricky; I have to track color values in a 3D space, but the pixel shader only works on the 2D screen. As a sort of compromise, I divide the X and Y of the screen into 10x10 pixel chunks, and the area within each of those chunks becomes 100 pixels that represent the the Z axis. Thus I get a lighting map that's a little boxy, but otherwise serviceable.

Here's what the lighting map looks like with a few light sources:

Please login to see this picture.

Each lighting object adds its color to the appropriate pixels on the lighting map.

For the character, I've got a sort of skeletal system where the character is built of two major spheroids, the body and the head, and then things like arms and legs and ears can be stuck onto it.

Please login to see this picture.

The head and body use a shader that takes a texture and creates a 5-layered sphere (sort of) out of it. The layers are paper-thin, so it's not perfect, but it works well enough at the resolution I'm working with.
The limbs and things are just active objects that are positioned in space relative to whichever spheroid they're attached to. Things like the tail are done by stretching an object between two different points.

The whole thing then runs based off of a simple animation system I put together:

Please login to see this picture.

The limbs and such can move based off of a sine wave or keyframe animation or some combination thereof. It's been a bit of a headache trying to wrangle an animation system like this into the game, since it's my first time doing something like this. It's been a bit of a learning experience!