5 ms·

>Cheating in MMO games is always a battle Cheating in MMOGs isn't much of a battle. Do everything on the server: problem solved. Consider UO did this correct

>Cheating in MMO games is always a battle Cheating in MMOGs isn't much of a battle. Do everything on the server: problem solved. Consider UO did this correctly in 1997 and yet games like WoW came out much later and still did it wrong (let the client choose its x,y,z position and tell the server, rather than asking the server "is it legal for me to move to x,y,z?"). It is faster paced games where you can't do everything server side that are the problem, first person shooters being the prime example.

crazypyro 13y ago
WoW has a demanding enough latency requirement. Same with DotA 2. Not to mention the server resources used.
- nousernamesleft 13y ago
  >WoW has a demanding enough latency requirement And yet ultima online proved that excuse was bogus before WoW ever existed.
sehrope 13y ago
> It is faster paced games where you can't do everything server side that are the problem, first person shooters being the prime example. First person shooters can be (and I believe usually are) done server side. Official movement, firing, health, and overall physics is handled 100% on the server. To smooth things out though, the client interpolates its view of the world. For example lets say you fire your gun at a person right in front of you. The server would have final say of whether you actually hit the target. Rather than waiting for a round trip to the server, your client may choose to immediately show some blood/shrapnel effects to give you the illusion that you hit them. If you actually did, the server will handle the health deduction. If not, you probably wouldn't even notice.
- TheLoneWolfling 13y ago
  Right and wrong. Movement and such can be done server-side, mainly. But visibility pretty much has to be done client-side. Which means that people can hack the client to see through walls. You can do culling server-side to an extent, but not entirely - because otherwise someone with a high latency coming around a corner will have no chance against someone with low latency on the other side. Also, servers pretty much have to (well, not really. But otherwise games become unplayable to those with higher latencies, as where you see other players is not where you need to fire to hit them) allow you to hit someone that was, according to your client game tick, in target when you fired. Which means that the client has to tell the server what game "tick" the client fired on. Which allows for cheating if the client deliberately tells the server that it fired/started to move on an earlier tick than it actually did.
- nousernamesleft 13y ago
  First person shooters are split, part server and part client. For example, an enemy comes in range of you, your cheat automatically triggers a "shoot at the precise direction of their head" command to be send to the server. The server does not check if you were actually facing that direction, it does not check if you actually turned to face them in a manner that a human could. So things like aimbots are common where you literally click "next target" and it cycles through all the enemies heads. There is really no way to prevent this kind of cheating. Slower paced RPG style games where you just send "attack target with ability X" can be handled entirely server side. As we start seeing more fast paced action style MMOGs and fewer "computer reproduction of pen+paper+dice" style MMOGs the line gets blurred and more impossible to deal with cheats become problems.
  - JoeAltmaier 13y ago
    But, but, you just said how to prevent it! "Check if you actually turned to face them..." would work just fine?
    - nousernamesleft 13y ago
      If you just check that they did face the right way, then cheating is still trivial. Just instantly turn and fire instead of just firing (this is what aimbots actually do anyways). The problem is you can't have the client send all 1000 "the mouse position changed" events to the server and have it approve them to ensure that you actually moved the mouse rather than just instantly changing to pointing straight at the enemy's head.
      - JoeAltmaier 13y ago
        Maybe stats on the behavior would work. You can tell who's typing on a keyboard by running stats on the inter-key delays etc. Probably stats on commands to the server (turn, fire delay etc) would identify bots pretty well.
      - Retric 13y ago
        You can't validate each mouse click before updating the client's view, but you can do the same aim validation as you do movement validation to prevent teleportation or excessive movement. Basicly, validating 1,000 motions a second is no problem it's latency that's the issue. So now you can still cheat but your limited to human reaction times or the server can detect and boot you.
Hacktivist 13y ago
The F2P game "Path of Exile" (similar to Diablo) does everything on the server and it causes so many problems that you need to avoid certain character skills that are more prone to causing desync issues between server and client. They even include a chat command that will sync you with the server which most people have macro'd to a key on their keyboard or mouse it's so prevalent.
- nousernamesleft 13y ago
  >The F2P game You've already explained a big chunk of the issue right there. There are many poorly written games. PoE is one of them. That doesn't mean you can't write a similar game well.
andypants 13y ago
> asking the server "is it legal for me to move to x,y,z?" These questions are not always straightforward. Why can't you do this in a shooter? Because any mouse position on the screen is valid. How do you know if the user physically moved the mouse or it was some other software that moved the mouse cursor? How do you know the user genuinely decided to aim at a random enemy, instead of relying on an on-screen display of player information that is not normally available? You can't do everything on the server side. If you could, it wouldn't be an interactive game.
- nousernamesleft 13y ago
  You might want to re-read my post. I specifically pointed out that shooters are the standard example of where you can't do everything server side, where as traditional MMOGs you can.
  - andypants 13y ago
    I know, I was just building on your example of why it's difficult for shooters. And it's also difficult for many other games for similar reasons. Being able to directly set your position in an MMO is not the only way to cheat. Some MMOs have rules against plugins and helper tools. Those are also cheats. You can hack the client and display more in the minimap, or show you exactly how much HP some monster has, run a bot to control your character, etc. Doing everything on the server only prevents god-mode types of cheats. You can also cheat with extra information, computer assistance, etc.
cma 13y ago
UO was horribly broken in 1997. There was a program "UO Extreme" which let you fast walk, because the server didn't check. You could dye items glitched out colors, because the server didn't check that you chose a valid color from the dialog. You could reveal hidden people, because the server just tagged them with a "hidden" flag, instead of not sending their location at all.
- nousernamesleft 13y ago
  >There was a program "UO Extreme" Yeah, I know the guy who wrote it. >which let you fast walk No, it let you work around having a high latency dialup connection. All it did was watch for outgoing movement request packets and respond to them with OKs. The server was still checking though. So if you tried to move somewhere you couldn't, your client would see the OK from UOE, then later see the "nope" from the server and you would rebound back to where you were, and you would often get your client's idea of your position desynced from the servers, which was the one that actually mattered. >You could dye items glitched out colors, because the server didn't check that you chose a valid color from the dialog Yes, there were many bugs. Large and complex software has bugs. That bug was fixed. Which demonstrates exactly my point, that you can in fact do everything server side. >You could reveal hidden people, because the server just tagged them with a "hidden" flag, instead of not sending their location at all. Which packet sets the "hidden" flag again? http://necrotoolz.sourceforge.net/kairpacketguide/ http://necrotoolz.sourceforge.net/kairpacketguide/
  - cma 13y ago
    They fixed the hidden flag problem by just not sending the character; you used to be able to talk while hidden, and later talking would reveal you, because there wasn't a hidden mob to tie the text to. If I remember right there were actually two stages of the run hack in UO; in the first it was an advantage when the server itself was laggy and not just the client, later it was only an advantage for working around laggy connections and had severe rubberbanding and desyncing. And no, this can never be worked around solely on the server without resorting to something like OnLive. Another thing I didn't mention about UOE was it could make it always be daytime--how are you going to work around that on the server? As for which packet: http://necrotoolz.sourceforge.net/kairpacketguide/packet78.htm http://necrotoolz.sourceforge.net/kairpacketguide/packet78.h... which links to: http://necrotoolz.sourceforge.net/kairpacketguide/CS/mobilestatus.htm http://necrotoolz.sourceforge.net/kairpacketguide/CS/mobiles... Which has the status "hidden"

crazypyro 13y ago

WoW has a demanding enough latency requirement. Same with DotA 2. Not to mention the server resources used.

nousernamesleft 13y ago
>WoW has a demanding enough latency requirement And yet ultima online proved that excuse was bogus before WoW ever existed.

sehrope 13y ago

> It is faster paced games where you can't do everything server side that are the problem, first person shooters being the prime example. First person shooters can be (and I believe usually are) done server side. Official movement, firing, health, and overall physics is handled 100% on the server. To smooth things out though, the client interpolates its view of the world. For example lets say you fire your gun at a person right in front of you. The server would have final say of whether you actually hit the target. Rather than waiting for a round trip to the server, your client may choose to immediately show some blood/shrapnel effects to give you the illusion that you hit them. If you actually did, the server will handle the health deduction. If not, you probably wouldn't even notice.

TheLoneWolfling 13y ago
Right and wrong. Movement and such can be done server-side, mainly. But visibility pretty much has to be done client-side. Which means that people can hack the client to see through walls. You can do culling server-side to an extent, but not entirely - because otherwise someone with a high latency coming around a corner will have no chance against someone with low latency on the other side. Also, servers pretty much have to (well, not really. But otherwise games become unplayable to those with higher latencies, as where you see other players is not where you need to fire to hit them) allow you to hit someone that was, according to your client game tick, in target when you fired. Which means that the client has to tell the server what game "tick" the client fired on. Which allows for cheating if the client deliberately tells the server that it fired/started to move on an earlier tick than it actually did.
nousernamesleft 13y ago
First person shooters are split, part server and part client. For example, an enemy comes in range of you, your cheat automatically triggers a "shoot at the precise direction of their head" command to be send to the server. The server does not check if you were actually facing that direction, it does not check if you actually turned to face them in a manner that a human could. So things like aimbots are common where you literally click "next target" and it cycles through all the enemies heads. There is really no way to prevent this kind of cheating. Slower paced RPG style games where you just send "attack target with ability X" can be handled entirely server side. As we start seeing more fast paced action style MMOGs and fewer "computer reproduction of pen+paper+dice" style MMOGs the line gets blurred and more impossible to deal with cheats become problems.
- JoeAltmaier 13y ago
  But, but, you just said how to prevent it! "Check if you actually turned to face them..." would work just fine?
  - nousernamesleft 13y ago
    If you just check that they did face the right way, then cheating is still trivial. Just instantly turn and fire instead of just firing (this is what aimbots actually do anyways). The problem is you can't have the client send all 1000 "the mouse position changed" events to the server and have it approve them to ensure that you actually moved the mouse rather than just instantly changing to pointing straight at the enemy's head.
    - JoeAltmaier 13y ago
      Maybe stats on the behavior would work. You can tell who's typing on a keyboard by running stats on the inter-key delays etc. Probably stats on commands to the server (turn, fire delay etc) would identify bots pretty well.
    - Retric 13y ago
      You can't validate each mouse click before updating the client's view, but you can do the same aim validation as you do movement validation to prevent teleportation or excessive movement. Basicly, validating 1,000 motions a second is no problem it's latency that's the issue. So now you can still cheat but your limited to human reaction times or the server can detect and boot you.

Hacktivist 13y ago

The F2P game "Path of Exile" (similar to Diablo) does everything on the server and it causes so many problems that you need to avoid certain character skills that are more prone to causing desync issues between server and client. They even include a chat command that will sync you with the server which most people have macro'd to a key on their keyboard or mouse it's so prevalent.

nousernamesleft 13y ago
>The F2P game You've already explained a big chunk of the issue right there. There are many poorly written games. PoE is one of them. That doesn't mean you can't write a similar game well.

andypants 13y ago

> asking the server "is it legal for me to move to x,y,z?" These questions are not always straightforward. Why can't you do this in a shooter? Because any mouse position on the screen is valid. How do you know if the user physically moved the mouse or it was some other software that moved the mouse cursor? How do you know the user genuinely decided to aim at a random enemy, instead of relying on an on-screen display of player information that is not normally available? You can't do everything on the server side. If you could, it wouldn't be an interactive game.

nousernamesleft 13y ago
You might want to re-read my post. I specifically pointed out that shooters are the standard example of where you can't do everything server side, where as traditional MMOGs you can.
- andypants 13y ago
  I know, I was just building on your example of why it's difficult for shooters. And it's also difficult for many other games for similar reasons. Being able to directly set your position in an MMO is not the only way to cheat. Some MMOs have rules against plugins and helper tools. Those are also cheats. You can hack the client and display more in the minimap, or show you exactly how much HP some monster has, run a bot to control your character, etc. Doing everything on the server only prevents god-mode types of cheats. You can also cheat with extra information, computer assistance, etc.

cma 13y ago

UO was horribly broken in 1997. There was a program "UO Extreme" which let you fast walk, because the server didn't check. You could dye items glitched out colors, because the server didn't check that you chose a valid color from the dialog. You could reveal hidden people, because the server just tagged them with a "hidden" flag, instead of not sending their location at all.

nousernamesleft 13y ago
>There was a program "UO Extreme" Yeah, I know the guy who wrote it. >which let you fast walk No, it let you work around having a high latency dialup connection. All it did was watch for outgoing movement request packets and respond to them with OKs. The server was still checking though. So if you tried to move somewhere you couldn't, your client would see the OK from UOE, then later see the "nope" from the server and you would rebound back to where you were, and you would often get your client's idea of your position desynced from the servers, which was the one that actually mattered. >You could dye items glitched out colors, because the server didn't check that you chose a valid color from the dialog Yes, there were many bugs. Large and complex software has bugs. That bug was fixed. Which demonstrates exactly my point, that you can in fact do everything server side. >You could reveal hidden people, because the server just tagged them with a "hidden" flag, instead of not sending their location at all. Which packet sets the "hidden" flag again? http://necrotoolz.sourceforge.net/kairpacketguide/ http://necrotoolz.sourceforge.net/kairpacketguide/
- cma 13y ago
  They fixed the hidden flag problem by just not sending the character; you used to be able to talk while hidden, and later talking would reveal you, because there wasn't a hidden mob to tie the text to. If I remember right there were actually two stages of the run hack in UO; in the first it was an advantage when the server itself was laggy and not just the client, later it was only an advantage for working around laggy connections and had severe rubberbanding and desyncing. And no, this can never be worked around solely on the server without resorting to something like OnLive. Another thing I didn't mention about UOE was it could make it always be daytime--how are you going to work around that on the server? As for which packet: http://necrotoolz.sourceforge.net/kairpacketguide/packet78.htm http://necrotoolz.sourceforge.net/kairpacketguide/packet78.h... which links to: http://necrotoolz.sourceforge.net/kairpacketguide/CS/mobilestatus.htm http://necrotoolz.sourceforge.net/kairpacketguide/CS/mobiles... Which has the status "hidden"