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)