How are rollbacks handled for firing weapons and projectile spawning in Forest Brawl?

[robinreversi]

Hey! Just trying to get a better understanding of some of the Forest Brawl code -- seems like the "fire weapon" detection logic is handled by the brawler-weapon class in the tick function, but a bit confused as to how this would interact with rollback. I'm not very experienced with rollback, but from my understanding since is_firing isn't stored as an Input in the Player's Rollback Synchronizer, isn't it possible that during a rollback, the is_firing variable gets set to false on a previous tick where it was true, and so during the rollback, the "fire weapon" logic doesn't end up running?

I guess thinking about it some more, since there doesn't seem to be logic to despawn the bomb projectile during a rollback, if the input were repeated, then there'd be two instances of the bomb, but then does this mean that if there were some event added that could block the player from firing in the tick they did, the bomb would continue to exist even though the server deems the player shouldn't have been able to fire on that frame?

Thanks for all the help in advance, would love to be able to get a point where I can help contribute as well!

[albertok]

Hey @robinreversi

Great question, it made me curious and start digging. This is my take on it and so I could be completely wrong -

@elementbound explains most of it really well in the docs.

The core of it is here:

When a client fires a weapon if its own checks pass it creates the projectile but also asks the server to confirm.

From here the server will do its own checks and confirm if it was ok to shoot or deny it at which point the client destroys its version and if was allowed the servers version of the projectile spawns and takes over.

Now... Neither weapon nor projectile participate in rollbacks as they don't implement _rollback_tick.
The docs explain that it's likely not ideal to involve a ton of projectiles into the rollback loop.

Basically the weapon fires when it does at the first valid input and there's no correcting that. There's no did Han or Greedo fire first kind of thing, first packet received at server will be actioned if its checks out. As you noticed there's no stun mechanic, the brawlers can always fire if their cooldowns have lapsed.

The projectiles explode on contact again without rollback participation but they don't do damage directly, they emit one of several types of repulse effect which does participate in rollback.

So I guess projectiles explode without re-checks but the explosion itself will confirm if the player was in the blast zone taking into account positional corrections via rollback checks.

Pretty clever!

[robinreversi]

Gotcha, so basically since there's no way to interrupt the fire action, the brawler's input should never be ignored which means there's no reason that the bomb would ever be affected in a rollback tick, so the bomb doesn't need to participate in rollback. That's very helpful, thanks!

I'm working on a project where some of the logic does involve a stun mechanic, so feel free to ignore this question since my original question was answered, but seems like if there were some kind of stun mechanic which could interrupt the brawler's input, you would need to add is_firing to the RollbackSynchronizer Inputs, and then also have the bombs participate in the rollback loop?

I guess I'm imagining a sequence something like this:

t=0

• A sends "A attacks B" to server. B is stunned locally.

t=1

• Server receives "A attacks B", starting a rollback since the input was missed on t=0. B is now stunned on the server.
• Server sends updated state for t=0 to B.
• B sends "B attacks A" to server. Projectile created by B locally.

t=2

• Server receives "B attacks A", but the input is ignored since B is stunned from A's attack.
• B receives updated state for t=0, starting rollback since this is a new authoritative state. B repeats inputs from t=1 as well, and the projectile this time is not created since B is also now stunned on t=0. However, the projectile B created originally before the rollback still remains.

I feel like one solution you might be able to do is:

1. Have projectiles participate in rollback in a similar way the effects do, except that when the current tick is prior to the spawn tick, the projectile should delete itself.
2. Record the is_firing input in the RollbackSynchronizer, so that when the rollback occurs the input is saved for that tick, and the logic will just naturally work from that point, assuming the projectile was despawned properly as well?

Not sure if this is the most effective way though, or if there's some part of rollback I've misunderstood here. Some of my thinking is based around the SpawnManager class in David Snopek's rollback implementation (which doesn't work for non-deterministic games since it's pure rollback without an authoritative server), so it may be a bit off here.

Either way, thanks again for the help!

[robinreversi]

After thinking about it some more, the input wouldn't actually trigger a rollback in the Forest Brawl case since the is_firing input isn't in the RollbackSynchronizer, so actually it seems like maybe this would be okay too? I think the situation would actually read like this:

t=0

• A sends "A attacks B" to server. B is stunned locally.

t=1

• Server receives "A attacks B", validates and forwards to B. B is now stunned on the server. Since this causes a state change, a rollback would also occur (assuming something like is_stunned is now a state in the RollbackSynchronizer) where the server sends the updated state for t=0 out to B.
• B sends "B attacks A" to server. Projectile created by B locally.

t=2

• Server receives "B attacks A", but since the input is not invalid, the server declines the projectile and requests B to delete it.
• B receives updated state for t=0, starting rollback since this is a new authoritative state. Since B is now registered as stunned, regardless of the value of is_firing, B cannot fire. The projectile B created originally will get deleted once the request from the server arrives.

[albertok]

@robinreversi

Yeah, there's a few ways to do it but it seems like you have a good grasp on it and all the compromises it will involve.

A lot of it is trialing and seeing what feels right and fun but is still fair for players.

Sometimes you need to change your game mechanics/rules to better suit a world where nothing is immediately confirmable.

Some games implement a weapon 'warm up effect and delay' to buy them time to confirm they can fire.

Some just instantly fire and favor the shooter based on a small grace period.

Some just do very in your face re-writes of history and take back a fired shots.

[elementbound]

Hi @robinreversi,

I think the important thing here to notice is that weapon firing is not connected to the rollback loop. When the player presses fire, a request is sent to the server and a projectile is created locally at the same time. From here, the server can either confirm and broadcast the firing event ( so that other players can create the projectile too ), or decline it, in which case the original projectile is deleted.

For the stunning mechanic, you can synchronize the stunned flag - so if the player is currently stunned, simply don't allow the weapon to be fired locally. Of course you'd still need to check the stun flag on the server, but in this case you can make the server decline the shot if the player is stunned.

You can implement the above easily by extending the NetworkWeapon2D or NetworkWeapon3D classes from netfox.extras.