|
-
Senior Member
[DISC] How to you deal with cheating in multiplayer games / leaderboards?
My current game is going to be tracking characters in a mysql database. I know flash documents are inherintly insecure, and even when obfuscated they can be cracked with arguable ease. The script obviously has class methods that can modify the character database.
Is there a way to prevent this? (turn based polling game using AS3->PhP->MySQL for all communication)
Looking at the number of leaderboards that are hacked so the top 20 scores are all 999,999,999,999,999 I am concerned this might not be possible.
If you can't prevent it programmatically, how do you personally deal with it? Does it bother you? Or do you take a more laid back attitude and not care, if cheating is fun for them, so be it.
My game won't have any pvp so the worst that could really happen is that you could group up with someone who is crazy overpowered. I guess I could add a system to report suspect cheaters or people who are abusive (good idea anyway since chat is possible).
Just wondering how you guys/gals handle cheaters and also wondering how rampant it is in the flash gaming community. Do you find cheaters in all/most/none of your games?
-
If your game gains any sort of popularity, there will be attempts at cheating. That's just a fact of life. One way to "plug holes" is sanity checks on those scripts that are modifying the database. For example, unsecured game has player killing bad guys and gaining experience and leveling up. It tells the database when this happens and the database just says okie doke. More secured game has player attack a bad guy, game tells the server player attacked bad guy A, server returns result of the action. So basically, to make it secure the game logic has to be handled on the server instead of inside the SWF.
Since you aren't doing PvP it probably isn't going to be a big issue. Report system is good, but make sure you have a solid outline of what is/isn't cheating and what is/isn't acceptable language and behavior in chat.
-
Senior Member
I just realized I could fix this in multiplayer games by having each client do all the calculations and the server wont make a change unless all the clients agree. Probably more effort than I will put in, and it won't work in single player games, but I could separate characters for single and multiplayer I guess. This would increase network traffic and confuse my tracking of the gamestate.
Doing the game logic on the server certainly would work if it was extensive enough. Then the flash interface would be myplayer.attack("north"); instead of myplayer.gainExp(100); (after the attack is finished in the flash game). Just not sure if I want to program the game logic in php or not though...
-
Yep, that's exactly what you'd need to do. Having multiple clients doing the calculation doesn't seem worth the effort to me, since that would still let people cheat in groups or in single player as you said. The difference in work required between server-side calculations and multiple client consensus seems small enough that if you're going to do one, better to just go server-side.
Luckily, it's something you can change after release if you have problems with cheaters and the well-behaved players won't even notice a difference since it is all behind the scenes to them anyway.
-
Senior Member
I think I will start off by doing the logic client side, with some serverside checks on the data.
Things like:
Map finished, did the player gain more experience than was possible on this map? If so, flag as cheater!
I should be able to handle loot assignment serverside as well.
And I can give the server a table letting it know what each character should have for total stats at each level to allow me to periodically check character files.
If someone wants to hack the game to let them teleport around the board or attack for silly damage I can let that slide initially and tighten up my checks over time.
-
 Originally Posted by Alluvian
I think I will start off by doing the logic client side, with some serverside checks on the data.
Things like:
Map finished, did the player gain more experience than was possible on this map? If so, flag as cheater!
I should be able to handle loot assignment serverside as well.
And I can give the server a table letting it know what each character should have for total stats at each level to allow me to periodically check character files.
If someone wants to hack the game to let them teleport around the board or attack for silly damage I can let that slide initially and tighten up my checks over time.
woa.
First, take a deep breath and calm down 
Second. You have a chance to make your game completely reliable/unhackable, you just don't know it.
Any as/php/mysql application has the same opportunity to be as secure as any html/php/mysql application (this forum, for example). Make your game's logic based on the same request/response idea that http is based on and your game can be secure.
For example a player can't move one square north in your game, he can only make a request to the server to move one square.
Then in the php script you calculate whether or not this is a valid move for this player, if it is you update the database and notify the client. If not, update the client that the move can't be made.
As for server intensity, your game will still have one up on many web based browser games for the fact that all of your requests/responses will be small pieces of data rather than entire html pages. Your game would need many players before it even needed to be taken off of a poor host (and it's not like you're breaking ground here--many of these games have been made with this idea in mind)
There are generic flash server packages that allow the clients to merely send variables to the server from the client as if they're one. I say these are awful
Last edited by 0kx; 05-24-2009 at 01:46 AM.
-
Senior Member
lol, redjag already suggested the same thing...do the game logic on the server side! But for a flash programmer, who is not very fluent in php or mysql communications, it's a bit daunting to do this! Also another fact is, nothing is 100% secure....
My suggetion would be, plan the game thoroughly, and find out exactly where a player can cheat...I mean which messages can the player modify to cheat, for example, if someone is trying to cheat, they will surely try to modify the messages that look like "&score=1000" or "&money=200", etc! So instead of trying to prevent the player from modifying these, make these messages more obvious, and send the encrypted real messages with some other name, which most players won't think of modifying, likr the sessionID(fake).....when this two messages don't match, that means player has tried to cheat!
Also, when you know the most important messages among these, you can calculate it server-side more easily than calculating the whole game logic(actually that isn't hard either, but it requires a little planning and practice).
Next, get yourself SSL, it will minimise the number of hack attempts!
Oh and keep one thing in mind, for encryption/decryption use your own custom logic, and make it so that you can change it from time to time(like a serverside key/seed), otherwise you can be sure they will be broken within a few days!
If you like me, add me to your friends list  .
PS: looking for spriters and graphics artists for a RPG and an Arcade fighting project. If you can help out, please pm me!
My Arcade My Blog
Add me on twitter: 
-
Obviously server side handling is one of the best ways, of course you cant always do it.
As for server calculations, dont worry! unless your game is played on a massive scale, with the speed of todays servers you probably wont get complex enough to bog it down.
With my game I have a few systems...
I random check the client for the players stats, having the client return the latest stats.
I have a one time key sent to the client, when the key isnt sent back in time, or is not the write key, it closes the client.
Main issues I have ran into is brute force hacking (easily stopped with sleep commands) and sql injections (use htmlspecialchars, or something like that)
just note that the packets you send are viewable, that anything in the clients memory, variables is exploitable... and easily done.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|