Entity with varying speed
Options
sowee15
✭
in Photon Bolt
Hi,
In my game, player entities can have varying speed when they pick up bonuses. I currently store the speed on the player's state and use it in ExecuteCommand. This results in players jitter when speed changes. I think it has to do with the fact that the server has to replay some commands but it uses the current state's speed instead of the speed at the time of the command (ServerFrame). I could add the speed to the command, but I think it would break the server authoritative movement.
Would it be better to store the player's speed on the server for each ServerFrame for the last 2 seconds or so and then use this in ExecuteCommand ?
Or if there's another way to handle this probably common situation, I'm all ears.
Thanks!
In my game, player entities can have varying speed when they pick up bonuses. I currently store the speed on the player's state and use it in ExecuteCommand. This results in players jitter when speed changes. I think it has to do with the fact that the server has to replay some commands but it uses the current state's speed instead of the speed at the time of the command (ServerFrame). I could add the speed to the command, but I think it would break the server authoritative movement.
Would it be better to store the player's speed on the server for each ServerFrame for the last 2 seconds or so and then use this in ExecuteCommand ?
Or if there's another way to handle this probably common situation, I'm all ears.
Thanks!
0
Best Answers
-
You need to add the speed as a result in your command and change it on reset state just like the position.1
-
Settings the result only matters on the host. The tutorial sample sets it on both but it doesn't matter.1
-
For @sowee15 or anyone curious about the issue, your resetstate is overwriting the speed after the speed boost pickup, it is the classic problem that the client can't predict a server state change.
I would either
a) don't do server auth unless this is really necessary, this looks like a mobile game. Unless you are planning on host dedicated servers it makes no real difference.
b) don't predict speed changes
c) don't run resetstate unless the result from the server has changed (this is a little complicated for a new Bolt user)
1
Answers
-
You need to add the speed as a result in your command and change it on reset state just like the position.1
-
Thanks for the fast reply.
Since ExecuteCommand is also executed on the controller, should I only set the result on the server so it stays authoritative? I currently set the result on the command in ExecuteCommand for both the server and the controller.0 -
Settings the result only matters on the host. The tutorial sample sets it on both but it doesn't matter.1
-
I tried it. I removed the Speed of the state of my player entity and added it to the player movement command's result. Then, in ExecuteCommand, I do this:
if (resetState)
{
// we got a correction from the server, reset (this only runs on the client)
entity.transform.position = cmd.Result.Position;
entity.transform.rotation = cmd.Result.Orientation;
forwardSpeed = cmd.Result.ForwardSpeed;
}
else
{
// apply movement (this runs on both server and client)
DoMovement(cmd.Input.Forward, forwardSpeed, cmd.Input.HitPoint, BoltNetwork.frameDeltaTime);
// copy the motor state to the commands result (this gets sent back to the client)
cmd.Result.Position = entity.transform.position;
cmd.Result.Orientation = entity.transform.rotation;
cmd.Result.ForwardSpeed = forwardSpeed;
}
It is slighty better than before, but there is still a jitter when there is a speed change. Am I missing anything? Thanks!0 -
I sent my project. Thank you for looking at it!0
-
For @sowee15 or anyone curious about the issue, your resetstate is overwriting the speed after the speed boost pickup, it is the classic problem that the client can't predict a server state change.
I would either
a) don't do server auth unless this is really necessary, this looks like a mobile game. Unless you are planning on host dedicated servers it makes no real difference.
b) don't predict speed changes
c) don't run resetstate unless the result from the server has changed (this is a little complicated for a new Bolt user)
1