5 ms·

"Otherwise known as the Maya Purple Hack, this is a fairly common hack exists in just about every game that incorporates invisibility. On RO--and probably most

by Ogre 15y ago

"Otherwise known as the Maya Purple Hack, this is a fairly common hack exists in just about every game that incorporates invisibility. On RO--and probably most other games as well--his hack works because of unneccesary information being sent from the server to the client. There are semi-logical reasons for it, but in the end we have to blame it on poor programming." I get that there are time constraints, code no one wants to deal with, deeply ingrained bad decisions, and who knows what else going on here, but I really think this point could use more elaboration. It IS poor programming. Why not fix the underlying issue and stop sending updates about invisible players to players that can't see them? While ingenious, detecting the mouseover requests isn't really fixing the problem. "this is a fairly common hack exists in just about every game that incorporates invisibility" I doubt the "just about every" part of this statement. But I can only say for sure that World of Warcraft does not send players updates for invisible objects (players or otherwise). Not that WoW hasn't had its share of attacks, but it hasn't had this one.

jerf 15y ago
Poor programming is a bit of a harsh read of the situation. The "obvious" solution of having the server simulate everything the client is simulating, then only sending the data that the client actually needs to display isn't free. It's a great deal more programming effort, with code that will tend to expose every bug in it. What features will you trade away for that? Will the lack of those features end up entirely killing the project? It also puts vastly more load on the servers, even if perfectly implemented. It also isn't easy even if you implement this from day one, and is usually going to be virtually impossible to retrofit. The question isn't about "poor programming" or not; it's a call about the costs and the benefits. The costs are quite large, and as this article demonstrates, if the benefits can be obtained much more cheaply in other ways, it may be a bad engineering decision to spend that much time to do "good programming" on the problem. Quality code isn't free and resources are never infinite.
- Ogre 15y ago
  "poor programming" was a quote from the article. Also, it wasn't clear from the article itself what game was being talked about. After clicking around the site, I realized this was about a "private server" for Ragnarok Online. In other words, a reverse engineered fan-made server. Though there appears to be an actual company behind it, just not Ragnarok Online's actual developer, I'm not quite clear on whether there's a business here. Either way, I was thinking of this in a completely different context. Indeed writing it properly isn't free, that's part of why people pay money to play these games! But in this case, people are perhaps not paying any money. I wonder if the official Ragnarok Online servers have this issue?
  - jerf 15y ago
    "Though there appears to be an actual company behind it, just not Ragnarok Online's actual developer, I'm not quite clear on whether there's a business here." Thinking about costs and benefits isn't just for businesses, it's for every programmer. Things like opportunity costs are always present, even when money isn't.
    - Ogre 15y ago
      My point was more that the benefits in this case are likely not as great as I had originally thought, not that individuals or amateurs shouldn't think about it. Same thing you're saying really.
  - Shenglong 15y ago
    Yes, they do have the issue - and a lot more issues. eAthena never rewrote the client - just the server code. Some of the eA guys (ultramage is -amazing-) are very smart.
    - Ogre 15y ago
      I guess that would follow. If the client is set up to receive invisible players and not display them, then the original architecture must have been the same. Do you have any evidence or experience to back up the "just about every game" comment? I still find that hard to believe. This is coming from having written code to "do it properly".
- tzs 15y ago
  I understand that argument when it comes to "see through walls" cheating. The server can't do real-time line of sight calculations for every player and only send them information on other players who they have line of sight on. I'm not so sure that applies to players who are invisible due to a stealth ability. The check there would not involve a lot of intense geometry calculation, but rather just a simple check to see if a given player can see through stealth. My guess is that for stealth players the reason you have to still send their data to everyone is for AoE effect checks. In many games, AoE effects still hit stealth players. AoE effects are still subject to line of sight checks in many games, so you'd want the client calculating the potential targets for the same reason you use the client for line of sight visibility checks. I wonder if any game companies have tried a statistical approach to catching cheaters? For instance, suppose on an AoE attack, the caster's client calculates which targets are hit and informs the server. Why not have the server randomly pick a small fraction of these attacks and verify them? This doesn't even have to be real time. The server could just log the relevant information (locations of both players, the spell that was cast), and a modified version of the client software could be used in a batch mode to go through these and verify that the user's client reported accurate results. Anyone who fails the random test gets flagged for more random tests.
- coderdude 15y ago
  I don't think that 'poor programming' is too harsh in this situation at all. You call it the obvious solution, but really there is only one solution worth spending your time on. The correct solution is to simulate the game on the server and update each client with only the information it is allowed to know. The client should not make any decisions and should only ask for permission. If the player wants to move forward then the client sends a request to the server to move forward. The server will respond with new player position data if the move was allowed. If the player asks to move through a wall then the server will not comply. The server should also never send clients data about other players not in their field of view (or in the immediate area, all depends on the game). To send the client any information it shouldn't have or to allow the client to make any decisions that the server takes and runs with is absolutely poor programming in the multiplayer game space. You just have to ask yourself if it's worth it to possibly save some time at the expense of introducing a systemic flaw in your client and server that allows cheating to occur. For a competitive multiplayer game I think it's worth the time to make sure you're not sending clients the position data of invisible players. Edit: The client will most likely also calculate some of these changes at the same time it requests a move though. This is called client-side prediction and it's done to keep the gameplay smooth over unreliable and slow networks. The clients will interpolate and extrapolate certain game moves and sync with what the server says as the data becomes available. That's why sometimes in Counter-Strike (for example) you can run in one direction for a second or two and then suddenly be in another location altogether, because the server corrected the client's increasingly inaccurate extrapolation of position. Some reading if this sort of stuff interests you: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking http://developer.valvesoftware.com/wiki/Source_Multiplayer_N... http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization http://developer.valvesoftware.com/wiki/Latency_Compensating... http://www.gamers.org/dEngine/q3suggest/final/generic.html http://www.gamers.org/dEngine/q3suggest/final/generic.html http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tribes_networking_model.pdf http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tr... [pdf] http://gafferongames.com/game-physics/networked-physics/ http://gafferongames.com/game-physics/networked-physics/ http://gmc.yoyogames.com/index.php?showtopic=415538 http://gmc.yoyogames.com/index.php?showtopic=415538
  - 15y ago
stonemetal 15y ago
I am not sure the solution is so easy. Invisible players might still make noises, attack, or interact with the environment in some way. So completely dropping them from the update stream might not be possible.

by Ogre 15y ago

jerf 15y ago

Poor programming is a bit of a harsh read of the situation. The "obvious" solution of having the server simulate everything the client is simulating, then only sending the data that the client actually needs to display isn't free. It's a great deal more programming effort, with code that will tend to expose every bug in it. What features will you trade away for that? Will the lack of those features end up entirely killing the project? It also puts vastly more load on the servers, even if perfectly implemented. It also isn't easy even if you implement this from day one, and is usually going to be virtually impossible to retrofit. The question isn't about "poor programming" or not; it's a call about the costs and the benefits. The costs are quite large, and as this article demonstrates, if the benefits can be obtained much more cheaply in other ways, it may be a bad engineering decision to spend that much time to do "good programming" on the problem. Quality code isn't free and resources are never infinite.

Ogre 15y ago
"poor programming" was a quote from the article. Also, it wasn't clear from the article itself what game was being talked about. After clicking around the site, I realized this was about a "private server" for Ragnarok Online. In other words, a reverse engineered fan-made server. Though there appears to be an actual company behind it, just not Ragnarok Online's actual developer, I'm not quite clear on whether there's a business here. Either way, I was thinking of this in a completely different context. Indeed writing it properly isn't free, that's part of why people pay money to play these games! But in this case, people are perhaps not paying any money. I wonder if the official Ragnarok Online servers have this issue?
- jerf 15y ago
  "Though there appears to be an actual company behind it, just not Ragnarok Online's actual developer, I'm not quite clear on whether there's a business here." Thinking about costs and benefits isn't just for businesses, it's for every programmer. Things like opportunity costs are always present, even when money isn't.
  - Ogre 15y ago
    My point was more that the benefits in this case are likely not as great as I had originally thought, not that individuals or amateurs shouldn't think about it. Same thing you're saying really.
- Shenglong 15y ago
  Yes, they do have the issue - and a lot more issues. eAthena never rewrote the client - just the server code. Some of the eA guys (ultramage is -amazing-) are very smart.
  - Ogre 15y ago
    I guess that would follow. If the client is set up to receive invisible players and not display them, then the original architecture must have been the same. Do you have any evidence or experience to back up the "just about every game" comment? I still find that hard to believe. This is coming from having written code to "do it properly".
tzs 15y ago
I understand that argument when it comes to "see through walls" cheating. The server can't do real-time line of sight calculations for every player and only send them information on other players who they have line of sight on. I'm not so sure that applies to players who are invisible due to a stealth ability. The check there would not involve a lot of intense geometry calculation, but rather just a simple check to see if a given player can see through stealth. My guess is that for stealth players the reason you have to still send their data to everyone is for AoE effect checks. In many games, AoE effects still hit stealth players. AoE effects are still subject to line of sight checks in many games, so you'd want the client calculating the potential targets for the same reason you use the client for line of sight visibility checks. I wonder if any game companies have tried a statistical approach to catching cheaters? For instance, suppose on an AoE attack, the caster's client calculates which targets are hit and informs the server. Why not have the server randomly pick a small fraction of these attacks and verify them? This doesn't even have to be real time. The server could just log the relevant information (locations of both players, the spell that was cast), and a modified version of the client software could be used in a batch mode to go through these and verify that the user's client reported accurate results. Anyone who fails the random test gets flagged for more random tests.
coderdude 15y ago
I don't think that 'poor programming' is too harsh in this situation at all. You call it the obvious solution, but really there is only one solution worth spending your time on. The correct solution is to simulate the game on the server and update each client with only the information it is allowed to know. The client should not make any decisions and should only ask for permission. If the player wants to move forward then the client sends a request to the server to move forward. The server will respond with new player position data if the move was allowed. If the player asks to move through a wall then the server will not comply. The server should also never send clients data about other players not in their field of view (or in the immediate area, all depends on the game). To send the client any information it shouldn't have or to allow the client to make any decisions that the server takes and runs with is absolutely poor programming in the multiplayer game space. You just have to ask yourself if it's worth it to possibly save some time at the expense of introducing a systemic flaw in your client and server that allows cheating to occur. For a competitive multiplayer game I think it's worth the time to make sure you're not sending clients the position data of invisible players. Edit: The client will most likely also calculate some of these changes at the same time it requests a move though. This is called client-side prediction and it's done to keep the gameplay smooth over unreliable and slow networks. The clients will interpolate and extrapolate certain game moves and sync with what the server says as the data becomes available. That's why sometimes in Counter-Strike (for example) you can run in one direction for a second or two and then suddenly be in another location altogether, because the server corrected the client's increasingly inaccurate extrapolation of position. Some reading if this sort of stuff interests you: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking http://developer.valvesoftware.com/wiki/Source_Multiplayer_N... http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization http://developer.valvesoftware.com/wiki/Latency_Compensating... http://www.gamers.org/dEngine/q3suggest/final/generic.html http://www.gamers.org/dEngine/q3suggest/final/generic.html http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tribes_networking_model.pdf http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tr... [pdf] http://gafferongames.com/game-physics/networked-physics/ http://gafferongames.com/game-physics/networked-physics/ http://gmc.yoyogames.com/index.php?showtopic=415538 http://gmc.yoyogames.com/index.php?showtopic=415538
- 15y ago

stonemetal 15y ago

I am not sure the solution is so easy. Invisible players might still make noises, attack, or interact with the environment in some way. So completely dropping them from the update stream might not be possible.