Decrease Game Size

Hey there…
When exporting a game as runtime blender exports the whole python folder. For me the folder is pretty huge. About 30 megabytes. I have deleted randomly a few folders and the game is still running.
Does anyone know which folders/modules are essentially important to run the bge and which are not?
I would like to decrease the game size as much as possible.
Also the default blenderplayer is very huge? I remember it was smaller some time ago. Is there a way to decrease it too? Some compile options maybe?

I hope some of you guys have experience.

Greetings

2.49 blenderplayer: 4.6MB
since 2.5 blenderplayer: >11MB
since 2.6 blenderplayer: >14MB

You might switch back to 2.49 ;).

I would not export the game as runtime at all.
First you get one platform only.
Second your work gets licensed under GPL.

Better have your game as one or more blend files.
If you really need a “startup”-application, you can bind a startup-.blend file, which loads your game file. The blenderplayer does that already for you. Just provide your .blend file as parameter.

With a script file (e.g. startGame.cmd or startGame.sh) you can take make this easier to the user.

Finally I can’t tell what libraries are required for the BGE.

yeah… I use exporting only for testpurposes. For my final product I won’t pack my blendfiles within the .exe
Still, in both cases I have the lib folder where all the stuff is in.
My blenderplayer.exe is 29MB large! Why is it so huge? Is this normal?

30 mb isn’t that big, really. Not sure of your exact use, but 30mb only takes maybe 15 seconds to download (on my computer at least). Big pro games are several gigs. I’m sure you know all that. I’m just saying that you may not need to worry about the size (unless your .blends and textures etc only come out to 10mb, and the exe adds 20mb, something like that!)

All in all I have about 45 mb(zipped) now. You are right it is not that big. But I thought that maybe it still can be decreased with not to much effort. Anyway thanks for your replies! :slight_smile:

my blenderplayer.exe is 24 MB (2.63a)
is much fatter in recent versions :smiley:

If I remember correctly, Blenderplayer + all the DLLs in windows is just a bit under 25MB. But if you must get the size down, you could try to compile your own Blenderplayer without some of the functionalities (i.e. ffmpeg, audio, sdl, etc) which should reduce the package down to ~15MB.

@Mike
thanks. I need to set up compiling again. Always not certain how to do this properly :slight_smile:

@Moguri
Thanks for your suggestions. I will look into this! I am curious why the blenderplayer sometimes is so large and sometimes smaller. I have downloaded a build yesterday where the bplayer is only 14 MB. Half the size I had before.

What is ffmpeg needed for exactly? Video textures? If so, I don’t use it. And audio is handled copletely via Audaspace.

Are you always using release versions or do you download development versions sometimes? If you do the latter it’s possible the binaries contain debug information (which can take a lot of space).

Don’t you mean the Game Engine part of your game remains GPL? Like if they demanded the source you would be obliged to give them that part (e.g. Blender itself) but not necessarily your code if you wanted the game you made to be non GPL?

Please read the stick regarding licences at the top of this forum (FAQ #3).

Blendenzo prepared this wonderful FAQs for us. Thanks for that.

the irony is that i would call 30mbs tiny size for a game :smiley:

Yeah, I think so too. Compared to Game Maker or similar 2D engines / frameworks, 30mb for even a blank game is huge, but compared to engines like UDK, Unity, or Crytek, the BGE’s runtime’s rather small. It also doesn’t have as many dependencies like other engines (Direct X, C++ distributable, etc).

@ndee
I wouldn’t be surprised if Audaspace makes use of ffmpeg for reading files.

@SolarLune
I believe the Blenderplayer does require the MSVC++ redistributible since Blender requires it. You could probably get rid of this dependency by building with MinGW.

I may have read it and very quickly trashed it. It looks like the “solution to not going GPL” is to have a separate .blend file (to call to) with all protection removed. What then if some game developer doesn’t want people to see inside their game? The method claims to help users make games which aren’t GPL… but if the process involves forcing formats where any fool could go in and steal the direct code (e.g. raw blend files provided) then the the method is practically useless.

Perhaps one way would be to include some kind of encryption exe which temporarily restores a garbled .blend file just while it is running? I’ve seen these measures in the past - they are often easy to crack.

Seriously - I still don’t see why people demanding the source of a commercial standalone can’t be given the raw blenderplayer… that should satisfy supplying the source for the parts which actually are intended GPL.

There are ways to hide python source code , for example you could encrypt it. Bsurfaces did something similar before going GPL.

I think you got the point of that licence conflict. Please check the resource forum for BBplayer and Burster.

BTW. the licence issue does not help you reducing the overall size of the game. It is just an important point to deliver more than one file.
If you deliver multiple files, you might deliver your game without the blender player forcing the user to download his version of Blender before playing.

Yes this is not “user friendly”, but this is a conflict between “one click installation” vs. small file-size/portablility.

@Lancer - This discussion’s kinda getting off-track of the thread, so I won’t continue with this past saying this: Packing the game blend file into the executable isn’t a fool-proof method for security. Being that the add-on for actually packing the blend file into the blenderplayer is distributed with Blender and is written in plain Python, I’m sure that reverse-engineering the process is possible. So, you can’t and shouldn’t rely on pushing your blend file into an executable for security.

If you think that it would be safer than leaving your blend file out ‘in the open’, rename it to something else, like “game.data”. Someone would have to know to rename the file to open it with Blender. Of course, this is pretty much just as effective as a paper sheet standing in as a locked door when it comes to security, but it’s something at least.

You can encrypt a blend file and then decrypt it to load it up, or load up scenes from the decrypted version with LibLoad if you want something more secure.

ndee, I don’t think that’s a big download at all, I only realised this after downloading Sintel the Game Alpha which is 708mb. If you’re making a mini-game (which I don’t think you are) anything under 50 is fine, other-wise, just avoid the thousands. :o

There are som nice tips in this thread, so thank you anyone who has commented them.

You don’t need the blenderplayer.exe to run the runtime :wink: Atleast in 2.49 I didn’t. Same with Blender.exe. You don’t need those.