I should amplify a bit. Why is sending inputs instead of position information not an interesting innovation? Because it has to do with trust. Everyone who writes client-server networked gaming eventually and usually pretty quickly has to address the question of hacking and cheating. The question is can you trust the client? And the answer is: no, absolutely not. If you let the client send you the position of the player, you're allowing anyone with a debugger or modding tool to teleport anywhere in the game instantly. Not good. You could try to validate positions, but how do you determine every possible way a player might get to a location, to determine if they didn't get there legally? You basically have to figure out every possible way to move, check to see what those methods do, and see if the position falls into one of them.
Anyone with a brain quickly realizes that rather than write a server that tries to figure out what the player did, its way simpler to just tell the server what the player did. Then the server doesn't have to figure out if there's a set of inputs the player could generate that can create a particular result. It just determines what the result of the transmitted inputs are. But that creates a new problem. The straight forward thing to do is to let the client tell the server "I moved forward," have the server figure out where that places the player in one game tick, and then transmit that new location to the client. Then the client moves the player. The problem is network and server lag: the time between when the client transmits that movement input, and when it gets the result back and displays it to the player. This can be long in gaming terms: dozens, possibly hundreds of milliseconds. When what you do is decoupled from what you see by more than about 50 milliseconds, human beings start to perceive a wrongness in what's happening: they perceive lagginess.
Since the client knows what the player wants to do immediately, the client could just do it. But again, we get to trust: how can we let the client do that, when we don't know if that's actually a legal move? We decide to presume the player isn't cheating - if he or she is, then it doesn't matter what bad thing happens so long as it doesn't affect anyone else. In the case where the player isn't cheating, we want to minimize the effects of lag on how they perceive the game. They don't actually *know* when anyone else does anything else, so they can't generally perceive a lag between when someone else does something and when they see it. They can only experience this with regard to their own controls. Since their client has those inputs, we can program the client to predict what should happen when the user uses those controls. They move forward, we move their character forward and then tell the server the player moved forward. The server also moves the player forward, and retroactively tells the client what that should have done. If that is what the client predicted, the client simply continues on. If the server disagrees with what the client predicted, the client revokes the prediction, in effect undoing it and altering the actions to what the server tells it. So long as the client predicts well, such corrections will be few and far between - what we would call rubberbanding.
Prediction allows us to take player inputs and display the result of those inputs immediately so they see them without delay, while still making the server the final authority on what happens. For this to work, what the client predicts must be essentially exactly what the server would ordinarily allow. For that reason, both the client and the server must check boundaries and geometry. Since the client is going to allow you to move in any direction before the server validates that move, the client must be at least generally aware of where the player can and cannot move based on geometry. Otherwise, players would walk through walls then rubberband bounce out of them regularly. Conversely, anything that pretends to be a server must validate geometry in exactly the way the client expects it do, or prediction won't work right.
Some things you just can't predict, or more precisely you can't allow the client to predict, like combat. So when you shoot something, that goes to the server, the server decides what's going to happen, and the client shows the results of that. That's one reason why attacks could not reasonably execute faster than a certain time: the activation time and attack animation were in part covering for round trip lag to and from the combat engine in the mapserver. And once you understand how this works, you start to see prediction failures in every MMO you play. When I'm playing STO, I often see a "multiple fire effect" when I shoot torpedoes at a target I'm turning to bear on. Basically, torpedoes only fire in a forward arc of about 90 degrees. If the target is moving quickly right to left or vice versa, and you're turning to face them, you can shoot only if they are inside that arc. But sometimes when you hit the button to fire a visual torp firing happens, then vanishes, then it happens again, then it vanishes, then it happens again, and this time the torpedo flies to the target. What's almost certainly happening is that the client sees the target is inside my arc, but remember *I* am pointing where the client thinks I should be pointing *now* but the server doesn't know that yet. So the client starts the torpedo animation and FX predicting I should be able to do that. But by the time the server gets my inputs, in that split second the target has moved slightly, and now its *not* in my firing arc. So the server says "nope, can't shoot yet" and the client revokes the attack. Then it tries again, and again, until finally the server says "I agree, that torp can fire" and the attack continues on without being revoked.
CoH devs on a couple of occasions said we moved basically as fast as the game allowed us to move. Many players didn't understand what that meant. What I believe they meant was that if we moved significantly faster than the maximum speeds we were currently capped at, the client-side prediction would start to break down in combat and other areas, and we would start seeing the "oops torpedo" effect I'm describing in STO, only worse.
In any case, sending inputs is the first thing you learn about client-server gaming. Its primary purpose isn't to reduce bandwidth, its to make sure you can validate what the client is telling you to do (in fact, you should probably periodically send positional information from server to client and/or vice versa anyway as a double check to confirm you're in sync with each other). It is prediction, and the specifics of how you implement it to get the very best apparent performance combined with the least amount of synchronization problems, that is the real magic. And everyone does this a little (or a lot) differently.
