Tag Info

Hot answers tagged

39

If you absolutely need to control whether the player can see something or not, possibly for multiplayer anti-cheat or if it's key to your game mechanics, then completely obscure them. This way no amount of gamma correction will make them visible. Not the best example, but in Closure, areas not being lit are in complete darkness: ... if you could ...


24

The way you have it described, somebody hacking a save file would just need to construct an MD5 hash of the save file values in order to bypass this measure. You need to add one thing in order for this to even really be worthwhile: a secret block of arbitrary data that's added to what you're hashing (both when creating the save and when validating it on ...


17

It depends how they're cheating, focusing on one of the primary ways of creating cheats, other processes latching into your application and modifying it - you can enumerate through all other processes, and hook their memory manipulation methods, and their keyboard/mouse emulation methods. Wallhacks are typically written by injecting code between your ...


15

Unfortunately it's really hard to stop people from cheating, which is why software like Punkbuster was created to try to catch some of them. For an MMO, the biggest thing you can do is to just not trust anything the client sends you. The client should not be able to tell you where the player has moved to, how much damage they have dealt to whom, etc. ...


15

Another possibility (for integer values) is to have a second member-variable which holds a bitwise complement of an existing variable. So imagine you got health, you would also have healthComplement. Your implementation could look like this: // setter sets value and complement void setHealth(int value){ health = value; healthComplement = ~value; } ...


15

Simple ways to protect your game: Duplicate your data: store some information twice and compare the copies. If they are different, something is going wrong. You don't have to do it per variable, you can also make CRC's on some big areas of memory (ex: on a struct that contains all player information). Encrypt your data before its written to memory (and ...


15

You can't stop memory editing cheats, so design your game so that such cheats won't matter. For an online game, sensitive data like money on your own server, and don't rely on the client to have the correct amount. That way it won't matter if players change the amount of money displayed on the client, because when the player purchases stuff the game checks ...


15

Think you're lagging now? Just wait 'till you have to get real-time occlusion information from the server. Now you can walk around from behind a wall and bad guys will suddenly pop into view as the server catches up and sends you the updated occlusion data. So my snarky comment tells it all. Likely the primary reason not to do this is lag and server load. ...


14

At the most extreme solution, you basically never trust the client. For games like MMOs, users don't run their servers, and any gameplay logic is handled server side. Never give the client the authority to say "I have X health" or "I have X ammo", etc.


13

There are a few different ways to handle this, and many solutions have their own merits. I will give my opinion of the ideal way to handle this. First, it's important to understand that no matter how complicated your system is, someone who is sufficiently invested in gaming the system (with appropriate knowledge) will figure out a way to game it. To ...


12

It's doable, and has been tried in research before; for a comparison of interest management schemes, see http://dl.acm.org/citation.cfm?id=1230069 As Byte56 said, it may require more CPU, but it may reduce your bandwidth, and reduce the likelihood of wall-hacks. And as Byte56 said, an interest area strictly limited to the player's occlusion-area may ...


12

If your game is singleplayer: it's not possible, but you shouldn't care. If your game is multiplayer: then you should store all your important state on the server, which is much harder to hack than a local machine.


12

Server-side hit detection isn't to prevent aimbots, it's to prevent cheaters who simply tell the server "I hit!" regardless of where they are aiming.


11

If this is not an online tracked competitive type game: Let em hack away man. You can spend way too much energy on things like this when people who will play the game, will just play the game. Those who want to hack it will never really want to play it, they just want to hack it. If it is an online competitive type game: All you have to do is store the ...


10

Being able to decompile/reverse engineer the client code easily is really only a slight hindrance. Enterprising hackers have been bending executables to their will (maliciously and non-) for years before high-level, trivial-to-decompile languages like C# came on to the scene. Security through obscurity alone is no security at all. Any data on the user's ...


9

If you've got a system where the logic is expensive and must be done mostly on the client to save server cycles, you can implement a probabilistic cheat detection system. Every few minutes it chooses a different few players to inspect closely and consistency-check on the server. Since cheaters rarely limit their cheating to short and rare periods of time, ...


9

The basic idea is trust. Who can you trust? Nobody. So, don't. Don't let the users decide anything, everything that requires trust happens on the server. Items only "exist" on the server. Money only "exists" on the server. The clients can do requests (like "I'd like to sell item X"), the server sees who owns what, and thus you can't sell something you don't ...


9

None ready that I know of. Commercial (expensive) systems like PunkBuster exist, which constantly scan memory locations for changes, asserting that they haven't changed by impossible amounts or at impossible moments in time. You could implement something like this yourself, by occasionally asserting that the changes to the contents of your variables make ...


8

The internal system we used for Moblox (later replaced with OpenFeint) worked like this: Send a JSON message over plain HTTP (not HTTPS). Include a MD5-hash of all fields plus a magic string. On the server, check the integrity of the message with the same operation. To crack the system, you'd have to find this magic string. It is possible with reverse ...


8

Here's one scheme I came up with when someone was asking for it on some board long ago. Using percentages or doubled variables doesn't really work, as you can search for "any" values and freeze them. Instead, make a monster of a data type. Basically, store your important values as a structure with: 32 pointers to bits For quick reading, have the struct ...


8

There are a couple of Windows API functions that might do the trick: SetMonitorBrightness and SetDeviceGammaRamp. However, this will be hardware-dependent; probably not all monitors support setting the brightness programmatically, and different monitors may produce different results, etc. Moreover, it doesn't sound like a very good idea. Locking the ...


8

Depending on the complexity of your game, verifying if an action is legal or not might require to backtrack large parts of the game. An example: Player A says Player B can't play that card right now because he has no ResourceX. PlayerB says he has plenty ResourceX. Who is right? To find out you would simulate the whole game again from start to finish to ...


7

You could award points based on the difference between the opponents' point totals. Very good players would earn few points for defeating newbies, and newbies would earn many points for defeating experienced players. Likewise, losers would lose points proportional to the same scale. This wouldn't completely solve your problem, but it would eliminate the ...


7

The simplest and most effective way to counter 'farming' of scores is to adjust the score received based on the disparity between the players. Bear in mind it's not just one player creating multiple accounts you need to worry about: imagine two friends, one deliberately losing so the others ranking is artificially boosted. Chess and other games avoid this ...


7

You can limit the most flagrant of abuses by monitoring the highest results in the top score table. Depending on your game, you may have a "perfect score," above which any score must be fraudulent. If not, you can calculate the lowest "impossible score;" can the player shoot 10 shots per second, the game lasts 1 minute, and each killed enemy is worth 100 ...


7

The client is in the hands of the enemy. (The Laws of Online World Design) Really, the only way to beat most cheats is to have the client be a "thin client", that is: To only act as an input and output device, and to never give it more information than it precisely needs. This won't stop automation and this won't stop passive information gathering and ...


7

Combining Randomness You need an algorithm that allows each player to contribute to the final random number in such a way that he can change the final outcome to every possible value, whatever the others have contributed to the random number. This way, even all other players may try to work together against a single player, but can not decide the outcome ...


6

I added a quick/dirty high score table to a project of mine a while back and not being at all versed in internet security/etc it turned out sort of flawed. Surprisingly, with nearly 1,200,000 recorded scores, I've only had maybe 5 or 6 occasions of batches of blatantly incorrect scores reaching the top of the board. Most of the scores even looked more like a ...



Only top voted, non community-wiki answers of a minimum length are eligible