hey everyone just a quick simple question …when i pass ACharacter* in an RPC does that mean that the whole class is being transferred across the network? if so isn’t it expensive ? what alternatives are there?
also I’m trying to create a sprinting system any best practices? (using cpp)
Hey,
No in fact this will send only a pointer to the actor you are referencing. Obviously it’s not the same pointer address on the client and on the server machines, but Unreal will figure this out for you.
Just take care if you RPC from the server before an actor has been spawned on the client it can result in nullptr.
You can check Unreal’s network profiler to see howmuch data is passed!
Sprinting is pretty straight forward.
On Input apply the sprint changes locally, then RPC the server to Sprint.
Input → Can I sprint [true]: set max walking speed → RPC Srv Sprint
Srv Sprint: Can I sprint [true]: set max walking speed
Stopping sprint…
Input Release → Am I sprinting?[true]: set max walking speed → RPC Srv Sprint stop
Srv SprintStop: Am I sprinting?[true]: set max walking speed
Make use of enumerators for movement states.
e.g. LocomotionMode[Walking, Jogging, Sprinting]
Setting these states to rep_notify and calling a movement speed function in the OnRep Function you can create a pretty deterministic speed setup.
So instead of directly changing the speed float value in the sprint flow logic, you just set the locomotionmode repnotify. It will execute the pawn movement speed function.
it’s a good system but it has one problem…you can’t change the sprinting speed …say you have different characters or abilities that affect the speed …you can’t do that using that solve
also if I make the client sprint locally and then ask the server to make the client sprint…Wouldn’t I need the server to multicast the sprint to all the other clients? and won’t that make the server correct the sprinting client more often whenever there’s a bit of lag? (it will make the movement feel jittery doesn’t it?)
No issue here. MovementSpeeds are stored in a data table on my end. If I have different characters or abilities, or combos of both I just create multiple data tables.
For example if I have a config var set on the character class I can use that to differentiate between the characters. I’d probably use a multiplier table to handle ability adjustments.
Get character table → get base speed for action → * multiplier → set speed.
This is a standard client-side prediction approach. The character movement component on both first and third player templates uses it. Works very similar. Look it up.
Apply changes locally, RPC server to make “authoritative” changes. Server will correct naturally if its changes differ.
Also, I’m using a Rep_Notify for the LocomotionMode. When the server sets the var it’s replicated over the network. No need for multicast.
The OnRep LocomotionMode function auto executes when the rep_notify var is changed. It’ll process the speed changes auto-magically.
Here’s a rough out of a working setup.
In this process I’m setting the repnotify locally which triggers the onrep function locally. This gets the speed change applied instantly for responsiveness.
Movement and speed changes are buttery smooth across all testing thresholds. 500ms pings, 10% loss etc.
The server will not make a correction until it receives data from the owning client. It doesn’t know anything changed.
The client, nor server sends an individual packet per rpc, input. Very common misconception across all game dev communities. Here, Unity, GoDot, Cry Engine etc.
Inputs, RPC’s, RepNotifies etc are buffered and bundled in a single packet for their update duration. Clients and the server send at defined frequencies.
e.g. Say the client → server update frequency is 60Hz. This means every 16.667ms all clients will send an update (packet).
Same applies to the server. 30Hz server tick means a NetFlush is executed every 33.333ms.
This reduces network saturation.
If you want prediction to work properly you need to extend the CharacterMovementComponent rather than simply changing the walk speed on the fly.
For client authoritative movement or simple movement it might work most of the time just changing the walk speed but when you get some complex interactions it starts to fall apart and server corrections start to happen often.
The Character Movement Component is complicated to look at but there is a lot of helpful information out there that makes it a lot easier to implement your own movement modes like sprinting.
If you want prediction to work properly you need to extend the CharacterMovementComponent rather than simply changing the walk speed on the fly.
For client authoritative movement or simple movement it might work most of the time just changing the walk speed but when you get some complex interactions it starts to fall apart and server corrections start to happen often.The Character Movement Component is complicated to look at but there is a lot of helpful information out there that makes it a lot easier to implement your own movement modes like sprinting.
Totally agree with implementing in CMC. Although, even in CMC you’ll be changing walk speed on the fly. You can, for the most part, duplicate the logic flow of Crouch/UnCrouch in CMC for a basic Sprint.
What I’m doing with my project is a lot more advanced than a basic sprint. At the moment there’s 21 state based speeds. Each combination has an effect on character movement speed.
Then there’s Swimming and Flying states/modes to contend with.
Flushing out the complete setup in BP, then eventually translating to CMC or more than likely a new class ADV_CMC and building a new character class on top of and extending. At which point repnotify process won’t be needed.
ATM, it’s a state/mode switch flow process.
Demo of it in action.
I haven’t added crouch animations yet, so I’m rendering the capsule to show crouch state.
