Game Obfuscation

[slime]

Now, what if the effort was already done for you by being built into LÖVE?

That would tip the scale for the lovers. Marginal effect for trivial effort? Great!

This effort now would lie with the LÖVE devs. Would it be worth it for the devs?

That depends on how easy it is to implement.

I think the more important question, though, is: should LÖVE provide an easy choice for game developers to make themselves (assuming an implementation would work out internally), or should the game developers have to search for their own solutions every time, possibly requiring knowledge of C++ and LÖVE's source?

Or framed differently: should LÖVE do the game developers' job by providing some kind of DRM, or is it outside of the scope of LÖVE and should those who really want it use tools and libraries seperate from LÖVE?

LÖVE should provide enough so game developers can create 2D games as they see fit, within the constraints of supporting and being consistent across multiple platforms and providing a consistent API which sticks to certain philosophies, and probably a few other ideals which encapsulate LÖVE's scope that escape my mind right now.

This question is even more pertinent as we start to think about the ramifications of potential mobile versions of LÖVE: the reasons for wanting game source content obfuscation/encryption are orders of magnitude more relevant on those platforms compared to on the desktop.

Why is that?

Unfortunately, code and asset stealing seems to be much more rampant and real on mobile platforms right now. Obviously there are some real.. 'professionals' doing it, but it's not unreasonable to expect to stop many such cases just by having a simple optional small-time protection feature built into LÖVE (assuming such a feature can be implemented nicely.)

[bartbes]

While it's possible that a tech-savvy and determined user could retrieve the key in the binary in the case of the first method, and that the user may be able to intercept/collect the key in the case of the second method, I don't think that either is giving the key directly to the user.

Yet the tech-savvy user is the only one you would have to worry about. It's true that without obfuscation/encryption/a false sense of security more people would be able to "do something", but even encrypted binaries can be uploaded to torrent sites. So what is it we're trying to prevent? Hacking? Guess what, tech-savvy, determined people do that! (And then make it available for everyone.)

Also, if you are truly desperate love has allowed loading binary modules for a while now, and with 0.9.0's liblove it's also trivial to write a frontend for it that does your wanted encryption/decryption, or even just contains the mangled code. I don't think, at all, it's a good idea to put this in the engine. Because let's think about this, nobody is going to agree with how we've done it, it's not effective enough and then we're to blame. Good job shifting both the effort and blame to us.

[scutheotaku]

While it's possible that a tech-savvy and determined user could retrieve the key in the binary in the case of the first method, and that the user may be able to intercept/collect the key in the case of the second method, I don't think that either is giving the key directly to the user.

Yet the tech-savvy user is the only one you would have to worry about. It's true that without obfuscation/encryption/a false sense of security more people would be able to "do something", but even encrypted binaries can be uploaded to torrent sites. So what is it we're trying to prevent? Hacking? Guess what, tech-savvy, determined people do that! (And then make it available for everyone.)

Also, if you are truly desperate love has allowed loading binary modules for a while now, and with 0.9.0's liblove it's also trivial to write a frontend for it that does your wanted encryption/decryption, or even just contains the mangled code. I don't think, at all, it's a good idea to put this in the engine. Because let's think about this, nobody is going to agree with how we've done it, it's not effective enough and then we're to blame. Good job shifting both the effort and blame to us.

I don't think anyone here is talking about game pirating - I'm certainly not.

I think that the main concerns here are: 1. protection of assets (graphics, music, etc...), and 2. protection of code. For the latter, there would be a few obvious reasons for that, and 2 are:
1. to prevent cheating: while this doesn't matter hugely for most singleplayer games, and can be mostly avoided with a "smart" server in regards to multiplayer games, cheating is a big issue in the case of single player games with "global" high score tables and such. This would be even more important if LOVE makes a real move into mobile platforms (where such high score tables, and achievement/trophy systems, are common).
2. to prevent direct clones: clones are a bigger issue than ever in the indie game dev world. And by clones being an issue I'm not referring to people making friendly tributes and such - I'm referring to people essentially stealing an entire game, reskinning it, and then releasing it as their own (oftentimes for profit). If you have a popular game (especially one you are giving away for free), it will probably happen. Having the code completely open and easily-accessible just makes it ridiculously easy for people to literally steal your game - for many, this doesn't matter; for others, this really does.

As I mentioned before, neither of those concerns are mine. I am not currently interested in obfuscation or encryption myself. But, they are concerns of many people, and they are reasons that people pass over using LOVE. I realize that LOVE's goal isn't to be the most popular kid in school, but it's still worth considering.

Also, as far as the "somebody can break it so why bother" mentality - I just don't agree with that. Somebody can break just about anything, given the time, but that doesn't mean that you don't try to protect it from everyone else (and make it as hard as possible for that "somebody."). Now, if you are philosophically against closed software, then that's an entirely different issue. But when you try to secure something you do the absolute best that you can (though, in the case of software at least, you MUST avoid harming the user's experience :cough: EA :cough: Ubisoft :cough:); if some people can get through, you don't just forget about security entirely...at least I wouldn't.

[Robin]

2. to prevent direct clones: clones are a bigger issue than ever in the indie game dev world. And by clones being an issue I'm not referring to people making friendly tributes and such - I'm referring to people essentially stealing an entire game, reskinning it, and then releasing it as their own (oftentimes for profit). If you have a popular game (especially one you are giving away for free), it will probably happen. Having the code completely open and easily-accessible just makes it ridiculously easy for people to literally steal your game - for many, this doesn't matter; for others, this really does.

This is both plagiarism as well as copyright infringement. I think it would be more productive to focus on legislation or codes of conduct and making them enforceable, rather than technical tricks that are nothing more than an inconvenience to the plagiarists. Gaming is not the only field that has to deal with plagiarism, it might be a good idea how other fields handle it.

they are concerns of many people,

Which people? Most I've seen here is "I wanna make an MMORPG and oh yeah, I'd like to make sure no-one steals my über-l33t codes", which isn't worth catering to. If there are lots of people actually making and selling games that pass over LÖVE because of this, that would be a different story.

Also, as far as the "somebody can break it so why bother" mentality - I just don't agree with that.

Neither do I. Like I said before, it's about the trade-off, and my claim is that it would be like spending a dollar to save a penny.

[scutheotaku]

2. to prevent direct clones: clones are a bigger issue than ever in the indie game dev world. And by clones being an issue I'm not referring to people making friendly tributes and such - I'm referring to people essentially stealing an entire game, reskinning it, and then releasing it as their own (oftentimes for profit). If you have a popular game (especially one you are giving away for free), it will probably happen. Having the code completely open and easily-accessible just makes it ridiculously easy for people to literally steal your game - for many, this doesn't matter; for others, this really does.

This is both plagiarism as well as copyright infringement. I think it would be more productive to focus on legislation or codes of conduct and making them enforceable, rather than technical tricks that are nothing more than an inconvenience to the plagiarists. Gaming is not the only field that has to deal with plagiarism, it might be a good idea how other fields handle it.

they are concerns of many people,

Which people? Most I've seen here is "I wanna make an MMORPG and oh yeah, I'd like to make sure no-one steals my über-l33t codes", which isn't worth catering to. If there are lots of people actually making and selling games that pass over LÖVE because of this, that would be a different story.

Also, as far as the "somebody can break it so why bother" mentality - I just don't agree with that.

Neither do I. Like I said before, it's about the trade-off, and my claim is that it would be like spending a dollar to save a penny.

Yeah, you're correct that it is plagiarism and copyright infringement. The problem is, most devs who give their games away for free, not to mention most indie devs who sell their games, don't have the money or resources to bring people to court over things like this. The only way this would be worth it is if the plagiarizer is making a lot of money off of your idea, but in that case the plagiarizer can probably afford to hire a lawyer who will drag things out and cost you an arm and a leg. It's just like copyright infringement in regards to music: the little guy can almost never touch the big guy (one notable and infamous example: http://en.wikipedia.org/wiki/Timbaland_ ... ontroversy ).

As far as which people are concerned about this...well, first of all, the O/P, who AFAIK has not mentioned any intention to make an MMORPG or anything like that. Aside from that and the starters of a few other similar threads, outside of my own experiences I have little proof that these "people" exist. I have personally recommended LOVE to 4 dev friends (2 of whom work together). All 4 loved LOVE, but 3 of them discounted using it seriously when they became aware of complete lack of game obfuscation* (2 of them are working on a commercial project, so this was of special concern to them). The fourth is using LOVE, but, for similar reasons, only for prototyping and small games. Also, considering how often this issue comes up here and on other frameworks'/engines' forums, it would be no surprise if there are SEVERAL people who were interested in LOVE but were turned off by this. After all, not every user or potential user takes the time to join the forums and ask about it.
*I'm not saying that I agree with them on this! I don't, really. I'm just stating their opinions

With a LuaJIT version of LOVE, this would actually be fairly easy, as (like I mentioned before) it has methods to generate fully portable bytecode from Lua scripts. You could even have a batch file or something similar that would generate compiled versions of all lua files in a directory, much like the Torque engines have for compiling projects' TorqueScript files.
And, in case you're skeptical of this method, Polycode, another Lua framework, uses this method exactly (as I guessed a post or two back). I recently asked Ivan of Polycode about Lua script obfuscation, and here was his response:
https://twitter.com/ivansafrin/status/3 ... 5702214656

While I'm not sure that LOVE would want to go to LuaJIT "full-time" (though, by what I know, this would have very few disadvantages, hence why some of the other Lua frameworks are changing over to that), this seems like it would be a great way to go since it would be completely optional and would not affect those who did not want to obfuscate their Lua scripts. I think that it would also be fairly trivial to implement, though I may be wrong on that. Actually, would this be supported by the LuaJIT versions of LOVE currently?

[SiENcE]

I would appreciate, if someone tells me how to use obfuscation and precompiled lua binaries with LÖVE. If not possible yet, i suggest this for later versions.

[Boolsheet]

A google search for "Lua obfuscation" gives a link to squish (which was already mentioned in another thread that is called "Lua obfuscation"). This should serve your obfuscation needs to make it tedious for someone else to decipher read the source code. LÖVE does not need to implement this.

Actually, would this be supported by the LuaJIT versions of LOVE currently?

Of course. There's no need to implement bytecode loading in LÖVE because Lua and LuaJIT automatically load their own bytecode formats. And yes, LuaJIT's portable bytecode is a huge advantage for the distribution problem.

My main problem with slapping LuaJIT on the official builds is that it is not pure Lua 5.1 or 5.2, but something in between. This has already confused new lovers because their game worked on one system that used LuaJIT, but not on the other that had Lua 5.1.

And there's the issue that not all Linux distributions have LuaJIT 2 yet or something like that. Everything else about LuaJIT is awesome.

[Frohman]

My main problem with slapping LuaJIT on the official builds is that it is not pure Lua 5.1 or 5.2, but something in between. This has already confused new lovers because their game worked on one system that used LuaJIT, but not on the other that had Lua 5.1.

And there's the issue that not all Linux distributions have LuaJIT 2 yet or something like that. Everything else about LuaJIT is awesome.

I'm fairly new to this whole LuaJIT <-> Love2D integration thing, but as far as I know, isn't luajit completely compatible with standard Lua 5.1?
And don't Love2D's binary distributions at the moment include 5.1, as well as being targeted it? I'm not entirely sure, but that should mean that incompatibilities would only arise if someone is making their own Love2D (c;) binaries from source.

[Boolsheet]

Yes, if not compiled with the 5.2 compatibility option, LuaJIT should handle the Lua scripts just like 5.1. Though even without that option, it will always have some of the 5.2 features that should not affect 5.1 scripts directly. math.log(x, base) is one example.

The official binaries do all have or require Lua 5.1, correct. However, the love package distributed by Arch Linux is linked with LuaJIT. There's also the LuaJIT thread here in the forum that offers a LÖVE build with LuaJIT. People want to try it out and then forget later that they have the LuaJIT version.