This is what a 32 player netgame looks like

[chaoloveicemdboy]

Originally Posted by SSNTails

Fantastic news. I was very sad when it turned out 2.1 had broken netcode. It is a big part of SRB2.

Clag isn't going away. SRB2 is a twitch game, like Smash Bros., and I'm sure a lot of you are familiar with the Smash Bros. latency issues. Unlike other games, you can't accurately 'predict' a player's movement, and if the computer guesses wrong, you then have to rollback any interactions and results from those interactions that occurred. Not a simple task.

Me too. I mostly played online in SRB2 back in the 2.0.X days. The sync fails always used to annoy me a lot in 2.1.X.

[Firework917]

This is beautiful, it really is. Wish I was there for it. ;v;
Next time a server like this pops up, I'm pouncing on it.

[CobaltBW]

Originally Posted by SSNTails

Clag isn't going away. SRB2 is a twitch game, like Smash Bros., and I'm sure a lot of you are familiar with the Smash Bros. latency issues.

And just like Smash Bros. latency, it's terrible. If anything I'd say SRB2's issues are way worse due both to small server selection as well as the game's inherent platforming and movement mechanics. Even without bursts of freeze lag, it's hardly what I would consider "playable".

Unlike other games, you can't accurately 'predict' a player's movement, and if the computer guesses wrong, you then have to rollback any interactions and results from those interactions that occurred. Not a simple task.

I guess, but I mean... hasn't it kind of been done before? And it's not that client-to-client is without its own issues, but those issues are dwarfed in comparison to not being able to platform and move correctly.

[Mystic]

Originally Posted by CobaltBW

I guess, but I mean... hasn't it kind of been done before? And it's not that client-to-client is without its own issues, but those issues are dwarfed in comparison to not being able to platform and move correctly.

The thing that always irritated me the most about that is that it's match that it implements, not coop/comp/race, which don't have much direct player interaction to begin with and therefore would work great with predictive netcode. If you don't have to shoot at another player there's no problem at all if they aren't exactly where they appear to be on your end. Those modes would basically feel exactly the same as single player with that kind of netcode.

[SSNTails]

Originally Posted by Mystic

The thing that always irritated me the most about that is that it's match that it implements, not coop/comp/race, which don't have much direct player interaction to begin with and therefore would work great with predictive netcode. If you don't have to shoot at another player there's no problem at all if they aren't exactly where they appear to be on your end. Those modes would basically feel exactly the same as single player with that kind of netcode.

It also probably hilariously breaks in levels that have interaction (i.e., stepping on a switch, pushing an object, etc.). If you have a flat-out static level, sure, it's a whole lot easier to do since the only thing you could possibly interact with are other players.

Best way to think of it is like in time travel movies, where they say 'don't do X or you'll change the way the future turns out!'. The game would have to be 4D to remedy that issue (rewind to any point in time).

[Monster Iestyn]

Ah, SRB2CS takes one back in time. I still remember one time in an SRB2CS CTF server, in Nimbus Ruins in particularly, where the game didn't remove the enemy flag I was holding even after respawning from falling in a death pit, allowing me to easily score a point for my team. That happened at least several times in the same session so I recall.

[Prime 2.0]

Not to mention the way something as simple as oscillating FOFs broke everything. Players standing on thin air in meadow match, anyone?

Mind you, it was still cool as hell, as a custom EXE. Getting to play with people from the other side of the Atlantic was fucking great, and I genuinely hope that it or something like it gets done again so I can have that experience again. It just... didn't come even remotely close to fulfilling the needs of the vanilla game.

[Monster Iestyn]

In related news, we at the dev team are making progress with fixing netgame issues with particular stages. For instance I've now eliminated all issues with the lava falls in ERCZ for joiners, as well as the electric barrier for Brak Eggman himself disappearing for joiners. toaster has also made a fix for Eggscalibur's spikeballs in CEZ3 ending up underground for joiners. Our netcode is slowly getting more stable, can you believe it? \o/

No idea about issues with any other stages yet, if we knew of any particular points in maps where things consistently start going wrong then we can do something about them.

[Steelie]

What are the chances it'll break again after 2.2 rolls in?

[RomioTheBadass]

Depends on the netcode i suppose, The less new engine (specifically mapping and modding) features the better lol.

[fickleheart]

Originally Posted by SSNTails

Clag isn't going away. SRB2 is a twitch game, like Smash Bros., and I'm sure a lot of you are familiar with the Smash Bros. latency issues. Unlike other games, you can't accurately 'predict' a player's movement, and if the computer guesses wrong, you then have to rollback any interactions and results from those interactions that occurred. Not a simple task.

The difference is Smash Bros is a fighting game, where direct player-to-player interaction is the entire game. Fighting games are built on precise frame-level timings, where one player's movement is entirely dependent on what the other players are doing, and attempting to predict movement will throw off every last one of the mechanics the game is built around.

SRB2, even though it may be fast-paced, is much less reliant on those sorts of interactions. Players phase through each other, and the only interaction in ringslinger gametypes is through slow, predictable projectiles. Predictions would still be fairly accurate at a low enough ping (and high pings can still be adjusted for), but more importantly a wrong prediction has much less impact on the game, since shot resolution can recognize the chance of inaccuracy and adjust. There's no "rewinding" required: you'll basically take damage when the server says you take damage, unless you're allowed to opt into taking damage and tell the server that. (If that prediction is wrong? Sorry, but you'll just have to live with it.) They'll bounce back later than they would've in the current netcode, but that still doesn't affect the game's state much.

As far as level geometry moving, just add some reasonable interpolation between known states and run the thinker slightly faster to catch up if it's way behind for some reason. Player positions can be latched to moving platforms when you know they're on the ground, and each client's map possibly being in slightly different positions - again - doesn't affect the game's state enough to be worth worrying over.

A good comparison that comes to my mind is Splatoon. Like SRB2's ringslinger modes, it's a momentum-based game where shots have position and velocity and players are constantly ducking and weaving around each other. Splatoon does, admittedly, have hiccups where shots don't always register how you'd like them to, but you still have fairly smooth interactions in that game even with the player-controlled moving platforms in Ancho-V.

Now, don't get me wrong; nobody's working on this right now. But it's absolutely technically possible to redo SRB2's netcode and remove control lag. The problem is the lack of motivated manpower.

[SSNTails]

Originally Posted by RedEnchilada

As far as level geometry moving, just add some reasonable interpolation between known states and run the thinker slightly faster to catch up if it's way behind for some reason. Player positions can be latched to moving platforms when you know they're on the ground, and each client's map possibly being in slightly different positions - again - doesn't affect the game's state enough to be worth worrying over.

No, it absolutely is a very huge problem. What you described is not what I'm talking about. Say a player is desynced/lagged, and jumps on a switch to trigger a script. That runs the script, doing a series of actions that could be any number of things, such as spawning a thinker to move the ceiling of that sector to 'open the door'. When the lag catches up, it's determined that the player really DIDN'T jump on that switch. So now you not only have to remove the script, you also have to REWIND all of the actions that script took, including removing the ceiling mover thinker, putting the ceiling sector height back to where it was, and if it's a complex script, how are you going to track and trace and rewind every action it's taken?

At least in Smash Bros, the levels are fairly static. But player interaction is of utmost importance. In SRB2, player interaction isn't nearly as important, like you said, but a player can trigger any sequence of events at any time that can be very difficult to correct in a sync.

It's not gonna happen. The best we'll probably be able to do is Quake3-like lag control, where you think you dodged a bullet, but then the server says "no, you actually were right in the line of fire", and take damage. I'm not sure if that's better than eliminating the clag.

Really, our best ally is the constantly-improving Internet. Back in 2001 I was able to host up to 10 people, running the server on a T3 (!). Now a lot of people have FiOS or similar services at home, with dramatically less latency. We used to do all of this on a dialup modem with 150ms ping.

[RomioTheBadass]

Originally Posted by Mr. Mystery

Rare footage of too many (real) people in this clown car of a game for the scoreboard to display

The Scoreboard needs to be updated anyway, It doesn't show more than 18 Players on list, and doesn't show number of tokens found like it does in SP Mode, Sometimes it even fails to display the correct Scores for players on some modes (commonly Tag).

[Mystic]

Originally Posted by SSNTails

No, it absolutely is a very huge problem. What you described is not what I'm talking about. Say a player is desynced/lagged, and jumps on a switch to trigger a script. That runs the script, doing a series of actions that could be any number of things, such as spawning a thinker to move the ceiling of that sector to 'open the door'. When the lag catches up, it's determined that the player really DIDN'T jump on that switch. So now you not only have to remove the script, you also have to REWIND all of the actions that script took, including removing the ceiling mover thinker, putting the ceiling sector height back to where it was, and if it's a complex script, how are you going to track and trace and rewind every action it's taken?

Not saying that doing that type of netcode isn't hard, but couldn't the script wait for authorization from the server that he stepped on it before activating? That's way easier than trying to rewind things that have already happened.

[Prime 2.0]

Originally Posted by Mystic

Not saying that doing that type of netcode isn't hard, but couldn't the script wait for authorization from the server that he stepped on it before activating? That's way easier than trying to rewind things that have already happened.

Think about that in the abstract though, especially with stuff like Lua. If complex scripted events have to wait on server confirmation, that means everything has to wait on that, every time - after all, you'd have to rewind back to when the script SHOULD have triggered if you just kept going until confirmation arrived, and that's the same problem all over again. A script can stop a series of complex actors just as easily as it can activate them, after all.

Now picture that "stop everything until script activation confirmed" issue being applied to custom character abilities. After all, a lua-based effect, even one tied to a player double-jumping, can do anything a button in a level can, so it would have to be subject to the same restrictions. Now you have the game stuttering on you constantly, every time you use your special ability... and then having to move forward to catch up with other people who were not frozen at that specific moment, but who none-the-less are also going through that but at different times...

And, well, that's ignoring that you'd need to rewind everything anyways unless all the clients were in synch and all halted at the same time to wait for authorization, because of the aforementioned "button can stop complex actors which otherwise have to be rewinded" issue. So now anything that triggers an authorization cycle, done by any player, causes the netgame to pause for every player.

It would be a clusterfuck.

[Jellybones]

Hopefully this leads to more improvements. I really miss the larger netgames of 1.09.

[fickleheart]

Originally Posted by SSNTails

No, it absolutely is a very huge problem. What you described is not what I'm talking about. Say a player is desynced/lagged, and jumps on a switch to trigger a script. That runs the script, doing a series of actions that could be any number of things, such as spawning a thinker to move the ceiling of that sector to 'open the door'. When the lag catches up, it's determined that the player really DIDN'T jump on that switch. So now you not only have to remove the script, you also have to REWIND all of the actions that script took, including removing the ceiling mover thinker, putting the ceiling sector height back to where it was, and if it's a complex script, how are you going to track and trace and rewind every action it's taken?

Mystic's right on the money. The server would be the one deciding when those kinds of actions take place.

Originally Posted by Prime 2.0

Think about that in the abstract though, especially with stuff like Lua. If complex scripted events have to wait on server confirmation, that means everything has to wait on that, every time - after all, you'd have to rewind back to when the script SHOULD have triggered if you just kept going until confirmation arrived, and that's the same problem all over again. A script can stop a series of complex actors just as easily as it can activate them, after all.

You guys are both thinking about this the wrong way. Of course the current logic of all actions being equal wouldn't work for a proper netcode rewrite. The whole reason such a concept works in other games is because actions are split into server actions and client actions.

A server action would be something like "stepping on this button causes that platform moves to a specific location" or "this door opens somewhere in the level while I play unfitting music". Things that don't belong to a specific player would fall under this role. Those would be the things that the server would have to tell each client to do. Now, yes, this means if you step on a button, it will take a certain amount of time based on your ping before the door opens, but that's the tradeoff you have to make with netcode.

Something like a player ability, on the other hand, would be a client action. Since it's important for the player to see their action happen as soon as they do it, they'll perform their butterfly spawning or projectile launching or whatever on their own, and at the same time tell the server what they did and when they did it, so that the server can get the other clients up to speed. If they need to do a server action, like open a door or destroy a level-owned enemy, they'll give the server a request to perform that action and wait for its approval before doing it. This is the exact kind of logic I applied earlier for the specific case of ringslinger shots; the concept of client actions vs server actions vs client requests for server actions is what allows such a thing to happen. That concept is the backbone of this sort of netcode, actually; without it, everything including player movement would be managed by the server and sent back to the clients, which... is exactly what we have now!

Like I already said, no rewinding is required. If a prediction is wrong, the game deals with it and lets it happen. Game state will bring the clients back into sync, and everything will be fine. Thinking about things in terms of "every client must be absolutely sure they're doing things right" is the exact opposite mentality you have to have for good netcode in platformers.

[Superjustinbros]

Well I'm glad the future of SRB2 multiplayer is looking up- it was always fun playing with others when I first did net games in 2013.

[Boo]

Originally Posted by Monster Iestyn

In related news, we at the dev team are making progress with fixing netgame issues with particular stages. For instance I've now eliminated all issues with the lava falls in ERCZ for joiners, as well as the electric barrier for Brak Eggman himself disappearing for joiners. toaster has also made a fix for Eggscalibur's spikeballs in CEZ3 ending up underground for joiners. Our netcode is slowly getting more stable, can you believe it? \o/

No idea about issues with any other stages yet, if we knew of any particular points in maps where things consistently start going wrong then we can do something about them.

Well, Some stages the lag Gets higher, and some stages the lag gets lower.
The ping lowers or gets higher sometimes depending on the stage. But its good to hear that our future netcode is getting Stable.

Good work DevTeam, Keep it up!

[shellyyeet]

Originally Posted by Boo

Well, Some stages the lag Gets higher, and some stages the lag gets lower.
The ping lowers or gets higher sometimes depending on the stage. But its good to hear that our future netcode is getting Stable.

Good work DevTeam, Keep it up!

Basically, if this is real life, sometimes you'd mildly twitch, and in SOME places, you'd become the goat from Goat Simulator.