BGE proposal: game data encryption

Reading this, isn’t the issue of cracking an encryption through reading how its done something that every FOSS engine out there has to deal with?

One could even try to say this as a reason why one should avoid open source like the plague when it comes to making game products, no matter how permissive the license is (unless it’s ‘open’ with strings attached like UE4). Of course on the opposite end, there’s the sticky situation of the fact that there’s a sizable school of thought that seeks to ‘punish’ people who overly secure their games by pirating it to heck and back (of course there will still be that minority that will refuse to pay anything for any digital product).

I don’t think that analogy fits: If I want to make games for a particular platform, the fact that I want to, and the method by which I could is fairly clear in advance. Games are not nearly as predictable (as I’m sure you know).

A game can (and usually does) evolve throughout development, many times.

In the same way, if you start a project thinking that there will be some way to protect your assets from users and complete the entire thing, only to find out there isn’t such a mechanism in place, you could feel like you wasted your time

And how would you feel if your game evolved into something that an existing mechanism is ill-suited to protect? I imagine that would also feel like a giant waste of time, especially if “protection” was one your reasons for selecting that engine, as opposed to something that was maybe easier to use, but that would require you to devise your own protection scheme (which, ironically, you now have to provide yourself, even with an engine that lists “protection” as a feature).

With a high level of certainty, planning far ahead makes a lot of sense. However, in uncertain circumstances (which dominate game development), I think it’s largely a waste of time.

As for spin-offs / mods / etc. supporting it, yeah, sure, more talk about your game’s good. However, there’s also the very real possibility of someone grabbing your stuff and using it for their own game. This is especially possible for .blend files where everything’s there - the animations, the rigs, the meshes. It’s all set up and ready to be appended into another project.

There is also the very real possibility that a plane will crash on your head.

Plenty is possible, but relevance is largely a function of probability.

It’s highly unlikely that someone will rip your assets to use in their own commercial game, but if they do, you have automatic copyright over your IP, so you can take legal action. Although, if you find anyone using your work, I think you’ll mostly find people making non-commercial fan games, which is just free advertising for you, so …

I think for many, time would be better spent actually trying to finish something, instead of fantasizing about how awesome their game will be, and how they must find ways to protect it from all those people who will naturally want to steal it.

The issue with any suggestion, proposal, or even finished code in encrypting the assets to be used in a bplayer-based application is that as soon as one distributes the result, the code for decrypting the data must be distributed with it. Unless you’re streaming the data down from a server (and even then, it can be intercepted) - at some point the data gets decrypted and because of the GPL - the end-user has the code that shows how and where it gets the decryption key from.

This is not actually unique to GPL applications like BlenderPlayer - it carries over to commerical/proprietary code to. It’s just it’s harder to extract the encryption/decryption code from a binary and a matter of minutes for a skilled developer to find & copy the code if provided in source form :slight_smile:

Also, people that are advocating storing code in .pyc files to prevent sharing - so long as that .pyc code is interacting with code that uses the BlenderPlayer API’s (i.e. you in some way use the Blender Game Engine, which 99.99% of Blender games will) - that code is subject to the GPL as well. By releasing only the compiled .pyc code, you are violating the GPL. Python code using Python API’s is subject to the GPL just as much as C/C++ is. This is not just my understanding, but that of the Free Software Foundation and key Blender developers such as Ton & Campbell.

Worst case scenario, you’re basically back to square one, which is pretty much where we all are right now - no built-in protection capabilities. We could just build in a simple form of protection that you can opt into or out of. If you need to make a custom solution, that option would still be available.

Part of me understands how scary it is to think of losing your project in to the world without protection.
On the other hand the other part just stopped worrying. We live in a greedy world, BUT it is also full of generous and nice people who appreciate a well done product and are willing to actually pay for it and give credit to the creator.

If we look in to the past of game development, we see many games that has almost zero protection and were highly succesful games.
People buy games if they enjoy them, that is a fact. People will always be ripping off game assets if they can, that is also a fact.

But if I create a product, a game, that sells wells and then I see some other person using my scripts or codes in their projects without asking or credits, what is my loss? I have already done my work and I’m getting money out of it. On the other hand I might feel generous and think that it’s nice to see my script living onwards and being further developed. Code is just a code afterall.

And what about the graphical assets? Don’t they need to be protected? Umm…Well I have noticed that if a game gets even more familiar to a larger growd, graphical assets become burned in to peoples minds.

If someone used a animated flame texture taken from another game, people tend to notice these things. It’s up to the people to judge.
Personally such notices make other games look a bit cheap, knowing that “I see THAT flame is taken from that OTHER game”.

Even if you don’t trust your artistical skills, just try! You don’t have to be an uber artist to make assets for your game. Just don’t worry about the looks of it. If the mechanics are great, people will like the game. And who knows, you might create a unique graphical style for your game with your not_so_good_artistic_skills :slight_smile:

you answer it by yourself:

Which one is the originator? someone spend a lot of time to to create the flames. Someone else is careless picking it up never mentioning where it comes from, or even wore stating it is own work [we had that at BA some years ago, more worse … someone sold Blender as own work under a different name].

The point of the proposal is not to prevent everybody from ripping your assets (this is simply not possible). A lot of the beginner’s game developers simply take what they can easily get and use it in own work. In most of the cases they do not even know where they get it from and if they are allowed to use it.

The point is … if you can’t simply grab it, you have to think about why you can’t. If can’t you will quickly notify … the author did not want that (even without reading the licence - be honest how many licence agreements have you really read?). If you still grab it you know you are not on the save side anymore.
Yes, it does not stop the bad guy - but it stops the good guy from accidentally becoming bad guy.

It is like open door. Do your insurance pay if get robbed but you left the doors and windows open? Just now we do not have a build in lock. We do not even have a sign that tells we are not providing free beer. We offer free Blender … but what about the assets?

Yes I know I answered it myself, I just don’t see it as an issue :slight_smile:

I doubt many beginner developers end up getting financial benefits out of ripping assets from other people’s work. What it does, it does hurt only themselves more. Because people will know those assets were ripped.

On another hand, while studying scripting for example, using existing assets can and will “free hands” and enables to focus on studying the script itself instead of figuring out what kind of graphical asset to put in. Sure there are free game assets out there though (opengameart.org for example).

I’m not saying I would support “stealing”. I just don’t see such a big problem. Professionals don’t usually rip off assets, only beginners do that. And those projects almost never reach markets anyway.

Still, if encryption is easy-ish to implement in one form or another I of course vouch for including it for the people that wish to use it. But there are some methods already available and there might be more important stuff on the table for BGE development. :slight_smile:

You have to walk back to square one.

If you’re likely to end up where you started, it actually better to just stay where you are, and think of a better approach.

We could just build in a simple form of protection

We already have options for “a simple form of protection” (zipped/renamed .blends, decoy files, etc). You could also do pretty much whatever you want with the raw file data; cut it in half, swap the partitions to make the file invalid. Then, on load, undo the operation, or some variant of that. There are many, many different things you can do, including crypto, which don’t require additional game engine code, because they’re basically just methods for scrambling a .blend, which you can do quite effectively with Python.

Good point.

This would imply that incentives to rip are next to nil. I mean, even without the legal risks, which are quite high, there’s still the court of public opinion, which can be just as (if not more) brutal.

I doubt there’s anyone stupid enough to ignore those facts, and at the same time smart enough to actually make a viable commercial replica.