The Open-Source Game Development Pipeline

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

The Pipeline: An Overview

Leave a comment

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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s