Thursday, 14 March 2013

Particle Editor

I'm sure you've all seen the videos of my game, and the particle system used for the fires and stuff. Well I've been hard at work massively upgrading the system to allow for timeline based changing attributes, (stuff like animation, multiple colour changes, velocity changing and variable sizes). Now this massively increases the complexity of creating a particle effect, and therefore I decided to write a editor to allow for creating the effects and testing the look of the effect in real-time.

It's nearly complete, only a few features left to implement but they are mostly convenience features, the editor as it stands is perfectly capable of creating the effects without issue.

Some screenies:


My new android phone arrived yesterday so I finally got to try my game on it. And good news! It works!

Obviously android has issues with render to texture so the deferred rendering pipeline is a no go, however the forward render works great and I'm intending to implement per-pixel forward and normal mapped forward to give the android more choices.

Controls do however need a lot of work to make them nice, but meh... it works!

Sunday, 10 March 2013

New particle system

Hello all! Just giving you all a little update on my current progress :)

I have spent the last week working on a new particle system for my game, one that supports animated effects, size changing, velocity changing etc all based on a timeline and keyframe system. It all works now, so all that is needed is a pretty editor and I can massively increase the quality of the particles :)

Screenshots and Videos will come soon once I create a decent looking animated fire / smoke spritesheet :p

Wednesday, 27 February 2013

New playable version

Just uploaded a new playable version of the game.

Added spell system, fixed timestep, added fullscreen ability, fixed glitchy weapons.

Get it here!


Spell System

Ive been hard at work implementing the spell system for my game, and I finally have something to show! Watch the following to see a demonstration of a simple fireball spell:

Spells are formed of a set of damage stats, and a two stage behaviour system.

Behaviour 'move' is evaluated until the spell collides with something, then behaviour 'damage' is evaluated until the alive flag is set to false.
In this example the 'move' behaviour is simply a move forward, and the 'damage' behaviour is a small explosion.

In my game spells are not skills or anything like that, instead they are just weapons. They can be crafted. This means that I am intending to allow players to customise the behaviour of the spells they create, hopefully making the spell system more interesting.

Deferred Rendering Pipeline

I made a little video demonstrating the Deferred Rendering pipeline, for anyone that is interested:

Friday, 22 February 2013

Deferred Rendering Fixed!

Finally! I managed to get deferred rendering to work nicely, without lighting artifacts! Also added some nice stuff to fix weapons jittering around and to allow for undecorated, native resolution windows on desktop :)

For the more technical minded of you heres some information about my deferred rendering woes.

Due to aiming the game to eventually work on android I need to make it compatible with OpenGL ES 2.0, and therefore I cannot use MRT for deferred rendering. This is a massive bummer, but seeing as I want loads of light sources in scenes (lots of torches, flashy spells, shiny weapons, glowy stuff) using a forward rendering approach is not feasible. For example, to get the same lighting quality, the cost for each approach is:

Deferred Rendering cost = Objects * 2 + Lights
Forward Rendering cost = Objects * Lights

As you can see deferred is much cheaper (btw with MRT that would be Objects + Lights).

So, without MRT I am limited to a maximum of 4 x 8 bit channels (rgba) output per scene pass. Obviously I'd prefer to keep the passes to a minimum (i.e. 2) so I settled to only being able to output the normals and the pixel depth (so that the position can be reconstructed). Now normals are 3 dimensional, but depth requires more than 8 bits or it'll have artifacts when reconstructed due to rounding errors. Obviously an issue with only 4 channels :p

This site to the rescue! After much googling I came across this site, with information for packing normals in 2 channels, leaving me 2 channels to pack depth into. Yay! Problems all soved! Woot!

Anyway hoped you like that narrative :p I'm off to work on more UI Screens (boring but necessary) so sometime soon I should be able to have a new and improved build of the game out for you lot to try :)