Except for the first article, most of this blog has been about gameplay, the game in itself from a player point of view, and content. But technical updates have been rather rare.
I (@fasterthanlime) have had my fun with the interview format, even bringing innocent outsiders in for comedy factor, but perhaps it is time to come back to a more classical format for this week.
The big picture
I’d like to talk a bit about the stack behind Jaakan: how we go about integrating a new functionality in the game that requires new native code.
When I think of the game’s stack, I see this in my head, mostly:
I put game assets in there too, because, honestly, what’s the difference between a song sheet, a level file, a story file, and character script? None! They’re all part of what makes the game what it is, how it behaves, looks, and feels.
So, any day where I only have to edit one of the green areas, e.g. integrate a new animation @bigsylvain just drew, is a walk in the park: I copy a file, maybe add a line or two of typescript, and I’m done.
Now, “compile once, run anywhere” is not a new thing by any stretch of the imagination, so don’t go thinking I’m bragging or anything, I’m just explaining how we work :)
If we have to modify the yellow parts however, then we need to make a new executable. ooc code is compiled to C code, then via gcc or clang, it’s compiled to native code, so you have to update the actual binary file and maybe some libraries.
Confused yet? Let’s try another way to visualize it:
Adding HTTP support
Now that you have a comprehensive understanding of the intricacies of Jaakan’s technical stack, let’s try and change it up a bit. Last week we added a brand new sound engine, this week we’ll try to add some http server functionality.
The first thing we’re going to need is an HTTP library. We could write one in ooc, but I don’t have that kind of free time, so let’s use an existing one. For The Stanley Enigma, I’ve used libmongoose, which is very easy to use but unfortunately it’s GPLv2-licensed so, no go for a commercial indie game (and honestly I don’t have time to contact them and get a quote)
Instead, let’s turn our attention to [libmicrohttpd] which, although it seems to live under the GNU umbrella, is licensed under the LGPL2, which allows us to use it in a commercial project without disclosing our source code, as long as it’s dynamically linked.
The thing with libmicrohttpd, as with most GNU things, is that it seems a tad complicated at first taste. Then again, it’s C, what do you expect, Sinatra?
Here’s how a basic example looks:
The first thing we need to do is write a set of ooc bindings for this library, so we can use from ooc code. Why do we need to write bindings? Because the ooc compiler has its own type system, type checking and so on, it allows us to handle some things as if they were object, which can make for more readable code sometimes. Let’s just go through the motions.
After downloading libmicrohttpd, building and installing it with the traditional:
make install -j4
We can take a look at the header file:
Looks like some sort of flags needed for initializing a server. We can cover that easily enough in ooc with:
Then we look up some functions used in the tutorial:
And we can wrap them as if they were an object:
The result of this binding work is available on Github at fasterthanlime/ooc-microhttpd, if you’re curious
And finally, our microhttpd tutorial, the very same, looks like that in ooc:
Higher and higher
So we need to buy a higher-level interface to libmicrohttpd. Let’s call it gonzales.
Here’s a first shot at it:
And then we can write a simple sample in ooc like so:
And that’s about it!
Until next time, take care.