Tuesday, July 2, 2013

Dragon game update: additive blending, contorted transformer and slender dragon

Hello again!

This has been a pretty big week for my game.
I've refactored the rendering engine simplifying some stuff and improving performance a lot. I've also added smooth shading to my dragon model and had a fight with blender over exporting models (I had to change roll of some bones which turns out isn't as simple as I though because all animations get screwed up).

As for additions to the animation system:
  • Additive and Subtractive blending. Allows me to create an animation I can lay on top of other animations (eg: small variations when running)
  • Skeleton masking: Allows me to select which bones get affected by a node
  • Triangular mesh node blending resulting in Head rotation: Ok, this isn't completely new but I did remove it for some time when I did the animation tree refactor
I also did another small anim tree refactor meaning it is no longer a tree and more of a graph with a root node and leaf nodes. This means I can now have one source animation node being used in several other places which is really useful.

Anyway, here's the latest update video:

And here you can see what happens if you don't subtract animation from a reference pose:  

Also my dragon is apparently a transformer, here he is as a spaceship:

That's all for this week. Next week I'll be working on leg IK, adding flying animations and I'll also work a bit on the texture. I'd love to do an IK tutorial eventually since it's a topic I already got myself quite familiar with, and there are a couple of techniques that are easy to implement that you don't need to know too much math to add to your own game.
Either way if you have any questions about animation blending/trees or IK feel free to contact me either by commenting or through twitter @SpliterCbb


Saturday, June 22, 2013

Working on a new game

I've been neglecting this blog for quite some time since I was thinking of moving to wordpress but without ever actually committing.

So I decided that for the time being I'll keep updating this blog with the news of the game I;m currently developing.

The end result I want is a game where the player is a dragon from the start of its life in the egg up to the end of the life. I want it to have a certain storyline but It'll be free-roaming/open world for the most part with story taking place in specific areas, one of the key focuses of the game will be the animation as I want to combine keyframed animation, IK, physics and procedural animation to have a dragon that controls great but still responds naturally to the world.

I'm developing it on my own engine since I want this to not only be a great game but I also want to learn the hard technical parts as I'm making it.

So far I have a basic resource management, a rendering system and the beginnings of a robust animation system.

Here are the video updates so far:
Update 1

Update 2
A funny bug related to my direction setting resulting in wobbling.
Update 3

Friday, December 2, 2011

New Website is Up!

Ok, so I was talking with the folks at the Ludumdare IRC the other day and they advised me to create a website to show off my stuff. And so for the last two days I've been working on it tirelessly almost every waking hour to get it up and running and I tell you: HTML, CSS and javascript are NOT nice to work with!

Also as I'm writing this I'm talking to the guys at IRC and another suggestion of theirs that I think I'll follow is first to switch from blogspot to wordpress, then register a proper domain name, and finally change my hosting. But since I've only just created it and I'm really busy right now I'll do that next week if not later.

Anyway, here's my Website:

Any critiques in relation to content, design and anything at all are very welcome!


Tuesday, November 29, 2011

Deferred Lighting

First a quick update on stuff that's been going on since my last post here:
-I've been let go from my old job, looking for new one.

And now back to our topic at hand.
I always like to boast that I'm a graphics programmer, that there's little that can stop me in my way and even though I actually do believe that's true I don't have much to show for that. Be it because of work and being uninspired to program back at home, or because I've spent far too long retouching my engine and in the end I end up with a lot of hidden work and nothing visible, or because I was simply too lazy/distracted.

Well, since I lost my job I decided It's time to boost my portfolio a bit, and prove to everyone and to myself that I can actually be a good graphic programmer. To accomplish this I decided to work every day on a small demo of a certain feature I never implemented before. The first one being:

Deferred Lighting.

Of course my first reaction was grabbing as much as I could from the internet in terms of research papers and tutorials. The most helpful I found are these:

Creating a GLSL Library - This was a good way to quickly sketch out a simple per-fragment lighting shader and apply it to a model lit directly. I've used this before so I simply copied most of the code

Coding Labs Deferred Rendering Tutorial - This is what I needed, though I decided to skip the tutorial and learn directly from source code since I already understood the concepts and implementation, but I didn't know which opengl functions to use.

Normally Deferred rendering requires you to use the inverse of the modelview matrix and inverse of the projection matrix to get both the pixel position from projected screen space to camera-space, and to get the lights from world space to camera space, however the tutorial used a nasty inefficient hack to get the pixels in world space without the need for transformation: it simply recorded all x, y and z inside what in normal deferred lighing program would be a single-32bit float-value gbuffer.

However with lights I did another nasty hack: instead of using the gl_LightSource[i].position in my shader I simply replaced it with an array of vec4 screen-space light positions I calculated outside using the modelview matrix from the first pass and passed to the shader.

All of this just so I didn't have to write/find and de-obscure and test and debug a matrix inverse function.

In the end I spend between 4 to 8 hours on this (how mach depends if you count the research time) over the course of 2 days.

The results?

All in all it wasn't that bad but the code ended up a horrible conglomerate mess, most of which was shoved into a single main.cpp file.

If you're interested you can download the demo with the code here:
Deferred Shading Demo

Before you look at the source please note that this is terrible code, unoptimized and originally wasn't meant for viewing by other people, if I ever did the exact same demo again there would be ZERO similarity.

Right now I'm working on another experiment, namely importing a model with animation using Assimp (which I still have to learn) and then use that data in my animation tree (similar to the one UDK has), in the end add some IK, but this experiment is much larger than the deferred shading one, so it'll take probably about a week or so before I post here again.

Thanks for your attention!

Sunday, August 21, 2011

Progress snippet

Ludum Dare 21 has started yesterday. Unfortunately I'm not participating but that doesn't mean I won't be doing anything this weekend!

For the last month or two I've been working on my game engine. My little baby Litterbox has it's third rewrite from scratch ever since I've started making it. This time the key word is "Components"!

Now, components are a very, very good thing, but the classical component-based engine design has it's flaws like component communication overhead, the lack of centralized control, and many more than would normally keep me away from it. However I couldn't just go back to using the traditional deep hierarchy design as it constraints the flexibility of the engine, and many times you have to use a super-complex base-object that I really don't want to have.

So.. What's the sollution?

My engine architecture is a hybrid one, having always a centralized  game entity to which the components are linked. In most cases this means that I have a command center for my objects, but I can also add and new components easily. So if I have a 2D game engine where I suddenly would want one of my bosses to be fully 3D there wouldn't be a problem! I just add a lb3DModelComponent to my boss object, and handle all the special 3D code in the entity.

So far I've moved from 2D animated sprites to 3D models (with Horde3D) without any problems, and if I want a 2D game on top of my 3D game then there's absolutely no problem!

So, here's my progress so far:
-I have a fully functional Entity system with attachable components.
-2D box-based collision system (with various iterations per frame)
-2D graphic system, leftover from earlier engine testing, with support for animated sprites loaded from a sprite sheet.

My Game
I also started thinking about the game I want to make. In my earlier days as a wannabe game dev I created a small demo in gamemaker, where you controlled a fiery guy, you had a selection of fire-based weapons and you were left in a small town full of squishy pink dudes and buildings to use your abilities on.
Recently I showed it to a couple of guys at LudumDare IRC channel and the feedback they gave me really pumped me up so I decided to give that game another try.

The basic idea of the game was that you were a Poyo, a little pink dude kinda resembling a Poring from Ragnarok Online. You would then acquire special powers that would let you transform into a version wielding 1 of 3 natural elements, namely: Fire, Water and Flora.

The game setting was mostly based in a fantasy land with traces of advanced tech.

Now I'm reworking the Idea. I'm planning for keeping the feature of 3 elemental transformations, and as planned before the game would be an Action-Adventure, though I might throw in some RPG elements in there too since it seems to be a good blend considering the fantasy setting.
Anyway, here's the screenshot of how things are so far:

This also was a good excuse to go back to modelling in Blender.
Importing these models to Horde3D was a real pain in the ass as the colladaConverter crashed when converting them, but the people on Horde3D forum had a nice workaround which works good so far.

For comparison here's how the old PoyoAdventure demo looked:

That's quite a sight there in all its 2D glory, however 2D constraints when it comes to depth and having object on top of one another really threw me away from it, that's why I decided to remake this game with 3D graphics (though with the same 3/4 view). I still plan on using 2D collisions though, just to work faster and have something done in less time.

I won't finish this game but I want to have a fun to play prototype. If it's fun enough then I'll work on it more adding fully 3D collisions, proper story, and I'll invest more time into it. (Basically this version will be the proof that I can make a game, as well as a proof of concept for my engine).

I'll be working on this most of the weekend, in a few hours I should have the little pink dude walking around with a basic animation and colliding with stuff. No idea what I'll do tomorrow but lately I've found out that striding back and forth around my house, brainstorming, gave me lots of good ideas as well as will/inspirations to implement them.

Edit: For those interested, no I didn't get the animations playing. I have no idea how I export animations from blender to use in Horde. I'll ask on Horde forums but that place is pretty much a ghost town. I'm kind of starting to regret using Horde instead of Ogre3D. If I don't find anything reasonable soon I'll try making my own converter with the help of AssImp.

That's all for now!