Kim's Adventure

This is Kim, or his pixelated alter ego at least.

We studied Computer Science together for some time until he had an epiphany and decided to change computers for chicks, and left to pursue a degree in economics.

Since then we haven't seen or heard much from him, but that hasn't stopped his old comrades from working on a game with him as the main character, revolving around his unique way of seeing the world.

It will be a graphic adventure in the traditional Lucasarts style at 320x240! I really miss those games.

Progress is slow, as it's nothing else than a fun little side project, but from time to time we enjoy juggling pixels around and getting it somewhere nearer to a playable game.

Here is one of my favourite backgrounds that belongs to the first act of the game ( click the on image for a better view )

I'll leave you with a a nice song that I believe has a very interesting title to say the least.

Ultimapped

By far, one of the nicest features I've used in XSI is the Ultimapper tool. I've been able to normal map my zombie friend quite easily. The next step is to export it to an Ogre mesh and see how it looks there. It should be quite straightforward.

Here is the result from the directx realtime viewport in XSI. It looks nicer with a moving light :)


And here he is with the normal map applied as a diffuse texture.


By the way, XSI is a very nice program once ( and if ) you get used to its weird user interface.

3D tools are inherently complex, I don't know why some developers attempt to obscure them even further by using non standard interfaces whenever possible.

For example, what's so bad about using the standard OS open file dialog... is there a real need to implement a custom crippled version of it? And this is but a drop in the sea...

Oh well, I believe anyone who uses XSI for the first time feels my pain.

I suppose you can get used to it and learn all these non standards workflows, but the real question is: Why should you have to?

Good Head!

Maybe you've listened to Turbonegro songs before, maybe you haven't. Of one thing I'm pretty sure: These aren't the kind of heads they had in mind :)


Drawn with a 0.5 technical pencil, coloured with a pink highlighter and then inked with a 0.5 pilot pen.

Michael, The Vegetarian Zombie

Let me introduce you my new friend Michael. He enjoys long walks on the beach, playing the piano and cooking. He's also single ladies!

Next step will be to unwrap the UVs of the low-poly version and figure out how to create the normal map.

The Road to Normal Mapping

I started to work on this guy today, and think it has turned out pretty decent. I wanted a cleanly modeled object to try normal mapping on, and just using a cube seemed lazy and boring.

Next step is take it to Mudbox and sculpt all the details there. I have only created normal maps for simple flat surfaces with Photoshop before, so I'm viewing all this as a workflow learning experience.

I have no idea what to do with his face, maybe I'll leave it as it is. I'm hoping to get inspired once I'm sculpting the detail in.

For those with a 3D fetish just like me, here's a wireframe screenshot ( the model ended up at 2588 triangles ).

It was my first time trying to keep everything as quads, and it can be a frustrating experience sometimes. It sure looks more tidy though :)

Bonus image:


This is the face of the main character of our game ( The Teddy Incident ). You can see some concept art featuring him in previous posts.

I've been working on the character head together with one of our artists ( he has done the whole body too, but I don't have images on that ).

...I can't wait to see the little dude alive with animations, running and jumping and chopping off heads.

Dead Sketchbook Back to Life

I was looking for some pictures to post here, and I've noticed that I haven't been drawing much lately... Pretend you've never seen the following drawing before :)



Bonus picture:


It's a concept sketch of the main character of the game mindlessly slaughtering zombies ( He's such a sweet child ). I doubt the zombies will make it into the final game version, but it was a fun drawing to do.

I promise that next drawing will be something new and original ( at least new ).

Serialize Me

I've been updating the animation system editor lately. More precisely on the saving/loading of nodes and connections.

The first thing that came to mind for the job was to use C# default xml serialization to do the work for me.

The animation engine has a diagram that contains all of it's nodes stored in a list of generic nodes. All nodes inherit from a base node class. I thought that the serializer would choose to write the subclass by default, but it has proven a little bit more complicated than that.

Disclaimer: Maybe I'm missing something out and doing it wrong. If anyone knows a better way to do this I'm really interested in knowing, so please contact me.

As it seems, a class that has subclasses that you may want to serialize needs to use the XmlInclude attribute and define what other classes it may represent...

e.g.

public class SubClass : SuperClass
{
//blah blah blah
}

[XmlInclude( typeof( SubClass ) )]
public class SuperClass
{
//etc etc etc
}


Any OO programmer should be running in circles, screaming and trying to pull out his eyes by now. Since when a superclass should have knowledge of all of its subclasses!?!

That's why I think I may be approaching this the wrong way. C# is too nice a language to have a shortcoming such as this one.

I'd also like to point out that my base node class resides in a separate assembly than my node subclasses, so even using that horrible solution is tricky.

In the end, I was wasting more time trying to get around this than doing real work, so I've used XmlReader and XmlWriter to save and load the node diagram manually.

How have I've solved the node type instantiation then?

When saving nodes I write a string with its type name.


BaseNode node = ( BaseNode ) diagram.Nodes[ nodeId ];

String type = node.GetType().ToString();

...

writer.WriteStartAttribute( "type" );
writer.WriteString( type );
writer.WriteEndAttribute();


And when reading them I use that string to instantiate the correct subclass dynamically. The only assumption I'm making here is that it has a default constructor.


reader.MoveToAttribute( "type" );
String typeString = reader.Value;

Type type = Type.GetType( typeString );
BaseNode node = ( BaseNode ) Activator.CreateInstance( type );


As nodes can have custom data, I've also created virtual functions in the base node class that subclasses can override to deal with that data. It may not be the most elegant solution, but it's quite flexible (and it works).

I think that the editor will soon be in a distributable (although feature limited, and nowhere near final) state and I'll be able to get some real feedback.

Next post I'll put some pretty drawings for my nonprogrammer friends :)