Font Generation Tool

July 29, 2009

As I couldn’t find an existing tool which met my requirements, I’ve written by own utility to generate a bitmap font from a true-type font, which is quite useful for when you want to use a font in a game but don’t want to buy the full distribution rights to it…

It can be downloaded here (source code included):
PixieFGT_1_0.zip

And the syntax is:
PixieFGT fontname size [spacing] [-antialias] [-texture]

The optional parameter spacing gives you that many empty pixels around each character, so there’s room to add things like dropshadow or glow in your image editing software.

The optional flag -texture will give you the characters arranged on a bitmap of power-of-two size, and if the flag is not specified, they will be placed on one long horizontal strip instead (which is what I most often use for fonts in Pixie, as it makes it easier to apply gradients to the font in photoshop).

If you specify -antialias, the font will be generated at 16 times the requested size, and then downsampled, for high quality antialias.

Here’s an example of how a generated font bitmap might look:

PixieFGT_example

And along with it you also get an XML file which specifies which character can be found in which area of the bitmap.

The XML file also contains kerning information, which you could make use of if you want. What it basically tells you is that if a character with the ascii value matching the "first"-value was rendered, followed immediately by one matching the "second"-value, the second character should be moved horizontally by the specified amount, so that, for example, "A" and "V" are placed closer together than "A" and "L"…

The source code is public domain as usual.

Using Strings as IDs

June 26, 2009

Sometimes, it’s nice to be able to identify things by name, rather than using a number or an enum. The problem is, that if you’re not careful, using strings can take a lot of memory, and LOADS of CPU-power, with all the stricmp’s. When I was hired for the Tycoon City project, and assigned the task of speeding up the game (which was *really* slow at that point), it turned out they were using several hundred megabytes for storing strings (of which most were used as ID:s, and was mostly duplicates of duplicates), and that string comparisons and string copying was right at the top of the profiling results. I won’t go into how we went about solving that particular problem – it was late in the project, and things turned out the way they turned out – but it got significantly faster and smaller, that’s for sure.

Ever since then, I’m always a bit wary about using strings – it can easily get out of hand, and it feels wrong to waste both memory and CPU-power on something if you don’t have to. So, I thought I’d share my own system for solving this problem, extracted from my (recently cleaned up) Pixie Game Engine. It’s a solid, fast solution, ready to just drop into any project, and consists of only two classes. At its core is a class I call StringId, which is easily created by:

StringId myStringIdVariable("myOwnIdNameHere");

Which internally results in the string "myOwnIdNameHere" being located in a global string table (non-case-sensitive), or inserted if it’s not already added. The lookup is done through a pretty fast hash-table. In the StringId object is stored a pointer to the shared string, so you can do:

if (myStringIdVariable==anotherStringIdVariable)

and know that it will result, internally, in just a comparison of two pointers. Nice and fast. And takes less memory too, as a string is only stored in one place – the global string table. There’s also a couple of macros defined (they’re nifty at times), strSwitch and strCase, which can be used to compare StringId’s in a way similar to switch-case statements:

strSwitch (myFruitTypeStringId)
    {
    strCase(Apples)
        {
        // code to do stuff here
        }
 
    strCase(Oranges)
        {
        // code to do other stuff here
        }
    }

Which is the same as doing this, but looks a bit nicer (though that is, of course, a matter of taste :D )

static StringId applesId("Apples");
if (myFruitTypeStringId==applesId)
    {
    // code to do stuff here
    }
 
static StringId orangesId("Oranges");
if (myFruitTypeStringId==orangesId)
    {
    // code to do other stuff here
    }

The code is well-written and well-commented, and can be downloaded here. It is C++, and as usual it’s public domain – use it anyway you like :D

Escape from the Dungeon

May 16, 2009

Here’s a little game I’ve been working on for a while, on and off.

eftd_title

It’s called "Escape from the Dungeon", and the back story is this: three adventurers (a man, a woman and a dwarf) have been split up while exploring a dungeon, and the player controls all three (can switch at any time he like).

eftd_players

The three characters start at different positions in the dungeon, and you simply need to bring the three together and hit the nearest exit.

eftd_screenshot

Initially, I started this because I just wanted to playaround with generating random dungeons, and after I had done the room generation, I sort of got stuck and didn’t know what to do with it, and only recently got moving with it again.

eftd_rooms

There’s going to be monsters too, like this:

eftd_monsters

There’s an early demo of the game here:

Escape from the Dungeon – Demo

The controls are cursor keys to move, TAB to bring up the map. 1,2,3 to change character (or click their portrait)

The characters start some distance away, and sometimes it’s a bit tricky to find a way to bring them together. There’s no monsters yet, and there’s not even an exit for you to find, but it’ll all get added in due time.

eftd_screenshot2

So, I would very much appreciate any feedback/thoughts on this. Don’t hesitate to point out things that don’t look right or which you just don’t like – anything that can help me improve things :-)

Parachute – A Game&Watch Tribute

February 18, 2009

Do you remember the old Game & Watch games? The little handheld one-game toys with simple and fun games? There was one called Parachute, which was one of my favourites.

Sometimes it’s fun to throw something quick and easy together, so I did a simple remake for Windows:

parachute

You can download it here:

Download Parachute here

And as usual, the source code for the game is public domain, and available here:

Download parachute source code

The original game looked like this:

parachutegw

And I’ve tried to stay faithful to the original, at least the way I remember it… but it was so long ago :P

Btw, thanks to my old friend Per Ekengren for the music, which he made years and years ago…

100 Faces

February 6, 2009

Over the last week, I’ve been taking a long hard look at all the projects I’m working on. Turns out that it’s just over 50 different things I’m working on, and that’s too much even for a student with no pressure to finish anything :P So I’ve stoved away the majority of them for later, and I’m now focusing on a total of 5 projects, which is much more reasonable…

I’m sure I will be telling you more about the individual projects later on, but for now I thought I’d show what I’ve been up to for the last couple of days:

siu_facegen_large 

One of the games I’m working on requires lots of portrait pictures of people of all types and ages. As the recent versions of Poser have scripting abilities, I’ve composed a script which will generate and render lots of different characters automatically. The image above shows the first proper batch of 100, and while not perfect, they’re pretty good enough for the effort involved in making them: One single click of a button, and out pops a hundred faces :D Next up is to do the same for female characters.

This is fun stuff to mess about with :-)

3D Engine – Animation Basics

January 4, 2009

I guess by now, some of you are getting a bit impatient to see some actual code put together for this, and it is almost time to get down with the practical side of things, but before we do, there’s ome more thing we need to look into: animation. So far, we’ve got models and lights which can be moved around, and in a way that’s all we need for making simple animations through code. However, we have no means of animating characters within a 3D modelling package and have them played back in the engine. This is where morphs and skinning comes into play.

renderer_morphs

Morphs is a quite straightforward concept: you take a mesh, move its vertices around in the modelling package (without removing or adding any vertices), deforming it into the desired shape. You then compare the new mesh with the original one, and for each vertex you calculate a delta value, which is the difference between the old and the new vertex positions. In the engine, you can apply the morph by adding each delta to its vertex, to deform the mesh on the fly. By scaling each delta as it is applied, you can smoothly transition from the original mesh to the deformed shape.

This technique is especially useful for animating character expressions, as pictured above. We could do other animations this way too, like maybe the walk cycle of the character, by saving each keyframe of the animation as a set of morph deltas. However, morph deltas require a lot of memory – we’re basically duplicating the mesh for each keyframe of animation, and there’s no way to reuse animations between different characters.

renderer_skinning

That’s why we’ll use skinning. The concept of skinning is a bit more complex than morphs, but the advantages makes them worth it in a lot of cases. Basically, what we do is build a "skeleton" (a series of connected bones) for the model (the black lines forming long triangular shapes in the arm at the top of the image above). Once we’ve created the skeleton, we bind all the vertices of the model to different bones. Most vertices are only bound to one bone, but some vertices, near the joints, are connected to more than one bones, and usually we use different weighting values for how much influence each of the bones have on the vertex. This might sound a bit complicated, but it’s all set up in the modelling package, and it’s actually quite straightforward. The important bit for us right now, is that when using skinning, we get a hierarchy of bones, information about which vertices are bound to which bone,  and weighting values for those vertices that are bound to multiple bones.

When we have this information, we can easily animate the hierarchy of bones, the skeleton, by simply rotating bones relative to their parent bones. In the above image, you can see an example of bending the arm at the elbow, by simply rotating the forearm bone. as you can see, we get a smooth deformation of the elbow, as those vertices are bound to both adjacent bones. Animation data for the hierarchy of bones is tiny – simply a rotational value for each bone, making it quite memory-efficient to store a lot of animations, at the cost of calculating the vertex positions in the engine. Using morphs on the other hand, takes a lot of memory, but is faster to apply.

In my indie engine, I’ll support both morphs and skinning, as I believe they are both very useful concepts, as well as quite simple to implement. As with all the other components of the engine, I’ll make a clear distinction between instances and definitions, and next time I will go into more detail about how morphs and skinned animations will be implemented in my engine.

Fighting Game – Oldshool Style

December 30, 2008

As I’ve talked about before, I’m a big fan of oldshool fighting games, like Way of the Exploding Fist or International Karate. I’ve always wanted to make a fighting game, and so I’ve now added one to my ever growing portfolio of "current projects".

wotif1

I’ve spent a bit of time playing around with some oriental/martial arts related models, and done a couple of quick renders to test things out, and I thought I’d post them here, and maybe get some feedback.

wotif2

The game itself will be a classic 2D fighting game, where timing and distance will be the key factors for success or failure. There won’t be any combos or frantic button pressing; instead, there will be well-timed, measured punches and kicks, delivered in just the right way to thwart your opponent. There also won’t be lots of characters with special moves – we’ll have exactly two visually distinct fighers with an identical set of moves, just like it should be :-)

Using XML for storing game data

November 24, 2008

When making games, you find yourself dealing with lots of data of different sorts, everything from the movement speed and jump height of the player to the level layouts or game art, and it can sometimes be of great importance how you deal with it. Some things (especially the smaller, simpler things), you might as well just store in the code itself, while other things might be better to store in external files. This entry will be about storing game data, and more specifically about using XML files for storage.

In the various online forums and messageboards about game development, the question about how to store game data pops up from time to time. Usually, some people will reply to this by recommending their favourite data format (be it scripts, like LUA, or data formats like INI-files or XML) and then keep defending their choice, touting it as the best in any given situation. These are people with enough experience to feel confident, but not nearly enough experience to be worth listening to. Give them a few years and a couple of large projects, and they’ll see the error of their ways :-)

The fact is, that how you store data depends on your game, the data in question and (yes) your personal preferences.

Don’t think that you’ll be using the same format for all the data in a game, or that you will use the same formats for every game you make. Attempting to do so will result in a lot of wasted time, that could have been better spent.

If the data is large (like bitmaps, 3d models etc), you must use custom, binary formats. There’s no other way to get maximum load speed, and there’s no reason to make your players wait for your game to complete a bunch of text-parsing during loading (and yes, even for small games, text-based formats make a significant impact on load times, even on fast computers). If you need the data to control flow or check conditions, you need a scripting language of some sort. But it’s usually not a good idea to use an out-of-the box scripting language – you need a simpler, custom solution which will let you express your game scripts in the most simple way possible, to make them easier to write/

Sometimes you need to store small amounts of data which you need to be fairly easy to edit by hand, or you need an intermediate format for larger amounts of data (which will be converted to a custom binary format before release, like my 3d model file format), and XML is a good choice for this (in many cases). Note though, that it’s not the only one – always evaluate your options and make the choice that you feel comfortable with.

When making games using my own free, public domain game engine, I use XML for some things from time to time, and if used right, it’s a really nice way of storing data. I won’t go into too much detail about the XML format itself – there’s plenty of online resources describing XML basics. There’s one thing I think I should mention though:

There’s two different ways of reading and working with XML files. two different classes of parsers: DOM (Document Object Model) and SAX (Simple API for XML).

With DOM, the game programmer tells the XML parser to read and parse an XML file. The parser will go through the file, and create a hierarchical datastructure in memory, mirroring the content of the XML file. The game programmer will then add code to parse this datastructure, pulling out strings from it and use this to create his own in-game structures.

With SAX, the game programmer also tells the XML parser to read and parse an XML file. The parser will go through the file, and for each element or attribute it encounters, it will call a function implemented by the game programmer, passing along the data. The game programmer can do pretty much what he wants in this function, and will use this to create his own in-game structures.

Though they appear quite similar, there’s a couple of significant differences between the SAX and DOM parsing philosophies. With DOM, there’s a lot of small memory allocations going on, as it will have to allocate string buffers and hierarchy nodes as it goes along. Memory allocations is very slow, and you definitely don’t want a lot of them going on during load time, if you can avoid it. With SAX, on the other hand, there won’t be much allocations going on, except whatever ones the game programmer makes in the callback functions, to store the in-game data. Also, using DOM, you will have to keep the entire contents of the XML file in memory while extracting the data – with SAX, you only hold bits of it at a time.

DOM parsers have their uses, especially if you need to load a hierarchy, change it, and save it back to file, but for games where you just want to read the data and store it in your own datasets, the obvious choice is a SAX parser.

So what do most games programmers use? Well, being games programmers, they use DOM parsers. Which doesn’t make much sense at all. I think the reason is that there’s a popular DOM parser called TinyXML, which a lot of programmers are recommending on forums and such. Not because it is better than other parsers, but because it is the only one they have used :P (or in some cases, heard that others have used). I think the "Tiny" part of the name appeals to a lot of programmers, and it is true that the source code is quite small, and the feature set is limited. But it’s still a DOM parser, so its memory footprint, number of allocations or general speed won’t be tiny.

A better choice is a little known SAX parser called expat, which is also the one I’m using in my engine. It’s small, easy to use and free to use and distribute in any way.

Using a SAX-based parser is not difficult, and just requires you to register some callback functions with the parser, and keep track of where the data should go. However, as I’m using object-oriented C++ for most things, I’ve built a simple system on top of expat, which allows for even easier loading of XML data, and I will be writing more about this system in a later blog entry.

Character from my new RPG

November 15, 2008

The last couple of weeks (in between studying for my exam :P ) I’ve been working on a new project, a quite hardcore (p&p style heavy number crunching) fantasy RPG. I won’t go into much details about it yet, but it’s progressing rather well, and I’ll keep posting little bits about it here as I go along.

Here’s a little preview, one of the characters from the game:

taw_thief

The game will (as usual) be free, and I’ll make the source code public domain (again, as usual) so that it may (potentially) be of some use to others :-)

Duell – A Card Game For Two

October 29, 2008

So far, I’ve mostly been writing about games I like, and unfortunately, Duell is not one of them.

KF2-22A0

The game is basically a card game, though you have a simple game board as well. The objective of the game is to be the first player to win five rounds, and you win a round by landing your piece on top of your opponents.

When playing the game, you hold five cards in your hand, and on your go, you play a card and move your piece that number of moves backwards or forward. You may not move into your opponents half of the board, and you can’t move backwards and forwards in the same go. If you are able to move on top of your opponent, you win the round, unless your opponent can counter your move by playing a card with the same number.

There’s a few special rules as well, but they don’t do much to make this game more fun. It’s not a really bad game, it’s just that it gets quite boring quite quickly. It feels like it’s a bit too random, and I think that if there had been a stronger element of strategy, it would have been much better.