5 ms·

> Cheating would surely be rampant. Not at all, as it is anybody can modify the game binaries in the same way they would modify the source code (albeit with mo

> Cheating would surely be rampant. Not at all, as it is anybody can modify the game binaries in the same way they would modify the source code (albeit with more difficulty). Cheating is prevented by having a central server validate all client actions for consistency, or in games without a simulation server (Starcraft II) having clients compare a game state hash and disconnect if they differ. Client side cheating (Wallhacks, Aimbots) are not preventable without a locked down client, open source or not.

shocks 15y ago
But open source would make cheating far more "assessable". It would be a trivial job to modify the opacity of walls for example - I imagine such a feat would be substantially harder without access to the source code (of course, still possible). It's easier to trust a "cheating hack" if it comes as a source code patch or the source code is readily available. If I was so inclined to cheat, I certainly would not trust a strange patch/executable from some shadowy figure I knew nothing about.
- chc 15y ago
  That's like worrying that sharper knives will make stabbing people easier. It's true, but stabbing is already easy enough with the knives we have that the difficulty of the act isn't really stopping anyone. Similarly, games get hacked, open-source or not.
- pantaloons 15y ago
  Ignoring the security through obscurity mess, the more salient point is that there are classes of problems that cannot be solved at present without a locked down client. If solving such a problem is the entire function of the device I don't know that I'm against this. Technology will eventually solve such problems (thin clients or fully homomorphic encryption) but these have serious issues of their own.
JoshTriplett 15y ago
> Client side cheating (Wallhacks, Aimbots) are not preventable without a locked down client, open source or not. You can easily prevent wallhacks; just don't tell clients information they shouldn't display to the user, such as the positions of players the user can't currently see.
- jiggy2011 15y ago
  I think this is a case for performance mostly. A character hidden behind a wall will be likely to appear to the player very soon. The client then gets a chance to pre-load any necissary rescources into memory and download from the server any information about the other character it might need. If you didn't do this then for example the page containing the player character model might have been swapped to disk and the delay caused in bringing this back in might cause a lag which will give one player a disadvantage. Also you may be able to hear the person behind the wall , for (even though it may only be a very quiet sound from the other character walking slowly). The client application will need a location in order to play the sound correctly, this information could be used to make a wallhack. The other alternative would be to pre-prepare all sound on the server and stream it to the client , but this would put extra stress on the server and more demand on bandwidth.
  - JoshTriplett 15y ago
    This is a very old discussion, by the way: http://catb.org/~esr/writings/quake-cheats.html http://catb.org/~esr/writings/quake-cheats.html
  - jeremysalwen 15y ago
    Hmm...I don't think you would need that much of a performance drop. If the data was received encrypted, you could have a relatively small decryption key sent when necessary, thus solving the "prefetch from server" problem. If the model files were broken up into chunks and xored with each other in various ways, and saved in a redundant manner, I could imagine that there is a setup in which there are a combinatorially large number of possible ways to fetch a set of blocks which reconstruct a given model, and if you prefetch a few red-herrings as well, it would be infeasible to determine which model you are loading based just on the commands the sever sent you on which blocks to load. Then, when the time comes, they send a very short command which tells you which blocks to use and how to reconstruct the model. Hmm... but now I'm thinking about it, I think you'd need a large overhead in both directions to make it difficult to just match the patterns of which blocks you used.
omouse 15y ago
In opensource code, you would have decentralized servers run by various groups that may or may not accept "cheating" (cheating is just a different set of game rules). You could have peers validate the game rule set for each of their peers as well so that everyone playing on servers is agreeing to the "cheats".

shocks 15y ago

But open source would make cheating far more "assessable". It would be a trivial job to modify the opacity of walls for example - I imagine such a feat would be substantially harder without access to the source code (of course, still possible). It's easier to trust a "cheating hack" if it comes as a source code patch or the source code is readily available. If I was so inclined to cheat, I certainly would not trust a strange patch/executable from some shadowy figure I knew nothing about.

chc 15y ago
That's like worrying that sharper knives will make stabbing people easier. It's true, but stabbing is already easy enough with the knives we have that the difficulty of the act isn't really stopping anyone. Similarly, games get hacked, open-source or not.
pantaloons 15y ago
Ignoring the security through obscurity mess, the more salient point is that there are classes of problems that cannot be solved at present without a locked down client. If solving such a problem is the entire function of the device I don't know that I'm against this. Technology will eventually solve such problems (thin clients or fully homomorphic encryption) but these have serious issues of their own.

JoshTriplett 15y ago

> Client side cheating (Wallhacks, Aimbots) are not preventable without a locked down client, open source or not. You can easily prevent wallhacks; just don't tell clients information they shouldn't display to the user, such as the positions of players the user can't currently see.

jiggy2011 15y ago
I think this is a case for performance mostly. A character hidden behind a wall will be likely to appear to the player very soon. The client then gets a chance to pre-load any necissary rescources into memory and download from the server any information about the other character it might need. If you didn't do this then for example the page containing the player character model might have been swapped to disk and the delay caused in bringing this back in might cause a lag which will give one player a disadvantage. Also you may be able to hear the person behind the wall , for (even though it may only be a very quiet sound from the other character walking slowly). The client application will need a location in order to play the sound correctly, this information could be used to make a wallhack. The other alternative would be to pre-prepare all sound on the server and stream it to the client , but this would put extra stress on the server and more demand on bandwidth.
- JoshTriplett 15y ago
  This is a very old discussion, by the way: http://catb.org/~esr/writings/quake-cheats.html http://catb.org/~esr/writings/quake-cheats.html
- jeremysalwen 15y ago
  Hmm...I don't think you would need that much of a performance drop. If the data was received encrypted, you could have a relatively small decryption key sent when necessary, thus solving the "prefetch from server" problem. If the model files were broken up into chunks and xored with each other in various ways, and saved in a redundant manner, I could imagine that there is a setup in which there are a combinatorially large number of possible ways to fetch a set of blocks which reconstruct a given model, and if you prefetch a few red-herrings as well, it would be infeasible to determine which model you are loading based just on the commands the sever sent you on which blocks to load. Then, when the time comes, they send a very short command which tells you which blocks to use and how to reconstruct the model. Hmm... but now I'm thinking about it, I think you'd need a large overhead in both directions to make it difficult to just match the patterns of which blocks you used.

omouse 15y ago

In opensource code, you would have decentralized servers run by various groups that may or may not accept "cheating" (cheating is just a different set of game rules). You could have peers validate the game rule set for each of their peers as well so that everyone playing on servers is agreeing to the "cheats".