Hot answers tagged

50

People reading about a game in the net is a problem for all games, not just level-based puzzle ones. For instance a simple search can give you detailed walkthrough/cheatsheet/solutions/guides to any game you can think of. Even games like Fifa or LoL that obviously has no definite solution in the first place. But that being said you can more or less control ...


44

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 ...


25

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 ...


19

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; } ...


19

While ideal, it is practically improbable to validate every single input against the server, both in terms of computational load and latency in input confirmation for the client. Consequently there are usually a handful of things that aren't validated on the server in many MMOs. In some cases this includes certain classes of character movement, which is why ...


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 ...


16

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. ...


16

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 ...


16

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. ...


15

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.


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 ...


14

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 ...


13

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 ...


13

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.


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.


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 ...


11

If a player cheats, it's likely either because they're frustrated with a particular puzzle (and want to continue progressing) or they're disinterested in a particular puzzle and just want to get it over with. Either case may be indicative of a problem with the particular puzzle's design. It helps a lot if your mechanics allow for more than one solution to ...


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

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 ...


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 ...


9

What I'd suggest is adding a small amount of white noise to the rendered output. In bright scenes this won't be visible, in dark scenes with ordinary gamma setting it's similar to what cameras or the human eye actually do in reality. But for someone who cranks up the gamma, this noise would be a strong nuisance. Not only won't dark objects become properly ...


9

One of the reasons why there are protections is that reading the game state could allow bots to know the state of the game and act accordingly. For instance, grinding in a MMO: if the "bot" knows what mob is around, it can send commands to the game clients to select the mob, hit it until its life is 0, pick up the loot, rinse and repeat. With this, even if ...


8

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 ...


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

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 ...


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 ...



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