Game Development

Game Development

Hi there!

I thought I’d just post something that could depict fairly accurately how the development of the game is going so far.

Now, again, I cannot say too much about what the game is, simply because it’s not that finished and is bound to change a whole lot before anyone outside of the development team gets a chance to play it.

I’ve programmed some interesting things that are designed to make the development easier for the part of the team that does not know how to code, I’m talking about editors and such. However, since most of these editors are quick “slap-together”s that are designed to do nothing else but the essentials, I cannot say anything good about them. They’re there, they do what they are supposed to, but are coded very badly and run poorly. This is simply because I cannot take the portion of time that I could use coding the game, to code these editors that a few people in the world will everΒ  see.

Whatever, I’ll go through them anyway.

The first tool I programmed was the level editor or “World Builder” and this is probably the ugliest thing that I’ve ever coded. The code handles a few classes, the ordinary stuff (window creation, GUI), a few global variables and a code loop.

Works fairly well though. I implemented a quick way of having a non-coder person add new models for the editor to use, since it can’t read them automatically. And it has a quick (not quick as in speed, quick as in implementation) Save/Load system that saves and loads data from a text-file.

I’m hoping to soon use binary files for levels and such because text has some very big and obvious flaws. But this is one of those things that get implemented fairly late, simply because text-files are easier for a human to read and therefore debug should anything bad happen. πŸ˜‰

The second tool I made (and am still making) is the Item Editor. The name is pretty self explanatory but just in case- think of items as RPG items: potion, sword and armor, not desk items such as: stapler, three hole punch or coffee mug.

Great, we’ve come so far. Anyway- The editor is programmed using the drag & drop window editor in Visual C++ so therefore It’s… Pretty bad. The code’s a real assault on the eyes.

But again, like the level editor it does what it’s supposed to so therefore there’s no need for complaints (until they crash, ha ha).

The game itself can currently read the levels saved in the level editor accurately and without any problems. The loaded level is complete with collision and other effects.

A quick run-down on what the editor does, shows that there really is no reason for the editor to be more complex:

First there is a common class for all the things a user can load into the editor, the editor doesn’t care about the object itself and treats every object the same.

The editor however is able to store an identifier, in my case a number ID for every object.

When the objects are “saved” the data in the class is printed out into a text-file. It prints numbers and strings for things like, Position XYZ, Rotation XYZ, Scale, ID, Texture and Mesh, resulting in a block of data in said text-file. It then iterates through all the objects placed and does the same thing.

The game reads this text-file and recreates the ID number that was previously stored for the object. With that ID number the game can create a specific object at the same Position XYZ, bla, bla exactly like it was in the editor! πŸ˜€

The item editor does the same, but the game isn’t in the stage yet where items matter.

I am planning on creating a NPC editor for all the friends and foes of the game that would work pretty much like the other two.

*Sigh* This right here is the negative side of being a programmer. You ramble on about things that matter to you knowing that they probably or definitely don’t matter to anyone else!

I said in the last post that I would post a video of the level editor but that will have to wait a little longer. I realized after making the video that the editor had changed a lot and therefore I am remaking it. I’ll also post more screenshots from the game to show what the graphics probably will look like when the first demo is finished.

Bye! πŸ™‚

Game Graphics


I thought that I’d show off some of the graphics that I’ve worked with combined into a scenario that might exist in a game. In other words, how my game could look at a later date.

The things you can see in the screenshot below are some placeholder props that I’ve made to learn to work better with the whole different textures required to achieve some effects, Colormap, Normalmap, Specularmap etc etc.


Never mind the man standing in front of the door there, he is sort of a size icon for the scenery props. Everything should be scaled according to the size of a human. πŸ˜‰

Whatever. I’ll post another post soon regarding the level editor I am assembling for the game project that I am working on right now.


Normalmapping Update

Hey there.

Yes, yes- It’s still about normalmapping, but I thought that I’d post another add on I put in the shader and point out this enormous flaw and what it does (for people who don’t know what all this is about).

Anyway, I coded my normalmapping that I showed off here a few days ago but shortly after that I realized my crucial mistake.

I had no coded light attenuation. (Light attenuation is how light diminishes with distance… Or something, look it up if you really want to know.)

And without the light attenuation the shader was pretty much useless to use in an actual game. So, painful as it was I was forced to crack open my shadercode again and read up on a solution.

It didn’t take long before I’d worked myself silly over this issue because I just didn’t see anything that made the problems appear, the problem being that the attenuation I’d coded caused this weird haloing effect on the models.

I took a break and came back later with a fresh mind. That break obviously meant a lot for my brain because I fixed it a short while later.

(I also noticed by this time that the attenuation the shader was calculating was per vertex, not per pixel like I wanted, so I just went ahead and fixed that too.)

Here’s the result.


Per pixel light attenuation in all its glory! πŸ˜€

And I also implemented the support for a luminosity map or glow map that can be used to make certain parts of a model self-illuminate.

I will also probably try to implement a fifth texture map that can be used to determine how light “rolls” off the surface so I can fake the light-scattering that happens in human skin and a plethora of other materials.

Well, anyway, that’s what I wanted to show. πŸ˜‰

Bye! πŸ™‚


Hi there! πŸ˜€

As I mentioned in my previous post I’m taking a break from developing my engine to program some actual games, since it was a while ago I did that.

This time I began working with the Ogre3D engine, and so far I am loving it. There were some issues that I was told were really bad in some previous Ogre3D versions but now I can see that they have ironed out those issues nice and clean, so there is nothing standing in the way of me using the engine… So I started using it. πŸ™‚

I am also a user of the Irrlicht engine, which I have continuously heard be pitted against each other in the persistent battle of which one of them is the better engine.

In my opinion and probably what seems logical they are both good engines, at different things however. Both have their pros and cons.

Well, anyhow. I began working on a game and for that I decided to code some rather current generation graphics, because that is one of the good things about Ogre3D, shaders are really easy to use. πŸ˜€

I took some pictures of my struggle to implement normalmapping into my game engine and I thought I’d line them up here from beginning to end.

(Note* Also, the screenshots are all a little displaced because I moved the model around when taking the screenshots)

This is the absolute first image, I have normalmapping working with ONE lightsource, not very good so I decided to implement more of them:


Here’s my first decent into madness, my multiple lights crashed and made a horrible mess of the model:


As if the previous step didn’t tick me off enough this happened:


I was losing it when I managed to make this happen. The lights work but there is a weird purple ambient light on it:


Then finally I got it working. The purple ambient light is gone and it’s looking pretty bad ass:


And for fun, here’s a screenshot that uses three lights, a light blue, a green and a white light:


So there it is, a fully working normalmapping shader with multiple lights! πŸ˜€

The model is a temporary model I made to test out some animations in Ogre3D… And conveniently enough it’s an Ogre.

That’s about everything for now. I’ll post again if I come across something cool. πŸ˜‰

Good bye.

Takin’ a break… I think?


Just thought I’d add here that I am taking a break from writing my engine to seek knowledge elsewhere for a while and to work on an actual game which I haven’t done in a while.Β  I’ll also be working more on stuff in 3D and posting those up here.

Basically I’m taking a break from the thing I love to do, to do something else I love to do, weird isn’t it? πŸ˜‰

Anyhow,Β  I’m going to sleep. Bye.

3D Concept/Mood Art


I’ve made a little picture for fun because I recently decided to really begin experimenting with Blender to see exactly how much I have not yet known about it. And to no secret at all, there are a lot of things I never even knew existed in that wonderful piece of software.

I recently began understanding some of the awesome features that can be used. Like noise algorithms for example.

The image I am posting here has a very high usage of noise functions in order to make things that I can possibly never do by hand.

Have a look.


(The image is enormous, click on it for full size)

The terrain is made using only a bunch noise algorithms and a handful of blended textures with normalmapping. And NO, the image is not perfect, I can see a few “inaccuracies” but I’m hoping you wont. πŸ˜‰

Pretty effective, isn’t it?

There are, however, software out there that can make images like this one in mere minutes. (see Terragen) And those software use similar methods for creating the terrains (Terragen classic at least): noise algorithm with textures, it’s all that simple.

And as the post title suggests, this is in fact a piece of concept/mood art for a 3d game I am making now, more information on that if I ever get it past alpha stages. I am currently writing story and lore for the game/game world. And since I really do want to make this game (and make it playable) I wont give a <censored> about the graphics. The game is supposed to be fun to play, not to look at… Or whatever.

That’s about everything for now.

Engine Update 5


I’ve finally managed to somewhat free myself from the motivation gap I suffered earlier because I couldn’t find a suitable model format for my engine. So I decided a while back to write my own, and so far It’s going great.

I have a working model exporter (no importer yet, have not found use for one) that is able to export an entire model with textures into my custom format.

The format I created is inspired from the Doom 3 md5 format and is stored in a similar fashion.

The format right now isn’t in binary format because of simplicity reasons. And it can do pretty much the exact same as the .OBJ model loader I wrote about earlier. Which is a good thing because that was initially what I wanted to have. But the key lies in that I will be able to extend my own format into supporting animation and bone joints.

Here’s a model in my own format rendered in my engine.


(The face looks a bit messed up but that’s not my exporters fault, Meh.)

So the next thing anyhow would be to export Blender bone joints and all their relations to the vertices, so that I can do stuff like animating the legs as if they were running and doing something completely different with the upper body!

I am currently deciding upon if I should store the animations in a separate file (like the Doom3 md5 format). Or if I should just go ahead and store the bone information and animation frames in the same file as the mesh.

The upside of having the animations in a separate file is that I can animate a model using the same animation regardless of the model itself, as long as the model stores the right kind of information.

The downside is that I’d have to have two exporters and a tool for examining the animations before binding the mesh to them in the engine.

The upside of having the animations and mesh in the same file is that it is simpler to examine and find out if anything is awry.

The downside is that I cannot reuse the animations for different meshes. (which really isn’t that big of a deal since I have worked that way in other engines.)

As you can clearly see, they are almost perfect opposites of each other these choices I’m contemplating about.

Although I do think that in the long run, the separated mesh and animation would pay off.

I’ll get back to studying the exporting of animation now. I’ll post back if I make something cool to share, like I always do.

Have a good one, bye bye.