I play fighting game for some time now. I’ve been through many of them and there’s still one thing I do not understand.
How a game like Tekken Revolution with those tasty graphics and 3D model can provide an almost perfect solid netcode, while game like 3SOE and other sprite based game struggle so hard with online experience ?
Regarding online, aren’t 3D model game supposed to be heavier to support than sprite based game ?
Uh… 3SOE’s netcode is pretty solid since it uses GGPO.
IIRC Tekken has a button buffer system so even if you fight in lag you might not realize it. Try frame punishing tight windows with an f,f move and you’ll feel every small delay…
Do you play it ? I am on ps3, I never had one small problem with SF4 nor Tekken TAG 2 netcode. But from my experience 3SOE is awefull online. I can not get any proper match.
Graphics have nothing to do with netcode. There is no correlation.
LMAO, SF4 netcode is godawful, my guess is that you think that there is not lag because there is no rollback happening.
Truth be told, 3soe has the better netcode of the 4 games that you mentioned, if you are not noticing lag is more probable that is something akin of what Tataki said, those games hide the lag with input lag which is 100 times worse than having a rollback in may instances.
Indeed, if the game is sending graphics data through the netcode there is a serious problem going on
If you’re not noticing the lag, or are bothered by the rollbacks in the 3SOE system, then you probably don’t understand what’s important in fighting game netcode. At low levels, stuff like SFI, TTT2, etc. is fine since casuals probably don’t notice or care too much about the timing of stuff changing due to fluctations in latency. When you’re trying to play at a higher level and want the online experience to be as close to offline as possible, then you’ll need rollback netcode (like the GGPO implementation in 3SOE) where the delay (which you set yourself) is fixed and the system simply allows the game to desync during any fluctations in latency, rolling back to the last fair state afterwards.
For more info, it’s best to read up on it via these articles.
http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking/
http://skullgirls.com/2011/09/skullgirls-ggpo-and-you/
http://evo.shoryuken.com/2012/08/24/game-developer-magazine-ggpo-technical-deep-dive/
Well, for starters, the graphics don’t really play a role in netcode (or more precisely, don’t need to in anything but brain-dead implementations). What netcode sends and receive is the inputs. It’s litterally like plugging a cable from your controller to the opponent’s machine and vice versa and have them start the exact same match (which can be a bit tricky in itself), so the same inputs will provide the same results. Then all of the netcode difficulties are in dealing with the fact the metaphorical cable is so long the inputs arrive late or occasionally not at all.
The brilliance in only having to send inputs is then the network load is the same no matter the kind of game. Controlling a team instead of just one character? No problem, that’s still only one controller.
All this happens on a gameplay “layer”, so to speak. The graphics layer, if you follow good development practices, is separate from that and can be run independently. That’s how you can do things like skipping frames if your rendering’s too slow, that’s the graphics layer updating less often that the gameplay one.
As I said, there are three aspects to netcode: starting the same match, dealing with late inputs, dealing with lost inputs (there’s one or two more things but let’s leave them aside).
Not starting the same match or losing input will cause desync, ie both player’s versions of the match giving different results. There are ways of detecting it but in fighting games usually no way of correcting it so you just drop the match (in client-server games like FPS the server serves as a referree and “his” game is always the true one. If you start to deviate, you just get the server’s version), instead you do many things to prevent it. Notably, protection against loss is to ask again for a lost input and/or always send redundant inputs . That basically turns lost inputs into inputs arriving late, and so shifts them to the remaining problem.
Inputs arriving late cause lag: you have to wait for the second player, freezing the game until the input arrives. To prevent that, there’s two things you can do: run the gameplay a few frames behind (so inputs arriving late will still arrive in time) or run it normally but rewind each time you receive a late input so you reapply the input retroactively (the rollback). You can combine them, running late so there are less rollbacks. Then you want to hide all that from the player -that’s the real trick. GGPO allows you to set your frame delay for example and many will set it to 0 (“less is better!”) and then call it crappy (because they see all the rollbacks, never mind all the gameplay’s technically still right) when setting it to 1 or 2 would hide most of it and not change much for them.
Now while those techniques are known it’s another problem to do them right, there’s a lot of things to enforce in your game’s structure so it plays nice with them and then you want to hide the rollbacks from the player, a science in itself.
And to fix those problems you have to acknowledge them in the first place: if you’ve been following the yatagarasu kickstarter maybe you know they originally were against rollback networking because they feel like they basically don’t need it in japan. Never mind they’re kickstarting for the whole world. That’s a common mindset, it’s not unusual devs make wrong decisions they won’t really notice because they don’t know or test for the complete problem. Or heck, for the longest time it was thought rollback networking would not work at all with fighting game, because the techniques used to hide it in FPS and RTS were unfit for the specific constraints of fighting games. Turns out we just needed different techniques! That does show fighting game networking is still a relatively young field compared to its FPS and RTS brothers though, something to keep in mind.
Thanks for the information all. That was precious reading.
FWIW I think the 3s GGPO implementation is a lot weaker than cps2 and neo geo games. Inputs get dropped a lot even on decent connections. Anti air parrying is definitely more hit and miss.
But it’s still loads better than input lag netcode. If 3s GGPO feels unplayable your only good option is offline. Which is where the game makes sense anyway!
That’s because Ponder didn’t have access to the source code for 3S.
And what was Iron Galaxy’s excuse?
They probably didn’t either, that’s why it’s a port based on the Anniversary Edition.
It was actually based on the Dreamcast version.
It was confirmed not too long ago they used the ps2 version. But, I could have swore that just after release they had said dreamcast version.