Immediately Responsive Scene Objects

Zelek

I am using the NetworkRigidbody script for my CoOp game, where each Player owns their own character object, and the enemies are instantiated as Scene objects. This is working great in general, though one thing I'm trying to figure out is how to make the enemies immediately responsive to Player attacks. I'd like to have "knockback" as the result of an attack, and it just doesn't feel right unless the knockback occurs immediately when the attack connects. What's the best way to handle something like this?

My first thought was to decide whether an attack is going to hit before the animation begins playing, so that there was time for a message to be sent to the enemy scene object. However, this makes dodging attacks impossible, and it's still difficult to sync up the knockback with the attack animation on all clients.

This is obviously a common issue, so I'm just wondering how other people are handling things so I can get an idea of my options. It seems like the attacking client may need to execute the enemy knockback "locally", before the scene object actually does it. However, this would probably be quite difficult to work into the NetworkRigidbody's BufferedState array.

vadim

Did you read NetworkRigidbody related topic
viewtopic.php?f=17&t=2666&p=14084&hilit=NetworkRigidbody#p14084

Zelek

Yes, this is where I got the code from. Are you suggesting that there's some relevant info there I should look at? Perhaps I'm not seeing it.

vadim

Please wait till next week when Tobias will be available.
He can provide more info on NetworkRigidbody.

Zelek

I just wanted to check on this now that Tobias is back. To summarize, I'd like for scene objects (enemies) to immediately change position when attacked by a non-master client. However, the BufferedState system in NetworkRigidbody makes this difficult. Any suggestions on the best approach to avoid a delayed response when a non-master client wants to move a scene object?

Tobias

While this borders on the concept of "concurrent control/ownership", I would try to fake this effect:

You should move the monster locally and immediately. This will mean you accept that the position is temporarily off from what the owner sent.
Actually, the owner will knockback the monster, too, and the position on the other clients will not be too far off.
The tricky part is how to detect when the owner sent a new position that includes the knockback.
Here I would experiment: Ignore 1..x updates by the owner. Implement some "knockback-count" sent by the owner and when this increased in updates, you accept the new position as new "correct" position and lerp towards this. Or you when you send a monster's health, you could check if that's reduced and then accept position updates again (as they likely include the knockback).

Just make sure that the monster's position eventually is correct again (meaning: after a moment, the monster must be at the same position that is being sent by the owner).

I hope that helps.

Zelek

Thanks for the advice, that does help. I was worried it might come to that, since there's a lot of potential for things to go wrong, but maybe that can't be avoided.

Tobias

So far, we didn't find the holy grail of non-lagged networking
If you can define simple rules when your monsters have to get to the assigned places again, you will be fine. Just save any last update you got and after a timeout, move to that last reported position.