Packaging guide

Why packaging?

You might code up the very most awesomest game of them all but nopony may be able to play it only because you failed to package it correctly. The problems of packaging are manifold and treacherous. There are many different configurations, programming languages and systems and you are only able to account for a limited number of those. Due to its inherent difficulty, this guide will focus on C++ for now. Other languages are usually much easier to package due to being interpreted as opposed to being compiled (see the example for python packaging).

C++ for Linux

On Linux, we need to try to stay distribution-neutral and thus we cannot make distribution-specific packages like .rpm or .deb. Instead, we'll focus on making self-contained universal packages that are well suited for game jams.

Let's say your game's executable is called coolgame.bin and you used g++ to compile it without any special flags. Now run $ ldd coolgame.bin on that executable and you will see all dynamic libraries you explicitly or implicitly link against. Wow, they are quite many, aren't they? Let's try something, compile your game with $ g++ -static -static-libgcc -static-libstdc++ and run ldd on it again. Quite a lot less dynamies libraries will show up now as you just linked many things statically into the executable which in turn as grown in size.

Moving on, to handle the remaining shared libraries, create a new directory beside your executable and call it "libs". Using ldd's output as a guideline, copy all remaining shared libraries into this directory. They may be quite numerous but don't worry about it. When time matters - as it happens to do in a game jam - we can't be too picky about redundancy.

Lastly, make a little helper script, maybe call it "". It should have something like this:

current_dir="$(dirname $(readlink -f $0))"
LD_LIBRARY_PATH="$current_dir/libs" ./coolgame.bin

Remember to make it all executable. You can now tar this up and it will work all nicely everywhere.

C++ for Windows

We will not be creating a nice installer here but rather a self-contained archive that people can just drop where ever they want and the game will run nonetheless. Make sure all required dlls are in the same place as the executable. If you are using mingw to cross-compile from linux, you should compile using $ g++ -static -static-libgcc -static-libstdc++ so that you will not need to copy as many dlls. If you use Microsoft Visual Studio, you will need to tell others to install the Microsoft C++ runtime before trying to run your game.

Make sure to pack all into a zipfile as Windows users can unpack these without additional software.


Python is a good example for interpreted languages. It is pretty easy to package, as you just need to deploy the source code and the included resources. Other interpreted languages work pretty much the same.

Essentially, you copy your scripts and the resources to a folder, keeping your original directory structure. You can optionally write startup scripts (e.g. AwesomeGame.bat or that execute your main python file, but usually marking the main file as such is sufficient. Users will have to run it from the terminal (Linux) or just double-click (Windows) the file to run your game.

If you include other packages (such as pygame) you should leave a dependency notice somewhere, preferably in a README file (or README.txt if you want Windows users to have it easy :D). Just give them a hint they need to install the package, and maybe leave a download link for convienience.

Finally, pack your folder into a zipfile or something similar (Linux users prefer tarballs) and upload it.

What about other frameworks / languages?

Most frameworks / game creation IDEs have their own file format (e.g. Blender, Löve) or an export routine (e.g. Unity3D). Browse the FAQ of your software for details on deployment, or just google.