Training Livestream - Understanding Replication in UE4 - March 21 - Live from Epic HQ

WHAT

A new presenter is joining the livestream this time to talk about replication! Gerleve, Sr Engine Programmer at Epic Games, is dropping in to break down and explain UE4’s replication. Be ready for some high-level insight and some quick examples about how Epic Games gets multiplayer running. Come by and ask your networking questions live!

WHEN
Tuesday, March 21st @ 2:00PM ET Countdown]

WHERE

WHO
Gerleve - Sr Engine Programmer

Feel free to ask any questions on the topic in the thread below, and remember, while we try to give attention to all inquiries, it’s not always possible to answer’s questions as they come up. This is especially true for off-topic requests, as it’s rather likely that we don’t have the appropriate person around to answer. Thanks for understanding!

?v=hlDWovBcu7E

I don’t know this has been covered in the past, but will you be going over anything about matchmaking and/or maybe how matchmaking works in Paragon? If not, will that be a topic you might cover in a future livestream? Thanks!

Wonderful, now if I can figure out sql I’ll be on my way to making my dreams a reality!

Sr Engine Programmer, you got my full attention! <3

I’d like to hear about replicating physics!

Oooo Multiplayer! This is my jam!

I know this is a training stream - but I do have quite a few questions. I’d also like to draw attention to a few areas that myself and a few others think could be improved.

Question 1:
Not really a question but, a few of us have been piling resources into trying to get a system for replicated PhysX movement with prediction and reconciliation. There’s a big thread here, and I have an open-source GitHub project Here. Obviously this is a huge problem and difficult to tackle, but it’s something lot’s of people have been asking for for a while to do things like properly replicated vehicles and suchlike (UT currently uses client-authority). I’d like to draw attention to this project so that we can hopefully get some information from engine peeps.

Question 2:
Is it possible that in the future, Character Movement Component might be divided up into smaller chunks to make it not only easier to customize - but also easier to adapt for other movement styles? I’ve actually made some progress on this already but it’s a lot of huge engine changes, so it’s probably better for Epic to do something. The end goal would be to have a nice system for replicating PhysX objects with prediction, and non-physX objects with prediction too.

Question 3:
Could it be made possible to send children of structs via RPC’s? In my movement system I have a “master” struct for sending input - and I want children to be able to use the same movement component class but send their own “Input” struct to the Server, without creating Server/Client functions for each struct type.

^^ Most of these are all related to Movement Component features.

Question 4:
Could we at some point have an updated Content Example, which contains C++ code for Matchmaking, Beacons, and using Game and Party sessions. ShooterGame was great but is very out-of-date now, and Unreal Tournament is a huge difficult to follow code base. Beacons and Parties are pretty much entirely undocumented, and those who have figured them out seem unwilling to share their knowledge. Sessions are pretty undocumented too, other than the content examples we have.

Question 5:
Any we can build Dedicated Server .exe’s from a Launcher build anytime soon.

Question 6:
Finally, how the heck does Paragon get away with replicating so many minions - when only a handful of characters or vehicles can usually grind a game to a halt?


I’m away in Iceland this week (!) so I’ll miss the stream, but will catch up when back :smiley:

I can answer a few of these:

No - but some functions do have a little icon for “Client” and “Server” which indicates what kind of function they are. Making them call RPC’s by default also removes a lot of fine-grain control that you need most of the time, and makes it far too easy for newbies to start flooding their bandwidth. UDK was different because it was very one-dimensional, and most people using it were making online character-based games - so the engine could assume lots of things.

PIE Servers and Clients are no different to regular instances as far as the networking layer is concerned. If you tell it to replicate movement, it will replicate position etc, - regardless of connection type (and so long as it exists client and server side).

Doubt it - but a few of us are making progress on that here.

I would love to hear more about the replay system and how it was implemented in paragon.

I think the answer to this question is Oodle Network Compression that is part of Oodle library by RAD tools.

Interesting. I’ve also been told that Minions use a very very simplified movement component, not the full character movement. Be interesting to get some answers.

Generally, anything about compressing bandwidth and good optimization techniques (most of this stuff is C++ only ofc) would be good. RTS games are hard :o

Not just Oodle I guess. If you look at the minions from far (down the lane for example) you can see they dont replicate at all (that is they just stay idle and not attacking at all) unless you get close to them (maybe 3000-4000 units I guess). You might know those settings (IIRC it was something called Network Cull Distance Squared and maybe Network Update Frequency also).

I’ve got a few suggestions for topic matter, that at least from my perspective, would provide a lot of value, especially for developers who’ve recently migrated to UE4.

A CURRENT ( 4.15, 4.15.1 ), ACCURATE, BEST-PRACTICES, walk-through taking us through the design & construction of a basic, yet functional, properly replicated, server-authoritive, multiplayer project setup.

The KEY here is that the setup and architecture of the demo project be validated by Epic’s Senior Engine & Networking Engineers and what is demonstrated is “A” CORRECT application of the core Gameplay classes as they were INTENDED to be used, and a solid little setup of a simple, custom Pawn Actor from scratch ( not a Character from one of the templates ) so that it properly replicates during spawning, input and movement.

If we can get that far, I’d also like to get into implementing our own client-side prediction component for that Pawn, similar to what’s built into the Character movement component but more universal, and of course technical detail on implementing networked physics simulation as and mentioned.

My last suggestion idea would be a walk-through of how to mod the stock VR Template to properly support Multiplayer and Replication. I think quite a few VR developers are going to run into that one…

I know I went through that whole learning curve, and it wasn’t fun, really, it was more like a compound stack of learning curves all at once… As I just finished a crazy deadline to deliver a VR Project that supported cross-platform multiplayer/replication between my GearVR mobile client and my Win64 HTC Vive client… I was researching in circles and digging through all sorts of outdated or incomplete documentation in order to finally break through and get that puppy working.

Anyway, looking forward to the Stream and the discussion.

Thanks!

Would love to know how to replicate child actor components. The Vive motion controllers and Leap motion components don’t seem to replicate even when manually setting transforms

Although may not be covered in this stream, I’d really love to see a simple replicated game that covers the best practices for setting up basic BP replicated movement, health, score and shooting systems (or another mechanic that causes score/health/game state changes) that works for any amount of clients that join a game. These basic mechanics can then be used as a rock solid reference for extending and creating new and more meaningful systems. Right now it seems that a lot of the content is older or no longer available- any fully setup projects aren’t as helpful due to the fact that a lot of the thought process and decision making behind the systems are lost, left for the user to try and figure out. Having a simple game set up as Epic would themselves would be extremely valuable not just for people learning replication, but in general as a good selection of common implementations and the do’s and don’ts associated with them.

ShooterGame is such an excellent content example, but both for people wishing to create BP only networked games and also to have the step by step thought process and reasoning behind each function, I think a new example would go a LONG way. Thanks Epic for doing what you do :slight_smile:

Sounds Awesome! I know a lot of people have been asking about this:

Q: The basic Actor “Replicate Movement” feature (a.k.a. “static mesh replication”) for dynamic PhysX objects in Unreal 4 is pretty much undocumented. It would be awesome to know if there are any config options (DefaultEngine.ini???) to tweak things like maximum distances between client copy and authoritative server copy. An overview of this feature’s capabilities and limitations would be awesome too!

I work on Squad a 100 player game with vehicles.

1 I’d love for them to explain how the gameplay abilities system of paragon allows them to replicate while doing local prediction in order for it to appear with less/no latency (Until the authority disagrees).

2 Additionally I’d love for them to talk about the progress they made with the charactermovementcomponent and if they plan to release any other movement components in 4.16 or later?

What are best practices for managing Client and Server version numbers?

I have a plug-in that uses a client-only and server-only plug-in. So I need two different projects, Client and Server.

I use the same source to build both but when connecting the client to the dedicated server I have invalid version issues.

What process am I supposed to follow for this?

[QUESTION]
Are there any things to keep in mind about replication in terms of making a VR multiplayer game?

Why not use Server module and Client module for your project and add your plugin dependency accordingly? This way the plugin will only be compiled and distributed for that specific target and since you are using the same project you can have same build numbers. I am not sure about your specific workflow but for my project it simply generates a new build number for every compile and I can access it in both server and client so in packaged game I do a HTTP request to check if client is running the same version as of Server. :slight_smile:

I would love to see some discussion/advice on compressing data for physics replication.

Things like not sending velocity and just deriving it from delta position (with a high enough frame rate) and only sending 3 of the 4 elements of a quaternion for rotation.

Any more tips like that would be awesome.