3
$\begingroup$

I'm wondering if I create a game using the game engine that relies on external libraries, for instance midi device libraries like pyGame.midi, if those can be bundled in the executable created by the game engine? I want to generate midi to external devices from the game engine, but I want to be able to use python modules that use ctypes etc to connect to native dll's/.so's.

What are the rules for packing external resources into the game engine? Does anyone have an example where this is being done?

I have seen a lot of posts describing using socketed IO to communicate with externally packaged apps, but I would like to be able to bundle everything for an architecture into one executable.

Or just not possible?

$\endgroup$

1 Answer 1

2
$\begingroup$

The limitations of the Make Runtime Function is that it can only work on the Blend file that's currently open. If your game has external assets (unpacked textures, unpacked sound, other blender file as libs, external Python modules), these will not be packaged automatically.

But it's definitely possible to make a stand-alone package with all the Python modules. It's just a matter of knowing where everything goes.

Python Module Basics

  1. Understand where Python looks for modules (hint: local modules override system modules)
  2. Because the current path of the Blend file is always the first place Blender will look for Python modules, you can just place any module right next to the Blend file. Alternatively, I'd like to keep all my non-standard modules in one folder. So if you have a myModule, I would place it in a directory called externs.
  3. You can access modules you've placed under externs by import externs.myModule

Packaging

For packaging a runtime to include all the external libraries, you just need to keep everything in place relative to the Blend file, since the blend file is always going to be your starting point. This applies to Python scripts/modules as well as unpacked asset such as textures and sound.

Pure Python modules are easier to deal with because you don't have to worry about them not working on different OSes. For dynamically linked libs (dlls/so's), just make sure you have a working version for each of the platform you are releasing for.

Folder Structure

Unfortunately, the structure of a packed runtime is slightly different for each OS. So you'd have to know where the Blend file is in order to copy the py modules to the right place.

On the mac, a runtime is pretty much the original blenderplayer.app with a game.blend file stored under the blenderplayer.app/Content/MacOS/Resources/ directory. So typically all your external asset that's not packed by make runtime need to go in the myGame.app/Content/MacOS/Resources/ folder.

On Windows, a single .exe is created that contains the blend file. So, any external asset go relative to the .exe file.

I believe Linux is the similar to Windows, external asset go relative to the binary blob.

Hope that helps!

$\endgroup$
2
  • $\begingroup$ So you are saying that if I need to use a shared library, put it in the same directory as the compiled runtime? $\endgroup$
    – MrMowgli
    Commented Jan 29, 2014 at 20:28
  • $\begingroup$ For Windows and (I think) Linux, Yes. For Mac, put it under .app/Contents/MacOS/Resources $\endgroup$
    – Mike Pan
    Commented Jan 29, 2014 at 20:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .