Post a Comment On: Charlie's Second Blog

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.