Oh, it was bad. It was bad bad bad.
Well, I don't disagree: that was was a predicate in my own observation. But without some kind of empirical reference point--the code itself or testing against some sort of benchmark beyond how it inutitively feels--I don't know if we can properly attribute it to net code. The best we have are side-by-side today, like you describe:
It isn't that long ago I randomly played some SC4, SC5 and SC6 against the same friend. SC4 feels absolutely atrocious compared to 5 and 6.
I can't say as I have had exactly the same experience. I will say that the last time I was in a position to do some comparing was about a year and a half back. Up until that time, I had been playing both games semi-regularly with a couple of friends since their respectively releases. At that point, I felt that SCIV was just as reliable as SCV, provided I played only with those regular friends who had decent connection. Both games were a bit of a nightmare with regard to getting randomly matched for ranked (a situation which has continued until today, and worsened further by lackluster matchmaking). Unfortunately, I can't do a side-by-side today, much as I'd like to, as the only machine I own a copy of both for is the 360, and I let my gold live account expire a while back. But if we have such radically different impressionistic takes, we're back at square one, without a better test.
And again, I can only endorse what a shit show it was back in the day, including the specific detail about Kilik and armies of spammy scrubs turning the situation tedious by using the disrupted action/reduced reaction windows to try to abuse any speedy sweep or high-low-high. Not unlike today with RE abuse by nitwits with potato router connections. But I'm not sure how much of it we can lay at the feet of the netcode is all, and I swear that as time went on, the situation got better, provided that I played with the same reliable people. Now, you might argue that part of what good netcode should do is mitigate artifacts of latency at the lower end of viable bandwidth to the extent it can, and I honestly don't know how well the code holds up there. But for purposes of maintaining a reasonably smooth frame rate for higher level play between good connections, even thousands of miles away along the backbone, it did the trick for me. But like you, I'd really like to see it.
And I'd say 5 and 6 feel more or less the same netcode-wise.
Can you be more specific about what you mean by "netcode-wise"? How are you controlling for other factors which could explain any differentials between inputs and a state outputted by the client? For that matter, how are you judging the timing of the inputs for reference to everything else? If its just your own sense of timing, I don't mean to dismiss that entirely: you've played these games for some time, so I am sure your perception is not to be completely ignored, but I think we both know that it's not a great measure for these kinds of determinations either.
It was bad back in 2008 as well. There were certainly many other games which struggled with bad netcode back in those days, but a lot of games got it right too.
Granted. But there was also a lot of variability in which games' communities included a higher portion of the hardcore, and who thus took their connections seriously. There's also, as you indirectly referenced above, the variation that comes with different platforms. I'm not saying your wrong about the netcode, particularly as it bore out in ranked as a practical matter, just that I don't think we have strong enough evidence that i would personally feel comfortable saying it is definitely the netcode that was responsible for the lion's share of the issues with SCIV. It's a perfectly plausible explanation, but I just don't feel confirmed in it.
I would love to see the actual code for SC4, because I don't understand how they messed it up so badly. 4, 5, and 6 are all using the same type of netcode. Each client waits for input from both players before it continues the game simulation. This means the input lag will be roughly half of your ping to the opponent (a ping is the time it takes for a network packet to reach a client and return back to you). As long as the game simulation is completely deterministic this is the easiest netcode to implement for any game.
I'm with you on all of this.
But somehow SC4 has a much higher input lag than you'd expect. My only guess is that they did some kind of packet verification where it waits for confirmation from both clients that they've received the input for the current frame, resulting in input lag 2 to 3 times higher than it should be.
That would be a pretty big blunder, even near the inception of the online fighting game market. That would serve no real pragmatic purpose with the kind of system you describe. It would also create a noticeable latency effect over even good connections, and I definitely know I played thousands of matches on that game that ran relatively smoothly.
Or maybe the game uses TCP rather than UDP for its netcode (TCP has more overhead than UDP), but I would assume all of Xbox used UDP for online play as that's naturally better for gaming. Whatever the reason is, I'm still bitter about the whole thing.
Well, one would expect not just UDP but also custom protocols for a game today. At the time, I think it was probably still more of a mix of UDP and TCP depending on functions, rather than overwhelmingly UDP as in games today. But I honestly don't know: that kind of detail of the state of netcode at that moment in time for the industry is beyond my firsthand knowledge.
I'm basically Nyte when it comes to this. Challenge fan service and you'll get hit over the head with a cushion by Nyte. Show me bad netcode and I'll hit you over the head with Nyte.
Hahaha, NyteStick, coming to an Injustice 3 DLC, soon!
