Not the case however, much to my delight. So hurray! Please don't fail to deliver GGPO. This game has an "acceptable" netcode most matches have a noticeable amount of slowdown for me. And I do have a fairly speedy connection. That would be very sad. If your game needs to roll back a large number of frames, once the previous state has been deserialized and loaded, the game must re-simulate all these frames back to the present and then also serialize all of them!
This means your game logic must be independent from everything else in your gameplay loop; you need to be able to run many frames of logic without rendering to the screen, or waiting on the network, or using any number of other systems that normally operate every frame. Because all these things need to be performed in one game frame, in addition to all your normal game loop operations, optimization in general is another key concern. Perhaps those costly CPU cycles that your fancy particle system or cloth simulation uses are now putting you over your performance budget.
Stallone says that MKX, under its old delay-based solution, took only an average of 10ms of its 16ms budget to run a complete frame due to the extra horsepower of the PS4 and Xbox One. When initially switching to a nonoptimal, naive rollback solution, he says the cost to run a frame more than tripled to 32ms , which forced his team to re-evaluate almost every single in-game system and look for performance gains.
Note that any deterministic game can use rollback netcode as long as it is able to save and load game states and perform multiple frames of game logic quickly enough to fit inside its game loop.
To dispel a common myth about rollback, there are no limitations based on the genre of game. Even games like Rocket League incorporate rollback to make online play just as responsive as offline play.
All netcode solutions, whether driven by input delay or rollbacks, must keep both systems running completely in sync.
This means both systems are showing each player the same frame at the same time, or as close to this as possible. Even though most fighting games try to lock the framerate at 60fps, it is not simply enough to sync at the beginning of a match and assume the players will remain in sync for the whole fight.
Many issues outside of networking, such as consoles overheating, computers performing operating system functions, or someone temporarily overloading their CPU, can cause performance drops which will put them out of sync with their opponent.
The consequences of not correcting this sync are catastrophic. Consider a rollback system where player A is being shown frame 20, but player B is being shown frame 23, across a network delay of three frames. Player B will send input for their frame 23 to player A. Because they are on frame 20, the network delay means they will receive the input on their own frame 23, which is just in time to execute it and will not have to roll back at all.
Meanwhile, player A sends their input for frame 20 to player B. With the network delay, player B will receive this input on their own frame 26, which will repeatedly cause lots of very uncomfortable six-frame rollbacks.
Note that this rollback is entirely one-sided; only the player who is ahead of the other will experience the effects of the bad connection. Some fans have even run their own tests and come to similar conclusions. To help illustrate the point even further, Zinac shows the one-sided rollback effect in action using a very simple project designed to teach about the benefits of rollback.
Solving the problem is relatively straightforward. Most rollback systems will briefly pause the player who is ahead for one or two frames so the player who is behind can catch up. If the game keeps on top of this system and never lets the games drift very far apart, the correction will be quick and painless. Note that these pauses are not due to missing input or other networking difficulties; they are designed to fix the fact that different computers will run software at slightly different rates in unpredictable ways, and losing one frame every 10 seconds to maintain the sync is unnoticeable to even the most astute players.
If you spend any time around the fighting game community, you have undoubtedly heard about GGPO , the rollback library that is now free and open source! The main function of GGPO is to provide a robust solution for syncing machines and game states.
For example, GGPO can tell your game when two machines are out of sync, and by how much. What I meant by predicting projectiles would be to do exactly what is done with client side prediction, i. Because this could let a player perform a rocket jump and feel the blast effect immediately instead of having it delayed by whatever lag there is. I did not understand that part. If we agree that a client cant "predict spawn" projectiles of opponents, how is that an issue?
A client would still see on its display whatever entities the server tells him exist. Yes, this would be a problem. We don't have that in shooters. However, just as GGPO adds a fixed number of frame delay to mitigate for this, I believe what is rendered on client side in source is "the past", for the server :.
The way I understand that, all clients are more or less in the past depending on their interp value. So if everyone agrees to be a fixed amount of time in the past, and that amount is great enough to mitigate teleporting projectiles issues, this problem should not arise most of the time.
I believe this is why interp is ms by default as well, if only jumping wasnt so sluggish, and everyone was forced to the same value, there would be no downsides to keeping it.
I think you're fundamentally missing where the prediction happens. The prediction that happens in peer-to-peer rollback is for missing inputs of OTHER players based on the last received input. With two clients, Client A and B, if Client B drops packets it was supposed to send to Client A, rollback netcode takes the last known inputs of Client B that it receives, and Client A then predicts missing data based on that. For rollback to work on a source server setup, the server would have to do that same "prediction" which would most likely just be a movement direction , and then send that prediction to every client except for the one dropping packets.
So the other 11 players would receive predictions from the server and display that, and then once the new inputs are received, they would be retroactively synchronized into the game state. Shifting game state calculations away from the server and onto each individual client is also a theoretical way of implementing that, but when managing a 1 on 1 peer to peer synchronization is already hard enough, you would essentially leave the server with the task of managing a 12 or 18 person way essentially peer to peer connection where if one person's game state is slightly different from the rest the server has to send them corrected data from every other client, which just generates WAY more input delay due to the increased amount of traffic that would be involved.
The 50ms mentioned in the documentation is separate from the ping you have to the server as well afaik, as the server has to receive an initial input lets say at an example 40ms ping , allow the 50ms buffer to receive the next snapshot, and then start allowing clients to render afterwards.
Fighting games don't have this extra rendering delay due to being locked at 60fps, and they simply send an input for each frame. If you set everyone to 50 ping buffer on a server, it doesn't magically make the person at ping send his inputs any faster, and that person will still have to send their inputs and data ms later. In a fighting game, you can cover up that extra delay by interpolating the new animations through the startup frames that are involved in pretty much every action you do.
However in any FPS game, you very rarely have any example of startup, outside of something like switching weapons where you are inactionable.
When you click, your gun shoots immediately , there's no room to interpolate the old action with the new. Rollback means you would have projectiles be spawning halfway through their travel time on people's screens, or have people suddenly teleport halfway into their rocket jump, which already does happen. If the client can only see the entities the server already knows about it can't "predict spawn" its own projectiles either.
They don't add a delay. Note that this is a horrible idea in any game with hitscan weapons. It's not ideal in their case either because you're losing a couple frames worth of reaction time, which was kind of the point of having startup frames instead of the damage starting immediately but there's always drawbacks one way or the other. The whole selling point of their method is that there is no delay to your actions, making it feel just like a local game and the tradeoff is that if prediction fails that is part two of their strategy you get warped to the correct state but as long as prediction is right everything is exactly as it would be in a local game.
Either projectiles spawn instantly locally and teleport for everyone else GGPO, if prediction fails or they appear everywhere at the same time at their actual spawn point which means they guy who pressed the button has to wait until everyone knows about the projectiles before they get to see their own projectile source. You can't have both at the same time. You can treat rng in the same way as player inputs which you can't predict , and the whole problem disappears..
Though it might be technically easier to synchronize the rng by having the server pre-determine the random results before they're needed, ex.
A much bigger problem may be that small hitches in the game's performance seem to have small effects on things like player trajectories. Nah, the server doesnt care about this stuff. What counts is that what is displayed on each client is as smooth and reactive as possible.
Therefore here I am not discussing "shifting away game state calculations to clients", I agree that it's not feasible and pointless. Thats the point of having everyone use the same interp value : everyone would see the prjojectile appear at the same place. The lower the interp, the farther from the shooter the projectile will appear. Hence, with everyone at high interp and playing in the past, the downside of the projectile spawning farther away could be mitigated, as everyone would be rendering frames related to the same tick and have an array of more recent ticks received stored waiting for eventual rollbacks.
So if that array is big enough compared to the connection quality of the worst player, all the netcode shenanigans are resolved before anyone renders the tick, and every client renders the same thing. I am not talking about any delay-based netcode such as what is done in fighting games not using rollback, because that's out for FPS for reasons stated in the valve documentation.
Why not? I believe most of the time when a client requests to spawn an projectile it is allowed to do so. If the client dies after predict spawning a projectile but before the projectile existence is confirmed by the server, then only that dead client will see some kind of visual artifact.
And that client's dead anyway, no big deal. Sure, my question now is, if it's the first case, can you mitigate how much the projectiles teleport by increasing what i believe is named interp, which is delay between what state is computed by server and what state is rendered by clients? Rollback netcode at its root is a delay based netcode system though, only due to the ability to rollback dropped packets they can set a low fixed delay instead of requiring a variable delay in order to ensure the inputs go through properly.
By using inactionable frames, rollback can seamlessly interpolate the old game state with the actual game state. The interp can only account for so much when the person is still ms behind everyone else, unless you also want to force everyone else to play at a noticeably higher input delay. The larger the difference between the interp and the ping, the more rollbacks will occur. Rollback's largest benefit is that it helps deal with packet loss, not general large ping differences like you first mentioned.
Sure your inputs feel like offline, but that doesn't mean the person with ping still isn't laggy as fuck and teleporting fairly often. In Melee, which probably has the most similar pace to TF2, ping 3 frame is barely playable against any mobile character as they start micro teleporting every other movement and you have to try and pin them down.
Since all hit detection occurs server-side, if a client predicts the movement of someone else incorrectly, than they'll simply be shooting at ghosts.
Alternatively if you were to change lag compensation to reflect compensating for false predictions, you would have people getting hit for moving in a way they never did. In the first scenario, a scout will be shooting at the ghost of a soldier who's already rocket jumped, and then have to react to them teleporting and adjust to hit them as they fly towards them much closer. In the latter scenario, a scout will win a 1v1 solely because the other scout dropped a packet and started running in a straight line.
No problem man, if you ever wanna discuss it more I'm down, netcode is a really interesting topic to think about for me. Glad you learned some things from all the talk.
0コメント