A basic doubt about the proposed multiplayer implementation

uem_s04_planning_clientside_prediction

#1

I followed the course so far, focused on the “complete and correct multiplayer implementation”, that is the one who solves all the networking and cheating problems: server authoritative with client prediction, lag mitigation, and so on.
Of course the course (sorry for the pun) so far is very good: very well explained with the right dive-in coding and I’m getting a precious understanding of how a “real multiplayer” should work. But nonetheless it raised a doubt.

In the first section we implemented a very basic multiplayer movement on the moving platforms. It has many defects compared to what we’re implementing in this lecture. But then we already had a “perfect” multiplayer example: the player character! Truth is, the ACharacter class (with its component UCharacterMovementComponent) already implements a very good networking and replication mechanism: indeed in the MovingPlatform game, we didn’t notice any glitch or defect on the player actors (I tried it on a dedicated Linux server deployed in a remote VPS and movements were perfect).
In the official UE4 documentation, in the UCharacterMovementComponent page they state: “Networking is fully implemented, with server-client correction and prediction included.”

So my doubt is: what is the “right” final way to implement replication in UE4? Can we rely on the ACharacter (UCharacterMovementComponent) or we have to do things by ourselves, like we’re studing in this lecture?
Maybe we’re studying them in such details for sake of understanding and knowledge (which is fine and good, IMO) but if this is the case, are we missing something about the “real way” to do things in a real world application developed with UE4 (since proper use of UCharacterMovementComponent is far from trivial)?

I hope @sampattuzzi would be so kind to give an hint about this.

Thanks in advance for any reply.
Cheers,
Fabio


#2

I think I mentioned that in the last section we are implementing a simplified version of what happens in the ACharacter movement. If that movement works for you, that’s great. But if you need something custom like our go-karts then you need to understand the principles and create your own logic.


#3

Thanks for your reply. I missed the mention about the implementation of a simplified ACharacter movement, that would have made things a lot clearer to me, my fault.

For what I’ve read in the official documentation and on other forums, UCharacterMovementComponent can be used only on a ACharacter, that is a very heavy actor class. What if I need a similiar quality of replication (with client prediction) for other scene objects, like AI controlled mobs or dynamic terrain obstacles? It appears UE4 has a very good replication implementation only for the main ACharacter class but when it comes to secondary objects (for which ACharacter would be overkill), there are no good alternatives. Is it possible for a first-class engine?

Anyway, great replication explanation and guided implementation, a must-follow course! :+1:


#4

Yeah, I think the engine is very focused on certain use cases such as character based games. At least that’s what they have the most tools for.