3 ms·

Yeah I know right. No wonder this game crashes. When you press the space bar it sends a message, when you move your mouse it sends a message. The message is in

by xana 11y ago

Yeah I know right. No wonder this game crashes. When you press the space bar it sends a message, when you move your mouse it sends a message. The message is in function U() (its the Y position, X position and some other value I've confirmed its not magnitude don't really know what it does). As soon as the connection is established it starts sending, although if you don't move the mouse it doesn't send a message. Then there is a message to update the players view of the game.

toxicFork 11y ago
I wasn't sarcastic! It's actually very good practice...
- xana 11y ago
  But wouldn't it be more efficient to calculate the velocity on the client side then only send changes to the vector?
  - toxicFork 11y ago
    It may be more efficient. But sometimes you should not trust the client ;)
  - IkmoIkmo 11y ago
    Absolutely, I'm still waiting for my bank to let me modify the money in my account client-side, that way they'll have to do a lot less computing! I swear I'll never send the server anything dishonest, like say owning a billion dollars. :)
    - deleted 11y ago
      [deleted]
      - SCHiM 11y ago
        But then you'd still be computing the velocity on the server side, only now you're checking if the reported velocity is legitimate or not.
        IkmoIkmo 11y ago
        Exactly. Client-side computing exists, but only to present a fake state which doesn't affect the game mechanics but only servers a cosmetic function to bridge the time until the server updates the client with the actual data (on which any essential game mechanics are based). Games typically just send keyboard input to the server, simulate the game as best they can, and receive the state of the game as it 'really' is. Just like you can't change your money on your bank account, but you can send instructions to send money (keyboard input), and your client-side app will likely immediately update your balance even if it's not fully processed yet by the server. Beyond that, computing vectors of a few players isn't really a big deal for a server, with 20 players you're really running a relatively simple simulation without any rendering. Data on the network is the bottleneck. And it's far more efficient to send e.g. a 'player pressed Forward' on second 0, and 'player released Forward' on second 8. That's two messages, as opposed to a 30-60 frames per second update on the player's position. So for security and performance, it's usually not that great of an idea for clients to do all that much computing. One day we might even see rendering happen serverside, too, OnLive got it to work pretty well at low-res but it was far from optimal. (they shut down btw)
learnstats2 11y ago
How could you do better than that? It's a real-time game; it needs that much input data (but nothing else).

by xana 11y ago

toxicFork 11y ago

I wasn't sarcastic! It's actually very good practice...

xana 11y ago
But wouldn't it be more efficient to calculate the velocity on the client side then only send changes to the vector?
- toxicFork 11y ago
  It may be more efficient. But sometimes you should not trust the client ;)
- IkmoIkmo 11y ago
  Absolutely, I'm still waiting for my bank to let me modify the money in my account client-side, that way they'll have to do a lot less computing! I swear I'll never send the server anything dishonest, like say owning a billion dollars. :)
  - deleted 11y ago
    [deleted]
    - SCHiM 11y ago
      But then you'd still be computing the velocity on the server side, only now you're checking if the reported velocity is legitimate or not.
      - IkmoIkmo 11y ago
        Exactly. Client-side computing exists, but only to present a fake state which doesn't affect the game mechanics but only servers a cosmetic function to bridge the time until the server updates the client with the actual data (on which any essential game mechanics are based). Games typically just send keyboard input to the server, simulate the game as best they can, and receive the state of the game as it 'really' is. Just like you can't change your money on your bank account, but you can send instructions to send money (keyboard input), and your client-side app will likely immediately update your balance even if it's not fully processed yet by the server. Beyond that, computing vectors of a few players isn't really a big deal for a server, with 20 players you're really running a relatively simple simulation without any rendering. Data on the network is the bottleneck. And it's far more efficient to send e.g. a 'player pressed Forward' on second 0, and 'player released Forward' on second 8. That's two messages, as opposed to a 30-60 frames per second update on the player's position. So for security and performance, it's usually not that great of an idea for clients to do all that much computing. One day we might even see rendering happen serverside, too, OnLive got it to work pretty well at low-res but it was far from optimal. (they shut down btw)

learnstats2 11y ago

How could you do better than that? It's a real-time game; it needs that much input data (but nothing else).