The Open-Source Game Development Pipeline

Providing the means and education to create games using free/libre open-source tools.

Leave a comment

Blender 2.79 Released

Howdy folks!

Just got back from ORConf, and it went really well! I’ll post the video of my presentation once it’s been released.

In other news, Blender 2.79 just came out! You can view the latest changes and download it at this link.

Cheers! 🙂


Leave a comment

Getting Started with Irrlicht: Let There Be Eerie Light


As an active member of the Irrlicht renderer community, I recently posted an article on how to set this robust, graphical framework up inside of the Eclipse Integrated Development Environment.

You can view my post on the official forums here.

After reading, since you will now have a basic understanding of how to get your development sandbox ready, you can start fiddling with the rendering engine via these tutorials. These are the same lessons that I used to ramp up on my knowledge of Irrlicht.

Let me know if you have any questions!

Cheers! 🙂

Leave a comment

Blender 2.75 Released!

Good morning!

What a pleasant surprise to wake up and find that your favorite 3D modeling/animation tool received a well-deserved update!

You can check out the new version of Blender here.

Happy 3D modeling/animating! 🙂


For those of you who like to compile from source, here’s a good walk-through explaining the process. Don’t let the “Ubuntu” in the URL fool you. This applies to all GNU/Linux distributions utilizing the same compilation tools. 😉

Leave a comment

Update: 9-17-14


Tonight I’m going to discuss interchange formats for a moment.

As of now, I’m currently getting my hands dirty with the Irrlicht-1.8.1 rendering engine. But, unlike its well-known rival (Ogre3D), it doesn’t have its own format for animated meshes. So, what’s a plucky soon-to-be 3D animator to do?

Well, if you take a look at Irrlicht’s supported animated formats here, you’ll see that only a handful are actually useful (or mature enough) for games. So, without further ado, here’s a link to a Blitz3D exporter that you can use for Blender (the open-source 3D animation software I recommend you use as part of the pipeline).

Blitz3D is a binary interchange format which specializes in skinned, bone-based animation. In the last article, I showed you some Blender tutorials regarding a gingerbread man. Given that the model was rigged and animated using bones, you’ll want to use this format to represent it as a 3D game asset.

You can begin to bring the exporter into Blender by going to File > User Preferences, clicking on the “Import-Export” tab on the left-hand side (so you can see what formats are currently installed/enabled), and continue by clicking on “Install from File” at the bottom. From there, you’ll just need to navigate to the zip file, select it, and then click on the “Install from File” button in the upper right. If everything goes well, you should now be presented with the option to export the Blitz3D format. (Don’t forget to check the box to the right of the add-on description so it gets enabled!)

Now that you have this new tool in your arsenal, feel free to start creating lots of animated characters for your game. The sky’s the limit! 🙂

That’s it for now! I’ll continue to keep you posted as I make more progress with my game design efforts.


Leave a comment

The Pipeline: An Overview

Good evening!

So, as you may have already noticed, the title of this Blog is “The Open-Source Game Development Pipeline”. Tonight, in this article, I’m going to talk about the actual pipeline.

There are three major components to creating a game: Audio, Image Assets, and a Game Engine to house and utilize them.

I’ve already mentioned various packages in one of my previous articles, and you’re going to need to learn how to use them if you want to make games!

So, let’s talk about the applications you’ll be using to create a game.


Linux is unique when it comes to sound design. JACK (package name “jackd”) is the standard audio interface for having your audio applications communicate with any internal/external sources. Learning how JACK works (which the “qjackctl” package can assist you with) will give you an advantage if you’re just starting out.

You’ll find (as you continue using Linux) that there are very few audio applications that can “do it all”. Most applications excel specifically at one thing. Take Hydrogen (package name “hydrogen”) for example. Hydrogen is an application that is purpose-built for creating beats using different sets of instruments. As a drum-machine, it can’t be beat (no pun intended), but creating an enticing percussive rhythm is just one part of a musical composition (unless that’s all you’re looking to do, then, hey, kudos!). There’s also melody and harmony, and there are other applications that excel in this department.

There are three applications that I’d specifically recommend for those of you who happen to be passionate musicians. They are: Linux MultiMedia Studio (package name “lmms”), Qtractor (package name “qtractor”), and Ecasound (package name “ecasound”). Both LMMS (I’ll be using the abbreviation for the rest of the article) and Qtractor are DAWs (Digital Audio Workstation), and have an interface built to handle most of the heavy-duty requirements needed by any serious sound designer. LMMS has the added benefit of having a beat-mixer built into it as well, potentially mitigating the need to use Hydrogen. But, since Hydrogen already has so much depth, those who need that much control will use it. Ecasound will cater specifically to musicians who want to rip sound directly from an instrument they’ve plugged into their computer. The application is run from the command-line, but is easy enough to figure out if you use the “-help” command. You should pair your usage of this application with Audacity (package name “audacity”) for any post-processing or editing needs.

Note: Downloading the CALF Plugins (package name “calf-plugins”) will give you some additional LV2 effects/instruments you can use inside of QTractor. This package also interfaces with JACK, for those of you who would like to do direct hardware recording via Ecasound.


So, unless you’re creating a command-line game, you’ll probably want to display some sort of visual content inside of its own window. In that case, you’re going to need tools to help create it.

Blender (package name “blender”) is a 3D modeller and animation tool you can use to create 3D characters/scenes/objects for your game. Paired up with GIMP (package name “gimp”), you can create nice textures to map onto your 3D shapes. If you prefer a more cell-shaded/vector art look, one could always use Inkscape (package name “inkscape”) to achieve those results.


I’ve done my fair share of homework over which tools to use to create my game, and in the end, I’ve chosen to use libraries that are either BSD, MIT, Apache 2.0, or zlib licensed. The reason for this is to make sure I can make money off of my game if I want to, and also not step on anybody’s toes for using their tools. Out of respect for the licenses themselves, I will be including a description of each inside a text file called “LICENSE”, which will be housed in the application’s root directory for users to see.

There are capabilities the engine will need to have in order to effectively deliver various types of game-play experiences. Here’s a list of some that I consider to be the most important (ordered appropriately):

-3D/2D rendering (fast, preferably)

-3D and 2D audio

-Joystick input

-Physics simulation

-Threading interface

-Networking interface

I’m currently looking into using “Irrlicht” for the graphical/input requirements of the game engine. Since Irrlicht has OpenGL and SDL integrated within it, the input interface has already been properly abstracted for you. In other words, using Irrlicht allows you to kill 2 birds with one stone… so why not?

Next on the list, allow me to explain the difference between two-dimensional and three-dimensional audio. Ambient noise, or background music, are examples of sound that occupy a static portion of the soundscape, and typically don’t need any depth added to them (or, in some cases, it’s already been added when the audio files were created). If I were making a game about war, though, and my player character was a soldier traversing a battlefield while under heavy enemy fire, I would need three-dimensional audio to simulate the different positions of gunfire (or fired mortar shells, for instance). This would require an API (Application Programming Interface) which could achieve that effect. Thankfully, there’s already a handy wrapper around OpenAL Soft called “TinyOAL” “cAudio” which I will be using to create 3D audio.

Next on the list is input. As I stated before, SDL handles this for us, so no need to go into detail there. SDL also comes with a cross-platform threading interface built-in, so I won’t have to worry about that either (now we’re up to three birds). Thanks, Irrlicht! I’ll need to do some more homework on whether or not Irrlicht will let you expose the SDL layer it uses for input and see if it also gives you access to threads. Otherwise, we may have to look into using PThreads… >_>

Now that leaves us with Physics simulation and Networking. As far as C++ goes, I’m new to programming with both of these, so I plan on giving Bullet a try and seeing how that plays out. As for networking, there are several high-level wrappers (nested above BSD socket interfaces) that should provide me with an easy way to connect to a remote server. As of now, I’m undecided if this functionality is really necessary for what I’d like to do… so, I’m going to put it on the shelf for the time being.

As stated in the title, this is just an overview. Each of these subjects require much more emphasis in order to be truly helpful.

In spite of that, however, I hope what I’ve written is enough to whet your appetite! If something doesn’t make sense, look it up! Web-searching is your friend. 🙂

That’s it for now! Please reach out if you have any questions or require further guidance. See you next time.