Like a little kid, I am Fascinated when people talk over my head. I can almost-Almost grasp the significance of the discussion. It doesn't bother me, though, because it's interesting!
Its not that complicated. Its just the technical short hand that makes it opaque. Like talking about testing arcanatime chains on pylons, that means something to (some) City of Heroes players, and no one else.
For example, I'm pretty much decided to go with client-side key state engines and translated key state combo messages. What the heck does that mean?
Pretty much everyone who ever learns programming learns a useful lie. We're taught or learn that the keyboard is an electronic typewriter that records the keys people type on it, and we can read those keys with some lines of code in our favorite language. So the user types "a s d f" and when we read the keyboard, we read an "a" and then an "s" and so forth. Its a convenient lie that radically simplifies using keyboards, and it works 90% of the time.
Then we all get the bright idea to write a game. Probably a simple game, maybe even something not even a game, just something where we input stuff and then stuff happens. Maybe we move a dot around on the screen. Maybe that dot leaves a trail behind. Maybe we check to see if the dot moves into a spot that already has a trail. And that's how we write a Tron lightcycle game. In any case, at some point we write something that stops treating the keyboard like a typewriter, and more like a game pad. We want the user to press the "a" and hold it down to go left, press and hold the "d" to go right, and maybe press the space bar to shoot something. And that's when we discover our convenient lie is not so convenient anymore.
We read the keyboard like we always did, and when the user holds down the "a" we get a stream of "a"s. So far so good, but when the user releases the "a" we still keep getting "a"s for a while. That's because the keyboard buffer is holding some "a"s it read from the player that we didn't use yet. That's not so good. Also, when the player holds down the "a" we probably notice that first we get an "a" and then for a while we get nothing. And then, after a delay, we start getting more "a"s. That's because of something called key repeat delay. When you are typing, you aren't pressing keys instantaneously. You are pressing them and holding them down for a split second. But to the computer, that's an eternity. The computer is so fast, it needs to make some assumptions and one of them is that normally when you are typing, it should treat a key press for a certain short length of time as a single keystroke. That's so that when you are typing, tttttthhhhhhiiiiiissssssss dddddooooooooeeessssnnnnn'''''tttt hhhaaaaaaaaapppppppppppppeeennnnnnnnnn. But in a game, that same behavior would cause your game to see a single "a" as a quick move to the left, followed by a pause where nothing happens even though the player is still holding down the key, and then a bunch of "a"s you interpret as moving to the left, and then when the player wants to stop and they release the key they will still move to the left for a while because your program is still reading "a"s.
Worse, suppose you hold down "a" and then press down on the space bar. Maybe that's a strafe left: keep moving left and also fire. When your program reads the keyboard, in most languages what you'll see is a stream of "a"s and then a stream of "space"s. When the space bar is pressed, you'll only see that, even though "a" is still being pressed. That's because the program code you're using assumes the keyboard shoots out whatever
key is being pressed, and cannot report two keys being pressed simultaneously. So it reports the last one pressed. You'll never see "a space a space a space" or anything like that, so you cannot tell what the player is actually doing. And certain other things like function keys or shift keys have similar problems: you won't know which one is pressed, because you'll only see what the program code thinks those keys do. Whether you hold the left shift or the right shift or CAPSLOCK is down, when you hit the letter "a" you'll get a capital "A" and that's it. You'll never know *why* you got a capital "A". And if CAPSLOCK is down *and* you hold down shift? You'll get a lower case "a" even though the user is in fact holding down the shift key. Oops.
This is a pain, and its because you're using a programming library that is making life easy for you by reading the keyboard for you, and letting you pretend its a typewriter. Its not. Its actually a more complex input device, and you could read it "raw" so to speak. For that, you need to learn how your particular language (and operating system and environment) allow you to do so. For most modern OSs, it comes down to keypress events. In the background,
something (your OS, some library function, some piece of software you normally don't have to worry about) is constantly reading the keyboard, waiting for something to happen. For our purposes, two things can happen we care about. The keyboard can say "this key is now pressed down" and "this key was down but now its back up again." Key Down, and Key Up. Now, we can see *exactly* what's going on at the keyboard, and now we can write games that use the keyboard as a game controller. When the user presses "a" we see that immediately. When they let go, we see that immediately. What if the user holds down A and then presses SPACE? We'd see a Key Down for A, and then a Key Down for SPACE. We would know the user was holding both keys down because we never saw him release the A.
This is great, but it comes at a cost. You have to keep track of what's going on yourself. Right now, at this moment, which keys are being pressed and which are not? If you lose an event like a Key Down, you'll miss the fact the user is pressing that key. You aren't going to get another Key Down event unless he lets go and presses again. And if your game mixes up controls and typing, you have to figure out when the player wants to move left, and when he wants to type an "a" and not "aaaaaaaaaaaa".
That's why we all learn the lie first. Its a pain to keep track of Key Up and Key Down and how long did the user hold that key down did he want to give us a stream of letters or only one? The lie does the work for us. But when you're writing a game with real time input, you usually have to throw the lie away, and do the work yourself.
And that's how keyboards work (basically). Not complicated really. But the first time you run into the problem as a programmer, its usually a pain. And when you are dealing with networking, the threat of losing an event and losing track of what's happening at the keyboard becomes more of a reality. Unless your computer is crappy or really overloaded, that's rarely if ever going to happen on your PC directly. But when you have to send that stuff over the internet, anything can happen. So its probably better to keep track of what's going on at the PC itself, and send the actual state of which keys the player is holding down to the server so the server can never lose track. You just have to do it efficiently.
