Game Maker Multiplayer Games are "more" Unprotectable

[Freddy Jones]

In the examples I'm about to provide, it is basically pointless to try and prevent people from hacking your game. The scenarios provided are assuming you're not using Game Maker as the server, but some other language.

If you had made a multiplayer game in HTML5, it is very prone to be hacked(explained in paragraph) by the user. It is completely possible to manipulate the packets being received from the server, and the data sent to the server.

Now these two problems are also possible in non-HTML5 applications, but the second problem that arises with HTML5 games is that the code is in plain(obscure at the least) and very editable sight. If someone wanted to modify the makings of your logic and create a hacked client that did as they wished, they could, and it wouldn't take much time at all for them to stay on top of your patches.

Now, the common answer to this particular problem is:" Don't trust the client, at all, with any of your main and user experience-ruining logic, but let the server handle that." Except, we're not going to be doing that, how could we do that? There's no realistic way that we'll be able to simulate the gameplay on the back end because that would mean we'd have to get Game Maker running on the back end. We couldn't possibly realistically try and attempt to mimic what the client is seeing in GM:S's engine with our own non-GML code. In regard to this technique, it is highly impractical unless you somehow utilize GM on the back end.

You could try to make as many validation/authorization gimmicky techniques to slow down potential hacks, but what's the point? What's the actual cost-benefit of taking these extra steps when as soon as someone gets the first hacked client they can keep patching theirs as you patch yours.

There is also another system you can implement where the server will watch players and check off ones with suspicious activity. This may be a particularly good approach in our case, especially when we can't exactly simulate the gameplay server side, but as soon as you introduce a FTP multiplayer game it's ultimately nullified. You ban one free-account another will be made. IP bans wouldn't be a plausible measure of defense either, only take up memory. If someone's hacking just for griefing or to ruin the game's reputation, it renders this technique unmanageable as well. But it is useful for targeting paid accounts trying to milk the game's flaws.

What I've argued above is that trying to protect a multiplayer game which is browser based (where Game Maker is the game-play logic) is ultimately impossible. My knowledge of how people hack games is very limited and these are the very small cases that I've recently tried studying. I do know that I said HTML5 this whole time, but I'm sure there are ways to hack other exports to a similar or the same extent as you can with HTML5 clients.

So my question really is, why go out of the way to prevent cheating/tampering in a multiplayer game if it is truly inevitable. I'm not sure if at the moment any form of client validating will be worth implementing.

If you know of techniques not mentioned above that can effectively combat hackers to a reasonable degree, even in our situation, Game Maker being only useable on our client and such, please do so. Or any thoughts at all are welcomed.

 

[YellowAfterlife]

Except, we're not going to be doing that, how could we do that? There's no realistic way that we'll be able to simulate the gameplay on the back end because that would mean we'd have to get Game Maker running on the back end.

Clarify further? Are you saying that you can't simulate the standard bounding box collision system on the server? Or does your game use Box2D, in which case you can use non-GMS version of Box2D server-side?

With free-to-play games people making new accounts to get around a ban for being a butt is something that can happen regardless of tools used, and is something that should be considered early on.

 

[Freddy Jones]

Clarify further? Are you saying that you can't simulate the standard bounding box collision system on the server? Or does your game use Box2D, in which case you can use non-GMS version of Box2D server-side?

With free-to-play games people making new accounts to get around a ban for being a butt is something that can happen regardless of tools used, and is something that should be considered early on.

Thanks for the quick reply YellowAfterLife! It is unlikely that we would be using Game Maker on our backend. It is also rather difficult to imitate GM's collision system alone when Game Maker offers pixel perfect collisions, and the bounding boxes between multiple instances can typically be vastly different. What about instance logic that start interacting with the world that isn't the player? The simulation starts becoming less of Game Maker's engine and more your own rendering Game Maker's functions less important to use. Box2D isn't well supported or easily used in JavaScript, Go-Lang, php(ha), Python, etc etc so it's not very easy to port to every backend language - you know?

It's not very practical if you have a strong background in GML that you'd like to incorporate. I have a strong background in JavaScript, and have made an entire platformer MMOG on client and server with it, but I'm trying to be more general to other people that encounter this problem too.