Core code obfuscation and scripting

Question

I am currently developing a 2D multiplayer game in Java and I would like to use Lua to define clientsided visual animations. Although this sounds like a reasonable idea to keep the core Java code to a minimum, these scripts would be depending on the core code and would therefore break if the core code is obfuscated (think of naming of classes and fields, imports).

What options do I have? Is there a way around this? If I was the head of a million dollar game development company I could just leave the source wide open without any obfuscation whatsoever but unfortunately I am not. Anyone could just reverse engineer the compiled code, modify it, alter resources and claim it as their own. I am aware that obfuscation does not completely stop that, but it does require someone to put a whole lot more effort into it.

I am currently still in an experimental design phase so I do not have any code examples of what I'd like to protect.

Answer 1

Don't obfuscate the names or interfaces required by the scripting system; that way the scripts still bind to the correct types and functions and whatever by name.

If you need the code for those methods to be obfuscated, have the implementations of the scripting functions themselves call other set of internal implementations which can be obfuscated.

Answer 2

You shouldn't waste any resources on obfuscating your code in the first place.

You work is protected by copyright. When anyone steals it, just call your lawyer and sue them. Changing it so much that it can no longer be traced back to your work would be more work than writing it from scratch in the first place, so nobody will do that.

On the other hand, when your soucecode is available, you open up your game to a modding community. Most games really benefit from modding, because modders add more content to your game for free and greatly enhance its long-term value.

When you are worried about cheating, then preventing it client-sided is futile anyway. A skilled hacker will always be able to reverse-engineer your game client. Having the sourcecode makes it easier for them, but it's not strictly necessary. Games written in compiled programming languages do not thwart the hackers either. A far better way to prevent cheating is by designing your network protocol with an authoritative server. This means any game mechanics which could be interesting for a cheater to manipulate are calculated on the server where it is out of reach of the hackers.

Answer 3

Whenever I read a question like this I really love to cite some basic rule I've read on the internet years ago (and it's still true):

The client is in the hands of the enemy.

So whatever you do: If you think players might change it to cheat, don't provide that part of the code in the first place. While code obfuscation might be a tiny step towards this goal, it's usually futile, because there are even modern tools to deobfuscate code. Picking a different language that is harder to disassemble (like C++ over Java) might be a even bigger (and significantly more effective) step, although not perfect either.

There's no perfect protection, no matter what you do, except taking the code to be protected from the client and moving it server side (assuming that's possible). Otherwise there will always be people putting hours or even days of work into getting some cheats to work, even if it's just some pointless tapping marathon on mobile with a high-score table.

So, if possible, change your game design to respect the quote mentioned above:

• Never ever allow any clients to dictate something on the server.

  If the client claims to shoot, let the server check, whether that player is actually allowed to shoot. If so, let him do it. Same goes for movement or pretty much every other "move". To reduce lag, clients might show feedback instantly (shooting animation, movement, etc.) but the server must always have absolute power and be able to correct any abnormalities (often seen and named as "rubberbanding" in online games).

• If you don't have a strict server/client separation (like peer-to-peer matchmaking), either elect one host temporary or let peers vote over important events (might be complicated).

  For example, when voting for the next map, all peers count the votes and the majority will determine the winning vote. If 4 out of 5 peers say "map 1" is next, but one peer claims "map 2", you know who's manipulated or simply lieing. In a similar way you could ensure checksums of scripts and similar, but this may be open for manipulation once again.

• Never tell clients/peers things they don't have to know. Imagine a stealth game. If one player has a modified client, he might be able to see all enemies all the time, ignoring their "stealth" flag. However, a cheat like this won't work, if his client won't get any information about players unless they're actually visible.