Among The Clouds 2.0

I guess I haven’t mentioned it on this blog so far: two friends and me created a wounderful-looking sidescroll-shooter for Xbox 360 back in university. It was called “Among The Clouds”. Unfortnuately we never got the time to finish it and realese it properly. So far only one demo-esque level exists and the gameplay is sort of… well let’s call it “unispired”. The core idea was to give the player four different colours for the shield of the player’s aircraft. If one shield-color is selected the aircraft’s shots affect only same-coloured enemies and is protected against those enemies at the same time.

I’m happy to announce that I’ve finally picked up work to completely re-code “Among The Clouds” and to release it on XBLI (“Xbox Live Indie Games”) once its finished. It’s a little embarrassing to say this now… but somehow I’ve lost the source code for the original game :-( But what the hell! This gives me also the chance to fully correct all those bloody and ugly mistakes and dirty hacks we did on the game. Because unfortunately the performance of “Among The Clouds” with all its pretty but memory-consuming graphics never has been quite good – it run around 15 – 25 fps on the XBOX 360 – and about twice as much on an ordinary PC. The main reasons for that crappy FPS-counts mostly lie in the complete absense of a seperated and well-coded graphics-engine. To go into closer detail arcitecture-wise: Every game object draws itself. The code which handles the draw-procedure lies in every sprite-object – of which each represented one graphic. To make things worse the draw-code itself had muuuch overhead: Different drawing-styles ( “glowing” sprites semi-opaque sprites, etc.. ) were each represented as additional function, although most sprites never needed all of them.

My new approach takes all these mis-plannings into consideration. What I wanted was to create a full-fledged 2D Rendering-Engine, which manages and draws all the sprites in the game completely detached from the actual game-objects. This design allows it to be fully portable to any other 2D-Game.

My plan for this blog is to provide permantent updates on the creation-process of the game. Talking about the rendering-engine I will talk about this in this post. As I mentioned I create the rendering-engine completely seperate to the actual game as a .dll. One of the things which bugged me in the original design was it’s low feature-level. There were only single-part sprites which were drawed, moved, scaled, rotated and so on. But what if I needed Sprites which were nested? For example a boss-enemy should feature multiple body-parts which move seperately to each other but form one big sprite at the same time – maybe something like a giant tail where each tail-joint influences a certain number of children-joints /-sprites. All of this simply wasn’t possible with the original design but is really important to me.

So my new design for sprite-organisation and -drawing is this (click to enlarge):

Maybe we need a bit of explanation here. First of all: don’t get confused with my German comments (yellow blocks) – this UML wasn’t intended to be shown anywhere originally.  As you can see each level is made of multiple layers (which represent different depth-steps visualized as parallax scrolling layers). Each layer basically contains all of it’s sprites – organized with an (unsorted) tree structure. The elements of this tree are “SpriteNodes”. Each SpriteNode contains the sprite-image itself, a list of child-nodes and (most impo

rtantly) a transform matrix. These matrices are the heart of the new engine. One matrix fully describes the position, the rotation and scale of the sprite in this node. These matrices enable the design of a scenegraph: each child-node’s matrix is built up from the local matrix multiplied with the parent’s matrix so that the tree is one giant dependency-graph. Whenever a matrix in the tree is changed, all subsequent matrices are changed with it – just like the design of composed sprites demands it to be.

The use of matrices has one big flaw though: you cannot just multiply the matrices down to the leafes: If you’re familiar with some basics of computer graphics you’ll know that the order in which the operations scale, rotate, translate are performed is crutial. This is because rotations and scales are always performed from the coordinate-origin. Applying rotate AFTER a translate-operation causes the radius of that rotation to increase with the distance to the origin. If two compound matrices of parent- and child-node would be multiplied directly with each other the order of these operations would be wrong in most of the times. That’s why I have to decompose both matrices to their three contributing elements (scale-vector, translate-vector, rotation-quaternion) and build up a new matrix by applying their elements in the desired order:

This is what the respective code looks like. First the local rotation (the rotation from the matrix of the node we’re currently in) is applied (the sprite still lies in the coordinate-origin), then the local scale and the scale of the parent-node is applied to the matrix. Now it becomes a bit tricky. For taking the rotation of the parent-node into consideration, we have to leave the origin, since we want to rotate the sprite around the position the current sprite has within the parent (e.g. a weapon (child) held by the arm (parent) of a human (parent’s parent) ) – so we move the sprite with the amount of translation it posesses locally within the parent – multiplied by the parent’s scale, because in case the parent scales up/down, the local translation in- or decreases so that the child stays in the exact same position relative to the parent. After this is done, the parent’s rotation and translation can be applied.

To make things a bit more visual I’ll provide two screenshots of my test-environment. The first image shows an aircraft (parent) holding a crystal (child). The aircraft is now rotated and scaled – and as you can see the crystal rotates and scales correctly and stays in the exactly same position relative to the aircraft.