Ideal Game Protection

Hey there,

So I was just wondering. In an ideal scenario, what kind of protection do you wish your RM games had?

Many folk undoubtedly know how easy it is to obtain a contents of an encrypted game file, and I am not going to discuss those methods here; however, I would like to discuss ideas you guys have for 'how to solve that issue'.

Do you think having your files stored in some alternate (different from RM standard) is enough to stop people from obtaining your games contents?

Would having some custom encryption method be enough security for your peace of mind?

Or do you need things even more secure? Perhaps some online database checks for valid game account, maybe even having all your games data read from an online source at game launch?

Would all this even be enough to detter someone who was determined and had understanding of the processes involved in obtaining your valuable information?

Thoughts, concerns, gripes? Please share. :)

The server check thing would be very useful and effective, however, it seems hard to do. Then you'd probably need to have a server up and running 24/7 so that people can play your game.

Yes, of course, but when you rent a server from some provider thats already taken care of.

Ok, lets say you have some script that performs the aforementioned checks.

What happens when someone breaks into your game and can see the online request code etc and can easily remove that check. ?

What then? :)

Yes, that might be a problem as well. Then it'd probably be better to create some kind of encryption method, as you mentioned earlier. I know this already exists, but it can always be improved and done better. But things like that happen to all games nowadays, when they get "cracked" and what not.

oh yea, there is no way to completely stop someone who is determined and has sufficient knowledge.

The question was more: what would be enough to put your mind at rest?

Well, what puts my mind at rest is; first, I compress the project, put the compressed files in a folder called 'Data' or something, put that folder in another folder with the name of the game, then make a shortcut of 'Game.exe', put it in its parent folder, and finally rename the shortcut to the name of the game. My point with all this is, I dunno why, but it feels like people never go snooping into a "data" folder of a game. You can still use a custom compression method if you're that concerned.

lol yea, thats not enough imo...

Ok, so I have a custom game launcher that passes command line arguments into my game.exe, this launcher is also capable of performing online requests to download patches and process 'login' and such..

So then I have my game exe only run [x] code if the command line argument [y] is passed upon game start, for taking sake, lets say [y] is 'legit'. So now my game exe will only startup if the game was opened with the argument 'legit'.

This helps provide some level of protection, but whats to stop someone from just breaking into your actual encrypted game contents and extracting them? And once people know what the command line arg is, its easy enough to replicate your game launcher - thus making it obsolete.

In an ideal world where there is zero latency issues on the internet (or very little), I would store all of the data on a server and only send it to you when you request it. Now you don't have an archive to unpack.


Here's a write-up of my thoughts on game resource security (for online games)


http://himeworks.com/2014/11/protecting-your-online-game-resources/

With cloud platforms this is no longer a real issue. I have a couple webapps running on a server 24/7 and I'm paying nothing for it because I'm within the allotted monthly allowance for bandwidth and up-time.


Sure, if I'm hosting a game with dozens of players, I might need to pay...but it's only probably going to a couple dollars a month.

I would be happy with something that made the game tamper-proof - difficult to get to the resources. Knowing the methods people use to do this would probably make it easier to avoid, but it's been low on my priority list.


For commercial games, a way to ensure the activation/registration check can't be bypassed (I already have this, but there are no doubt a number of methods that could be used and I'd be interested in seeing some alternatives).

It's all very well have servers which run 24/7, but not everyone has constant access to the internet for a wide variety of reasons.  For example, when I'm traveling, which I do a fair bit, then I can run a game on my laptop no problem.  If I have to have internet access to even start the game, I probably wouldn't get it in the first place.

Fortunately, my own resources are very unique and probably not functionally compatible with anything in any other style. As well, a lot of people think they're ugly and probably wouldn't want to use them anyway. :D Unless they were making a fan-game or something (and that would actually be a compliment).

Imitation is the sincerest form of flattery, after all...

 
If somebody wants to do it, they would find a way... Me, simple protection is enough for my peace of mind. 

 
Dev wise, yeah... but player wise, I personally won't play a single player RPG that requires internet connection to play...

This is a real problem that several companies faced. For example, Blizzard and Ubisoft both implemented always-online DRM solutions for some of their (single-player) games and players were split on the issue.


Unfortunately we are just not at a position where everyone has decent internet.

I'd be satisfied with simple protection for now.

Single-player games that require internet connection 24/7 are illogical. You'd be wasting precious bandwidth, have constant frustration when your connection's slow, or even be unable to play at leisure just because your monthly's quota is up.

Beyond Divinity had a DRM that was almost impossible to hack. When someone did manage to do so, it had major stability issues.

On the minus side of that DRM, there were reports that it, by itself, caused problems for the user's computer as well, which was probably why it has never been used since.