Rob's Log - December 15, 1998
Well, since I’ve yet to post any information on this thing, I guess it’s
about time to let you guys in on some of the things I’ve been working on.
Mostly, I’ve lately been working on the networking code and getting it to
work nicely with our scripting language. My basic plan is to get all
rudimentary fighter control and every type of basic move (controllable
projectile, standard attack, throw, etc.) working and sequenced over a
network as best it can and then I can consider the basic network and
script design as "solid".
Getting the networking system working from the ground up was pretty difficult, but predictably so. In other words, so far I don’t feel the networking was any easier or harder than I’d originally thought, it was tough and challenging at first, but some things started to fall into place nicely as things went on. It’s still pretty unclean as far as connecting and leaving a server, but it’s looking pretty promising.
Now, I’ll explain a little of the technical aspects of the networking. The basic networking philosophy is quite different than, say, Quake2. In Quake2, when an action takes place, say firing the rail-gun, the client sends the firing info to the server, the server sends back kindof an "authorization" that the firing took place and then you see the blast happen. The problem with this is that your gun fire doesn’t really happen until a certain amount of time has passed (your ping). They’ve done a fantastic job masking and working around these limitations and produced a very fun experience though.
With our system, in contrast, when you press an attack button the client starts attacking immediately, and message is sent to the server saying that an attack was performed at the specified time. When the server receives this message, things get interesting. The client will already be performing the move that the server has not yet authorized. So, the server will "rewind" the worlds time to the point that the client started attacking and let the attack happen, then send these changes to all other players. Therefore, as long as the client doesn’t need to be corrected (explained later) the fighter movement and all actions happen immediately, and the difference between controlling your fighter in a network game and a local game are no different. Now, this is great and dandy, but it comes at a price, and here’s the downside...
Let’s say player A attacks player B and player B attacks player A, slightly after player A’s attack. Now, if they have the same ping, say 300, then the server is going to get notified that player A attacked 150ms ago, he’ll rewind time and finds out that player A hit player B. At that point, the server will send the message to player B notifying him that he was smacked and should react accordingly. In a few milliseconds, the server will receive the message that player B attacked. Now, the server will have to throw out the fact that player B even attacked at all, because he’s in the process of being hit. So, after player B receives the getting hit message, he’ll start reeling from the attack. The only big problem here is that player B will get a pretty big "snap" in the visuals, because he’s going to see his player get hit half a ping after he actually got hit (150ms) and it may be somewhat difficult to mentally adjust to these rather harsh corrections. Also, even without correction you are going to see other players updated after the sum of half your ping and half their ping has passed, therefore on high pings you may see opponents "snap" a bit.
Another disadvantage is the amount of processing time it’ll take to rewind and replay time every time a network message is received (well, not exactly every message). Right now, we haven’t tested too many fighters in the arena, but the cost is negligible, but in the future with, say 16 players (too many for my liking, but others may dig it), high ping times will create much replaying of world time, so it could get somewhat expensive.
Also, and this is a good and bad thing, our system requires that the designer actively tell the system when he wants to update the server and/or clients. IOW, when you start running forward you’d have a line of code in the script that essentially says "I’m doing something important here, update whoever wants to know". This places a tremendous responsibility on whoever is making a fighter, but it also allows updates to suck less bandwidth (you can send information relative to that specific "move" or state change) and you can trigger the sending of this information at key points in the game.
However, there’s really no question in my mind that this networking scenario is the way to go, especially for us. Essentially, doing combos while waiting for the server to authorize each attack would make for a less than stellar experience (if you’ve played OMF:2097 over a modem you’ve had a taste of what that’d be like). Also, I think that being a high ping player will not be quite the crippling disadvantage it is in most network games. Since your control is not often hampered by your ping, it won’t hurt as much. Don’t get me wrong, having a low ping will ALWAYS give you an advantage, in any networking system (unless low pingers were actively crippled, which would be phenomenally stupid), just hopefully not that bad in this one.
Well, that’s it for now. BTW, I’m going to try to update this thing as often as possible, but I make no promises.
Getting the networking system working from the ground up was pretty difficult, but predictably so. In other words, so far I don’t feel the networking was any easier or harder than I’d originally thought, it was tough and challenging at first, but some things started to fall into place nicely as things went on. It’s still pretty unclean as far as connecting and leaving a server, but it’s looking pretty promising.
Now, I’ll explain a little of the technical aspects of the networking. The basic networking philosophy is quite different than, say, Quake2. In Quake2, when an action takes place, say firing the rail-gun, the client sends the firing info to the server, the server sends back kindof an "authorization" that the firing took place and then you see the blast happen. The problem with this is that your gun fire doesn’t really happen until a certain amount of time has passed (your ping). They’ve done a fantastic job masking and working around these limitations and produced a very fun experience though.
With our system, in contrast, when you press an attack button the client starts attacking immediately, and message is sent to the server saying that an attack was performed at the specified time. When the server receives this message, things get interesting. The client will already be performing the move that the server has not yet authorized. So, the server will "rewind" the worlds time to the point that the client started attacking and let the attack happen, then send these changes to all other players. Therefore, as long as the client doesn’t need to be corrected (explained later) the fighter movement and all actions happen immediately, and the difference between controlling your fighter in a network game and a local game are no different. Now, this is great and dandy, but it comes at a price, and here’s the downside...
Let’s say player A attacks player B and player B attacks player A, slightly after player A’s attack. Now, if they have the same ping, say 300, then the server is going to get notified that player A attacked 150ms ago, he’ll rewind time and finds out that player A hit player B. At that point, the server will send the message to player B notifying him that he was smacked and should react accordingly. In a few milliseconds, the server will receive the message that player B attacked. Now, the server will have to throw out the fact that player B even attacked at all, because he’s in the process of being hit. So, after player B receives the getting hit message, he’ll start reeling from the attack. The only big problem here is that player B will get a pretty big "snap" in the visuals, because he’s going to see his player get hit half a ping after he actually got hit (150ms) and it may be somewhat difficult to mentally adjust to these rather harsh corrections. Also, even without correction you are going to see other players updated after the sum of half your ping and half their ping has passed, therefore on high pings you may see opponents "snap" a bit.
Another disadvantage is the amount of processing time it’ll take to rewind and replay time every time a network message is received (well, not exactly every message). Right now, we haven’t tested too many fighters in the arena, but the cost is negligible, but in the future with, say 16 players (too many for my liking, but others may dig it), high ping times will create much replaying of world time, so it could get somewhat expensive.
Also, and this is a good and bad thing, our system requires that the designer actively tell the system when he wants to update the server and/or clients. IOW, when you start running forward you’d have a line of code in the script that essentially says "I’m doing something important here, update whoever wants to know". This places a tremendous responsibility on whoever is making a fighter, but it also allows updates to suck less bandwidth (you can send information relative to that specific "move" or state change) and you can trigger the sending of this information at key points in the game.
However, there’s really no question in my mind that this networking scenario is the way to go, especially for us. Essentially, doing combos while waiting for the server to authorize each attack would make for a less than stellar experience (if you’ve played OMF:2097 over a modem you’ve had a taste of what that’d be like). Also, I think that being a high ping player will not be quite the crippling disadvantage it is in most network games. Since your control is not often hampered by your ping, it won’t hurt as much. Don’t get me wrong, having a low ping will ALWAYS give you an advantage, in any networking system (unless low pingers were actively crippled, which would be phenomenally stupid), just hopefully not that bad in this one.
Well, that’s it for now. BTW, I’m going to try to update this thing as often as possible, but I make no promises.