The game is a grid of tiles that can be changed into walls and towers. When a player clicks on a tile actor, they may need to know whether that tile is a tower, a wall etc.
The grid actors variables are all set on the server. But I’m unsure the best way to go about retrieving that information.
Is there an advantage to using a Server RPC to retrieve the tile actor’s “current state” variable and returning to the player’s controller with that information, versus just having that variable set to “replicate” on the tile actor and NOT using a server RPC?
Using the RPC seems more “secure” because I know the player is getting the right information, and I know the player cannot cheat. But, can they cheat if the logic is all client side but the variable is set to replicate? Or, if I just rely on the variable being set to “replicate”, can I trust the tile’s client instance is going to have the “right” variable state in a timely manner?
Thank you for the quick response, that was helpful. I won’t be changing the variable value on the client. I just need to see what the server says it is, and quickly.
Question though. I found another post with some information regarding timing.
Replicated variables while are always reliable, aren’t replicated as fast as possible. They are queued, and replicated in batches at the end of tick.
RPC on the other hand are replicated to clients the moment they are called (doesn’t mean they will arrive faster than variable, though they usually are). You can send data with RPC (as value parameters), but as per usually it won’t work with UObjects only simple data with defined serialization/deserialization. Most native UE types will work out of box. If you have something special, you have to take care of it, yourself.
You should use RPC any time you want to get data to clients, as fast as possible and use replicated variables if you just want to synchronize values or state of object.
It sounds like I should be using RPC if I want the client to have the updated information asap. For instance, the player can “click-drag” multiple tiles to create a wall which I could see issues arising if the logic is not getting a guaranteed accurate current variable.
Though with RPC’s make sure to set them as reliable if you want them a 100% delivered.
The information transfer will always be limited by the network bandwidth. If you eat if up for instance by mistakenly RPCing on tick you can exhaust this resource.
Non reliable RPC’s would be dropped in this case. Not sure about reliable ones, if they are queued for the next packed or not. Haven’t tested it myself but the name does suggest they should arrive if perhaps later.
think of everything the client does as a request, you can click and drag as many tiles as you want and ask the server can create walls here?
this can be done client side so it feels smooth
the server can then verify it and complete the action.
there will be a delay/lag but assuming no one is cheating or tried to access the same tile at the same time it will usually always work, this is where prediction come in if you want to go down that path.
a server RPC wouldnt help as it’d suffer the same delay/lag anyway so best just request and hope
The game is a grid of tiles that can be changed into walls and towers. When a player clicks on a tile actor, they may need to know whether that tile is a tower, a wall etc.
If clients only need to know what something is, then define it in the actor itself.
Create an enum of all the different types of tiles (wall, tower, etc). In each tile actor class add a variable for TileType ( your enum). Set the variable for the class.
When the server spawns it that information will be part of the actor itself and not need replication. You can then easily use a common blueprint interface to locally request the information without having to cast or rpc the server.
The player/controller and the tile actors need to implement the interface.
Then it’s only a matter of creating “PlayerRequest” and “ActorResponse” functions to communicate locally.
