3 ms·

Another problem that needs to be handled is how to keep the source code secret. For open source/free games this isn't a huge concern, but for a triple-A company

Another problem that needs to be handled is how to keep the source code secret. For open source/free games this isn't a huge concern, but for a triple-A company, or a company making a multiplayer game, keeping the source code out of those haxxors hands is important. For a browser based game can we do much besides simply obfuscating the javascript? If people can pick apart obfuscated assembly code, js will be a piece of cake. And for multiplayer games, how will a company detect a modified client? Short of issuing a browser plugin there isn't access to the low level so a Warden type program like the one Blizzard uses for WoW won't be workable. I'm not saying these are impossible problems to solve, but I don't think they're going to be trivial. Hopefully I'm wrong though :)

kevingadd 14y ago
You can't do it. Don't bother trying. It's at least less impossible in Native Client, but the verifier means that you can only obfuscate so much. Ultimately the winning model here (that most games with serious competition end up taking, to some degree) is to never trust the client, at all, with anything. Everything remotely important is the domain of the server and the client is basically a dumb renderer that only has the minimum amount of information necessary to play the game. This does have some unfortunate consequences for latency and responsiveness, but people tend to hate cheating more than lag. Sometimes you can find domains where cheating is okay in exchange for better responsiveness, but then it creeps into your design and causes issues. World of Warcraft, for example, trusts the client to handle pathing and movement logic in order to create the illusion of low-latency, super smooth motion. As a result there are a litany of clever exploits that utilized this to break important game systems or acquire subtle advantages over others. For example, a locked door in a dungeon obviously is going to be impassable to players, right? What do you mean they teleported through it?
- shasta 14y ago
  World of Warcraft, for example, trusts the client to handle pathing and movement logic in order to create the illusion of low-latency, super smooth motion. There is a simple solution: Trust but verify. The main reasons not to check that your clients aren't cheating are code complexity and the server processing required.
  - kevingadd 14y ago
    Well, there's a reason why there are games (DOTA 2, for one modern example I'm certain about) that don't do 'trust but verify': sometimes if you verify, you will find that the client is wrong, in a way that probably just means they are innocently desynced, but might mean they're cheating, and it's hard to tell the difference. Worse still, those minor desyncs end up causing major gameplay differences that make the player feel like your netcode is terrible. Textbook example of the latter: Playing a melee class in Diablo 3. Rubber-banding and teleporting everywhere, getting killed by things you can't see or that are on the other side of the screen, etc: http://www.youtube.com/watch?v=CFw6MYqUyKs#t=0m15s http://www.youtube.com/watch?v=CFw6MYqUyKs#t=0m15s I do wish 'trust but verify' worked at scale though. It feels like one of those brilliant technology solutions that lets you beat the competitor on server costs. :D
    - shasta 14y ago
      AFAIK, the primary reasons are the ones that I gave. Synchronization of client and server can be achieved at scale -- just look at every multiplayer RTS -- it's just expensive to do on top of an FPS client-server architecture because you have to simulate every client on the server.
    - Negitivefrags 14y ago
      Trust but verify is absolutely the way that games using client side movement prediction work, and games without client side movement prediction feel terrible to play. World of Warcraft has problems because they don't do much of the verify part. The kind of problems you are seeing in this Diablo 3 video are avoidable, and solving those kinds of problems are essential to making a networked game.
- jfoutz 14y ago
  Ths is one of the beautiful things about eval in a browser/node.js combo. You can give each client a unique implementation of the communication api. so trivially, you can rename and reorder functions. more significantly, if you have an orthogonal set of operations, each client can can have a unique set of functions that are compositions of those operations. And if you're nervous about a specific client, you can just re-eval your communication api. Unhackable? no. but you have some options about what to do to a client you're not finding very trustworthy.
biot 14y ago
There's always the OnLive model, something which many thought wouldn't be possible. A browser game could be little more than a canvas tag to which pixels are streamed with input events being sent back to the server.

kevingadd 14y ago

You can't do it. Don't bother trying. It's at least less impossible in Native Client, but the verifier means that you can only obfuscate so much. Ultimately the winning model here (that most games with serious competition end up taking, to some degree) is to never trust the client, at all, with anything. Everything remotely important is the domain of the server and the client is basically a dumb renderer that only has the minimum amount of information necessary to play the game. This does have some unfortunate consequences for latency and responsiveness, but people tend to hate cheating more than lag. Sometimes you can find domains where cheating is okay in exchange for better responsiveness, but then it creeps into your design and causes issues. World of Warcraft, for example, trusts the client to handle pathing and movement logic in order to create the illusion of low-latency, super smooth motion. As a result there are a litany of clever exploits that utilized this to break important game systems or acquire subtle advantages over others. For example, a locked door in a dungeon obviously is going to be impassable to players, right? What do you mean they teleported through it?

shasta 14y ago
World of Warcraft, for example, trusts the client to handle pathing and movement logic in order to create the illusion of low-latency, super smooth motion. There is a simple solution: Trust but verify. The main reasons not to check that your clients aren't cheating are code complexity and the server processing required.
- kevingadd 14y ago
  Well, there's a reason why there are games (DOTA 2, for one modern example I'm certain about) that don't do 'trust but verify': sometimes if you verify, you will find that the client is wrong, in a way that probably just means they are innocently desynced, but might mean they're cheating, and it's hard to tell the difference. Worse still, those minor desyncs end up causing major gameplay differences that make the player feel like your netcode is terrible. Textbook example of the latter: Playing a melee class in Diablo 3. Rubber-banding and teleporting everywhere, getting killed by things you can't see or that are on the other side of the screen, etc: http://www.youtube.com/watch?v=CFw6MYqUyKs#t=0m15s http://www.youtube.com/watch?v=CFw6MYqUyKs#t=0m15s I do wish 'trust but verify' worked at scale though. It feels like one of those brilliant technology solutions that lets you beat the competitor on server costs. :D
  - shasta 14y ago
    AFAIK, the primary reasons are the ones that I gave. Synchronization of client and server can be achieved at scale -- just look at every multiplayer RTS -- it's just expensive to do on top of an FPS client-server architecture because you have to simulate every client on the server.
  - Negitivefrags 14y ago
    Trust but verify is absolutely the way that games using client side movement prediction work, and games without client side movement prediction feel terrible to play. World of Warcraft has problems because they don't do much of the verify part. The kind of problems you are seeing in this Diablo 3 video are avoidable, and solving those kinds of problems are essential to making a networked game.
jfoutz 14y ago
Ths is one of the beautiful things about eval in a browser/node.js combo. You can give each client a unique implementation of the communication api. so trivially, you can rename and reorder functions. more significantly, if you have an orthogonal set of operations, each client can can have a unique set of functions that are compositions of those operations. And if you're nervous about a specific client, you can just re-eval your communication api. Unhackable? no. but you have some options about what to do to a client you're not finding very trustworthy.

biot 14y ago

There's always the OnLive model, something which many thought wouldn't be possible. A browser game could be little more than a canvas tag to which pixels are streamed with input events being sent back to the server.