This blog has moved

This blog has moved to http://blog.noctua-software.com I finally decided to host my blog on my own machine. Please update your bookmark ;)

Object Oriented in C

I decided to write this post because a few people were surprised when I told them I make video games in C (and not in C++). What I am told is that since a video game usually requires an object oriented design, using C++ is more suitable to the task. I disagree with this common opinion: writing object oriented code in C is not only possible but, I might even argue, easier than in C++.

Before I enter into the matter, I need to say that I am not against C++. It does indeed have a few interesting features that C does not have. I decide not use C++ in my games because, from my experience, the risk of messing up the code with no way to go back once you realized it outweigh the relatively small convenience you get from it. Yet, some people manage to use C++ in a successful way, and I think that is usually because they enforce strict guideline about what features can be used.

So let's go back to video games. Usually the basic design of a game is to have a common class for all the game objects and then for each type of object (player, enemies, doors, decor, etc.) we create a sub-class. Each sub class reimplements a few methods like "iter", "render". We maintain a list of all the game objects and the engine is responsible for looping over them and calling "iter" and "render".

Of course at first glance C++ seems to be the perfect choice to implement this kind of design. We could have something like:

class Object {
public:
    virtual void iter(float dt);
    virtual void render();
private:
    Vec pos;
    // ...
};

class Player : public Object {
// ....
};

class EnemyA : public Object {
// ....
};

Then we could implement Player::iter to update the player position when we press a key, and EnemyA::iter to move the enemy the way we want it.

(Note that in practice it is not efficient to have such a "render" method, because the nature of modern GPU makes it better to batch the rendering of all the entities of a game, but this is not really important for my argument).

In C, there are several ways of implementing the same design, all making use of function pointers.

Since C++ user are rarely exposed to function pointer, lets quickly remind the somehow awkward syntax to define them:

static void my_func(int x) {printf("hello %d\n", x);}

// Here the variable func_ptr is pointing the the function my_func.
void (*func_ptr)(int x) = my_func;

So here is how we could do Object oriented in C: Each base object we create keep pointers to all the implementations of its methods, we then need to create a special constructor function for each type of objects, equivalent to the C++ constructor:

struct Object {
    void (*iter)(struct Object *this, float dt);
    void (*render)(struct Object *this);
    Vec pos;
};

static void player_iter(struct Object *this, float dt) { ... }
static voif player_render(struct Object *this) { ... }

Object *create_player()
{
    struct Object *ret = calloc(1, sizeof(*ret));
    ret->iter = player_iter;
    ret->render = player_render;
    return ret;
}

Calling a method of an object is simple, we just need to remember to pass the "this" argument as first parameter, since C won't do it for you.

Object *object = create_player();
object->iter(object, dt);

Of course we are wasting a lot of memory by storing those function pointer for each object. If this is an issue, we can use instead a single pointer to a "v-table" struct that we share among objects of the same type. But for the sake of simplicity I prefer to skip this for the moment. Also this structure offers the interesting possibility to dynamically change the methods of an active object. This can be used in game to simulate state changes. Let say your enemy has two possible states: patrolling, and attacking. If we were to use C++ it would be complicated to implement this using the language classes features. Here we could simply change the "iter" pointer of the object at any time during the game to make it behave differently:

void enemy_patrolling(Object *this, float dt)
{
    ...
    if (player_in_sight)
        this->iter = enemy_attacking;
}

void enemy_attacking(Object *this, float dt)
{
    ...
    if (end_attack)
        this->iter = enemy_patrolling;
}

Object *create_enemy()
{
    struct Object *ret = calloc(1, sizeof(*ret));
    ret->iter = enemy_patrolling; // Initial state.
    ...
    return ret;
}

One point I didn't cover is how to create specific attribute to the sub classes. I will talk about this in a next post.

Voxel Invaders ported to javascript using emscripten

We just released a javascript version of our game voxel invaders that can run on any browser with webgl support.

Turns out the port was pretty easy, and I didn't have to write a single line of javascript.

So how did we do it? Since our game was written entirely in C, we used emscripten to compile our source code directly to JavaScript. For those who don't know, emscripten is an LLVM backend that generates JavaScript code, so if a project is written in a language that can be compiled by clang, then it is in theory possible to make it run on a browser.

Of course there are a few restrictions, and in our cases we had to make some changes to the code before we could have it running properly on a browser:

• Emscripten has no support for client side arrays in OpenGL. Even though it has a pretty good support for OpenGL ES2 via webgl, using client side arrays is not supported. This is not really a problem: we just used array buffer everywhere we had client side arrays.

• Some standard C functions are missing. The one that really hit me was strsep that we used in the levels parsing code. In that case I just modified the code to use strtok_r instead. As a bonus, it turns out the code using strtok_r was actually cleaner than the original one.

• Sound. When doing a portable game, sound is probably the most complicated part. For the graphics, using Opengl ES2 pretty much works on every possible platforms, but for the sounds, there is still no clear standard library that can be used everywhere. So, as we already had an openAL and an OpenSL ES backends for the desktop and android versions, we created an other sound backend using SDL_mixer for the javascript version. [By the way, I always find it funny that OpenSL ES -that has been done by the same company behind OpenGL- is such a complicated mess compared to OpenAL].

All in all, it wasn't that hard to port the game to JavaScript. The performances are probably not as good as it would have been if we had rewritten the game manually in javascript, but the amount of work done was negligible.

Video Game in C: using X macros to define game data

As my brother and I recently released our last video game voxel invaders on android and symbian, I though I would share some of the technical details about it. For my the first post I will talk about a quite useful, although rarely used, C trick known as "X macros", and how we can use it to simplify game code.

The code is written in plain C, and the original design was very simple: all the elements of the game are stored in a structure (called obj_t in the code) that looks like that:

struct obj_t { 
    int type;
    float pos[3];
    float speed[3];
    sprite_t *sprite;
    // A lot of other attributes follow...
};

The important attribute of the structure is the first one: int type. This value allows us to differentiate all the kinds of objects in the game (in C++ I would have probably used subclassing instead). We can see it as a pointer to the object class, except that it is not a real pointer but an index on an array of a structure obj_info_t that contains all the information about a type of object (the game equivalent of a C++ class).

file objects.h:

struct obj_info_t {
   const char *sprite_file;
   float initial_speed[3];
   void (*on_hit)();
   // Lot of other attributes...
};

enum {
   PLAYER,
   ENEMY_A,
   ENEMY_B,
   // And so on...
   OBJ_COUNT
};

file objects.c:

obj_info_t obj_infos[] = {
    // PLAYER
    {
        "data/img1.png",  // sprite_file
        {0, 1, 0},        // initial speed
        NULL             // on hit
    },
    // ENEMY_A
    {
        "data/img2.png",  // sprite_file
        {1, 2, 2},        // initial speed
        enemy_a_on_hit    // on hit
    },
    // And so on..
};

By the way, this kind of design was mostly inspired by the code of the original doom game by John Carmack.

The first improvement we can do is to realize that since we are using C98, we can make the array declaration look better using designated initializers:

file objects.c:

obj_info_t obj_infos[] = {
    [PLAYER] = {
        .sprite_file = "data/img1.png",
        .initial_speed = {0, 1, 0},
    },
    [ENEMY_A] = {
        .sprite_file = "data/img2.png",
        .initial_speed = {1, 2, 2},
        .on_hit = enemy_a_on_hit,
    },
    // And so on.
};

See how the code already looks nice and simple. Although this is how our code looked like for a while, at some point we started to get annoyed by a problem with this pattern. The problem is that every time we define a new enemy, we need to modify too files: the file containing the object types enum, and the file containing the object infos array. Beside, since there is no way to separate the array or the enum into several files, those two files got bigger and bigger. This might not seem too bad, but really it is, specially when you have to find the definition of a given object in the thousand of lines of code containing the obj_infos array.

As I mentioned, the original doom engine also used this kind of pattern, and I think the way they overcame this problem was to use a special tool that would automatically generate the C code for both the enum and the array.

In our case I though writing a C generator tool would be overkill. That is where I realized that there is a simple way to have the C preprocessor generates those two parts (enum and global array) for us. Later when I searched for occurrences of this pattern online I found out this is known as "X macros", there is a very comprehensive article about it from Randy Meyers.

The idea behind C macros is to use a C preprocessor macro that, depending on the context, will expand to either the enum part, either the array initializer part.

In our simple case, it would be something like this:

file object_defs.h:

OBJ(PLAYER,
    .sprite_file = "data/img1.png",
    .initial_speed = {0, 1, -},
)

OBJ(ENEMY_A,
    .sprite_file = "data/img2/png",
    .initial_speed = {1, 2, 2},
    .on_hit = enemy_a_on_hit,
)

file object.h:

#define OBJ(name, ...) name,

enum {
    #include "object_defs.h"
}

file objects.c:

#define OBJ(name, ...) [name] = {__VA_ARGS__},

obj_info_t obj_infos[] = {
    #include "object_defs.h"
}

And so, thanks to this trick, we just need to modify the objects_def.h file to add or remove an object type. Both our enum and our global array will be automatically updated by the preprocessor at compile time. As a bonus, this makes it easy to split the object definitions into several files. For that we just need to #include all the needed files instead of just object_defs.h.

Voxel Invaders : space invader + 3d voxels

This week we (noctua software) released our new video game for android phone: voxel invaders.
This is the sequel of our previous game Retrocosmos, and it follows the same principle (making a fun space invader game for touch screen devices).  Only this time we used 3d voxels (the equivalent of pixels in 3d) for all the graphics.

Voxels based games are starting to appear more and more and are particularly interesting for independent developers because it is much easier to generate a voxel model than a traditional 3d model.

Anyway back to the game:  this has been written almost entirely in C using android ndk, with just a few java code for some of the stuffs the ndk does not allow to do easily (like controlling the device vibrator). I wrote the engine from scratch, using opengl es 2 for the rendering, and some interesting C hacks using macro for the enemies behaviour state machines (maybe I'll do an other post on that an other time).  The good thing about that is that if the game is a success it will be quite easy to port it to other platforms like iOS or symbian.

From a marketing point of view, we did two versions of the game: a free demo and a full paid version.  We have little experience of this kind of approach so I might do a follow up an other time about how much money we made from that.

Here is a video of the gameplay:

Ascii art Tetris game

I was bored so I wrote this little online tetris game in ascii art.

I hope someone will have fun playing it.

Voxpaint, an opensource 3d voxels painter

This is the first release of a small 3D voxels painter I had been working on recently.

For the moment it cannot do much, but I am planning to use to create some video game graphics.

The code is hosted on launchpad: https://launchpad.net/voxpaint

Check out the videos: