Dave McKean Should Be Flattered, Right? Right?

So, what do you do when your game is a week from the final deadline and you realize you want some cool promotional art, splash screens and loading screens? Why, you task it to your AI engineer! Wait, why doesn't that sound right? Anyways, when I thought about what these images should look like, my mind immediately went to one of my favorite artists, who has done album covers and comic covers: Dave McKean. I had three images in particular of his in my mind when creating the images for our game:

The Sandman Vol. 7 Cover


The Last Temptation album cover, also the cover of Book I of The Last Temptation Comic


Cover of Book III of The Last Temptation comic

The middle image hangs on my wall as a large print. With those images in mind I created:

Remote Shepherd comic book cover

Remote Shepherd splash screen

Remote Shepherd loading screen

This Is Why We Can't Have Nice Things, Delta

A little photoshop magic on the city map shows just how well our detective takes care of his things.

Animations: Part 1

So far, basic animations now work within the engine. We have accomplished this by using the Havok physics and animation engine along with its exporting tools for Maya. Our modelers and animators create the skinned skeletal rig along with any partial or full body animations we need and export them out as .hkx files. These contain either all of the information for a single animator's character, or simply a single skin, skeletal rig, or animation. As we will want a variety of animations to help in behavioral profiling within the game, the later approach will most likely be the main version used.

Each of these individual items, i.e. the skin, skeleton, and animation are all loaded in separately through Havok's pipeline and assigned to an animated mesh object. For the most part these are stored 1-to-1 within the animated mesh. However since we use our own rendering system, we need to convert the mesh provided by Havok into our own form for rendering.

After getting all of the items needed for animation, updated matrices based on the skin bindings and modified by the rig and animation are passed over to a shader to handle hardware skinning. Cel-shading and other effects are also performed to get the desired style we need for the game.

What still needs to be done or made:

• Blending of animations so that a character can wave to someone, spray paint a building, or flail their arms all with the same walk cycle
• Allowing for quick ease of animation swapping within a mesh
• A manager to handle storage of all this data so as to not flood memory with multiple objects of the same animation.

The Infernal-Light Engine and Graphics Going Forward

So, my primary objective over the past 7 weeks has been to reorganize our game engine for use with producing our game. This has included clean up and refining of the original code base (this included adding an event system, observer-observable model, smart pointers, and general code refactoring and cleanup).

While doing that, we had an express need to incorporate a pre-built physics and animation system. The reasoning was, in our previous games Polarity and Rogue Squirrel Returns, I had written our physics and collisions from scratch (basic acceleration, velocity, momentum, bounding sphere, bounding box, and bounding plane). The amount of time and effort required was tremendous, and while the code was re-usable, more optimized and organized technologies would have saved us a lot of time. So, for this, we included rolling Havok Physics and Animation into our engine. This required writing an extension library, which we could use for handling all of our interactions with the Havok system. Currently, we've incorporated Havok Physics into the system, with specialized event handlers for catching collision events. We are still working on getting Animation into the system.

So, what is next on the agenda? Next, is to take our DirectX 11 library and extend aspects of it to allow for multi-pass special effect rendering. To accomplish this, I will be doing three specific things:

1. Extracting out code used to render and put it into a more generalized "Pass" object, which knows what objects it wants to render.
2. Give the pass object as set of input and output "Buffers", which represent the render targets they will attempt to read from and render to.
3. Create a manager that keeps track of these "Buffers", enabling quick fetching and storing of Buffers as soon as they're available.
4. Create a unified light manager to manage all of the lights available in the scene. The manager should be capable of getting all of the relevant lights (up to a max number) for a given object in the scene.
   

The goal is to create a chain of passes which can be processed, feeding one into the other. The end result is a render chain which can build all of the components of various rendering effects, and perform them in the order stored in the chain.