Packaging your game

Posted by (twitter: @Sosowski)
December 20th, 2011 10:47 am

Ok, I guess everyone here packaged and submitted the game already, but as I was trying some of them out, I thought that it’s a good thing to post some advice on how to make your game work out of the box, thus getting more views and plays. Consider repackaging the game if some of the below points apply to yours!

How to have your game working out the box:

  • First of all
    • Listen to suggestions, people will surely feedback if the game is not working for some reason! Check comments, come to IRC and ask if the game runs fine.
    • Make a gameplay video and include it in your game links! Even if someone is unable to play, he can give you some ratings (e.g. Graphics and Audio)!
  • Downloadable games
    • Subdirectory – Include a directory with your game files in the downloadable archive, it makes unpackaging way easier!
    • Decrease size – make sure you remove all redundant files form the archive!
    • File name – avoid using file names such as,, etc.
  • Java
  • AS3/Flash/HAXE/Stencyl
    • Include classid parameter when embedding!
    • Add a preloader if your game is over 1MB!
  • Love2D
  • Python
    • Use Py2exe!
    • Keep the source inside too!
  • C#/XNA/Mono
  • JavaScript/HTML5/WebGL
    • Make sure your game works in different browsers! At least Firefox and Chrome!
  • C/C++/Native
    • Make sure you included all the dlls and that these are right version!
    • Add links to redistributables: VS 2005, VS 2008, VS 2010
    • Use static linking if possible!
  • Ruby
    • Use OCRA to package your game into executable!
  • Game maker
  • Linux
    • Use ldd to pick and package correct libraries with your game!
  • Mac users
  • Read DO’s and DON’Ts list by Mathias Zarzecki!
  • “[…] Damn. I spent ages searching for such a place. Ah well. I’ll do it next time.” SUPERBAD!
    • Do it now! That’s what this guide is for!

If you run across anything annoying regarding packaging, or have a piece of valuable advice, write it in the comments, and I will snip it to the list!

38 Responses to “Packaging your game”

  1. shawn42 says:

    Ruby – use ocra to build an exe (Don’t make users get Ruby)

  2. Raptor85 says:

    Cant really argue with the others, but for love2d and python dont forget not all of us are on windows! make the “converted to exe” version seperate and leave the normal version so us Mac & linux guys can still run the game. For people packing the linux executables as well, please run ldd on your game and pick any “odd” libraries you used and include them in your zip (especially if you linked to stuff dependant on version, like libpng)

  3. incobalt says:

    For C++, if people are having problems with dlls for you, see if your library has a static link version. I used Allegro, and compiled against the static-link version of the library, which basically puts all the *required* dlls into the executable for that library. This bloats the individual file size, but gets around “dll hell” if you’re experiencing that. Additionally, it might reduce overall distribution size, as it will only include the parts your executable needs to run (I think anyway. I could be wrong, but it seems like that’s the case).

  4. RHY3756547 says:

    I think asking for feedback is a great way to get more people to go into detail about what parts of your game could be better.

  5. sol_hsa says:

    With visual studio pro and cygwin installed, to figure out which dlls you need, run vsvars32.bat, after which you can do

    dumpbin /imports yourgame.exe | grep dll

  6. Mjiig says:

    2 things occur to me, firstly if you’re on linux and the libraries your using support it, pkg-config is a neater (if less powerful) alternative to ldd, as it’s output is already formatted to be passed straight to gcc.
    Secondly, if the comments ask for some other distribution format, deal with it ASAP.

  7. Danik says:

    What is the classid parameter for when embedding flash? Would you recommend they way described here?

  8. TaintedFork says:

    This is a fantastic write-up. Thanks for sharing!

  9. Bad Sector says:

    Actually using ldd isn’t a very good idea because ldd “walks through” all the libraries recursively and many (if not most) of these are needed by the libraries, not the game itself. Using objdump is a better idea:

    objdump -x | grep NEEDED

    these are the libraries your game *directly* references. If you see some library you specified yourself at build time you may want to include that (although “system” or “widely available” libraries such as SDL, zlib, x11, etc are obviously not needed and can be put in your game’s system requirements).

    • Raptor85 says:

      well, objdump is nice in it does what you say, but if you “only” include libs shown in objdump you’ll end up with missing deps, for instance SDL_image requires the specific version of libpng you compiled it with or you’ll crash out every time you try to load images. If you’re going to pack dependencies in a binary build, pack ALL that you can’t be almost 100% sure the user will have (like it’s a pretty safe bet all users will have libpthread), and your more advanced users will know they can just check versions on them and remove them so the system versions are used. But yes, that should be clarified, dont pack everything ldd shows, only pack non-system libs like SDL, libpng, openal and such. (or to use objdump, you need to scan the deps that the first scan returns also). And unless you’re going to write distro specific files for apt, rpg, deb, portage,etc do not simply say “this game requires x/y/and z to be installed”, or 9/10 users will pass your game up and move onto the next one (not to mention configuration issues, not all copies of the SDL libs for instance have png, tiff, opengl, or pulseaudio support, these are optional and not all distributions enable them by default)

      • Raptor85 says:

        should mention, as a general rule of thumb, only pack libs where the linked version is normally under /usr/lib and not /lib (though there are some exceptions, but these are semi-rare) stuff under /lib is going to be system libraries and 99% of your users will have them, and they won’t vary enough to be an issue from machine to machine.

  10. urth says:

    What about an iOS App?
    What to do with that?

    Only Mac users with XCode with same version the game was made with or newer can run the App.

    • Sos says:

      No idea. I’m hoping for some suggestions!

    • Mjiig says:

      If you consider getting lots of ratings your main priority, can I suggest an iOS game is probably not the best idea for Ludum Dare. If you’re doing it to learn something or just keep your hand in etc. then knock yourself out, but it’s always going to be the least rated category of games I think.

    • RHY3756547 says:

      Maybe ask for UDIDs, and every so often re-build an ad hoc version for everyone who supplied UDIDs? Then you would distribute it over TestFlight. I’m not sure how many people would come back to rate your game after initially requesting inclusion in the provisioning, but it’s worth a shot I guess.

      Option 2 is publish to app store for free, but if you’re going to expand it into a bigger/enhanced/paid game in the future then that probably wouldn’t be the best course of action.

    • Atomic says:

      Generate a jailbroken .ipa, that way everyone with a jailbroken iOS can install it using iTunes. I’ve done it once but haven’t touched xcode in a long long time.

  11. arielsan says:

    If you are using Java you can use Java Web Start and runnable jars too, at least I am using it for my game.

  12. Nice to see that Love2D is included. However, do remember that the Game Distribution page you linked to has instructions for all three operating systems, although I’m not entirely sure whether it works on Linux without a bunch of libraries. Still, it’s definitely a good idea to make the .love file available anyway.

  13. Pixelsheep says:

    Game maker games can go on the web? Damn. I spent ages searching for such a place. Ah well. I’ll do it next time.

  14. Thief says:

    For XNA 4.0 games, set your game to the “Reach” profile if you game will run with it. It runs on far more PCs.

  15. tcstyle says:

    Some advice for packaging a python/pygame game that has sound and especially the default pygame font:

    In the file add:

    def isSystemDLL(pathname):
    if os.path.basename(pathname).lower() in (“msvcp71.dll”, “dwmapi.dll”, “portmidi.dll”, “libogg-0.dll”, “libvorbis-0.dll”, “libvorbisfile-3.dll”, “SDL_mixer.dll”,”SDL_ttf.dll”,”smpeg.dll”, “zlib1.dll”):
    return 0
    return origIsSystemDLL(pathname)
    py2exe.build_exe.isSystemDLL = isSystemD

    That’s probably not totally optimal, but will do the stuff for integrating sound.

    Additionaly for using the pygame.font module with the default font, you should:

    1. specify the font directly as a resource in your game’s folder:
    font = pygame.font.Font(‘freesansbold.ttf’,20)
    2. copy the font from “–/pythonXX/lib/site-packages/pygame” to your dist folder and also all the yet missing .dlls from “–/pythonXX/lib/site-packages/pygame”

    That should do the job. It’s actually a summary of my experience from searching a lot sites for a solution of problems pygame.font and pygame.mixer can cause wirh py2exe.

  16. Mjiig says:

    I just thought of something else to consider – get someone to test it on another computer before the end of the contest – either by dropping into IRC or by using a test machine you own. By another machine I mean one that doesn’t have any libraries that you don’t expect your users to have – hence why your development machine isn’t going to cut it.

  17. Raptor85 says:

    Btw, you mention in the instructions for Mac users to use winebottler to play windows entries, should note that winebottler is just a Mac port of the linux “WINE” project with a GUI added in, so that advice works for linux also. There is a issue though, a lot of the .net stuff, and basicly all of the xna stuff will not run (dotnet3 and xna are known to have major issues to the point of being unusable under both native mono and in wine)

    • Sos says:

      Yeah, I do know that. Linux users have superpowers and don’t need instructions mostly :) I was suggested to suggest WiuneBottler once, and as it’s only emegring adn is not very well known yet, I though it’s a good thing to drop it here. Also, You should get it while it’s beta, it might be paid later!

      • Mjiig says:

        I could well be wrong, but if it’s actually a port of the linux wine, (rather than cedega or something), then it’ll either be free for ever, or a free version will quickly become available when they charge, because wine is GPL’d so wine bottler will have to keep it’s source open.
        Feel free to correct me if I’ve missed something.

        • Sos says:

          Man, Wine is LGPL 😛

        • Raptor85 says:

          If they built of the cedega branch of WINE (basicly really, really old WINE before the licence was changed updated with securerom and directx support) you’d be better off using a pure port of WINE for macos anyways, main branch WINE surpassed cedega in game support like 5 years ago and cedega kept falling further and further behind since then. @Sos LGPL doesnt matter, if you build off the source directly it’s the same as GPL and any project built on it will have to release source (it would be forked and free within minutes). WINE is LGPL so that you can link to the wine libraries without releasing source, this allows for an easy way to port commercial applications to linux (not the BEST or recommended way, but if a program requires a lot of windows functionality you can link against the wine libs to build a native install for linux, basicly an alternative to doing an actual port, and slightly better than just hoping the executable runs under wine.

  18. For OSX ports, if WineBottler isn’t working for you (it was a little finicky on me, and winetricks didn’t work at all), try Wineskin (

  19. Lattyware says:

    Just as a note, Python 3 users, or people using Python 2 or 3 who want to make pre-made builds for OSX and Linux too, check out cx_Freeze – it does what Py2exe does, but works with a lot more stuff.

  20. ericdpitts says:

    I uploaded my game maker game to the Yoyogames sandbox, but I can’t seem to get it to launch in the browser. It appears to need either an activex control or a firefox plugin, but I tried installing those and neither of them work for me.

  21. biaxynte says:

    to find out needed libraries for c/c++ under windows there’s this nifty thing
    to make sure you don’t miss any.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]