1
\$\begingroup\$

With many games it is said that server will assume that clients keep track of the world accurately. Assuming this is true, for a browser based multiplier space invaders game you would only tell the client when new bullets or the players ship moves and everything that behaves in a predetermined manner in the js client.

It would be expected that positions would be the same in the browsers. Do you think you could trust browsers to do this? I feel that timings could differ between rendering loops and cause positions to get out of sync and might just get the server to maintain all the positions to make sure.

\$\endgroup\$
8
\$\begingroup\$

The server should maintain all the positions to "make sure" anyway -- this is how you prevent trivial cheating.

Most browsers have a "debug mode" they can be put into. It's trivial for me to hit F12 on my copy of IE, for example, and have access to a JS debugger I can use to halt execution, inspect variables, and change them. So you should be aware that a client could potentially do that.

Even without that sort of effort on the end-user's part, you shouldn't rely on your simulation being in exactly the same state at exactly the same time on all machines; that level of synchronization is basically improbable to achieve for real-time games, since you are dealing with the internet and all the latency involved, floating point inaccuracies, clock drifts, et cetera.

Most of the time things will be "good enough" that you can do what you are asking and send only the updates to the client, allow the clients to simulate locally (this is good, in fact, because it allows you to hide some of the latency and make your game feel better) but you should still simulate everything on the server and periodically ensure the client and server are in sync.

You should not trust client state, ever (not just for browser-based games either).

\$\endgroup\$
-1
\$\begingroup\$

Yes, it's fully possible to trust client state, and to mutate that state across all clients using only commands. (Whether or not that's a good idea with respect to security and cheat protection is another matter.)

Mark Terrano and Paul Bettner describe one such model in this article about Age of Empires multiplayer synchronization. Think of a game as a sequence of game states (or, better yet, a trajectory through the space of all possible game states) and imagine what's necessary to keep the trajectory of each client the same.

Again, this answer is not about trusting the browser or any other client environment from a security or cheating perspective. It's only about distributed state synchronization. From that perspective, you, the developer, can use a browser to design trustworthy client-side game state and iteration logic. Verifying that your client has not been tampered with is a different problem, but it is possible to synchronize state with the model you mention.

You have to write your game to execute with the following properties:

  • Each client must start with exactly the same initial condition, like a common seed state.
  • Each command (like new bullet or ship move left by 3) must change the game state in exactly the same way on each client. (This is called determinism and it's the essential part of "trusting" your code to behave identically on all clients.)
  • On each client, before applying a command, all previous commands from each client must already be received and applied in the same order on each client.

Things to be careful of, because they degrade determinism:

  • The same code can do strangely different things on different machines, whether it's JavaScript in Firefox vs. Chrome, or C++ in OS X vs. Windows. Same code + different behavior == nondeterministic program!
  • Floating point (decimal/fractional) numbers are dangerous, because they are more difficult to mutate deterministically.
  • Commands that use a random number generator should be seeded by the same number on each client, that way each client gets the same random number each time one is generated. In other words, random number generation needs to behave (you guessed it...) deterministically!

TLDR

  1. Make a deterministic system composed of game state and game commands.
  2. Make sure each client starts with the same state.
  3. Make sure each client applies the same commands in the same order as close to the same time as possible.
\$\endgroup\$
  • 1
    \$\begingroup\$ -1: if somebody can make a program that behaves incorrectly and sends incorrect data, then you cannot trust the client. Being able to trust the client means designing a game system where having complete knowledge of the game state and the communication protocol will give you no advantage over not having it. Perfect information games like chess can do this, but most online games are not perfect information, and therefore clients cannot be trusted. Also -1 for "client-server is more scalable than peer-to-peer"; I wonder whose behind you pulled that assertion out of. \$\endgroup\$ – Panda Pajama Jun 9 '14 at 4:07
  • 1
    \$\begingroup\$ Thanks for the feedback, @Panda. (Really!) Clarification: I didn't mean "trust the client" in the network security sense - maliciously constructed clients are outside the scope of my answer, because I don't think that what the question was about. I interpreted the question as asking, "Can a browser be used to construct a 'perfect information' game, and, therefore, only send commands instead of state?" (I appreciate your distinction between perfect and imperfect state for this.) My response is essentially saying, "If you're careful, yes. It's possible." Does this jive with you? \$\endgroup\$ – kdbanman Jun 9 '14 at 17:10
  • 1
    \$\begingroup\$ Wait, I googled "perfect information game" and I no longer understand why it matters. I thought it meant "deterministic," but that's not true. Can you explain why a player agent having perfect information changes client trust? (Also, I've removed my commentary on scalability.) \$\endgroup\$ – kdbanman Jun 9 '14 at 17:19
  • \$\begingroup\$ For the sake of illustration, consider a first person multiplayer shooter. The location of every player is a fundamental part of the gamestate, and hiding part of that information from the players is crucial for the correct working of the game, and there lies the dillema: if you share the state, you have to trust the program will not show where everybody is to the player, but if you calculate visibility on the server and only information that should be known by the players gets sent, then the entire real time action element is lost. \$\endgroup\$ – Panda Pajama Jun 9 '14 at 17:41
  • \$\begingroup\$ Same for shooting bullets: if you trust the clients will tell the server when they get a hit, the game may be more responsive, but you're leaving the decision to the client, which means that they may cheat by always saying they hit the target. A complicated dillema indeed. \$\endgroup\$ – Panda Pajama Jun 9 '14 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.