Distributing Blender games on OS X/Linux

I’ve been looking through all the FAQs but haven’t managed to find a clear answer on this: is it possible to package a Blender game as a .app or .deb on OS X and Linux?

I tried Dead Cyborg to get a feel for BGE’s capabilities, and was dismayed to see that the Mac version was distributed as a blenderplayer.app and a bunch of .blend files. Now, I have no problem with distributing my game’s .blend files — that makes it easier for modders, after all — but it’s rather unprofessional to just have this thing called blenderplayer with the Blender icon and say “look, it’s a game!”

I know you can export to .exe on Windows, but is there a way to create a slicker looking file on other OSes?

Oh, and another thing, I noticed I could only get Dead Cyborg to run in a window, and there were no resolution and graphics options. Is BGE capable of fullscreen at multiple resolutions?

Hey! So, yeah, it’s possible to export a game to an executable for whatever OS you’re using. While you can’t alter resolution options in-game, you can do so before launching the game, which is what I’m trying to do with bgLauncher. It works fine on Windows, but I ran into a bit of trouble with Linux launhing the game file. I’m trying to find a consistent distro to work with, and then I’ll try porting it over.

Currently you should separate the blend file from the blenderplayer / launcher to bypass the GPL issue, which there is a thread about at the top of this forum section.

Hopefully soon, though, the GSoC project to convert BGE blend files to optimized, un-loadable data files will be merged soon, which should solve the security issue somewhat. In the meantime, name your game files game.data instead of game.blend. :stuck_out_tongue:

First off, to change the resolution at runtime:
http://www.blender.org/documentation/blender_python_api_2_64_6/bge.render.html#bge.render.setWindowSize

Secondly, what I worked on for GSoC was not what was in my original proposal. My project got changed to optimizing and bug fixing with a focus on the converter (this is where async lib loading came from).

Oh, so the new BGE data type wasn’t implemented. Oh, well. It’s still possible to encrypt the blend files and then decrypt them when you want to run them.

I don’t mind distributing my game under a GPL-compatible license (I prefer WTFPL honestly) or having people modify the source files as much as they like. Is there any other security reason I’d want to do this?

Thanks for the replies, everyone.

You mean security reason you’d want to encrypt the game file? Only if you don’t want it to be modified / accessed.

I never had any problem creating stand-alones for Linux. Doing a regular export seems to produce a working, statically linked binary, which the user can simply run on their distribution (whatever that distribution happens to be - assuming a compatible processor architecture).

Of course, you can go the extra mile, and make a nice package for any given distro, but it’s not mandatory; Traditionally, the /opt directory is used to store software, and related resources, intended to exist outside the native package manager.

As for the “security” question: Valve has essentially proven that piracy is a non-issue, if you’re selling a quality product. Time spent on convoluted encryption techniques, which make things more complicated for legitimate users, would be better spent on improving the quality of the game.

This and similar issues have come up time and again concerning making games with the BGE.

Apparently making a game in BGE but not giving away the source (the original blend files) is a no-no under the GPL because it’s seen as making a non Open Source mod of the GPL Blender Player. I have (in the past) been a member of Stallman’s FSF for a number of years and this does not make sense to me and I think Blender Artists have tended to miss the spirit of GPL by this interpretation.

Personally, I think the following should be okay under GPL:

You should be able to make a commercial (e.g. non-GPL) game under Blender and have it distributed as a closed, self running executable. When challenged with “Hey, you’ve got GPL involved there, let’s see the code”, you should be able to comply by simply handing over the code of the Blender Player (but without your game assets). This way, you’re not closing Blender at all while still managing to protect your own work.

In this context, you’d hardly prosecute anyone else making games with Blender, though you’d still be able to protect yourself if others start pirating the work put into your own game project. Blender: still open. Your game: licensed as you want. Everyone wins.

Apparently I’m wrong though. Every time the debate reopens, the community ends up concluding that you must provide separate blend files from the stand alone player (to be called separately). They tend to avoid the issue of this effectively exposing the source and thereby rendering Blender unusable for closed-source commercial products.

Like I say, I think we’ve interpreted the GPL wrongly to take it that far (e.g. to force developers to reveal their blend files). GPL is supposed to protect everyone’s interests and the fine print isn’t meant to be stretched to that it hinders rather than helps.

While checking the GPL and Blender’s Wiki tells me that a BGE game melded with the BlenderPlayer comes under the GPL license, I agree with you, Lancer. I’m wondering if it might be possible to E-Mail the FSF and ask them what they think. Maybe an exception can be made as long as the developer clearly states that the game was made with the free, open-source BGE. After all, the developer isn’t improving or changing the core GPL’d engine in any way, but rather interpreting separate binary code with it…?

I haven’t been able to make a linux executable yet. Always throws a weird error. I’ll cross that bridge when I have to though.

If you throw me a blend I’ll see if I can export it. You’ll have to let me know what version blender as well.

I exported a version of Blender 2.64a to my launcher for Linux 32 / 64-bit, as well. It’s in the resources section.

I would agree.

There is nothing in the GPL that prevents one from shipping the stand-alone without the .blend files, because the blender player source is freely available, to anyone who wants to browse it.

But, let’s assume for a moment that this is not true, and that there is indeed some deep technical loophole that could theoretically be exploited by someone else -> In real practical terms, it changes absolutely nothing, because there are very few people who actually have the time, money, and inclination to play such convoluted legal games.

And for those few rare creatures that do: Both the FSF and the Blender foundation would probably help you argue your case, and you would probably win.

Although, you’re more likely to win the lottery before having to deal with anything even remotely similar.

That’s the really funny part about all this “OMG - The GPL will help ppl steal my gamez” nonsense: It’s just worry about some legal loop-hole that no one will ever use (even if it actually exists), because if anyone really wants to steal your game, they can probably just do it outright, or pay someone else to do it, which is much cheaper (and faster) than hiring a lawyer.

I agree with you. What I personally think is as follows:

The GPL is in place to ensure that everyone has equal rights to software. For example, if I were the creator of an open-source game engine, the GPL would ensure that I’m not ‘stepped on’ by someone else who downloads the engine, changes a few lines, and then relicenses it as a closed-source product and sells it. With the GPL, any changes to the engine that are published must be distributed back to the source (i.e. me) and are freely available for download. With a game made with the engine, though, while it is derived from or uses the engine, it doesn’t digitally alter the engine.

Something that was mentioned on the GPL’s website was that the point of the GPL was to ensure that everyone knows what software they have the rights to download, and that they understand that they’re downloading two separate portions of a game (i.e. the proprietary portion (the game), and the free portion (the engine)).

With the BGE especially, we’re looking at an engine that interprets blend files - where they’re physically (digitally) located shouldn’t really matter. I would gladly tell all of my customers that the game was made with the BGE and tell them where they could locate it, for free. Everyone would have the same right to the same software that I have.

As a side-note, according to the GPL:

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can’t treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

Does it matter that the BlenderPlayer can be separated from the game post-compiling? It’s possible to make a plug-in that reverses the process and separates a compiled game into the blend file and the BlenderPlayer, which proves that they’re two separate programs - an interpreter, and a data file.

I don’t think so, because you could theoretically separate any two “combined programs”; Whether you’re doing it before or after compilation is completely irrelevant.

It’s possible to make a plug-in that reverses the process and separates a compiled game into the blend file and the BlenderPlayer, which proves that they’re two separate programs

If you have a single program, and you show that you can split it into two programs, you would effectively prove that both of the resulting programs are covered by the GPL, assuming that either one of them was originally under the GPL.

So, don’t do that.

an interpreter, and a data file.

That’s the point to make: a .blend is not a program, and therefore the “combined programs” clause does not apply.

But really, it’s all basically irrelevant, for reasons already stated in my last post.

This kind of question is hard to answer. What I generally get from research is that you must make your source available. I found this here, http://programmers.stackexchange.com/questions/47032/can-i-use-gpl-software-in-a-commercial-application where someone answers pretty well. Though I’m not sure if it deals with assets like sound/art. But really, I’m pretty sure no one would come after you for doing it.

It seems like a shame because many people may shy away from Blender because of it. I honestly like the bsd license much better. Why doesn’t Blender just use the bsd license and we can put it all to rest?

If anyone asks you to open source your Python code, and you don’t want to, just say no.

That’s all you would have to do.

Although, I really don’t care about the code: You want to have a bunch of python files that don’t function outside the specific environment created in my .blend files? -> Feel free to waste your disk space.

I am somewhat in agreement with this;
I find that the majority of functions that I use in the BGE are nondescript. There are many more ways to skin a cat, and so there is rarely a situation where what I have written is better, or more powerful than an existing solution. For most users, game code will not be advanced beyond the capabilities of another programmer. Even with my entire networking system, If somebody had the time and knowledge of Python to tackle the problem, they would likely realise a suitable solution. Furthermore, most scripts require understanding of their functionality to be of any use, thus it is relatively useless to steal someone’s code because you’d need to reverse engineer it to understand how to use it. (Unless you leave docstrings all over the place). I always rewrite scripts, even when they are my own, because then I know how they work (less of a problem for typical game scripting) and I can improve upon any given design.

Well, regardless of what we decide is “reasonable” interpretations for GPL, at the end of the day the official line is what matters:

from: http://www.blender.org/education-help/faq/gpl-for-artists/

So I can make games without having to worry about the GPL, right?

Games created in Blender (.blend files) are program output and therefore not covered by the GPL. You can consider them your property, and license or sell them freely.
With stand-alone games however, any data that is included inside the actual stand-alone executable is covered by the GPL. If this is a problem then you should set up the stand-alone player so it reads from external .blend files. A common practice is to include a “please wait, loading…” scene in the standalone, and read level files externally.
The Blender standalone player or the game player can be sold commercially too, but you have to make it available under the GPL conditions.

…in other words, if you make a game in Blender, the moment you compile your product as stand alone, then the part which was originally just a blend file (essentially game date) now becomes part of a full GPL product and must from therein be given (openly) along with every other part of the source.

It is this part that I don’t personally agree with in terms of how I think GPL has been interpreted by the Blender Foundation. Nevertheless, it is the official line, and when I wrote Beginning Blender, it was all I had to go on for an officially “correct” interpretation of the rules.

It is unfortunate, but the official answer is what we have to go on. Like I mentioned, since the FSF owns the GPL copyright, it might be worth writing them to ask them about it. Perhaps they could clarify, or even make an exception to cases like these (interpreted data being packed in with a GPL interpreter).