record it in a cd and put it under your bed…
or just use delta’s bpplayer thingy XD
Under the game menu, you can select “auto start”.
It will make it so that when someone opens the .blend file, it automatically starts the game engine.
I’m not sure if this prevents appending though.:no:
Someone could just open blender -> file -> open
then select the .blend and the autoplay wont work.
You are not reading the FAQ correctly or understanding its implications correctly.
First of all, the FAQ seems to be stating that if you link against any external compiled code whatsoever that the full terms of the GPL come to bear on your .blend file. It matters not whether you have kept your .blend separate or bundled it into a runtime. It is GPL’ed because it has supposedly become party to the linking. (See footnote)
So under the interpretation of the GPL in the FAQ (as I currently understanding it), you can import Python modules safely, but you cannot import compiled libraries (.so files or .dll files) without making your entire game inherit the GPL and following all of the GPL restrictions regarding linking. This could potentially be problematic for certain commercial endeavors.
Secondly, the real issue that I’m personally still concerned about is the nature of a .blend file itself. Is it a game program, part of a game program, or an interpreted media file? It is obviously not a game program, since it cannot run of its own accord. However, the “murky water” that remains is the distinction between the other two.
For example, it is possible to use the GIMP to insert a Python script in the comment line of a JPEG image. Imagine there existed two image viewers capable of parsing Python scripts in JPEG comments: one licensed under the GPL, and one licensed under the zlib license (I don’t know of such a viewer, but it would be a relatively simple task to write one). Now imagine that I intentionally included a Python script in the comments of my JPEG image which linked against external compiled libraries with the intent that the script should be interpreted by any capable image viewer (GPL or otherwise). After viewing the image with a GPL viewer and a zlib licensed image viewer, both of which ran the script, what license has the JPEG inherited? This is certainly a difficult legal question, and I am neither a lawyer nor a judge, but my personal opinion is, “Neither.” In the same way, I do not think that the actions of the interpreter used to view the game content in a .blend file should have any bearing on the licensing of the viewed content.
It is beneficial for Erwin to be creating a second interpreter capable of displaying games written in the .blend format, because it lends validity to the perspective I have just put forth. If multiple interpreters with multiple licenses can be used to view the same file, then it becomes rather ludicrous to suggest that the chosen interpreter could impose a license on the viewed media.
Footnote:
I say “has supposedly become party to the linking” because the .blend file actually has nothing to do with the act of linking other than passing instructions to the interpreter–the blenderplayer binary. The blenderplayer is the only active party in the linking action, and it is acting based on its interpretation of what the text in the .blend file means, not based on any action of the .blend file itself.
Disclaimer: I am not a lawyer. This post is not legal advice.
I believe Blendenzo is right on.
It sounds like we’ll need a lawyer to officially clear up all these GPL shenanigans for people to calm down though.
It is very easy to solve the .blend GPL issue: adding an additional binary format, and use the .blend only as intermediate format.
During development, you can use the .blend files for fast turnaround, and before shipping the game, the gamekit can export to a final binary format, with all bells and whistles (including encryption if needed it). Free of any (L)GPL hassle.
so if I understand well this could also be used on something like the Beagleboard or the Pandora console running on ARM cortex 8 with OpenGL ES ? would be neat ! as blender GE is not usable for now on those platforms…
edit : I got one of those beagleboard here, would be interested on getting the source to test a compilation one of these days…
Good Job Erwin, you are a great contributor to hobbyist game makers!
I believe you can check the current source out via anonymous SVN by following the instructions on this page:
http://code.google.com/p/gamekit/source/checkout
I would really be interested to know when you get it working on your beagleboard, since that’s a very similar setup the the Open Pandora.
Huh. Okay. Guess I should have tried it myself before suggesting that.
Maybe you should send Erwin a PM and see if he’s willing to share it with you for testing on the ARM architecture. He might not be far enough along for that yet, but then again, he might be glad to have a tester 
I might send him a line and see if I can get a Linux test build going.
On request, I added the initial source checking for gamekit.
Note that it is still preliminary, and only MSVC 2005 projectfiles are working at the moment. I might add Mac OSX support and CMake build system for cross-platform support (if it is easy to add CMake support for Irrlicht)
Nice work.
I’ve used irrlicht before. 
Ok Thanks Erwin, just tell when there is a working CMake build system available so I can test on my beagleboard … (I’ve got no Billy Big Bucks systems here so can’t build this now … )
cheers,
Latest trunk revision 10 of gamekit has CMake support, but only Mac OSX and Windows have been tested.
http://code.google.com/p/gamekit/downloads/list
You will likely need to tweak the CMakeList.txt files a bit for Linux, so a patch would be very welcome!
Thanks,
Erwin
Nice work Erwin!
I’ll keep an eye on this, sounds promising, you do a lot of hard work for all us game designers. 
The FAQ entry on game engine licensing is a naive interpretation of the GPL. This is a very serious problem. They should clearly state their intentions in a special license.
It’s very similar to the linux kernel driver problem. The games could be seen as the drivers, and Blender+BGE as the kernel. Since python scripts inside game files call methods that are implemented in Blender, they can be considered derivative works of Blender (and I think it’s exactly this way). So I’d bet that all scripts you’ve ever written or used for the Blender Game Engine have to be GPL compatible. The way you bundle the game (.exe or launcher) is completely irrelevant. The only thing that matters is whether the scripts are derivative works of Blender or not. And I think they are.
The Right Way to solve this is to have a .blend reader library, game engine and it’s dependencies under a liberal license (uhm … exactly what erwin is writing) and an exception added to the license of the rest of the Blender source files that allows linking against these libraries (standard practice in the open source world). I find it really frustrating that this problem is being solved by developing exactly the same thing in a new project. This has to be discussed on the blender mailing list because it’s a very serious problem and for a decent long term solution only one should get development focus. If it’s not possible to relicense the thing, it should be rewritten and the same code should be used for an external player, such as the one erwin is developing.
While I’m sure BF wouldn’t sue if you didn’t release the source code of your scripts, it’s still a spikey situtation.
erwin said:
It is very easy to solve the .blend GPL issue: adding an additional binary format, and use the .blend only as intermediate format.
During development, you can use the .blend files for fast turnaround, and before shipping the game, the gamekit can export to a final binary format, with all bells and whistles (including encryption if needed it). Free of any (L)GPL hassle.
If what you need is just a simple visualization/animation application that reads .blend data files, with physics support and incomplete logic&others support then yes, it’s very easy. Having two implementations doing the same thing won’t solve the problem (compatible engine). I can place a bet on that. The blender game engine is not some network protocol that can be rigurously specified. It’s a dynamic piece and it’s obvious that it won’t be possible to keep the two implementations in sync.
This is a nice project and it may provide an opportunity to replace the existing GE with a liberally licensed one (and it could also fix some design problems :), although I think the best solution is to add an exception to the blender license because it affects all scripts ). I think you should raise this issue on the blender mailing list. Best of luck!
Since this is a problem that also affects blender scripts in general, and the current interpretation is that those scripts don’t have to be GPL (which I think is not correct) the quick and elegant way to solve this is to add an appropriate exception to the license.
By the way, the “encryption” features some of you are thinking about are useless if you release the game on the PC, so having a non-free blender game player won’t protect your files from being copied. If the licensing issue of Blender is clarified, it should be just fine to bundle Blender with your non-free games.
An explicit license exception for .blend files would be best indeed.
With a bit of luck, if this GameKit becomes a more mature project, it will be a built-in / plugin alternative to the Blender Game Engine, after Blender 2.50 release. Then developer can choose between original BGE and GameKit. Because I’m targeting iPhone, we can’t use python scripts directly, so they can be removed from the .blend file, similar to the DNA. We’ll see where the project is going, the logic bricks and perhaps future ‘hierachical finite state machine’ logic could be exported just as data, bypassing the license issues.
Thanks,
Erwin
It’s not the Blender Foundation that would sue. The GPL states that anyone is allowed to use your code for whatever they want. If you try to prevent this, than anyone could sue you after release.