Downloadable game vs non-downloadable web browser game

[optiprimeful]

If I want to protect my assets, scripts, etc, from being stolen after deployment, what is the best option between making the game downloadable + encryption and making it playable on a website (not downloadable)? Is it worth paying the hosting fee just for protection? I is it safer to publish on mobile? I know there's no very good way to protect my project but what is the best deployment method between those mentioned above?

Thanks

 

[Poryg]

Well, let me say something as someone who has delved into the problematics of MV file security.
You can't develop good security without being or having a good programmer. The reason for that is simple.
There are several ways to hide your assets online. But mere upload is far from enough. What is accessible over the internet, is also downloadable over the internet. The only thing that matters is how can you access it.
Of course there are ways to hide files from being visible. Otherwise servers wouldn't be able to hide files containing passwords. But html and Javascript files are completely readable and analyzable. So relying on Javascript only is not a good way to secure yourvresources on the internet. You could try to mix in some php, not sure how would it work though, since I'm not knowledgeable there.

As for PC, any encryption is absolutely useless as long as the code is not compiled, because it doesn't matter how hard you make doors to unlock when you hide keys inside the nearby flower pot.
In other words the code is perfectly readable and if you encrypt it, the steps to decrypt it must be readable anyway, otherwise the engine wouldn't understand what to do to decrypt them. So when you have readable steps on how to decrypt files, it's useless to decrypt them.
However, there is one way. NW.js, the executable MV uses, allows for binary compilation of Javascript code into native NW.js code. If you encrypt your resources AND compile your javascript code afterwards, you should be able to ensure a decent level of safety. Also it's a good idea to implement a custom way of encryption, because it's not a secret that MV default encryption is a joke.

If you want to see how to deal with it, I've posted a tutorial in the tutorials section.

As for mobiles... It's not good either, because mobiles are weak and decent MV games are often too demanding to be platable on mobiles.

 

[optiprimeful]

"But html and Javascript files are completely readable and analyzable" so does it make it easier to get my art, audio, common events from the browser than if I just made the game downloadable with weak encryption? I don't care about the code itself because I use public plugins, I just don't want someone uploading my project by just dragging png, ogg, json files to their project. Downloading my art, audio, common events, from the browser would need a software and some minimum knowledge, right? Your tutorial seems advanced but will be handy if I'm faced with the weak encryption option.

 

[Poryg]

Downloading my art, audio, common events, from the browser would need a software and some minimum knowledge, right?

No, stealing your assets from the internet - images etc. is as easy as it can get. I'm not going to describe here how to do it, since it could be interpreted by the mods as supporting illegal activity. But you can be completely certain that when I said that if I told a 10-year-old how to do it, he would do it without a problem. It is that easy. And I can't stress "easy" enough. In fact MV thanks to its unique structure makes it easy to steal the reaources even from my android tablet, which is not a luxury many html5 game makers would give me.

so does it make it easier to get my art, audio, common events from the browser than if I just made the game downloadable with weak encryption?

Not at all. Neither is easier. From the browser it just takes more time, because you download every file manually, but it's not any more or less difficult than when you use weak MV encryption in a downloadable game.Downloadable MV game with weak MV encryption is just not as much of a hassle as there are already tools that can decrypt your MV game. There are also tutorials on decrypting your MV game., essentially doing all hard work for you (although not that it's difficult to build one yourself).

So if you want to protect your resources, you need to do something for it. One layer of defence could be custom encryption. But as long as your scripts are easily accessible, any encryption is effectively useless, because people can read them and find the decryption key. And what good does it do when the person can just open your script and search for Decrypt function? The rest is just to make themselves a script that decrypts it and saves the result. So you not only need to encrypt resources, but also prevent your code from being readable.
For this purpose obfuscation and code minification are pretty decent steps. Another one could be trying to mix in some php, although that is rather weak as well. And if you intend to go go a desktop version, you may add the script compilation.

And yes, the tutorial I made is fairly advanced. Because it's not your standard tutorial. It's not something made in a couple of hours, but there are weeks of work behind it. It's also not a step by step guide, because there are several things you just need to do on your own.

 

[ChampX]

The first thing to understand is no matter what you do, it is not 100% bulletproof. People skilled and willing can crack and get your assets. Even the AAA industry has the problem where engineers with possibly up to more years of experience in this field than many forum members here have probably been alive still can't produce a solution that stops dedicated and talented consumers from cracking it.

The first thing you would be better off doing is trademarking your assets and taking civil action against any offenders as needed. This is what most professional companies do as while you may not be able to stop them from stealing the resources from your game, you can certainly sue for damages which will also discourage a lot of people from attempting to take your resources to begin with.

Next, as Poryg already mentioned, you would want to change to some degree the level of the default encryption MV has. Minimal case, you just want to stop typical MV decrypters from working on your game specifically as it is much more useful for people to make a decrypter that works on thousands of MV games instead of your game in specific. Most people will want a tool, and if one doesn't exist that works on your game that is half the battle. You won't have a perfect solution, but you don't want to make it easy for them either. Make them work for it!

I don't think MV's default encryption is "bad" as many great encryption algorithms are available to the public. What is important is that you do not expose the key needed to unlock the door. A good encryption system is not easily penetrable without having the key. What this means for MV is after you deploy your game with the encrypted setting enabled, you need to remove the key from a particular file and change it so that MV does not look for the key from that file. I don't think the EULA allows me to say which one though so you'll be on your own there. Instead you could directly embed the key into the source itself and then obfuscate and/or compile the js code into the NW.js application directly. Not a perfect solution but should be good enough to stop a lot of users and common tools.

From a game development standpoint, at least if you're worried about people stealing resources to use in their game, most developers won't do that. That is usually something only amateur developers would try to do and is frowned upon by anyone who takes game development even mildly seriously. People who do it who want to go far with games aren't going to be making too many friends by stealing other people's assets.

 

[Poryg]

@ChampX MV's encryption algorithm is not bad?
It is the worst possible algorithm.
I will clarify.
I was interested in seeing how MV does it... So I encrypted a demo project, then opened one file in its encrypted and in its unencrypted version. And that was literally all I needed to do to crack the encryption. Building a script that decrypts the entire project took me 35 seconds and the program did not even care about the encryption key.

So no, the default encryption is not good. Those who decrypted it will tell you.

 

[ChampX]

@Poryg
I didn't dissect the algorithm in detail and was more distracted by the encryption key being visible in plain site as the glaring weak point and I understand the decision of why they went about encryption the way they did, but I guess I just put too much faith in the actual algorithm itself.

Regardless I definitely do think implementing one of the publicly well known algorithms is miles better, but I also think (though I haven't tested this yet) having the key not visible in plain site will prevent most tools found on the internet from working and most people will rely on one of those tools.

But again, regardless of the solution implemented, I think trademarking and legally protecting your assets is probably the most important step anyone can take overall.

 

[Poryg]

Yup, it's completely understandable why they made a simple algorithm for resource encryption and why they made it the way they did. And there would be no point in making it complex. Nevertheless, it's still a weak algorithm

Regardless I definitely do think implementing one of the publicly well known algorithms is miles better, but I also think (though I haven't tested this yet) having the key not visible in plain site will prevent most tools found on the internet from working and most people will rely on one of those tools.

You are absolutely right, most people won't have enough skill to solve that. However, the problem isn't these people, because they're only a part of the chain. In fact weak link of the chain, but whatever.

I've been part of RPG maker since 2009 and at that time it was normal to have ripped resources in your projects, since it was pretty much the only way to have high quality resources if you had no skill with graphics.
Many people just used the easy way to obtain graphics. Found them on the internet or copied them from another rpg maker game in other words. Nowadays they don't copy files from other people's projects due to encryption, but instead we use easy to access tools that decrypt the encrypted resources. Which is the same thing more or less.
However, ripping communities have been consisting of two groups of people. A group that makes tools and the group that just uses them. And even if you kill off the part of the community that doesn't have the skill, the group that has the skill is still too huge if you leave default mv encryption. So the chance that they break in and share your resources over the internet is still too high.

Nevertheless, I agree with trademarking being the most important step. Because encryption is there to make stealing more difficult. But trademarking them gives a tool to use in case they actually are stolen.

 

[optiprimeful]

Thank you for all your answers. From what I understand, legal protection is the less time consuming way to protect my assets. My problem is that I purchased a font and the license says the font must not be available to the end user for the own use. Putting the game on browser is not like I made it available to everyone right? Also, is there a way to encrypt the font folder or hide it? At least something to prove i did my best not to share it.

 

[Poryg]

There's one difference between available and possible in the sense of stealing.
Available means it's been permitted.
In explanation I can steal all your resources. But unless you specify I can use them, they are not available for using. I just stole them. So you can freely use it in your game, you just cannot share it while giving permission to use.
And yes, there are ways to encrypt files. But any encryption, no matter how strong, is essentially useless, because I can just open your js code and find the decryption algorithm there. Which is why the MV encryption is so weak... It's more for legal reasons than anything. There is of course a way to compile js files into nw native code, but not there's a ton of work behind it you have to do.

Also, about trademarking... You can trademark a game, but can't trademark resources themselves unless you have an exclusive licence, simply because you're not a copyright holder.