![]() ![]() However, this "Lag Compensation" only works for colliders (for now.).Every game involving attacking needs this to feel decent. Our "Lag Compensation" solution will automatically track the history of the victim entities collider(s) (via `PhysicsWorldHistory`) to allow you to check whether or not an owner-predicted, fired projectile would have hit the victim (from the attackers POV).There are a few interesting things happening with "Lag Compensation" in netcode: Faster movements (and faster TTK) leads to worse miss-predictions. Thus, your design philosophy for abilities will drastically change how badly prediction messes with users. You hide the lag by having a slightly longer "ability activation" timer for the caster (who is predicting it) than everyone else, so they resolve "simultaneously".Įxample of an unpredictable interruption: Insta-cast, insta-hit stun spell. Generally speaking: You can predict your own characters movement and abilities, and if you have spells that interrupt those, try to make those interruptions predictable themselves.Įxample of a predictable interruption: Spell cast on ground that'll stun you after X seconds. ![]() Even though we (netcode) do provide a mechanism to predict spawns, we don't predict despawns. if you write the game logic in the `PredictedSimulationSystemGroup`).Įxample of 1): Your client will predict your own blink ability cast, as it's so rare for it to be interrupted.Įxample of 2): Killing an enemy is not predicted, because the implication of a client being wrong about that is devastating for the user. We support both, and you'll get 1) "by default" (i.e. Hey Opeth! It's a combination of 1) and 2) in MOBAs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |