Textures

So I'm discovering that making textures takes a LONG time. this is especially true if you are just using a mouse to do all of your drawing.
Previously I was able to, if undisturbed, to make at MOST 2 textures a day.
It's worth mentioning that all of the textures I make are quite large; most are 1024 x 1024 - I can always, easily make them smaller.
A week ago I decided that I was tired of drawing with a mouse, so I decided that I was going to get a graphics tablet. After much browsing online I finally found one I liked:
The Wacom Bamboo Capture looked like the perfect mix of functionality and price - I promptly picked one up from my local big-box electronics store.

I must say that using a tablet is not only more intuitive than using a mouse, but it's also quite faster.
The software I use to author my textures - GIMP - conveniently supports tablets, and the 3d modeler I use  - Blender - surprisingly does as well.

All in all I must say that a graphics tablet was a wise investment, I can now easily pump out up-to 6 completely new textures a day. That's three times faster than with a mouse, and I must also say that my images also look better as a result.

Some of the textures I've made in GIMP, rendered in Blender.
Can you tell what game I'm using for inspiration?

Finally a level editor!

Well it took a bit of time, but it's finally in working order! To elaborate a bit further, here's a list of things that are now possible in the Portal debug mode:

• Load levels from Ruined Level Portal files (*.rlp)
• Switch to portal editor mode - I edit individual portals at a time
• Select just about any object in the level, and edit its properties with the Property-grid control and my "gizmo" control
•  Load new models and collision meshes while the game is running
• Save portals into *rlp format

To make loading, and saving levels possible, I had a couple of options.

1. Use reflection to process and load the level data to and from XML files
2. Use reflection to process and load the level data to and from "binary" files
3. Write my own format, importer and processor

I went with option number 3, for a couple of reasons:

• I could make my format as size efficient as possible ( I'm using bits, bytes, and uint16's)
• I could store just enough data ,as opposed to too much junk
• I could store what I wanted and know where to find it in the file
• XNA makes writing importers and processors REALLY easy
• I just like the flexibility

Now my format may not have the readability of XML, but it is sure a LOT more readable than XNA's binary-serializer. If someone needed to, they could parse through the level files by hand and make changes - with the right documentation of course.

Here's a little bit of the level parser to give you an idea of what I mean:

ushort Type = input.ReadUInt16();
if (Type == 0x0000) // Torch
     portal.DynamicObjects.Add(new Engine.DynamicObjects.Torch(input.ReadVector3(), input.ReadSingle(), portal, input.ReadBoolean()));
else if (Type == 1)
{
     // Door
}
else if (Type == 0x0002) // Ladder
     portal.DynamicObjects.Add(new Engine.DynamicObjects.Ladder(input.ReadVector3(), input.ReadSingle(), input.ReadSingle()));
else if (Type == 0x0003) // Chest
     portal.DynamicObjects.Add(new Engine.DynamicObjects.Chest(input.ReadVector3(), input.ReadSingle(), Index, input.ReadUInt16(), input.ReadUInt16()));

So as you can see, I'm only reading the data used to initialize the torch, I don't need to store all the other fluff XNA's-serializers store - and I'm not talking about the stuff you can mark to ignore.
For example: things like strings can be stored as a char[] instead of 2 bytes per letter, or if i had an object that contains both a model and a collision mesh, I can have an unique type saying, "Hey, this object's model and collision mesh are the same, I don't have to store the file name twice."

Enough talk for now though, here are some pictures of the level editor in action-

I can even edit instanced-objects individually!

Trees and God Rays

Yep, another one of those posts where the title summarizes its content.
So, as far as eye-candy goes, Ruined should more than fill ones appetite - at least for an indie game.

First up it's:
Dynamic Trees - the kind with leaves.

• You heard right, trees will appear to blow and sway in the wind. 
• I'm also using hardware instancing for drawing trees/bushes/grass, so I should be able to have a considerable amount of vegetation on the screen at once. 
• Trees are pretty awesome...

Followed by:

God Rays a.k.a. Light Shafts

• God rays create the effect of sun-rays shining around sun-occluding objects.
• In other words, it's nothing but eye candy, but delicious eye candy at that!

A word on implementation

God-rays are actually really easy to program.

1. Draw the sky, masked by the environment into a TINY render-target (you can use your depth buffer for this)
2. Radially blur this image into another TINY render-target, using the sun-screen-space position
3. Additively blend the blurred image with your final output.

Here are some links where you can find out more on programming god-rays

• http://http.developer.nvidia.com/GPUGems3/gpugems3_ch13.html
• http://jcoluna.wordpress.com/2012/06/05/light-shafts-tone-mapping/

Dynamic Vegetation is a bit harder.

1. Your model needs to have certain values painted to each of it's vertices
2. In the vertex shader you transform each vertices position taking into account it's vertex color
3. Blender doesn't support painting a single channel of a vertex color at a time (ie Red, Green, or Blue), so a processor must be written to combine three separate vertex color channels into one. So you have to make a channel for Reds, a channel for Greens, and a channel for Blues, then you combine all three of these channels into one.
4. I then wrote my own simple model format to allow me to hardware instance with ease

Again, here are some links that have some more information on the topic

• http://http.developer.nvidia.com/GPUGems3/gpugems3_ch16.html
• http://mtnphil.wordpress.com/2011/10/18/wind-animations-for-vegetation/

Note: The tree model used in this post is provided as free-ware from the Loopix-Project in its original form.

Night Sky

Well, this post will be a quick one.
As the title implies, I have a working night sky, complete with stars clouds and a moon!

Oooooh! The Red moon.

Sky

So, considering the last post, Terrain, one of the other constantly visible things in a game is the sky. Whether  you're just getting a glimpse of it as you fight off some monsters or flying through it, the sky can be equally important as any other part visual part of a game. so of course I've gone ahead and started work on the sky system for Ruined. I wanted to follow the art style of the game, so I stuck with a stylized design.
The sky is still "under construction," but I feel like a good portion of it is working

The clouds follow the stylized theme of the game,
and move dynamically over time

Terrain

One of the most important things in a game can easily be its terrain. The scale, the detail and the atmosphere it creates easily make a good terrain system a must.

So of course I've begun work on a terrain system, nothing fancy yet, I've only invested 2 days in it so far, but I'm pretty pleased with the results.

I've created a terrain editor, built right into the engine.
Features include:

• Loading/Saving of a height-map
• Physics, dynamic lighting... - all the features of the engine
• Texture splatting
• Raise, lower and smooth tools
• The ability to paint terrain from right in the game!

I still need to look at some optimization techniques so I can be sure it runs flawlessly on the Xbox, but for now here's some screen-shots of the editor.

The terrain editor doing its thing.
Green = Raise; Red = Lower; Blue = Smooth; White = Texture Paint

Back and ready for action

So as the title says, I'm back! "From where?" you may ask;
I had had finals and afterward was taking a quick brake/vacation for the summer, but I assure you I'm ready to get back to work now.

A few new features have been added that still need to be tweaked before I can show them off, namely a couple of render-specific adjustments. All will be revealed shortly...