Background drawing with parallax sprites.

With the introduction of a background image, I wanted to make it more robust than simply drawing a background sprite. I also wanted the user to be able to define multiple background layers. Why stop at just backgrouds? I wanted to give the user a method of drawing a foreground as well. The answer to this design comes in the form of Parallax Drawing. In a nut shell it means that a sprite moves in relation to the camera or in our case, viewport. 

Instead of giving the game engine an api to make backgrounds or foregrounds, I wanted to let the game engine's base sprite management handle the drawing of these layers like there were just another sprite. The controlling application wouldn't want to use these as collidables as it would create adverse affects and hinder character movement. The parallax sprites move in opposite relationship to the viewport. We must, however, provide a speed. We want foreground images to move faster past our view than the background.

See the video below for a demonstration of both parallax drawing and binding our viewport to the world.

You can see that the foreground moves faster than the background. When link hits the right edge of the world, the viewport stops. Obviously in a real game, the viewport would be locked to link. Usually placing him in the center of the screen or some buffer from the left and right edges. This is simply a test.

Graphics Rendering and Management

A lot of development has gone into the graphic rendering of the engine and has caused the delay in blog posts. I don't claim this is the best design but I tried several others that weren't complex enough to do everything I imagine this engine should do. The engine should be designed to support the following game modes:

• Top Down
• Side Scroller
• Dungeon Scroller

Viewport

The viewport is the visible area of your game. For some types of games, this viewport may be movable or even scale-able. The viewport can be the entire drawn area or just a portion. 

Tilemap

The tilemap consists of any number of layers. The layer maximum must be provided to the game engine upon initialization. Layer are arranged from 0 to the maximum. 0 being the lowest layer and drawn first. Memory is allocated per layer based on the number of rows and columns in the tilemap. Only tiles with a grid if of non zero are drawn. Tilesets for the tilemap are aligned in a grid with the first grid id being 1. The sequence follows the rows, not columns, meaning in a 10x10 grid, grid ids 1-10 are on the first row.

Sprites

Sprites can be drawn at any z depth. If a sprite is drawn on the same level as a tilemap layer, it is drawn after that tilemap layer.

Z Depth

Z depth determines the draw order. This is essentially the third dimension in our 2d game engine. Each layer of a tilemap should be a different z depth as two tilemap layers will overwrite each other.

In the above picture the cave is drawn at a higher z depth so it is drawn over the player character.

In the above picture the cave front is drawn at a lower z depth than the player character. Also, the path to the entrance is drawn at a lower level so that it looks like the player character is walking on the gravel tiles and standing in front of the cave.

Background

I debated having anything to do with a background. A background could easily be implemented as a single sprite that was as big as the viewport. I decided that managing this within the engine would be beneficial. I wanted to reduce the amount of code that a game developer would have to use and adding small things like this would help in faster deployment of new games. The engine will decide what bounds of the sprite to draw based on where the viewport is. This does, however, introduce the idea of a world into the engine design. Since the background I wish to provide is one where the viewport can show all of it or part of it, the engine must know the size of the world in pixels. 

I hope to upload some code in the next blog entry.